A CMMC shared responsibility matrix (SRM) maps every NIST SP 800-171 control required for CMMC Level 2 to the party responsible for enforcing it. For an on-premise environment using a network security tool, it sorts the 110 controls into three buckets: controls the tool enforces at the network layer, controls the customer owns through organizational process, and controls handled by compensating mechanisms for OT assets that cannot comply natively.
What is the point of an SRM?
The SRM is the evidence roadmap for a C3PAO assessment. It tells the assessor which controls have technical enforcement, with logs, policy configs, and segmentation baselines as proof, and which are met through the customer's own processes like physical security, personnel screening, and media handling. Without it, an assessor has to reconstruct that division of labor from scratch, which slows the assessment and invites findings.
How is a shared responsibility matrix structured?
A typical SRM organizes controls by NIST 800-171 control family:
- Access Control (AC): 22 controls covering identity verification, role-based access, and least privilege.
- Audit and Accountability (AU): 9 controls covering session logging and event monitoring.
- Configuration Management (CM): 9 controls covering baselines and change tracking.
- Identification and Authentication (IA): 11 controls covering MFA and credential management.
- System and Communications Protection (SC): 16 controls covering encryption, segmentation, and deny-by-default.
- Incident Response (IR): 3 controls covering detection and response.
- Physical Protection (PE): 5 controls, usually customer-owned.
- Personnel Security (PS): 2 controls, usually customer-owned.
- Media Protection (MP): 9 controls, usually customer-owned.
- Risk Assessment (RA): 3 controls, mixed, with vulnerability scanning often documented as not applicable for OT.
Why does the SRM matter for OT environments?
For environments with PLCs, CNCs, HMIs, and legacy equipment, the SRM has to account for assets that invoke the CMMC enduring exception. These assets need documented compensating controls for the specific requirements they cannot meet natively: multi-factor authentication (3.5.3), audit logging (3.3.1), and encryption in transit (3.13.8). The SRM is where you record how a network-layer mechanism covers those gaps, so the assessor sees enforcement instead of an unaddressed control.
How is an SRM different from an SSP?
They are complementary. The System Security Plan describes how each control is implemented in your environment. The shared responsibility matrix answers a narrower question: who is on the hook for each control. An SSP can name a tool that enforces a control; the SRM makes the division of labor explicit across all 110 controls, which is what an assessor uses to plan the assessment.
Related terms
- CMMC, the certification framework requiring the SRM
- CMMC Level 2, the level requiring all 110 NIST 800-171 controls
- CMMC Enduring Exception, the mechanism for OT assets that cannot comply natively
- NIST SP 800-171, the underlying control framework
- C3PAO, the assessor that uses the SRM during certification
