Shared Responsibility Matrix

    Shared Responsibility Matrix for CMMC

    A shared responsibility matrix (SRM) for CMMC documents which party — you, your cloud provider, or your managed-service partner — owns each NIST 800-171 control. C3PAOs ask for an SRM on every Level 2 assessment that involves a cloud enclave or an external service provider, which is almost all of them. Without one, you cannot defensibly inherit controls; with a sloppy one, you reimplement controls the provider already runs for you.
    See the Assessment Pack Free CMMC Quick Score

    Why C3PAOs ask for an SRM

    The SRM is not itself a CMMC artifact, but the 32 CFR Part 170 final rule made it functionally mandatory. If you claim a control is inherited from Microsoft GCC High or your MSSP, the C3PAO needs documentation showing the provider performs the control and you have validated it. The SRM is that documentation. No SRM means no inheritance means you implement the control yourself or it is a gap.

    What an SRM has to cover

    For each of the 110 NIST 800-171 controls (or 320 objectives if you go deeper), the SRM names the responsibility split:

    The four responsibility categories

    • Provider. Provider implements the control fully. You consume the assurance via the provider's FedRAMP authorization or SOC 2 report.
    • Customer. You implement the control fully. Provider has no role.
    • Shared. Both parties implement portions. Document who does what — e.g., provider hardens the platform, you configure the tenant.
    • Inherited. Provider implements; you must validate (configure correctly, monitor the assurance, refresh annually). The most common category and the most frequently mis-documented.

    Worked example: GCC High + your tenant

    • AC.L2-3.1.1 (account management): Shared. Microsoft provides the identity platform; you configure conditional access, group membership, and JML procedures.
    • AU.L2-3.3.1 (audit logging): Shared. Microsoft generates platform logs; you enable Unified Audit Log, configure retention, and route to your SIEM.
    • SC.L2-3.13.11 (FIPS-validated crypto): Inherited. Microsoft's GCC High platform uses FIPS-validated modules; you validate the inheritance via Microsoft's compliance documentation.
    • PE.L2-3.10.1 (physical access): Provider. Microsoft's datacenter physical security; you consume via FedRAMP High authorization.
    • SI.L2-3.14.1 (flaw remediation): Shared. Microsoft patches the platform; you patch your tenant configurations and any deployed apps.

    SRMs for MSSPs and ESPs

    The final rule treats Managed Security Service Providers and External Service Providers as in-scope for CMMC if they touch your CUI environment. That means your MSSP needs its own assessment posture — or you absorb the risk. The SRM is where this split is documented. If your MSSP runs your SIEM, the SIEM-related controls are inherited from them; your SRM has to name them and reference their assessment evidence. The scoping guide covers the broader question of where MSSP touchpoints pull assets into scope.

    How Athena handles SRMs

    Athena's SRM module starts from a baseline for common providers (GCC High, AWS GovCloud, common MSSPs) and lets you override per-control. SRM assignments flow into the SSP implementation statements and into POA&M ownership. When a provider updates its FedRAMP posture or your MSSP changes scope, the SRM regenerates and surfaces the affected SSP sections for re-review.

    Frequently asked questions

    Is a shared responsibility matrix required for CMMC?

    Not as a named CMMC artifact, but C3PAOs require one in practice whenever you claim inherited controls from a cloud provider or external service provider. Under 32 CFR Part 170, you cannot defensibly inherit a control without documentation of the responsibility split — the SRM is that documentation.

    Can I inherit controls from Microsoft GCC High?

    Yes, for controls Microsoft fully implements (most physical and environmental controls, platform-level crypto, datacenter security). Most other controls are shared — Microsoft provides the platform capability, you configure and operate it. Inheritance has to be documented per-control in your SRM, with reference to Microsoft's compliance posture.

    What about my MSP or MSSP?

    If your MSP or MSSP touches the CUI environment, they are in scope under 32 CFR Part 170 as an External Service Provider. Either they hold their own CMMC posture or you absorb the assessment risk. The SRM documents which controls they own and how you validate their performance.

    How often do I update the SRM?

    At minimum annually, and whenever a provider updates their FedRAMP authorization, an MSSP changes scope, or you onboard or offboard a service. The SRM is a living document — treat it like the SSP.

    Further reading

    Related Athena pages and authoritative external references.

    On Athena

    Authoritative external sources

    Ready to act on this?

    Run the free Quick Score, then walk through the Assessment Pack.

    Free CMMC Quick ScoreSee the Assessment PackPricing & demo