Who is accountable when an MDR provider misses an active intrusion?

Why This Matters for Security Teams

Accountability does not shift just because detection and response are outsourced. An MDR provider may monitor telemetry, investigate alerts, and recommend containment, but the organisation still owns risk decisions, business impact, and regulatory exposure. That distinction matters most when a breach is discovered late, because the question is not whether the provider noticed it quickly enough, but whether governance, logging, escalation, and authority were defined before the incident. NIST SP 800-53 Rev 5 Security and Privacy Controls makes this separation between control operation and responsibility explicit in practice, especially across audit, incident response, and access governance areas.

Security teams often get this wrong by assuming the service contract replaces internal oversight. It does not. If evidence is missing, access was never provisioned for the right responders, or the business approved a delay in containment, the organisation still owns the outcome. MDR is a control layer, not a liability transfer mechanism. In practice, many security teams encounter this only after an intrusion has already persisted long enough to create legal, financial, and operational damage.

How It Works in Practice

In a well-run operating model, MDR functions as an extension of the security operations capability, not as a substitute for it. The provider may detect suspicious activity, enrich alerts, and trigger containment actions, but those actions should sit inside a pre-agreed decision framework that defines who can isolate hosts, disable accounts, collect evidence, and declare an incident. Without that framework, providers tend to stop at notification, and the organisation is left to interpret severity after the attacker has already moved.

The practical split usually looks like this:

• The provider owns monitoring, triage, and first-line response actions within agreed scope.
• The organisation owns risk acceptance, legal reporting decisions, recovery priorities, and business communication.
• Both parties need a shared escalation path, evidence handling process, and service-level definition for active intrusions.
• Access to logs, endpoints, identity systems, and cloud control planes must be tested before a real incident, not negotiated during one.

This is where NIST SP 800-53 Rev 5 Security and Privacy Controls is useful: it reinforces that incident response, auditability, and access control are operational controls that must be assigned, evidenced, and exercised. For response workflows, teams should also map MDR activity to known adversary behaviours using MITRE ATT&CK, because missed intrusions often involve living-off-the-land techniques, credential misuse, or lateral movement that blend into normal activity.

Where identity is in scope, especially with privileged access and service accounts, the operating model should also define who can revoke secrets, rotate credentials, and validate whether an alert reflects genuine compromise or expected automation. MDR cannot make that call in isolation if the environment uses shared admin paths, ephemeral access, or non-human identities tied to production workflows. These controls tend to break down when the provider sees only partial telemetry because endpoint, identity, and cloud logs are not centrally retained or correlated.

Common Variations and Edge Cases

Tighter response authority often increases operational overhead, requiring organisations to balance faster containment against change-control, legal approval, and business continuity constraints. There is no universal standard for exactly how much authority an MDR provider should have; current guidance suggests the answer depends on system criticality, data sensitivity, and whether the provider can act safely without creating secondary harm.

Some environments need narrow, read-only MDR scope because production outages are more damaging than delayed containment. Others need pre-authorised action for high-risk assets, especially where ransomware exposure or identity compromise can spread quickly. In regulated sectors, contractual accountability becomes even more important because outsourced monitoring does not remove obligations under CISA Secure by Design principles or incident handling expectations. The organisation should also align escalation and reporting to its broader resilience obligations, including NIS2 guidance where applicable.

The main edge case is a shared responsibility gap: the provider believes containment was outside scope, while the customer believes “managed detection” included active intervention. That gap is usually exposed by missing runbooks, unclear evidence retention, or a contract that defines monitoring but not response authority. When that happens, accountability is not ambiguous in practice. The organisation still owns the breach, and the provider’s role becomes a question of service quality rather than ultimate responsibility.

Related resources from NHI Mgmt Group

• Who remains accountable when a managed cloud security provider misses an incident?
• How can security teams judge whether an MDR provider is accountable for outcomes?
• Who is accountable when an alert backlog hides an active intrusion?
• Who is accountable when an agentic SOC misses a real intrusion?