The monitoring problem most businesses ignore
Most Belgian businesses have some form of perimeter security. A firewall. An endpoint protection tool. Maybe a SIEM their IT team deployed a few years ago and has been slowly falling behind on ever since.
What they do not have is anyone watching.
Attackers rarely announce themselves. The typical intrusion dwell time — the gap between when an attacker gets in and when anyone notices — is measured in days or weeks, not hours. During that window, access gets established, data gets mapped, and the groundwork gets laid for whatever comes next. By the time an alert fires, the attacker may have been sitting quietly in your environment for a month.
This is the problem managed detection and response is designed to solve.
What MDR actually is
MDR is a security service that combines continuous threat monitoring with active incident response.
The key distinction from other security services is the response half. A lot of what is sold in the managed security space is monitoring-only: someone receives your logs, checks for alerts, and calls you when something looks wrong. MDR goes a step further. When a threat is confirmed, the response is handled — containment, isolation, investigation — not just escalated.
In practical terms, a good MDR service includes:
24/7 monitoring. Security analysts watching your environment around the clock. Not a ticketing system that pages someone when an alert threshold is crossed. Actual human analysts working shifts, with the context to distinguish a genuine attack from a noisy endpoint.
SIEM and log aggregation. All your logs — endpoints, network, cloud, identity — flowing into a central platform where correlation happens at scale. Individual events rarely tell you much. Patterns across sources often do.
EDR (Endpoint Detection and Response). Agent-based software on your endpoints that records what processes run, what files they touch, what network connections they make. This is the telemetry that makes post-incident investigation possible, and it is what separates modern MDR from old-school antivirus.
Threat hunting. Analysts proactively searching for indicators of compromise that automated detection missed. Not every attacker trips a detection rule. Experienced analysts look for the quiet anomalies — the lateral movement that looks almost like normal IT activity, the persistence mechanism that blends into startup processes.
Incident response. When a confirmed threat is found, the MDR provider contains it. This means isolating affected systems, blocking malicious activity, preserving evidence, and working with you through remediation. Some providers handle this entirely remotely; others can deploy on-site when needed.
Why most businesses cannot run this themselves
A properly staffed SOC — Security Operations Centre — requires multiple shifts of analysts, a platform engineer or two to keep the tooling running, threat intelligence feeds, and senior capacity to handle escalations. You are looking at six to ten people minimum for round-the-clock coverage, plus tooling costs and ongoing training.
For a mid-sized Belgian company with a five-person IT team, this is not a realistic option. The economics do not work. The talent market is tight. And the threat landscape does not slow down while you are hiring.
This is not a criticism of in-house IT teams — it is just the reality of what continuous security monitoring actually requires to function. Most organizations below enterprise scale are better served by buying this capability than building it.
MDR vs the alternatives
MSSP (Managed Security Service Provider). Traditional MSSPs typically offer monitoring and alerting, then hand incident response back to you. They will tell you something is wrong; what you do about it is your problem. This was the model before MDR and it still exists. Whether it is enough depends on whether your internal team can actually respond when the call comes at 2am.
In-house SOC. If you have the resources, an internal team has advantages: deep knowledge of your environment, full control over tooling and process, and faster integration with the rest of IT. The costs and talent requirements are real, though. Most organizations that run effective in-house SOCs are large enterprises.
EDR-only. Deploying an endpoint detection tool without analyst coverage is like installing an alarm system and turning off the monitoring. The tool will fire when something happens. Whether anyone acts on it in time is a different question.
MDR. You get the analyst coverage, the tooling, and the response capability without building and staffing it yourself. The tradeoff is that an external provider will never know your environment as well as an internal team. Good MDR providers invest in understanding your environment during onboarding and maintain that context over time. Bad ones treat every customer identically.
What NIS2 means for your monitoring obligations
If your organization falls under NIS2 — and from October 2024, that scope expanded significantly in Belgium — you have legal obligations around incident detection and reporting.
NIS2 requires that incidents meeting certain criteria be reported to the relevant authority within 72 hours of discovery. That obligation creates a practical problem: if you have no continuous monitoring capability, you may not discover an incident until days after it happened, compressing an already short reporting window to nearly nothing.
Beyond reporting, NIS2 requires that organizations implement appropriate technical measures to detect and respond to incidents. While the directive does not mandate any specific technology, continuous monitoring is the standard interpretation of what “appropriate” looks like for most organizations in scope.
MDR does not guarantee NIS2 compliance — compliance is broader than monitoring. But adequate security monitoring is a necessary component of it, and MDR is how most mid-sized organizations achieve that component without building an internal SOC.
What to look for in an MDR provider
Not all MDR is the same. A few things worth examining before you commit:
Response capability, not just monitoring. Ask specifically what happens when a threat is confirmed. Is the provider authorized to contain affected systems on your behalf? What does containment look like for cloud workloads versus on-premise endpoints? If the answer involves a lot of “we will notify you and you take it from there,” that is closer to MSSP than MDR.
Visibility into your environment. An MDR provider that does not understand your architecture cannot effectively monitor it. Look for a proper onboarding process that documents your critical assets, normal traffic patterns, and known-good behavior. This is what makes signal meaningful and reduces alert noise.
Analyst quality. The technology is table stakes. The people doing the analysis matter more than most providers will admit. Ask about analyst experience levels, escalation procedures, and whether your organization gets a dedicated contact or goes into a shared queue.
Transparency. You should know what is happening in your environment. Regular reporting, clear incident timelines, and access to your own data are reasonable expectations. Providers who are vague about what they detected, when, and how should raise flags.
Belgian and European context. Threat intelligence that is relevant to your region and sector matters. The regulatory context you operate under — NIS2, GDPR, DORA if you are in financial services — should inform how incidents are handled and documented.
MDR as part of a security programme
MDR addresses the detection and response side of security. It does not replace the need to know what your attack surface looks like in the first place.
Organizations with mature security programmes typically run both: regular penetration testing to find and fix vulnerabilities before attackers exploit them, and MDR to catch the things that slip through. The two capabilities inform each other. Findings from a penetration test shape what the MDR team prioritizes in monitoring. Incidents detected through MDR surface gaps that go onto the remediation backlog.
Running one without the other leaves a predictable blind spot. Testing without monitoring means you fix known issues but remain unaware when new ones are exploited. Monitoring without testing means you are watching an environment with weaknesses you could have identified and addressed.
If you are evaluating managed detection and response for your organization, TSO’s MDR service covers continuous monitoring, threat hunting, and incident response for Belgian and European businesses. We work with organizations that need credible 24/7 security coverage without building an internal SOC.
If you are not sure where to start, get in touch — we can assess what your environment actually needs rather than sell you what fits a standard package.