CRMs and SRMs

Harmonizing Responsibility in Cybersecurity Compliance

In cybersecurity compliance—especially when preparing for a CMMC assessment—unclear delineation of responsibility can lead to missed requirements, failed assessments, and security breakdowns. Enter the Customer Responsibility Matrix (CRM) and Shared Responsibility Matrix (SRM): two essential tools for clarifying who is responsible for implementing and maintaining compliance with specific security requirements.

These tools help Organizations Seeking Certification (OSCs) and their External Service Providers (ESPs) align on expectations, reduce confusion, and demonstrate shared compliance with frameworks like NIST SP 800-171 and CMMC.

What Is a CRM?

A Customer Responsibility Matrix (CRM) is authored and provided by an External Service Provider (ESP) and identifies the specific responsibilities the customer (OSC) must fulfill in order to ensure that the service being provided is compliant with applicable cybersecurity requirements (e.g., NIST SP 800-171).

The CRM does not describe how the ESP implements the requirement—that level of detail remains within the ESP’s internal documentation (e.g., their own SSP or system-specific documentation). Instead, the CRM exists to:

• Clarify what the OSC must do (e.g., provide inputs, configure integrations, review logs, enforce policies)
• Define the boundary of the ESP’s responsibility
• Support CMMC compliance by satisfying 32 CFR § 170.19(c)(2)(ii), which requires documentation of shared or inherited responsibilities

A CRM is a one-directional artifact that outlines what the customer must do to ensure that a third-party service supports their compliance program.

What Is a SRM?

A Shared Responsibility Matrix (SRM) is often collaboratively developed between the OSC and the ESP, and it maps both parties’ responsibilities for each applicable security requirement. Unlike the CRM, the SRM is:

• Bidirectional: It documents what the ESP is responsible for and what the OSC is responsible for
• Collaborative: Often co-developed and reviewed by both parties to ensure shared understanding
• More granular: May include specific descriptions of how controls are implemented and how responsibility is shared

SRMs are particularly useful when services are not fully inherited, and responsibilities are divided across system boundaries—for example, if an ESP provides a vulnerability scanning service, but the OSC is responsible for interpreting results and approving remediation.

Why CMMC Only Uses the Term CRM

Under 32 CFR Part 170 § 170.19(c)(2)(ii), OSCs are required to define their assessment scope and document the responsibilities for each service provider used. The regulation refers specifically to the Customer Responsibility Matrix (CRM) because:

• CMMC assessments evaluate the OSC’s implementation, not the provider’s internal controls
• The OSC is ultimately accountable, regardless of how much is outsourced
• The CRM provides a customer-focused artifact that assessors can use to validate compliance at the OSC level

SRMs may still be useful, especially for internal planning and contracting discussions—but only the CRM is formally required under the CMMC rule.

Who Needs a CRM?

Any OSC that relies on external services to satisfy any portion of a NIST SP 800-171 or CMMC control must have a CRM. This includes services such as:

• Cloud service providers (CSPs) – e.g., Azure Government, AWS GovCloud
• Email and collaboration platforms – e.g., O365 GCC High
• Managed Service Providers (MSPs) – e.g., providing helpdesk, backups, system configuration
• Managed Security Service Providers (MSSPs) – e.g., endpoint protection, patching, SIEM
• Third-party tools – e.g., vulnerability scanning platforms, MFA providers

If even one control is implemented—or partially supported—by a provider, a CRM must be collected and used to define customer responsibilities.

Who Writes a CRM or SRM?

• CRM: Authored by the ESP, as a way to document what the OSC must do in order to ensure the ESP’s service supports compliance. CRMs are typically published per product/service and updated as offerings evolve.
  • Example: Microsoft provides CRM documents for its cloud services that identify what the customer must do to configure and use the service securely.
• SRM: A more collaborative artifact that is either authored by the ESP, the OSC, or co-developed. It defines who does what and can be used internally or contractually to supplement the CRM.
  • Example: An OSC works with its MSSP to identify which team performs patch validation, which performs endpoint log review, and how alerts are escalated.

Regardless of author, the OSC is accountable for ensuring these artifacts are integrated into their documentation and used during assessments.

What Should a CRM Include as Extra?

A useful CRM typically includes the following components:

• Service Description: High-level overview of what the ESP provides
• Control Mapping: The associated control ID (e.g., RA-3.11.2)
• Assessment Objective (AO): NIST SP 800-171A objective(s) affected by the service
• Customer Responsibilities: Clearly written tasks the OSC must perform
• Responsibility Type: One of the following:
  • Fully Covered / Fully Inherited
  • Shared Responsibility
  • Full Customer Responsibility
• Reference Documentation: SLA excerpts, configuration guides, interface documentation, etc.

To make a CRM not just functional, but effective, include:

