Category: Cloud Security & Providers

Customer Responsibility Matrix

Also known as: CRM, Customer Responsibilities Matrix, Shared Responsibility Matrix, Control Responsibility Matrix

Simply put

A Customer Responsibility Matrix is a document that spells out which security controls a cloud service provider handles and which ones the customer using the service must handle themselves. It exists because in cloud environments the work of protecting a system is split between the provider and the customer, and each side needs to know exactly what they are accountable for. Without a clear division, controls can fall through the gaps because each party assumes the other is covering them.

Formal definition

A Customer Responsibility Matrix is a control-by-control mapping that allocates responsibility for implementing, operating, and maintaining security controls between a cloud service provider (CSP) and the customer (consuming organization) in a shared-responsibility model. It typically identifies each applicable control and designates it as provider-responsible, customer-responsible, or shared/hybrid, and often describes the specific customer-implemented (or customer-configured) portion the consuming organization must satisfy within its own boundary. In an authorization context, the CRM helps the customer determine which inherited controls are covered by the provider's authorization and which controls remain the customer's obligation to implement and assess for its own system. Practitioners should note that specific control identifiers, baselines, and the precise scope of allocation depend on the applicable framework, revision, and the individual service offering; the actual contents, format, and binding effect of a given CRM should be verified against the provider's documentation and the governing authorization or contractual requirements. A CRM allocates responsibility but does not by itself demonstrate that customer-responsible controls have been implemented or assessed; the customer must still implement and validate those controls, and reliance on a CRM does not transfer accountability for controls designated as the customer's.

Why it matters

In a shared-responsibility model, security failures most often occur not in the controls one party actively manages, but in the ambiguous space between provider and customer. A Customer Responsibility Matrix exists to eliminate that ambiguity by documenting, control by control, who is accountable for what. When this division is unclear or unread, controls can fall through the gaps because each party assumes the other is covering them, a customer may assume the cloud provider is encrypting data or managing access logs when, in fact, that configuration is the customer's obligation. The CRM is the reference document that prevents these assumptions from becoming exposures.

A critical point that practitioners frequently misunderstand is that a CRM allocates responsibility but does not demonstrate compliance. The existence of a matrix stating that a control is customer-responsible does nothing to prove that the customer has actually implemented, configured, or assessed that control. Similarly, inheriting a control from a provider's authorization does not relieve the customer of the obligation to confirm the inheritance is valid for its own system boundary and use case. Reliance on a CRM does not transfer accountability for controls designated as the customer's; accountability for a customer-responsible control remains with the customer regardless of what the matrix says.

For organizations operating in authorization contexts, whether pursuing an Authority to Operate for a federal system or documenting a security posture for CUI, the CRM is generally central to distinguishing inherited controls from those that must be independently implemented and assessed. Because the specific control identifiers, baselines, and scope of allocation depend on the applicable framework, revision, and the individual service offering, the CRM should always be read against the current provider documentation and the governing authorization or contractual requirements rather than treated as a static or interchangeable artifact.

Who it's relevant to

Information System Security Managers and System Owners

These practitioners use the CRM to distinguish inherited controls from controls their organization must implement, operate, and assess within its own boundary. They should treat the matrix as a starting point for scoping their own responsibilities rather than as evidence that customer-responsible controls have been satisfied, and should confirm that claimed inheritances are valid for their specific system and use case.

Authorizing Officials

Officials making risk-based authorization decisions rely on a clear allocation of responsibility to understand which controls are covered by a provider's authorization and which remain the customer's obligation. Because a CRM allocates responsibility but does not by itself demonstrate implementation or assessment, authorizing officials should look for evidence that customer-responsible controls have actually been implemented and validated.

Government Contractors and Cloud Consumers

Organizations consuming cloud services, particularly those handling CUI or supporting federal systems, use the CRM to identify their configuration and implementation obligations. They should verify the matrix against the provider's current documentation and the governing contractual or authorization requirements, and should not assume that a provider's authorization automatically satisfies their own obligations across differing scopes and frameworks.

Assessors and Auditors

Assessors use the CRM to determine the boundary of what the customer must independently demonstrate versus what may be inherited. They should be careful to distinguish assessment from authorization and allocation from implementation: a matrix designating a control as customer-responsible does not establish that the control was implemented or assessed, and each customer-responsible control still requires validation.

Inside CRM

Shared Responsibility Delineation

A mapping of security controls that identifies which party (the cloud service provider, the customer/agency, or both in a shared capacity) is responsible for implementing and maintaining each control. This clarifies boundaries between provider-managed and customer-managed responsibilities.

Control Inheritance Statements

Documentation of which controls a customer can inherit from the underlying service or platform and which must be independently implemented at the customer layer. Inheritance is typically tied to a specific baseline and may vary by impact level.

Customer-Configured Controls

Identification of controls the provider makes available but that the customer must configure, operate, or enforce in their own environment or application layer to achieve full compliance.

Baseline and Impact Level Reference

