Managed SOC and MDR: 24/7 detection and response

Managed SOC, MDR, SOC as a service: what we are talking about

A managed SOC is a Security Operations Center you don't build in-house: a partner runs it, with its own people, its own processes and a platform that collects the logs from your infrastructure. The outcome you buy is simple to state: someone spots an attack, verifies that it is real, contains it and explains what happened, at any hour.

The acronyms you find in proposals describe the same model from different angles:

• SOC as a service puts the emphasis on the contract: the operations centre becomes a subscription service.
• MDR, Managed Detection and Response, puts the emphasis on the outcome: detection and response that work, not a console to watch.
• Managed cybersecurity is the broadest term, and often also covers pentesting and cloud posture management.

What the acronyms don't tell you is what sits underneath. The SIEM is the tool that collects and correlates the logs, the SOC is the team that makes it work, and MDR is the package that brings them together. In the same way, EDR and XDR are technologies, while MDR is the people who run them on your behalf.

What changed in 2026: time matters more than tools

A SOC is judged by two numbers: how long it takes to notice an attack and how long it takes to stop it. The data published this year shows why these two numbers weigh more than any technology catalogue.

• Global median dwell time rose to 14 days, up from 11 in the previous edition, according to Mandiant M-Trends 2026, which analyses Mandiant's 2025 investigations. It is the time an attacker stays inside before being discovered.
• The hand-off between whoever gets in and whoever strikes has shrunk to 22 seconds. In 2022 the median time between initial access and hand-off to a second group, ransomware operators for example, was more than 8 hours (same report). A minor alert at 3 a.m. can be the start of a serious attack.
• In 52% of 2025 investigations, organisations detected the malicious activity themselves, up from 43% in 2024. Internal visibility is improving, but almost one case in two is still reported by someone else.

The gap between these numbers is the window in which the attacker works undisturbed. Dwell time measures how long they stay; MTTR (mean time to respond) measures how fast you react. Both are the metrics to ask any SOC provider about.

Then there is a problem that starts inside the SOC itself: alert fatigue. When alerts exceed the capacity to read them, the real one ends up queued behind the ones that aren't. Adding tools doesn't fix it; calibration, correlation and continuous coverage do.

In-house, managed or hybrid SOC: how to decide

The real question is not which provider to choose, but whether to build the capability or buy it. An in-house SOC gives direct control and deep knowledge of the context. The price is shift maths: covering 24 hours a day, seven days a week, without gaps takes a rotation of about six analysts, which market estimates put at €400,000 to €600,000 a year in staff costs alone, before tools and training.

The second obstacle is finding the people. Experienced security analysts are scarce across Europe, and an understaffed in-house SOC is not a cheaper SOC: it is a SOC with uncovered nights.

There are three realistic options:

1. In-house, if your scope is large, you already have security operations skills and can carry a significant fixed cost and months of ramp-up.
2. Managed, if IT is small and already stretched, you need continuous coverage quickly and prefer a subscription to building a team.
3. Hybrid, if you have one or two specialists: they cover the day, when knowledge of the context matters most, and the partner covers nights, weekends and peaks.

And if what you are missing is the person who governs security, even before the people who run it, a virtual CISO (CISO as a service) is worth considering first.

NIS2 and DORA: where the SOC fits with the obligations

Neither NIS2 nor DORA requires you to buy a SOC. But both ask for capabilities that are hard to demonstrate to an authority or an auditor without continuous coverage.

NIS2: incident handling and 24- and 72-hour reporting

Directive (EU) 2022/2555, NIS2, lists incident handling among the minimum cybersecurity risk-management measures for essential and important entities (Article 21(2)(b)). Article 23(4) then sets the sequence for significant incidents, towards the CSIRT or, where applicable, the competent authority:

• an early warning within 24 hours of becoming aware of the significant incident;
• an incident notification within 72 hours, updating the early warning with an initial assessment of severity and impact and, where available, the indicators of compromise;
• a final report within one month of the incident notification, with the root cause and the mitigation measures applied.

The operational point is in the wording: the clock starts when the entity becomes aware of the significant incident. To meet the 24 hours with useful information you need someone who notices the incident, a timeline of events and the indicators of compromise: that is the daily work of a SOC. Each Member State transposes the directive into national law, so the receiving authority and the exact channel depend on the country you operate in.

There is a second, less obvious link: the same minimum measures include supply chain security (Article 21(2)(d)). A SOC provider has access to logs and critical systems, so it needs to be assessed and contracted with the same care as any other critical supplier. For the full picture of the obligations, see our NIS2 page.

DORA: detecting and managing ICT-related incidents

For banks, insurers, investment firms, payment and e-money institutions, and the other financial entities listed in Article 2, the reference is Regulation (EU) 2022/2554. Article 10 requires mechanisms to promptly detect anomalous activities and sufficient resources to monitor anomalies, incidents and cyber attacks; Article 17 an ICT-related incident management process to detect, manage and notify incidents; Article 19 the reporting of major ICT-related incidents to the competent authority. The full picture is on our DORA page.

