Who meets which PCI DSS requirement, and how the matrix records it
A PCI DSS responsibility matrix is a written record, maintained by the provider and the customer together, that assigns each requirement to the provider, the customer or both. Requirement 12.8.5 expects the entity to keep this record for each third-party service provider it relies on, and the matrix is the document an assessor reads first when testing that split. The matrix does not validate anything by itself. Only the independent QSA assessment, documented in a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance, produces a validated result.
The split depends on three things: the service model, the scope of the provider's own assessment and the evidence the provider can actually show. A provider that runs a shared platform may take on the physical, infrastructure and hosting controls while the customer keeps user access, application configuration and log review. Where a provider meets a requirement on a customer's behalf but cannot show evidence that it is met, that requirement is not in place for the customer. A matrix that claims coverage the provider cannot document is therefore worse than an honest gap, because the customer will rely on it in its own assessment.
Start by asking the provider for its current Attestation of Compliance and the responsibility information it gives customers under Requirement 12.9.2, then check each row against the sections that cover the service you actually buy. Confirm the assessment date, the exact services in scope and whether any requirement was handled through the customized approach. For each requirement marked as shared, write down the specific artifact that proves each side's part, such as a provider's penetration test summary or your own quarterly access review. Treat any row without a named owner and a named artifact as an open item to resolve before the matrix goes to your acquirer or auditor.
How provider, customer and shared responsibilities differ by service model
Under infrastructure services (IaaS) and platform services (PaaS), the provider typically owns the physical facilities, the hardware, the hypervisor layer and much of the managed platform beneath the customer's workloads. The customer typically owns what it deploys on top: operating systems, application code, network configuration, identity and access settings, encryption key choices, logging configuration and the data itself. Many requirements, such as access control and log review, are shared because both parties hold a piece of the control.
- Provider-owned: physical security of data centers, environmental controls and the infrastructure layer the provider operates.
- Customer-owned: guest operating system hardening, application security, cardholder data storage and key use, and user access inside the environment.
- Shared: vulnerability management, logging and monitoring, network controls and change management, where each party runs part of the process.
- Managed services: a managed database or container service may move some configuration tasks to the provider, which changes the split for that component only.
- Assessment reach: a provider's assessment covers the services it lists in scope, so confirm each service the customer uses appears in that scope.
Check the provider's published responsibility matrix against every service in your architecture, then record the split in your own matrix.
A SaaS platform that sits in the payment flow, for example one that stores, processes or transmits account data for its customers, usually owns most of the application-level controls. The platform's own environment, code, release process and tenant isolation fall to the SaaS provider. The customer usually owns how it configures the product, who holds accounts, which integrations it enables and how it reviews its own users and records. The split is rarely clean, so the written agreement has to name the requirements that cross the boundary.
- Provider-owned: secure development, application vulnerability handling, tenant separation and the hosting infrastructure the service runs on.
- Customer-owned: user roles and access reviews within the product, integration settings, and the decision of which data to send to the service.
- Shared: authentication options, logging of administrative actions, and incident response when a breach touches both sides.
- Evidence flow: the provider must be able to show its own compliance status and the responsibilities it accepts for the customer.
- Customer testing: whether the provider supports customer penetration testing or sets limits on it should appear in writing.
Ask the provider which requirements it accepts in writing and which it expects the customer to meet, and compare that list against your own assessment.
A managed service provider that never handles card data can still affect the security of a customer's cardholder data environment through remote administration, privileged access, monitoring or patching. In this model the customer typically keeps ownership of its environment and its data, while the provider owns the security of its own tools, staff, remote access paths and credentials. Shared requirements often include access control, logging and change management, because the provider's actions inside the customer's environment must be traceable and authorized.
- Provider-owned: security of its own administrative workstations, jump hosts, ticketing and monitoring systems, and staff screening.
- Customer-owned: approval of access, scope of the provider's permissions, and the customer's own policies and logs.
- Shared: remote access controls, multi-factor authentication for vendor accounts, session logging and review of changes made by the provider.
- Written acknowledgment: the provider should acknowledge in writing its responsibility for the security of the customer's account data it can affect.
- Evidence: the provider should show which requirements it meets for the customer and how it supports the customer's periodic checks.
Confirm the list of access paths and privileged actions with the provider before the engagement starts, then verify that each one appears in the matrix.
Payment software vendors, hosted payment components and embedded scripts on a checkout page form another group. The vendor often owns the secure development of its code and the controls over its release pipeline, while the merchant owns how it deploys, configures and maintains that code on its own pages or servers. Hosted components can shift parts of the payment page under the provider's control, but the merchant still has to confirm which elements of the page it controls and which it does not. Script and page controls are a common point of confusion, so this split needs explicit confirmation.
- Vendor-owned: secure coding, vulnerability fixes in the product, and the provider's own hosting and build systems.
- Customer-owned: deployment, configuration, patch application on self-hosted components, and the merchant's own page content.
- Shared: change control for updates, monitoring of payment page changes, and maintenance of an accurate inventory of third-party scripts.
- Component scope: whether a hosted element removes parts of the page from scope depends on how it is delivered, so confirm the method with your assessor.
- Update records: the vendor should describe how it notifies customers of security updates and what the customer must do.
Request the vendor's responsibility statement for each component and check it against your page architecture and your assessor's view of scope.
How to build the matrix in six steps
The sequence starts with what the provider runs and how card data moves, then works through the provider's obligations and evidence before assigning each PCI DSS requirement to a party. The output is a signed matrix that the written agreement can reference.
Inventory services and the data flow
Start by listing every service the provider runs for the customer, including hosting, managed network devices, administrative access, backups and support tooling. Draw how account data enters, moves through, is stored in and leaves each component, and mark which components are inside the cardholder data environment and which could affect its security. The provider's engineering and architecture leads usually own this step, with the customer's payment team reviewing it. It is done when both parties agree on one diagram and one component list that they can reference by name.
List the provider's TPSP obligations
Identify which third parties the provider itself depends on, such as cloud hosts, colocation operators, payment gateways, support vendors and software suppliers that could affect account data. Under Requirement 12.8, the customer must track these, so the provider needs a current register of them with the requirements each one manages. The provider's compliance lead owns the register, and the output is a list of named third parties, each tied to the services it supports and to the evidence the provider holds for it.
Collect current AOCs and responsibility documents
Request the Attestation of Compliance for the provider and for each relevant third party, along with the responsibility summary or the relevant sections of its Report on Compliance or SAQ D. Check the validation date, the scope statement and whether the services you use are inside that scope, since a valid attestation for one service does not cover every service. Also ask which requirements the provider states it leaves to the customer. The output is a dated evidence folder with a note on any service that is missing from the scope.
Map each requirement to a responsible party
Work through the 12 principal requirements and their sub-requirements in order, and record for each one whether the provider, the customer or both meet it. Use the provider's responsibility documents as the starting point, then check the result against the data flow from step one, since shared responsibility often shifts at the boundary of a specific service. Where a requirement has no owner, treat it as a gap and escalate it. The output is a complete draft matrix with an owner on every row.
Document each shared control with evidence
For every requirement marked as shared, write down the exact control each side operates, the boundary between them and the evidence each party produces. Name the artifact, its owner and how often it is refreshed, such as access review records, log retention settings or vulnerability scan reports. Where the provider cannot produce evidence for a control it claims to meet, the requirement is not in place for the customer, so mark it open rather than assuming coverage. The output is a shared-controls register where every row names a control, an owner and an evidence item.
Sign the matrix into the written agreement
Attach the finished matrix to the written agreement between the provider and the customer, and have authorized representatives from both parties sign or accept it. Confirm that the agreement includes the provider's written acknowledgment of its responsibility for account data security, and that it sets out how the provider will supply compliance status on request. Schedule the matrix for review whenever the scope, a service or a third party changes. The output is a signed, versioned matrix that both assessors can reference.
Which provider evidence supports the matrix
A responsibility matrix is only as strong as the evidence behind each row. The cards below list the provider documents a customer should request before marking a requirement as met by the provider, and the checks to run on each one. Every document needs a date and a stated scope, and each must cover the service the customer actually uses.
Attestation of Compliance and service coverage
The provider's Attestation of Compliance (AOC) is the primary proof that an independent assessor validated the provider. Check the assessment date, the PCI DSS version it names, and whether the listed services include the exact product, region and deployment model you use. A certificate or logo is not validation, so an AOC that omits your service does not support the matrix for that service. Confirm the coverage with the provider in writing.
Relevant ROC or SAQ D sections
Under FAQ 1576, a service provider should give customers relevant sections of its Report on Compliance or SAQ D on request, in addition to the AOC. Ask for the sections covering the requirements the matrix assigns to the provider, such as access control, logging, and key management. Redact sensitive detail under a non-disclosure agreement, but confirm that the sections you receive still match the scope and date of the AOC.
Provider responsibility summary
A provider's responsibility summary states, for each requirement, whether the provider, the customer or both are responsible. Use it as the starting point for your own matrix rather than copying it unchanged, since it reflects the provider's service boundary and not your configuration. Check every row that touches your cardholder data environment, and flag any requirement the summary leaves blank or marks as customer responsibility without explanation.
Current scope and network diagrams
Ask for a current scope statement and network diagram that show which provider systems, facilities and administrative paths can affect your cardholder data. A diagram from two years ago cannot confirm that a new region, shared tenancy or management plane sits outside or inside scope. Compare the provider's scope with your own data flow diagrams, and record every point where the two boundaries meet, because those points usually drive the shared requirements.
Monitoring of the provider's own controls
Requirement 12.8.5 expects you to know how the provider manages its own controls, so ask for evidence that the provider monitors them. Useful artifacts include recent vulnerability scan and penetration test summaries, internal review records, and incident notification procedures. Confirm the period each artifact covers and whether the provider tells customers about material changes between assessments. Gaps in this evidence should move the affected rows toward shared responsibility until resolved.
Written acknowledgments of responsibility
Requirement 12.9.1 requires a service provider to acknowledge in writing that it is responsible for the security of the account data it stores, processes or transmits, or could affect. Confirm that the signed agreement contains this acknowledgment and that it refers to the responsibilities in your matrix. An acknowledgment that is missing, generic, or not signed by an authorized person leaves the matrix without a contractual basis, and that gap should be resolved before the matrix is used in your assessment.
Using AWS and Azure responsibility matrices correctly
A cloud provider's PCI DSS status does not validate what you build on top of it. AWS states that it is assessed as a PCI DSS Level 1 Service Provider by Coalfire, an independent QSA, and that customers obtain the AWS PCI DSS Attestation of Compliance and Responsibility Summary through AWS Artifact in the AWS Management Console. Microsoft takes the same position for Azure: its PCI DSS status does not automatically translate to validation of services customers build or host there, and it publishes an Azure PCI DSS Shared Responsibility Matrix showing, for each requirement, whether Azure, the customer or both are responsible. Download both documents, confirm their assessment dates and the scope of services they cover, and check that every service in your cardholder data environment appears in the provider's assessed list.
The provider matrix tells you only what the provider handles. You still have to map your own layer: the operating system images and hardening baselines on your instances, the cloud configurations that control network paths, storage encryption and logging, the application code that handles primary account numbers, and the identities your staff use to reach the environment. Build a second matrix for these items, assign an owner to each requirement, and record the evidence that proves it, such as configuration exports, access review records and log retention settings. Where a requirement is shared, write down the exact boundary so that neither party assumes the other has covered it.
Treat the matrix as a statement of responsibility, not a finding of compliance. An assessor will test the controls in your environment, and if you rely on a provider for a requirement you cannot produce evidence for, that requirement is not in place for you. Ask your provider in writing which documents it will supply on request, how often it updates its matrix, and how it notifies customers when a service moves in or out of its assessed scope. Your own team, or a consultant working within the independence rules of the assessment, should review both matrices against your architecture before your assessor begins fieldwork.
What happens when a provider cannot show evidence
A provider's claim that it meets a requirement on a customer's behalf only counts if the provider can prove it. The cards below cover how the customer's assessor treats unproven requirements, what remediation paths exist, and which contract terms secure the evidence before a gap appears.
Unproven claims count as open
PCI SSC FAQ 1312 says that if a service provider meets PCI DSS requirements on a customer's behalf but cannot show evidence that they are met, those requirements are not in place for the customer. The provider's marketing statement or general certification is not enough on its own. Check each row of the matrix the provider claims and ask for the evidence that row depends on, such as a current AOC, a relevant ROC section or a configuration record.
Assessor treats the requirement as open
When the customer's QSA reviews the matrix and finds a requirement attributed to a provider without supporting evidence, the QSA will record that requirement as not met for the customer's environment. The customer then has to explain the gap in its own Report on Compliance or Self-Assessment Questionnaire. Confirm with your assessor early how they expect provider evidence to be presented and how recent it must be.
Remediate the gap internally
The customer can meet the requirement itself, for example by running its own log review, file integrity monitoring or vulnerability scans over the systems it controls. The matrix must then be updated so the requirement moves from shared or provider-owned to customer-owned. Work out the internal owner, tooling and evidence before the assessment window opens, since the gap does not close on paper alone.
Compensating controls need proof
A compensating control may be considered only where a constraint prevents meeting a requirement as written and the alternative meets the same intent. The control must be documented, tested and supported by evidence the assessor can review. Treat it as a last resort, because an undocumented or untested alternative is unlikely to survive review. Confirm the current rules for compensating controls with your assessor and the PCI SSC blog on the topic.
Customized approach needs objective evidence
The customized approach lets an entity meet a stated objective in a different way, and the PCI SSC limits it to entities with robust security and risk management. Using it for a provider gap requires a documented, targeted risk analysis and evidence that the alternative achieves the objective. Expect the assessor to test that evidence in the same way as the defined approach. Ask your assessor whether they will accept the approach before you commit engineering time to it.
Contract clauses for evidence delivery
Write evidence obligations into the agreement before the gap appears. Request a current AOC on an annual basis, access to relevant ROC or SAQ D sections on request, written acknowledgment of responsibility for account data security, and notice of changes to the services or their assessment status. Include a clear right to request additional evidence for any requirement the provider claims to meet. Ask counsel to review how these clauses interact with the provider's standard terms.
Who owns the matrix, the assessor and the implementation partner
The organization owns its PCI DSS controls and the responsibility matrix it adopts. Ultimate responsibility for payment data security cannot be outsourced. The PCI SSC has said that using a cloud service provider does not remove that responsibility, and that written agreements and responsibility matrices should state which party meets which requirement. Whoever signs the matrix, whether a merchant, a service provider or a SaaS company, is the party that must be able to defend each line of it to an assessor.
An implementation partner such as DeployOpen can help prepare the systems, controls and evidence behind the matrix, and can draft the matrix from a written scope that the client approves. That work includes mapping which configurations, logs, access reviews and tests exist, where they live, and who produces them. It does not make the partner a party that validates the result. DeployOpen prepares systems and evidence for assessment; it does not issue reports, attestations or certificates. Before work starts, confirm in writing that the partner's role is limited to preparation.
Only the Qualified Security Assessor or other assessor issues the Report on Compliance or the Self-Assessment Questionnaire, along with the Attestation of Compliance. Ask early whether the assessor will review your draft matrix against the evidence it expects to sample, and whether it accepts provider evidence for the services you rely on. Keep the matrix, the evidence index and the assessor's sampling requests in one controlled location so that each responsibility line can be traced to a named owner and a current artifact at assessment time.
Questions providers and customers ask about the responsibility matrix
Does a service provider have to be validated for its customer to meet Requirement 12.8?
No. A service provider does not have to be validated for a customer to satisfy Requirement 12.8, but the customer still needs evidence. If a provider meets PCI DSS requirements on the customer's behalf and cannot show evidence that those requirements are met, the customer cannot treat them as in place. Ask the provider for its current Attestation of Compliance, its responsibility matrix and the sections of its Report on Compliance or SAQ D that cover the requirements it claims. Confirm that the evidence names the specific services in use, not only the provider's general business.
Does a cloud provider's AOC cover the systems we build on its platform?
Usually not on its own. A cloud provider's Attestation of Compliance describes the services it assessed and the requirements it covers for its own infrastructure. Microsoft states that Azure's PCI DSS status does not automatically validate services a customer builds or hosts on Azure, and it publishes a shared responsibility matrix that shows, for each requirement, whether Azure, the customer or both are responsible. AWS makes its Attestation of Compliance and Responsibility Summary available through AWS Artifact. Confirm which services are in your architecture, check that each one appears in the assessed scope, and assign the remaining requirements to your own team or to a partner in writing.
How often should we refresh the responsibility matrix?
At least every 12 months, aligned with the monitoring duty in Requirement 12.8.4, and whenever the payment flow changes. The matrix is only as current as the provider's latest evidence, so schedule the refresh around the provider's annual assessment date. Trigger an earlier review when the provider adds a service, changes its hosting region, changes a subprocessor, or your own architecture moves a component into or out of the cardholder data environment. Keep dated versions so an assessor can see what was in place at the time of your own assessment.
Who should sign the responsibility matrix?
Both parties should sign or formally acknowledge it, usually as part of the written agreement that carries the security acknowledgments required by Requirement 12.8.2. On the provider side, the signer should have authority over the services listed and the evidence behind them. On the customer side, it should be the owner of the payment environment, often the person accountable for the PCI DSS program, with input from security and engineering. Confirm who can change the matrix mid-term and how changes are communicated, because an unsigned edit can quietly move a requirement from one party to the other.
Do we need the provider's SAQ D or its full ROC?
It depends on what you need to verify. A service provider generally supplies its Attestation of Compliance on request, and customers may also ask for the relevant sections of the provider's Report on Compliance or its SAQ D. The SAQ D for service providers is the questionnaire that covers the requirements in Requirement 12.9, including the provider's acknowledgment of responsibility and its support for customers' 12.8.4 and 12.8.5 duties. Ask for the sections that cover the services you use, and confirm with your acquirer or payment brand whether they expect a particular format for your own validation. Full reports often carry confidentiality terms, so agree how the provider will share them before you need them.
What should we ask for before procurement signs a provider?
Ask for four things before signature. First, the provider's current Attestation of Compliance and the date it covers. Second, a draft responsibility matrix that lists every requirement in your environment and assigns each to the provider, your team or both. Third, the provider's written acknowledgment of its responsibility for account data security, as described in Requirement 12.9.1. Fourth, a commitment to provide evidence on request and to notify you of material changes. Also confirm which subservice providers the provider uses, because their evidence may be needed too. Lawyers and procurement should not sign until the matrix can be checked against the provider's evidence. If the provider cannot produce these documents, treat that as a finding in your own risk assessment, and confirm the gap with your QSA before relying on the service for cardholder data.
How DeployOpen prepares the responsibility record and its evidence
DeployOpen works on the responsibility record as an implementation task: we scope the self-hosted platforms in your environment, prepare the systems and evidence behind each requirement, and hand over a matrix your team and assessor can check. Ownership of every control stays with your organization, and only an independent QSA or assessor can issue a report or attestation.
How we scope
- Each written scope names the platforms, environments and provider boundaries the matrix will cover.
- We list which requirements your organization owns, which the provider meets and which are shared.
- Scope boundaries and exclusions are agreed in writing before any work starts, as engagements are fixed-scope.
- Ongoing support for the matrix can be set up as a retainer after the initial handover.
How we build
- We configure self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
- We map each platform component to the evidence it produces, such as logs, configuration baselines and access records.
- We draft the matrix entries for each sub-requirement in the 12.8 and 12.9 record, using your environment as the basis.
- We test that the evidence each entry cites can actually be produced on request.
How we hand over
- You receive the responsibility matrix, the supporting configuration records and an evidence index tied to each entry.
- Documentation states which party is accountable for each requirement and where the matching evidence is stored.
- We walk your team through how to refresh the matrix when systems, providers or scope change.
- Your QSA or assessor reviews the record independently, since DeployOpen does not issue reports or attestations.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer work can keep provider evidence current, such as requests for updated attestations and responsibility summaries.
- We can rerun security testing against platforms in scope so the matrix reflects their current state.
- Quotes follow from the written scope, so ask for the exact deliverables, exclusions and review points before signing.