Association of the matrix with a specific control baseline and impact level (for example, a FedRAMP Low, Moderate, or High baseline), since responsibilities can shift across baselines and revisions. Practitioners should verify the applicable revision against current authoritative sources.

Mapping to a Controlling Control Set

A cross-reference of responsibilities to the underlying control catalog (commonly NIST SP 800-53 controls used within FedRAMP authorizations), noting that the exact control identifiers depend on the revision in effect.

Common questions

Answers to the questions practitioners most commonly ask about CRM.

Does a cloud service provider's FedRAMP authorization mean all controls are handled by the provider?

No. A common misconception is that authorization means the provider satisfies every control on the customer's behalf. The Customer Responsibility Matrix (CRM) exists precisely because responsibility for many controls is shared or falls entirely to the customer. The CRM identifies which controls the provider implements, which are shared, and which the customer must implement in their own environment. Reviewing the CRM is generally necessary to understand what the customer still owns; treating the provider's authorization as covering everything typically leaves customer-responsible controls unaddressed.

If a service is FedRAMP authorized, does the CRM automatically satisfy DoD requirements?

Not necessarily. FedRAMP authorization and any accompanying CRM address the FedRAMP baseline as maintained by the FedRAMP PMO, which is distinct from DoD-specific requirements. A CRM produced for a FedRAMP context does not automatically demonstrate satisfaction of DoD authorization requirements under the RMF or of contractual obligations that may apply to CUI. Readers should confirm scope against the applicable authority and verify whether additional DoD-specific requirements or a separate assessment applies, rather than assuming one authorization or matrix transfers to another program.

Who is responsible for producing and maintaining the CRM?

In most implementations, the cloud service provider produces the CRM to document how responsibility for controls is allocated between the provider and the customer, and it is typically delivered as part of the authorization package. However, the customer generally remains responsible for implementing and documenting the controls assigned to them. The reader should confirm delivery, format, and update expectations against the specific agreement and the current authoritative documentation for the service in question.

How should an organization use the CRM during its own authorization process?

The CRM is generally used to map inherited and shared controls into the organization's own security documentation and to identify which controls the customer must implement, assess, and document. It helps distinguish inherited responsibilities from those the customer owns. Because assessment is distinct from authorization, the CRM informs but does not replace the customer's own assessment and authorization activities. Confirm how your authorizing official expects inherited and shared controls to be reflected in your package.

What should be verified when reviewing a shared control in the CRM?

For controls marked as shared, it is generally important to confirm exactly which portions the provider implements and which portions remain the customer's responsibility, because ambiguity in a shared designation can leave gaps. Reviewers should look for a clear description of the customer's implementation obligation for each shared control and confirm that these obligations are addressed in the customer's environment and documentation. Interpretations of a shared designation can vary, so verify specifics against the provider's current documentation.

How often should the CRM be revisited?

Because authorizations are time-bound and subject to continuous monitoring, and because control baselines and service offerings can change across revisions, the CRM should generally be revisited when the underlying authorization is updated, when the service changes, or when the applicable baseline is revised. Treating the CRM as a static, one-time document can result in misalignment between documented responsibilities and current conditions. Confirm update timing and triggers against the current authoritative documentation and your agreement.

Common misconceptions

A CRM proves that the customer's system is compliant or secure once the provider's portion is authorized.

A CRM only allocates responsibility; it does not implement controls or demonstrate the customer's own controls are in place. The customer generally remains accountable for their assigned and configured controls, and compliance is not the same as security. Inheriting a control from a provider does not relieve the customer of controls allocated to them.

If a cloud offering is FedRAMP authorized, the CRM automatically satisfies DoD requirements for the customer's system.

FedRAMP authorization does not automatically satisfy DoD-specific requirements. DoD systems are generally assessed and authorized under the RMF, and additional requirements may apply to CUI (for example under DFARS clause 252.204-7012) or under CMMC. Customers should confirm applicable DoD requirements against current authoritative sources rather than assuming the CRM alone is sufficient.

Once responsibilities are assigned in the CRM, the allocation is fixed and one-time.

A CRM is tied to a specific baseline and revision and is subject to change as control catalogs, impact levels, and agency tailoring evolve. It also supports continuous monitoring rather than a one-time event; an associated Authority to Operate (ATO) is time-bound and subject to ongoing review, so the customer's responsibilities persist over the authorization lifecycle.

Best practices

Confirm the baseline, impact level, and applicable control catalog revision the CRM is built against, and verify these against current authoritative sources before relying on the allocation.

Treat every control marked as a customer or shared responsibility as an action item, and track implementation and evidence for those controls in your own system documentation.

Do not assume inherited controls are complete; validate that provider-managed and customer-configured controls together cover the full requirement for your environment.

For DoD or CUI use cases, separately confirm RMF, DFARS, or CMMC obligations rather than treating a FedRAMP-oriented CRM as sufficient.

Integrate the CRM into continuous monitoring so customer-assigned responsibilities are reassessed as controls, baselines, or the authorization status change over time.

Reconcile the CRM against your organization's own authorization documentation to ensure no allocated responsibility is left unowned or duplicated.