Terms / Scope and assets
Customer responsibility matrix
The document from a service provider that says which requirements it meets and which are yours. The rule requires one for every ESP.
Also called CRM, customer responsibility matrices.
Official Source Material
The use of an ESP, its relationship to the OSA, and the services provided need to be documented in the OSA's SSP and described in the ESP's service description and customer responsibility matrix (CRM), which describes the responsibilities of the OSA and ESP with respect to the services provided.
Source: 32 CFR 170.19(c)(2)(ii), eCFR text current as of September 17, 2026
Practitioner Guidance
What it means in practice
This document tells you which requirements are yours, and the rule requires it.
A customer responsibility matrix lists the security requirements and says, for each one, whether the provider implements it, you implement it, or you share it. Section 170.19(c)(2)(ii) requires the provider to describe the split for every external service provider. Do not accept a shared responsibility matrix in its place, because that document describes a platform rather than your requirements. Ask for the right one before you sign, not before you are assessed.
Read the shared rows first, because that is where responsibility falls through.
A row marked provider is usually safe. A row marked customer is clearly yours. A row marked shared means the provider supplies the capability and you configure it, and that configuration is your evidence. A shared row is where a control ends up owned by nobody and switched on by nobody.
A matrix is not evidence that a control works.
It records who is responsible. For the rows that are yours, you still hold the configuration and records that show the control runs. For the rows that are the provider's, you hold the matrix and whatever assurance the provider gives you. This is what inheritance actually looks like in a file.
The matrix has to cover the service you bought, not the provider's best offering.
Providers publish one matrix for a product family and sell several tiers of it. Check that the matrix matches your plan, your region, and the features you actually licensed. A control described in the matrix but absent from your tier is a gap you own.
What falls short
- A matrix for a product you did not buy. It has to describe the service you use.
- A matrix with no shared rows at all. Almost every real service splits responsibility somewhere, and a matrix without splits has not been written carefully.
- A matrix held in a sales folder and never mapped to your plan. The rule asks you to document the relationship and the services in your system security plan too.
Edge cases
- Your provider has never produced one. Ask anyway, and record the answer. A provider with defense clients will have something, and one that does not is a risk to your timeline.
- You use several providers whose matrices overlap on a requirement. Decide which one you rely on and write it down, because two owners often means none.
- Your provider updates the matrix after a platform change. Re-read the shared rows, because a default that moved is a control that may have moved with it.
Over-engineering
- Building your own matrix for a provider that supplies one. Map theirs to your plan instead.
- Demanding a matrix from a vendor that handles neither your information nor your security data. That vendor is not an external service provider under the rule.