The MDR shared-responsibility model: who owns detection, investigation, containment and remediation

Why shared-responsibility gaps cause MDR failures

The most common MDR failure mode is not a missed detection. It is an unsigned authorization. When a provider detects a threat and a customer lacks a clear internal owner for containment decisions, the response stalls — not because capability is absent, but because no one in the contract said who could pull the trigger.

Incident handling defines roles and handoffs across detection, analysis, containment, and notification — the boundary a shared-responsibility model must assign. (Source: NIST SP 800-61r3, Incident Response Recommendations and Considerations, https://csrc.nist.gov/pubs/sp/800/61/r3/final) The problem surfaces at hand-off moments: the provider closes a triage ticket, the customer assumes the provider will act, and the threat persists in the gap between those two assumptions. The sales conversation centers on coverage and telemetry, not authorization chains, so leaders underestimate it.

The boundary buyers misunderstand

MDR contracts vary significantly in what "managed" means. Monitoring and alerting are nearly always provider-owned. Remediation almost never is. The space between those poles — investigation depth, containment authority, threat-hunting cadence — is where most operational friction lives, and where contract language is least precise. A customer that treats MDR as equivalent to having an internal SOC is likely to discover, under incident conditions, that the provider cannot push a firewall block, isolate a workstation, or disable a compromised account without a separate authorization step.

The CSF Respond function enumerates containment and mitigation responsibilities that must be explicitly owned in a managed service, while the CSF Govern function underscores the need to define supplier roles and responsibilities in advance. (Source: NIST Cybersecurity Framework CSF 2.0, https://www.nist.gov/cyberframework) Without explicit ownership, the default is that the customer owns anything the provider cannot do unilaterally — and customers often do not know that default exists until they need the response.

Who writes and tunes detections

Detection content — the rules, correlation logic, behavioral baselines, and threat-intelligence-derived signatures that generate alerts — is typically provider-owned, maintained across the provider's customer base and updated against current threat intelligence. But environment-specific detections for custom applications, legacy systems, or unusual network architectures are not something a provider can author without customer input.

In environments with significant custom tooling, delegating detection authoring entirely to the provider creates a coverage blind spot that may not be visible in routine reporting; the control is a recurring detection review where the customer presents environment changes and the provider maps them to coverage gaps. The frequency of those reviews — quarterly, monthly, or triggered by material environment changes — should be defined in the service agreement.

Who investigates and triages

Alert triage and initial investigation are core MDR provider functions: the provider correlates raw alerts, reduces false positives, and produces an assessed finding with severity and context. What varies by contract is investigation depth — some providers deliver a confirmed incident with a root-cause hypothesis; others hand off a high-confidence alert with supporting artifacts and expect the customer's team to complete the analysis. That difference determines how much internal analyst capacity the customer must still maintain.

Where identity systems are involved — compromised credentials, abnormal privileged access, lateral movement via service accounts — investigation often requires customer-side access to IAM logs, directory event data, or PAM session recordings the provider cannot reach without integration. A provider that cannot query your identity store is investigating with partial evidence. NIST SP 800-61r3 specifically addresses coordination with external parties, including managed service providers, as a dimension of incident-response planning that organizations must address before an incident occurs.

Who has authority to contain

Containment authority — the permission to take an action that degrades attacker capability, such as isolating a host, blocking an IP, suspending an account, or revoking a token — is the most consequential hand-off in an MDR engagement and the one most often left ambiguous. Providers can typically execute containment within tools they manage: EDR-driven host isolation, firewall changes through integrated platforms, or account suspension within a managed identity layer. Actions that require customer-infrastructure access — disabling an Active Directory account, revoking cloud IAM credentials, isolating a network segment via the customer's own controls — generally require either pre-delegated authority or a synchronous authorization step.

Pre-delegating containment authority through a signed playbook reduces response latency during high-severity incidents but requires the customer to accept some operational risk; that tradeoff should be resolved by severity tier, not a single blanket policy. NIST SP 800-61r3 emphasizes that incident-response authority — including who can authorize containment actions and under what conditions — must be established before incidents occur, not negotiated in real time.

Who remediates

Remediation — restoring systems, patching vulnerabilities, rebuilding compromised configurations, rotating credentials — is in most MDR contracts the customer's responsibility; the provider identifies the problem and may recommend steps, but execution falls to the customer's infrastructure and identity teams. Some MDR providers offer remediation as a narrowly scoped, separately priced add-on, particularly for endpoint reimaging or credential rotation within managed identity layers; assuming remediation is included without verifying it against the service schedule is a common gap that extends recovery timelines.

For identity-specific remediation — rotating compromised credentials, revoking access grants made during an incident window, auditing group membership changes — the customer's IAM team carries the workload regardless of provider model. NIST CSF 2.0 frames recovery planning as an organizational responsibility that managed service arrangements do not transfer; customers should ensure their recovery plans are updated to reflect what the MDR provider will and will not execute.

Notification and escalation: who contacts whom

Notification chains — who tells whom, through what channel, within what timeframe — must be explicitly defined in the service agreement: the provider notifies the customer's designated contact when a confirmed or suspected incident meets a defined threshold, and the customer maintains current escalation contacts and defines what "high severity" means in operational terms. Regulatory notification obligations — breach disclosure to regulators, affected individuals, or sector authorities — remain with the customer in almost all MDR arrangements.

A provider that manages detection and triage does not assume the customer's legal notification obligations. NIST SP 800-61r3 is explicit that organizations retain responsibility for external communications, including regulatory reporting, even when response activities are partially or substantially outsourced. Customers in regulated sectors should confirm their incident response plan accounts for notification timelines independent of provider capability.

Evidence the provider must retain

Evidence retention — raw log data, alert artifacts, investigation notes, chain-of-custody documentation — affects both post-incident analysis and the capacity to satisfy regulatory or legal requirements. Retention periods, data residency, and log completeness should be specified in the contract, not assumed from platform defaults.

Customers should request clarity on how long raw telemetry (not just processed alerts) is retained, whether forensic artifacts remain accessible post-engagement, and what happens to retained data if the contract is terminated — questions easier to negotiate before an incident than to litigate after one. NIST SP 800-61r3 addresses evidence handling as a core component of incident response; organizations using MDR services should confirm that provider retention and handoff practices satisfy their own evidentiary and regulatory requirements.

What remains the customer's responsibility

Regardless of provider scope, customers retain ownership of functions an MDR engagement does not transfer: asset inventory and coverage verification, IAM configuration and privileged access governance, endpoint and cloud security hygiene, user security awareness, and regulatory compliance obligations. Coverage gaps — assets not reporting telemetry, cloud workloads not integrated into the MDR platform, identity systems outside provider visibility — are the customer's responsibility to identify and disclose, because a provider can only detect across what it sees.

Customers that do not maintain an accurate asset inventory will systematically underestimate their coverage gaps, often discovering them when an incident originates from an unmonitored system. NIST CSF 2.0's Identify function assigns asset management and risk assessment ownership to the organization itself; MDR does not fulfill those responsibilities on the customer's behalf.

Shared responsibility matrix

This matrix is a negotiation checklist, not a fixed standard. Actual splits vary by contract, provider platform, and customer environment. Use it to identify undefined ownership before it becomes an incident-condition problem. It is not a substitute for formal contractual definition of responsibilities.

Sources