Who is accountable when an MSP helps operate CMMC controls?

Why This Matters for Security Teams

When an MSP operates parts of a CMMC environment, the biggest mistake is assuming the provider’s operational role transfers accountability. It does not. The assessed organisation still has to demonstrate that controls are implemented, effective, and evidenced inside its own environment, including third-party-operated components. That means internal owners need a clear line of sight into what the MSP is doing, what evidence exists, and which obligations remain in-house. NIST’s control baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces that control responsibility must be assigned, tracked, and verifiable. NHIMG research shows that visibility gaps are common: only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of blind spot that makes MSP-managed control evidence hard to trust. In practice, many security teams discover ownership gaps only after an assessment has already exposed missing evidence, rather than through intentional control governance.

How It Works in Practice

In CMMC programs, an MSP may operate technical controls such as patching, endpoint protection, logging, backup administration, or access enforcement, but the assessed organisation remains responsible for defining scope, retaining evidence, and proving the control is operating as intended. This is especially important when the MSP touches identities, secrets, or privileged access, because those functions create shared operational boundaries that can be hard to audit later. NHIMG’s Ultimate Guide to NHIs is relevant here because third-party operators often manage service accounts and API keys that become hidden dependencies in compliance evidence.

Practitioners usually need to separate four things:

• control ownership, which stays with the assessed organisation;
• control operation, which may be delegated to the MSP;
• control evidence, which must be retrievable and reviewable by the assessed organisation;
• attestation, which must be signed by accountable internal roles.

A practical model is to map each CMMC control to a named internal owner, a named MSP operator, and a named evidence source. For example, if an MSP manages logging, the organisation still needs to know which logs exist, how long they are retained, who can access them, and how exceptions are approved. If an MSP handles access administration, the organisation still needs evidence of approvals, periodic reviews, and revocation workflows. This aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls because the control system must be traceable, not just outsourced. These controls tend to break down when the MSP has tooling access but the customer lacks exportable evidence, especially in hybrid environments with shared admin consoles and undocumented exception handling.

Common Variations and Edge Cases

Tighter MSP oversight often improves assurance, but it also increases coordination overhead, requiring organisations to balance audit readiness against operational convenience. There is no universal standard for every MSP contract, so current guidance suggests treating managed services as a control dependency, not a compliance substitute. That distinction matters most when the MSP also manages non-human identities, cloud administration, or security tooling that can quietly expand the blast radius of a failure.

Two edge cases come up often. First, some organisations assume a vendor’s SSAE-style report or service summary is enough to prove CMMC readiness. It is not. Those reports may support due diligence, but they rarely replace control-specific evidence from the assessed environment. Second, some MSPs operate security controls inside their own portal, which creates a documentation gap if the customer cannot observe configurations, logs, or change history. In those cases, the organisation should require contractual evidence rights, defined escalation paths, and clear boundaries for shared responsibilities.

For teams dealing with secrets, service accounts, or privileged automation, the accountability question is even sharper because the assessor will expect to see who approves access, who rotates credentials, and who confirms revocation. That is why NHI governance often becomes part of CMMC readiness even when the original question sounds purely contractual. The safest operating model is simple: the MSP can help run the control, but the assessed organisation still owns the proof.

Related resources from NHI Mgmt Group

• Who is accountable when administrative access controls fail in CMMC assessments?
• Who is accountable when a contractor cannot prove CMMC identity controls?
• Who is accountable when identity security controls fail across team boundaries?
• Who is accountable for proof-of-possession controls in OAuth environments?