How we work: from assessment to 24/7 coverage

Our SOC operates from Italy, 24 hours a day, with analysts based in Italy and data processed in the EU. We are an authorised Managed Security Service Provider for Google Security Operations and SentinelOne. The path has three phases.

1. Assessment

It starts with a 30-minute call with our technical team. A free assessment follows: we map assets, log sources, attack surface and coverage gaps, and define which threats matter for your sector. The report is yours to keep, even if you decide not to go ahead.

2. Onboarding and tuning

We connect the sources to the platform, write detection rules for your environment, reduce false positives and agree the response playbooks, including what we can contain on our own and when we call you first. Typical onboarding takes a few weeks: the time depends mainly on how many sources need connecting.

3. 24/7 coverage

The SOC monitors, investigates, contains and runs threat hunting. Response is measured in minutes, not hours. You receive monthly reports with posture KPIs and have a dedicated point of contact, not a ticket queue.

The stack

• Google SecOps as the platform. Google describes it as a unified SIEM, SOAR and threat intelligence experience, with 12 months of hot data retention included in the Standard package.
• Mandiant for threat intelligence, built into detection and investigation work.
• SentinelOne on endpoints and servers, to isolate the compromised machine and contain the attack.
• Wiz for cloud and identity posture, with its risks flowing into the SIEM, plus Horizon3 and Detectify for automated pentesting and the external attack surface.

On top of the platform sits the Agentic SOC approach: AI agents that speed up triage and first checks, analysts who make the decisions that count. Fewer alerts, more decisions. And retention matters more than it seems: M-Trends 2026 cites threats such as BRICKSTORM with dwell times close to 400 days, and notes that 90 days of log retention leaves you blind to the initial access vector.

What we need from you

A managed SOC is not a black-box handover. Getting off to a good start takes only a few things, but they really count:

• An internal point of contact with the authority to make decisions during an incident, and a reachable deputy.
• Access to the sources: endpoints, Active Directory or identity provider, firewalls, cloud, email. Every source left out is a blind spot.
• An asset inventory, even an imperfect one: knowing which systems are critical sets the triage priorities.
• The rules of engagement: what the SOC can isolate without calling you, who to call at night and in what order.
• The foundations: MFA, tested backups and patch management. Monitoring multiplies the value of these measures; it does not replace them.

If one of these is missing, it is not a reason to wait: it becomes the first item in the plan that comes out of the assessment.

If you already have a SIEM: QRadar, Splunk, Sentinel

Many companies come to a managed SOC with a SIEM already in place. There are two paths: keep it and have it monitored, or use the moment to migrate. For QRadar users the question is now a concrete one.

A well-run migration to Google SecOps follows five phases: inventory of sources and detections, mapping the logs to the UDM data model, rewriting the rules in YARA-L, a parallel run with both systems live, and cutover. The non-negotiable rule: the old SIEM is switched off last, after checking that the new one really sees the attacks.

If Microsoft Sentinel is also on the table, they are two solid platforms with different cost and integration models. And if the question is whether you need a SIEM at all or whether log collection is enough, the assessment answers that too.

Common mistakes and how to choose a partner

The same mistakes keep recurring in managed SOC proposals, and almost all of them come from comparing the wrong thing.

1. Comparing fees instead of SLAs. Ask for time to acknowledge and time to contain, how they are measured and when the clock starts. That is the yardstick that counts.
2. Buying alerts, not response. An email at 3 a.m. is not detection and response. Ask what happens after the alert, who does it and with what authorisations.
3. 24/7 on paper only. Out of hours, are there analysts at work or only automated notifications?
4. Locked-in data and rules. Who owns the logs, detections and playbooks if you change provider? The exit plan is agreed before you sign.
5. Onboarding without tuning. A service that doesn't calibrate the rules to your environment inherits the same noise, just in a different queue.
6. Overlooking language and context. During an incident you talk to management, legal and sometimes the national CSIRT: you need a contact who knows NIS2 and DORA and works in your time zone.

What drives the cost of a managed SOC

There is no single price list, and a price given before seeing the scope says little. The factors that move the fee are always the same:

• Scope: number of endpoints, servers, users and cloud environments.
• Log volume: how much data is collected and analysed. This weighs mainly on the platform: Google, for example, offers SecOps in ingestion-based packages.
• Coverage: office hours or 24/7 with people.
• Depth: monitoring and alerting only, or investigation, containment and threat hunting too.
• Platform: already yours or included in the service. Keeping the two items separate avoids surprises at renewal.
• Starting point: a SIEM to migrate or many sources to connect from scratch changes the onboarding work.

The benchmark remains the cost of doing it yourself, with the six analysts needed to cover the shifts. We produce the estimate for your scope after the assessment, not before.