Accountability should be shared but explicit. The MSP owns delivery quality, service design, and operational execution, while the client retains governance authority, risk decisions, and business priorities. Clear roles are essential when services include access revocation, policy enforcement, and compliance support. Without that split, managed services can create confusion instead of stronger security outcomes.
Why This Matters for Security Teams
Accountability in a co-managed MSP security service is not just a contract issue. It determines who can prove control effectiveness, who answers when outcomes miss target, and who can act quickly when access revocation, logging, or policy enforcement fails. The risk is highest where identity and secrets are involved, because a service can look operationally healthy while quietly leaving excessive privilege in place.
This is a governance problem as much as an operations problem. NIST’s Cybersecurity Framework 2.0 and SP 800-53 Rev. 5 both assume responsibilities are defined, measured, and auditable, not implied by a managed service label. That same principle shows up in NHI operations: NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames lifecycle ownership, revocation, and audit evidence as explicit duties, not shared assumptions.
In practice, many security teams discover that “the MSP handles it” becomes a control failure only after a stale secret, missed revocation, or failed audit evidence request has already affected production.
How It Works in Practice
Effective co-management separates delivery accountability from risk accountability. The MSP should be accountable for service design, operational execution, ticket handling, alert triage, patching, log collection, and agreed response times. The client should remain accountable for risk acceptance, policy decisions, business priorities, exception approval, and whether the service outcome is acceptable for the organisation.
For identity-heavy services, that split must be documented at the control level. If the MSP is responsible for access revocation, the contract should define the trigger, the SLA, the source of truth, and the evidence required to prove completion. If the MSP manages secrets rotation or policy enforcement, the client still owns the decision to require those controls and the residual risk if coverage is incomplete. NHIMG’s Top 10 NHI Issues and NHI Lifecycle Management Guide are useful references for mapping those lifecycle duties to measurable operational tasks.
- Define who owns each control, not just who performs the task.
- Attach metrics to outcomes, such as revocation time, rotation completion, and evidence completeness.
- Require escalation paths when the MSP cannot meet a control objective.
- Separate operational reporting from risk acceptance so exceptions are visible and time-bound.
This model aligns well with NIST SP 800-53 Rev. 5 because accountability only has value when it can be tested against control evidence, not verbal assurance. These controls tend to break down when the MSP has operational access but the client lacks timely evidence and authority to enforce remediation.
Common Variations and Edge Cases
Tighter co-management often improves consistency, but it also increases coordination overhead, requiring organisations to balance stronger control with slower decision cycles and more formal approvals. That tradeoff becomes visible when incidents span multiple teams or when the MSP manages only part of the control stack.
Best practice is evolving for hybrid models where the MSP runs day-to-day monitoring while the client retains final approval for privileged changes. In those environments, shared dashboards are not enough. There must be a clear rule for who can approve emergency access, who can disable an account, and who must sign off on unresolved exceptions. Where third-party systems, OAuth connections, or service accounts are involved, the organisation should also treat the MSP as part of the control surface, not just an operator. NHIMG’s research shows how quickly visibility gaps can obscure third-party access and weaken assurance, especially when lifecycle ownership is unclear.
For audit and assurance purposes, the question is not whether the MSP is “responsible” in a general sense, but whether measurable outcomes are assigned to one named accountable party. If that answer is ambiguous, the service may still be functioning while the control environment is not. That ambiguity is especially risky when contracts span compliance support, access operations, and incident response, because no universal standard yet resolves every shared-responsibility edge case.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Outcome accountability depends on governance and oversight being assigned and measured. |
| NIST SP 800-63 | Identity assurance matters when MSPs administer revocation and access decisions. | |
| NIST AI RMF | Shared accountability mirrors the AI RMF need for clear governance and accountability. | |
| NIST Zero Trust (SP 800-207) | 4.5 | Zero Trust requires explicit policy enforcement and continuous verification of access. |
| OWASP Non-Human Identity Top 10 | NHI-04 | NHI lifecycle ownership is central when MSPs handle secrets and service accounts. |
Assign lifecycle ownership for secrets, rotation, and revocation to a named accountable party.
Related resources from NHI Mgmt Group
- How should security teams govern Active Directory service accounts?
- Who is accountable when sensitive data exposure creates regulatory or security risk in a managed service model?
- Who is accountable when AI systems are deployed with shared security, consulting, and managed service responsibilities?
- Who is accountable for security and reliability when a managed data connectivity service is used?
