The customer remains accountable for the risk, even if the provider runs the service, so approval boundaries must be explicit. Governance frameworks should define which actions are advisory, which are supervised and which are permitted to execute automatically before any incident occurs.
Why This Matters for Security Teams
An MDR provider can operate tooling, triage alerts, and even trigger containment, but that does not transfer accountability for business risk. The security team still needs a clear decision model for what the provider may do without approval, what requires a human check, and what must be escalated immediately. That distinction matters because response action can affect production services, evidence preservation, legal holds, and customer trust.
Current guidance around shared responsibility is strongest when it is written into playbooks, contracts, and control ownership rather than left to service assumptions. A useful baseline is NIST SP 800-53 Rev 5 Security and Privacy Controls, which maps incident response, access control, and auditability into operational controls that can be assigned and tested. The key issue is not whether the MDR is trusted, but whether the customer can prove who authorised each action and why. In practice, many security teams discover this only after an overly aggressive quarantine, account disablement, or isolation action has already disrupted critical operations.
How It Works in Practice
Accountability should be built as a control chain, not assumed from the contract. The customer defines the acceptable response envelope, the MDR provider executes within that envelope, and logging proves what happened. If the provider goes beyond that envelope, the customer still owns the governance failure, while the provider may also carry contractual or negligence exposure depending on the agreement and applicable law. In other words, operational execution can be delegated, but risk ownership usually cannot.
Good practice is to classify response actions into three buckets:
- Advisory actions, where the MDR recommends a step and waits for customer approval.
- Supervised actions, where the MDR can prepare or stage containment but needs sign-off before execution.
- Pre-authorised actions, where the MDR may act automatically within narrow, documented thresholds.
That structure should be backed by change windows, exception handling, and rollback criteria. It should also include evidence retention so the team can reconstruct what was seen, what was decided, and who approved it. NIST incident handling guidance, alongside NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide, supports this kind of disciplined workflow even when a third party is doing the hands-on response. For environments with automated containment, the decision logic should be tested against real alert conditions, not just tabletop scenarios.
Where identity and privilege are involved, the same principle applies to privileged access pathways, service accounts, and non-human identities used by the MDR platform. If those identities can disable systems, rotate secrets, or isolate workloads, they need explicit scope, monitoring, and revocation rules. These controls tend to break down when high-severity alerts are routed through generic “full response” permissions because the provider’s automation then outruns the customer’s approval model.
Common Variations and Edge Cases
Tighter response controls often increase dwell time and coordination overhead, so organisations must balance speed against operational risk. That tradeoff becomes sharper in regulated sectors, during ransomware events, and in cloud environments where containment can cascade across shared services.
There is no universal standard for every MDR scenario. Some organisations allow automatic host isolation but require human approval before disabling user accounts. Others permit emergency action only for a named set of assets, with post-action review within a fixed time window. The right model depends on business criticality, legal obligations, and the maturity of detection engineering.
Edge cases deserve explicit treatment in the playbook. For example, if an MDR analyst isolates the wrong endpoint, the issue may be both an operational error and a governance defect if the customer never defined the approval threshold. If the provider acts within scope but the outcome is still harmful, accountability usually sits with the customer for the risk decision and with the provider for execution quality. Where personal data, regulated records, or production identity systems are involved, teams should also consider audit and reporting obligations under CISA incident response planning guidance and control expectations from NIST SP 800-61. The practical test is simple: if the team cannot state who may approve, who may execute, and who must be notified, the accountability model is not ready yet.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.RP-1 | Response actions need a defined, tested incident response plan. |
| MITRE ATT&CK | T1562 | Containment errors often arise during defense evasion or response activities. |
| OWASP Non-Human Identity Top 10 | NHI-05 | MDR platforms may act through non-human identities with high-impact privileges. |
Govern service identities used by MDR tools with explicit scope, rotation, and revocation rules.
