The Shared Responsibility Matrix helps you define which cybersecurity tasks you own and which are handled by service providers like AWS or Microsoft Azure.
The CMMC Shared Responsibility Matrix (SRM) helps businesses define which cybersecurity tasks they own and which are handled by service providers like AWS, Microsoft Azure, or Google Cloud. By clarifying roles in encryption, access control, and incident response, organizations can simplify compliance, strengthen security, and prepare for the upcoming CMMC requirements.
Why the SRM Matters
Cloud providers operate under a shared responsibility model: they secure the infrastructure ("of the cloud"), and you secure what you put in it ("in the cloud"). For CMMC, every one of the 110 NIST SP 800-171 controls must be implemented somewhere — by you, by the provider, or by both. The SRM is the document that makes those boundaries explicit.
Building Your SRM
For each NIST SP 800-171 control, record:
- Implementation owner — Customer, Provider, or Shared.
- The provider's documented inheritance (FedRAMP package, customer responsibility matrix).
- Your implementation evidence for any portion you own.
- Cross-references between the SRM, your SSP, and your POA&M.
Common Misalignments
The mistakes we see most often: assuming the provider covers logging when only infrastructure logging is included; assuming encryption-at-rest is sufficient when CMMC also requires encryption-in-transit and FIPS validation; assuming incident response is fully provider-owned when in reality the customer must detect, declare, and report incidents in their tenant.
A well-constructed SRM saves weeks of assessment back-and-forth and removes the most common source of audit findings.