• RACI Mapping: Define who is Responsible, Accountable, Consulted, and Informed
• SSP Integration Guidance: Suggested narrative OSCs can insert directly into their SSP
• Key Performance Indicators (KPIs): Metrics or logs the OSC should monitor to ensure ongoing compliance
• Review Cadence: Specify how often the CRM is updated or reviewed
• Version Control & Ownership: Identify document owner and revision tracking

These enhancements help integrate the CRM into continuous compliance workflows and streamline assessment preparation.

How to Write a CRM – Defined Process

A well-written Customer Responsibility Matrix (CRM) should be clear, actionable, and aligned with how the service supports compliance with NIST SP 800-171 and CMMC requirements. While CRM content may vary depending on the type of ESP, the process to develop one should follow a structured approach to ensure completeness and audit utility.

Below is a step-by-step process for writing an effective CRM.

Step 1: Define the Service

Start by clearly identifying the service being provided. Describe what the service does, what systems or requirements it supports, and where it fits within the OSC’s environment. This helps ensure the CRM aligns with the actual use case and scope of the service.

Example: “SecureScan™ is a vulnerability scanning solution used to scan internal endpoints and applications for known vulnerabilities. The service includes a customer-deployed scanner agent and a cloud-based management dashboard.”

Step 2: Map Applicable Requirements

Next, identify the specific security requirements and associated assessment objectives (AOs) that the service supports. These can be pulled from NIST SP 800-171A publications, which breaks down each requirement into verifiable objectives.

This mapping ensures that the CRM is control-focused and aligned with what assessors are looking for.

Step 3: Assign Responsibility at the AO Level

For each relevant AO, determine what you, as the ESP, are responsible for and what the OSC is responsible for doing to ensure the overall requirement is implemented effectively.

Label the Responsibility Type for each AO using one of three options:

• Fully Covered / Fully Inherited: The ESP is fully responsible.
• Shared Responsibility / Partial Inheritance: Both the OSC and ESP contribute to implementation.
• Full Customer Responsibility / No Inheritance: The OSC is fully responsible.

Then, clearly describe what the OSC must do. This could include providing input, taking action, reviewing results, or maintaining settings. Ensure this information is communicated to the customer and that they understand what they are responsible for.

Step 4: Provide Reference Documentation

List any documents or resources that help explain the control implementation and support audit readiness. This may include:

• Service Level Agreements (SLAs)
• Policies and procedures
• System Security Plan (SSP) references
• Support tickets or change logs

Step 5: Include CRM Maintenance Details

Every CRM should define who maintains the document, how often it is reviewed, and under what conditions it must be updated (e.g., new version of the service, change in system scope, change in contract terms). The CRM should also indicate the last review date and the responsible party.

While the ESP is responsible for maintaining and updating the CRM, the OSC must ensure it is collected, appropriately referenced in the SSP, and aligned with their system usage.

Summary: CRM Development in Five Steps

• Define the service and its role in compliance
• Map the applicable controls and assessment objectives
• Assign responsibility for each AO and describe OSC actions
• Reference supporting documentation
• Maintain version control and provide SSP-ready language

When Should an OSC Request the CRM?

Request the CRM at the earliest opportunity, especially:

• When evaluating or onboarding a new ESP
• Before finalizing or updating the System Security Plan (SSP)
• When revising scope documentation or boundary definitions
• Prior to a CMMC assessment
• When preparing the POA&M or identifying inherited/shared gaps

Procrastination leads to gaps in documentation and unprepared assessment answers.

How Should an OSC Use a CRM?

An OSC should actively integrate the CRM into their compliance program:

• Incorporate CRM content into the SSP under the control it relates to
• Use the CRM to verify shared or inherited controls during internal audits
• Use CRM action items to guide internal responsibilities for monitoring, logging, or configuration
• Reference it in Continuous Monitoring Plans (ConMon)
• Prepare for assessment questions using CRM entries to show what the OSC does vs. what the ESP does

Where Should the CRM Be Referenced?

• System Security Plan (SSP): Each shared/inherited control should have language like:
  “This requirement is implemented through [ESP]. The customer responsibilities are described below. The provider responsibilities are documented in the CRM, Appendix X.”
• Body of Evidence (BoE): Include the full CRM or link it as a supplemental document.
• POA&M: Use CRM to describe who is responsible for remediation activities on shared controls.
• Assessment Prep Guides: Use CRM content to prepare SMEs and technical staff for interviews.

Final Thoughts

CRMs and SRMs are not just paperwork—they’re instruments of clarity, accountability, and successful compliance.

• The CRM ensures your assessors understand your responsibilities.
• The SRM ensures your team and your providers know who owns what.
• Together, they support a strong, audit-ready security program.

If you’re working with any service providers in your CMMC environment, start composing your CRM now—before your system falls out of tune.