A PCI responsibility matrix is a table that records, requirement by requirement, whether you, a third-party service provider (TPSP) or both of you are responsible for meeting PCI DSS. Requirement 12.8.5 in PCI DSS v4.0 says you must maintain that information for every TPSP, and requirement 12.9.2 says service providers must supply it when customers ask. A workable matrix is simple: one row per requirement, a named owner, a written split for anything shared, and a pointer to the evidence.
This post covers what the standard asks for and how to build a matrix that holds up in an assessment.
What is a PCI responsibility matrix?
Outsourcing a service takes controls out of your hands without taking them out of your assessment. Your assessor, or your own Self-Assessment Questionnaire, still needs an answer for every applicable requirement. Sometimes that answer is "our hosting provider handles this, and here's the proof."
A responsibility matrix puts those answers in one place. The PCI Security Standards Council (PCI SSC), in its third-party assurance guidance, describes it as a schedule or appendix that sets out each party's responsibilities in an easy-to-understand, tabular format. It's also the quickest way to spot controls that nobody owns.
What does PCI DSS v4.0 require for managing service providers?
Requirement 12.8 covers your side of the relationship: managing the TPSPs you share account data with, or that could affect its security.
| Requirement | What it asks for | What it looks like in practice |
|---|---|---|
| 12.8.1 | A list of all TPSPs that account data is shared with or that could affect its security, with a description of each service | A maintained inventory, not a raw procurement export |
| 12.8.2 | Written agreements that include each TPSP's acknowledgment of responsibility for the account data it handles, or for the security it could affect | Contract clauses or addenda for every listed TPSP |
| 12.8.3 | An established process for engaging TPSPs, including due diligence before engagement | A documented onboarding checklist that security signs off |
| 12.8.4 | A program to monitor each TPSP's PCI DSS compliance status at least once every 12 months | Annual collection and review of Attestations of Compliance (AOCs), with follow-up |
| 12.8.5 | Information on which requirements each TPSP manages, which you manage, and which are shared | The responsibility matrix |
Requirement 12.8.5 isn't new. The v3.2.1 version asked which requirements were managed by each service provider and which by the entity. Version 4.0 names the shared category explicitly, and that's the category where gaps tend to hide.
What must service providers give their customers?
Requirement 12.9 is the service provider's side and applies only to service providers.
- 12.9.1: TPSPs acknowledge in writing that they're responsible for the security of account data they possess, store, process or transmit for the customer, or to the extent they could affect the security of the customer's cardholder data environment (CDE).
- 12.9.2: New in v4.0. TPSPs must support customers' requests for information to meet 12.8.4 and 12.8.5. On request, they must provide their PCI DSS compliance status for any service they perform for customers, and information on which requirements are theirs, which are the customer's and which are shared.
If you're a service provider as well as a customer, as many hosting and managed service firms are, you need both sides. That means one matrix for your customers and another for your own suppliers.
Which service providers belong in the matrix?
Start with your 12.8.1 list. The test is wider than "who touches card numbers", because it includes anyone who could affect the security of account data. Typical entries include:
- Payment gateways and processors
- Cloud infrastructure and hosting providers
- Managed network, firewall and security monitoring providers
- Hosted telephony or call recording services used for phone payments
- Data center and colocation providers
- Off-site backup and media storage services
- Developers or support firms with administrative access to in-scope systems
Each one needs matrix coverage, even if most of its rows turn out to be "not applicable".
How do you build a PCI responsibility matrix?
1. Collect what your providers already publish
Ask each TPSP for its current AOC and its responsibility information under 12.9.2. Larger providers often publish a standard responsibility document for each service. Check the AOC's list of services included in the assessment. If a service you use isn't there, the AOC doesn't cover it.
2. Choose the level of detail
Use one row per PCI DSS requirement, numbered to match the version you're assessed against. With v3.2.1 retiring on 31 March 2024, anything you build now should use v4.0.
Rows at the level of whole principal requirements are too coarse. A hosting provider might own all of the physical controls in Requirement 9 but share parts of Requirement 8 with you. Sub-requirement rows take longer to build, but they prevent arguments later.
3. Assign an owner to every row
Use four values and apply them consistently:
- Entity: you own the requirement completely.
- TPSP: the provider owns it, and you rely on its validation.
- Shared: each party covers part of it.
- Not applicable: the requirement doesn't apply to this service, with a short reason.
For every shared row, write the split in a sentence. A cell that only says "shared" tells an assessor nothing.
4. Record the evidence
For each row, note what proves the requirement is met and where that proof lives. TPSP rows usually point to the provider's AOC and the relevant contract clause. Your own rows point to your policies, configurations and logs, and shared rows need both.
5. Name internal owners
Give every entity or shared row a named person or team. When the assessor asks about requirement 10.2.1, someone should already know it's theirs.
6. Tie it to contracts and monitoring
Reference the matrix in your written agreements under 12.8.2, so the split is contractual and not just informal. Review it at least once every 12 months as part of your 12.8.4 monitoring, and whenever a service changes.
What does a responsibility matrix look like?
Here's an illustrative extract for an organization running its payment application on a cloud infrastructure service. Your actual split will depend on the service and your provider's own documentation.
| Req. | Topic | Owner | How it's split | Evidence |
|---|---|---|---|---|
| 9.2.1 | Physical entry controls for facilities | TPSP | Provider controls its data centers | Provider AOC and services list |
| 2.2.1 | Configuration standards | Shared | Provider hardens the underlying infrastructure; we harden our virtual machines and services | Provider AOC; our build standards |
| 8.4.1 | MFA for administrative access | Shared | Provider supplies MFA capability; we enforce it for our console and server administrators | Provider documentation; our configuration exports |
| 10.2.1 | Audit logs enabled | Shared | Provider logs its infrastructure; we enable logging for our workloads and account activity | Provider AOC; our logging configuration |
| 11.3.2 | Quarterly ASV scans | Entity | We scan our own internet-facing addresses | ASV reports |
| 12.10.1 | Incident response plan | Shared | Provider notifies us of incidents affecting our services; we run our own plan | Contract clause; our plan and test records |
Keep the matrix in a format that's easy to filter and update. A spreadsheet is fine.
Where do responsibility matrices go wrong?
- "Shared" with no explanation. Both parties assume the other has it covered.
- Assuming the AOC covers everything. It only covers the services listed in it, as they stood when the assessment was done.
- Ignoring the provider's own providers. Your TPSP may rely on others for parts of its service. Ask how it manages them.
- Freezing the matrix at onboarding. Services, features and contracts change, and the matrix has to keep up.
- Mixing versions. A provider's document mapped to v3.2.1 numbering needs translating before it fits a v4.0 assessment.
What if a service provider hasn't validated its own compliance?
PCI DSS allows two routes. A TPSP can undergo its own assessment and give customers evidence such as its AOC. If it doesn't, its services have to be reviewed as part of each customer's assessment.
The second route means your assessor may need access to the provider's people, systems and evidence. Secure that right in the contract before you depend on it.
How can the Third-Party Security Assurance supplement help?
The PCI SSC's Information Supplement: Third-Party Security Assurance was first published in August 2014 and updated to version 1.1 in March 2016. It covers due diligence, engagement, written agreements and ongoing monitoring, and Appendix B contains a sample responsibility matrix.
It predates v4.0, so its requirement numbers follow earlier versions of the standard. The approach carries over well, and the sample matrix is a sensible starting template.
Frequently asked questions
Does the matrix replace the written agreement?
No. Requirement 12.8.2 is separate, and you need both. The best arrangement is a contract that references the matrix, so responsibilities are agreed and enforceable.
Do we need a separate matrix for each provider?
Either approach works: one matrix per provider, or one master matrix with a column for each provider. What matters is that every TPSP on your 12.8.1 list is covered and every row has an owner.
What if a provider won't tell us who is responsible for what?
A service provider validating against v4.0 must support these requests under 12.9.2, so a refusal is a warning sign. Record it as a due diligence finding and escalate it. You may need to include the provider's services in your own assessment, or reconsider the relationship.
How often should we update the matrix?
At least once every 12 months alongside your 12.8.4 monitoring, and whenever a provider, service or contract changes.
Key takeaways
- Requirement 12.8.5 requires you to know who owns each PCI DSS requirement for every TPSP, including shared ones.
- Requirement 12.9.2, new in v4.0, obliges service providers to give you that information and their compliance status on request.
- Build one row per requirement, with an owner, a written split for shared items and a pointer to the evidence.
- Check every provider's AOC covers the services you actually use.
- Keep the matrix tied to your contracts and review it at least annually.