The Problem With Waiting to Be Told
Most cyberattacks do not announce themselves. An adversary who has gained a foothold in your network has every incentive to move quietly, escalate privileges gradually, and reach their objective before anyone notices. By the time a ransomware note appears on screen, the attacker may have been present for days or weeks. The breach was not silent — there were signals throughout. The problem was that no one was watching, or those watching did not know what they were looking at.
This is the core problem that a Security Operations Centre (SOC) and Managed Detection and Response (MDR) service exist to solve. They are not just about deploying better technology. They are about having skilled people monitoring your environment continuously, knowing what normal looks like, and being able to distinguish a genuine threat from background noise — and then doing something about it quickly.
For Luxembourg SMEs, that proposition raises an immediate question: can we build this ourselves, or should we buy it? The answer matters more than ever now that NIS2 has raised the bar on incident detection and reporting across the country.
What a SOC Actually Does
The term Security Operations Centre covers a wide range of capabilities, but in practice a functioning SOC performs five core activities.
24/7 Monitoring
Threats do not respect business hours. Attackers frequently time their most disruptive actions — deploying ransomware, exfiltrating data, destroying backups — for nights, weekends, and public holidays, precisely because internal IT teams are not watching. A SOC provides continuous visibility: logs, alerts, and telemetry from across your environment are ingested, correlated, and reviewed around the clock.
Detection Engineering
Raw log data is not useful on its own. Detection engineering is the discipline of writing, tuning, and maintaining the rules, queries, and machine-learning models that convert events into actionable alerts. Good detection engineering reduces false positives (alerts that waste analyst time) and false negatives (genuine threats that generate no alert). It requires deep knowledge of attacker techniques, your specific environment, and the tools in your stack. It is a specialist skill that needs constant updating as the threat landscape shifts.
Triage and Investigation
When an alert fires, a SOC analyst assesses it: is this a genuine threat or a benign activity that matches a rule? Triage involves pulling correlated evidence — endpoint telemetry, network flows, authentication logs, email headers — and making a rapid judgment. If the alert is confirmed as a true positive, the investigation deepens: what is the scope of compromise, what systems are affected, and what did the attacker do?
Threat Hunting
Detection rules catch what you have already defined. Threat hunting is the proactive search for attacker behaviour that has not yet triggered an alert. Hunters form hypotheses based on threat intelligence and known attacker techniques, then search your environment for evidence of those behaviours. It is how sophisticated, low-and-slow attacks get uncovered before they reach their objective.
Incident Response
When a confirmed incident is identified, the SOC coordinates the response: isolating affected systems, preserving forensic evidence, eradicating the threat, and restoring normal operations. In an MDR model, the provider typically has both the authority and the tooling to take direct containment action — not just to advise.
MDR Versus MSSP: A Distinction Worth Making
The market uses several overlapping terms. A Managed Security Service Provider (MSSP) traditionally offered monitoring and alerting — ingesting your logs, generating reports, and passing alerts to your team. An MDR provider goes further: they do not just alert, they respond. They have endpoint agents that allow direct containment actions, analysts who investigate rather than simply triage, and accountability for outcomes rather than just process.
In practice, the line has blurred. Some MSSPs now offer response capabilities, and some MDR providers are closer to the old MSSP model than their marketing suggests. What matters is the substance: when an incident occurs, who does what, and how quickly?
The Build-vs-Buy Decision for SMEs
The honest answer for most Luxembourg SMEs is that building a capable in-house SOC is not feasible — not because of a lack of ambition, but because of structural realities.
The Staffing Reality
A minimal 24/7 SOC requires at least six to eight analysts to cover shifts, allow for leave, and maintain operational continuity. Each analyst must have the skills to perform triage, investigate incidents, and escalate correctly. Senior analysts and detection engineers — the people who write the rules and hunt for threats — are considerably more experienced and costly. In Luxembourg, where the cybersecurity talent pool is limited and competition from financial institutions and EU bodies is intense, hiring and retaining this team is genuinely difficult regardless of budget.
Beyond raw headcount, a SOC needs a platform: a Security Information and Event Management (SIEM) system to collect and correlate logs, an Endpoint Detection and Response (EDR) solution deployed across your estate, and typically a Security Orchestration, Automation and Response (SOAR) platform to manage workflows. Each of these requires deployment, tuning, and ongoing maintenance — specialist work that is separate from the act of monitoring.
The Cost Reality
When you aggregate staff costs, tooling licences, training, and infrastructure, the total cost of a credible in-house SOC is substantial — typically well beyond what an SME with fewer than a few hundred employees can justify, especially when that capability sits largely idle during quiet periods. An MDR engagement converts that large, fixed cost into a predictable monthly or annual fee, shared across the provider's entire client base.
This does not mean outsourcing is always cheaper in absolute terms for every conceivable scenario. For large enterprises with complex environments and strong hiring capability, in-house can be the right answer. For the typical Luxembourg SME — fifty to a few hundred employees, operating in a regulated sector, with a small IT team — the economics almost always favour a managed service.
What You Give Up
Outsourcing is not without trade-offs. A provider's analysts are not embedded in your business; they know your environment through telemetry, not proximity. Context about an unusual but legitimate business process may need to be communicated during onboarding and updated as your operations evolve. Co-managed models, where your internal team retains visibility and participates in the SOC alongside the provider's analysts, can address much of this concern.
What to Expect From an MDR Engagement
Onboarding
A responsible MDR engagement begins with an onboarding phase, typically lasting several weeks. During this period, the provider deploys endpoint agents across your estate, configures log collection from your key sources — Active Directory, firewalls, VPN, cloud environments, email gateway — and establishes a baseline of normal behaviour for your environment. The onboarding phase is also when you define escalation paths: who in your organisation receives alerts at what severity level, how the provider should contact your team out of hours, and what actions the provider is authorised to take autonomously versus which require your approval.
Telemetry and Log Sources
The value of an MDR service depends entirely on the quality and breadth of telemetry it receives. Core sources typically include endpoint telemetry (from EDR agents on workstations and servers), identity and authentication logs (Active Directory, Azure AD, Entra ID), network flow data, firewall and proxy logs, cloud platform logs (Microsoft 365, AWS CloudTrail, Azure Monitor), and email security events. The more visibility the provider has, the more effective detection becomes. A provider who cannot ingest your cloud environment or who only sees a subset of your endpoints is operating with blind spots.
Service Level Agreements
SLAs define what you are buying. Key metrics to scrutinise include the mean time to detect (the point at which a genuine threat is identified), mean time to respond (when containment action begins), and escalation timelines by severity. Critical incidents — active ransomware deployment, confirmed data exfiltration, compromised domain administrator accounts — should trigger immediate escalation and response, measured in minutes. Lower-severity findings may operate on longer timelines. Understand what "24/7 coverage" actually means: does it include threat hunting and active investigation, or only alert triage?
Escalation and Communication
When a confirmed incident occurs, the escalation process should be clear and practised. You should receive a structured notification that tells you: what happened, which systems are affected, what containment actions have been taken or are recommended, and what you need to do next. Ambiguous or overly technical escalation communications that require you to interpret raw log data yourself are a red flag. The provider's role is to translate technical findings into actionable decisions for your team.
MDR and NIS2: The Reporting Clock
For Luxembourg organisations in scope of NIS2, the incident reporting timeline is demanding: a 24-hour early warning to the competent authority (ILR — Institut Luxembourgeois de Régulation) after becoming aware of a significant incident, followed by a full incident notification within 72 hours, and a final report within one month. The 24-hour early warning in particular requires that you know about an incident very quickly after it occurs — ideally before significant damage has been done.
This is where continuous monitoring becomes a compliance asset, not just a security one. An MDR provider who detects an intrusion in its early stages and escalates to your team gives you time to assess severity, determine whether the NIS2 reporting threshold has been crossed, and submit the early warning within the required window. A company relying on reactive discovery — noticing something is wrong when systems start failing — may already be outside the reporting window before they have begun to understand what happened.
A good MDR provider will assist with the factual elements of incident notification: what happened, when it was detected, what systems were affected, and what steps were taken. They will not make the regulatory decision for you — that remains with your management — but they provide the evidence base you need to meet your reporting obligations accurately and on time. CIRCL (Computer Incident Response Center Luxembourg) remains an important national resource for incident response coordination and threat intelligence, and your MDR provider should be capable of liaising with CIRCL where appropriate.
NIS2 reporting in brief: 24 hours — early warning to ILR; 72 hours — full notification including initial assessment of severity, scope, and indicators of compromise; 1 month — final report with root cause, mitigation measures, and cross-border impact where applicable. These timelines start from the point at which your organisation becomes aware of a significant incident, not from when the breach occurred.
Evaluating a Provider: What to Look For
The MDR market ranges from genuine, deeply capable services to rebranded alert-forwarding tools with a 24/7 label attached. Here is how to tell the difference.
Coverage and Tooling
Assess what the provider actually monitors. Do they deploy their own EDR, or do they work with your existing tools? Can they ingest all of your log sources, including cloud platforms and SaaS applications you rely on? A provider who requires you to replace all your security tooling with their proprietary stack may be creating unnecessary switching costs; conversely, a provider who cannot integrate with common platforms may leave critical blind spots.
Detection Capability
Ask the provider how they develop and maintain their detection rules. Are these generic, off-the-shelf rules applied to every client, or are they tuned to your environment over time? What threat intelligence sources do they use, and how quickly are new techniques incorporated into detection logic? A provider who cannot explain their detection methodology in concrete terms is unlikely to catch sophisticated threats.
Response Authority
Clarify exactly what the provider can do without waiting for your approval. In the minutes following a ransomware deployment, the difference between a provider who can isolate an endpoint immediately and one who must wait for a phone call to be answered can be the difference between a contained incident and a full-scale outage. Define the response playbooks and authorisation levels before you sign.
Transparency and Reporting
You should have continuous access to your own telemetry and alert history, not just periodic PDF reports. A provider who keeps your data in a black box you cannot query is not a partner — they are a vendor with limited accountability. Look for a portal or dashboard that gives your team real visibility into what is being monitored and what has been detected.
Local Presence and Context
Luxembourg has specific regulatory obligations, a particular threat landscape driven by its concentration of financial institutions and EU bodies, and communication that often crosses language and legal boundaries. A provider with genuine local presence — people who understand the regulatory environment, can engage with ILR and CIRCL, and can be physically present during a major incident if needed — offers capabilities that a purely remote, globalised operation cannot fully replicate.
Co-Managed Options
Fully managed and fully in-house are not the only choices. Many providers offer co-managed SOC models where your internal team retains access to the SIEM and participates in investigations, while the provider handles 24/7 coverage and supplies senior expertise for complex incidents. This model suits organisations that have some security capability in-house but cannot sustain round-the-clock operations. It also reduces the knowledge dependency on a single external provider — your team remains engaged with the environment rather than becoming entirely dependent on the outsourced service.
Questions to Ask a Provider Before You Commit
- What is your mean time to detect and mean time to respond, and how are these measured across your client base? Ask for evidence, not just claims.
- What telemetry sources do you require, and which do you support? Map this against your actual environment before signing.
- What does your onboarding process look like, and what is a realistic timeline to reach full operational coverage?
- What actions can your analysts take autonomously versus what requires our approval? Review the response playbooks in detail.
- Do we retain access to our own log data and alert history? What happens to our data if we terminate the contract?
- How do you handle false positives, and what is your process for tuning detections to reduce alert fatigue?
- Do you have experience supporting NIS2 incident notification in Luxembourg specifically? Can you assist in compiling the factual content of notifications to ILR?
- Do you offer a co-managed model, and what does that look like in practice?
- What threat intelligence feeds do you use, and how do they inform your detection engineering?
- Can you provide references from clients of comparable size and sector in Luxembourg or the wider EU?
Getting Started: A Practical Approach
If you are evaluating MDR for the first time, resist the temptation to issue an RFP immediately. The quality of responses you receive will be heavily influenced by how well you understand your own environment and requirements.
Start by mapping your critical assets: which systems, if compromised, would cause the most damage to your operations? Which data, if exfiltrated, would trigger a regulatory or reputational crisis? This asset mapping will help you scope the engagement and evaluate whether a provider's proposed coverage actually addresses your real risks.
Next, assess your current telemetry. What logs are you already collecting? What EDR coverage do you have? Understanding your current state helps you have an informed conversation with providers about what onboarding will require and what gaps exist.
Finally, involve your management team early. MDR is not purely a technical decision. The response authority provisions, the escalation procedures, and the regulatory reporting support elements all have governance implications that require management sign-off. In the context of NIS2, where management bodies are personally accountable for cybersecurity risk management, this conversation belongs at the board level.
How ObsidianCorps Approaches Security Operations
We work with Luxembourg SMEs on the full spectrum of security operations challenges — from assessing whether MDR is the right fit for a given organisation, to helping design the governance framework around a managed service, to providing incident response support when things go wrong. We are deliberately vendor-neutral in our advisory work: our job is to help you find the right service for your environment and your risk profile, not to steer you toward a predetermined answer.
If you are trying to understand your options, prepare for a provider evaluation, or work through how MDR fits into your broader NIS2 compliance programme, we are glad to help. The goal is continuous visibility, credible response capability, and the confidence that when something happens — not if — your organisation is equipped to contain it and communicate about it within the timelines the law requires.
