PCI DSS for Service Providers and Responsibility Matrix Guide: Requirements 12.8 and 12.9, AOCs and Shared Controls

Most PCI DSS failures involving third parties are not technical: the customer and the provider each assume the other one owns a requirement, and nobody does. PCI DSS v4.0.1 deals with this through Requirement 12.8 for customers, Requirement 12.9 for third-party service providers (TPSPs), a set of extra requirements that apply only to service providers, and Appendix A1 for multi-tenant providers. This guide explains who counts as a service provider, what each side must do, how to read an Attestation of Compliance (AOC) and build a responsibility matrix that an assessor will accept, and how cloud shared responsibility fits. It is for compliance managers at merchants and service providers, vendor risk teams, cloud and managed service architects, and assessors. The PCI DSS 4.0 Guide covers the standard as a whole; this page goes deeper on third parties.

Key takeaways

• Using a compliant TPSP never makes you compliant. The applicability note to 12.8.1 says use of a PCI DSS compliant TPSP does not remove the entity's responsibility for its own compliance.
• 12.8 does not require your TPSPs to be compliant. It requires you to list them, contract with them, do due diligence, monitor their status at least every 12 months and record who manages which requirement.
• A brand listing is not enough for requirements a TPSP meets for you. For those, PCI DSS expects evidence such as the AOC, relevant ROC sections or specific evidence, showing the service you use was in the TPSP's assessment scope.
• Service providers carry extra requirements. At least 15 requirements apply only to service providers, including six-monthly scope confirmation (12.5.2.1), quarterly operational reviews (12.4.2) and six-monthly segmentation tests (11.4.6).
• The responsibility matrix is the core artefact. 12.8.5 and 12.9.2 together mean both sides must hold the same record of which requirements are the TPSP's, the customer's or shared, per service.

Who is a service provider in PCI DSS

The PCI DSS glossary defines a service provider as a business entity, other than a payment brand, directly involved in processing, storing or transmitting cardholder data or sensitive authentication data on behalf of another entity. It explicitly includes payment gateways, payment service providers and independent sales organisations, and companies whose services control or could impact the security of that data, such as managed firewall and IDS providers and hosting providers. A telecoms company that only supplies a public network link is not a service provider for that service. A multi-tenant service provider is a TPSP whose customers share resources such as servers, infrastructure, applications (including SaaS) or databases. Co-location providers that only rent space, equipment and bandwidth are not multi-tenant providers for Appendix A1.

Scope decisions about which providers connect to the CDE belong to scoping. See the PCI DSS Scoping and Network Segmentation Guide.

Customer obligations: Requirement 12.8

• 12.8.1 Inventory: keep a list of all TPSPs with which account data is shared or that could affect its security, with a description of each service. Include providers that never see card data but manage in-scope systems.
• 12.8.2 Written agreements: agreements with all such TPSPs must include the TPSP's acknowledgement that it is responsible for the security of account data it holds or processes for you, or to the extent it could impact your cardholder data or sensitive authentication data.
• 12.8.3 Due diligence: an established process for engaging TPSPs, including due diligence before engagement. The customised approach objective frames this as assessing a prospective TPSP's capability, intent and resources to protect account data.
• 12.8.4 Monitoring: a programme to monitor each TPSP's PCI DSS compliance status at least once every 12 months.
• 12.8.5 Responsibility record: information on which requirements each TPSP manages, which you manage, and which are shared. The customised approach objective adds that the record covers related system components and is reviewed periodically.

The standard's section on use of TPSPs is explicit that 12.8 applies to TPSPs that have access to the CDE, manage in-scope components for you, or can impact the security of your data. The wider vendor risk process sits around this. See the Third-Party Risk Management Guide and the Third-Party Security Contract Clauses Template.

Service provider obligations: 12.9 and the provider-only requirements

12.9.1 is the mirror of 12.8.2: TPSPs provide written agreements to customers acknowledging their responsibility for account data. 12.9.2 requires TPSPs to support customer requests for their compliance status (for 12.8.4) and for the split of TPSP, customer and shared responsibilities (for 12.8.5), for any service that meets a requirement on the customer's behalf or can impact the security of customer data. Beyond these, PCI DSS v4.0.1 marks a set of requirements "Additional requirement for service providers only". All of the former future-dated ones have applied since 31 March 2025.

Validation options and the evidence to collect

PCI DSS gives TPSPs two ways to validate services that meet or affect customers' requirements: an annual assessment with evidence provided to customers, or multiple on-demand assessments, where the TPSP is assessed at customers' request or takes part in each customer's assessment. The standard expects a TPSP with an AOC to provide it on request, and says customers may also request relevant, possibly redacted, sections of the ROC.

A SOC 2 report helps with due diligence, but it is not PCI DSS evidence. See the How to Read a SOC 2 Report Guide and the Third-Party Attestation Comparison Map.

Building a responsibility matrix that holds up

PCI DSS points to the PCI SSC Information Supplement: Third-Party Security Assurance for a sample matrix. Whatever format you use, it must work at the level of sub-requirements and per service, because a provider may own 9.4 for one service and nothing for another.

1. One matrix per service: list the specific service and its system components, not the vendor in general.
2. Every applicable sub-requirement as a row: mark each as TPSP, customer, shared or not applicable. "Shared" must describe exactly which part each side does.
3. Tie each TPSP row to the AOC: any row marked TPSP must sit within the services and requirements covered by the TPSP's assessment, or be backed by specific evidence.
4. Turn every customer row into a control: each customer or shared row needs a named owner and an entry in your own control evidence.
5. Review on change: refresh when services, architecture or the TPSP's AOC change, and at least at each annual status check under 12.8.4.

Cloud shared responsibility example

The standard gives one example itself: a cloud provider should state which IP addresses it scans quarterly and which are the customer's responsibility. Typical splits for an IaaS customer look like this:

• Provider: physical security of data centres (Requirement 9), hypervisor and underlying network security for the services assessed.
• Customer: guest operating system hardening, application security, network security group and firewall rules, account management for its own users and workloads, logging configuration and review.
• Shared: encryption of stored account data where the provider runs the key service but the customer configures keys and access; vulnerability scanning split by IP range; incident response with A1.2.2 forensic support.

The general model is covered in the Shared Responsibility Models Guide.

Where identity fits

Third-party access is mostly identity: provider staff logging into customer systems and provider applications holding standing credentials into customer environments.

• Per-customer credentials: 8.2.3 requires a service provider with remote access to customer premises to use unique authentication factors for each customer, so one stolen credential cannot open every customer.
• Third-party remote access: 8.2.7 requires accounts used by third parties for remote access to be enabled only when needed, disabled otherwise and monitored for unexpected activity. Put this in the matrix as a customer row even where the TPSP supplies the accounts.
• Machine identities of the provider: integration apps, API keys and service principals a provider holds into your environment are system accounts under 8.6. See the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6) and the OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide.
• Multi-tenant separation: A1.1.1 to A1.1.3 require that the provider cannot reach customer environments without authorisation, and customers can reach only their own data and resources. Ask how provider administrator access to tenant environments is authorised and logged.

How to implement

1. Build the 12.8.1 list: start from procurement, the network diagram and data flows, and identity logs showing third-party accounts and applications. Tag each provider with the services it delivers.
2. Classify each service: stores or processes account data, manages in-scope components, can impact security, or none.
3. Close the contract gaps: add the 12.8.2 acknowledgement, a right to the AOC and responsibility matrix, and incident notification terms. Providers check that their template agreements meet 12.9.1.
4. Collect evidence: request the AOC and matrix, compare service names and dates, and record exceptions.
5. Pilot with the highest-risk providers: gateway, hosting and managed security first; run the matrix past your QSA before rolling it out to all providers.
6. Operate it: set the 12-month status review, track AOC expiry dates and trigger a review when a provider changes services. If a provider cannot evidence a requirement, take it back as a customer row or find another provider.

Decision guidance

• Provider AOC or include them in your assessment: an AOC that covers your service is cheaper for both sides. Where a provider has no AOC, plan for your assessor to test the provider's controls and agree access in the contract.
• Small merchants: outsourcing payment pages and processing to a validated provider can shrink scope a great deal, but the 12.8 duties stay. See the Card Payments Security for Small Merchants Guide.
• Large service providers: publish a standard matrix per service and a request process for 12.9.2, so you are not answering every customer from scratch.

Detection and measurement

• Coverage: percentage of TPSPs on the 12.8.1 list with a current status check in the last 12 months (target 100%).
• Evidence quality: percentage of TPSP-owned matrix rows backed by an AOC whose scope names the service.
• Expiry: number of AOCs older than 12 months still relied on.
• Unowned rows: customer or shared rows with no named owner (target zero).
• Third-party access: third-party remote access accounts enabled outside an approved window, and provider applications with unused permissions.

Framework mapping

Common failure patterns

• Collecting an AOC without reading it: the AOC covers a different service, data centre or product line from the one you buy, or is more than a year old.
• "Shared" with no detail: rows marked shared without saying which side configures, operates and evidences what, so neither side tests it.
• Forgetting providers that never touch card data: managed firewall, remote support and logging providers can impact security and belong on the 12.8.1 list.
• Treating a brand listing as full evidence: PCI DSS says a listing is not sufficient evidence for requirements a TPSP meets on your behalf.
• Provider credentials reused across customers: one support account or application secret for every customer conflicts with the intent of 8.2.3 and turns one compromise into many.
• Customer controls left off because the platform offers them: MFA, network restrictions and credential rotation configured by the customer are still customer rows.

Lessons from incidents

• Customer-side controls on a provider platform: in the Snowflake Breach 2024, Snowflake and Mandiant found no flaw in the platform; attackers used infostealer credentials against customer accounts with no MFA, no network allow lists and unrotated passwords. In a matrix, those controls are customer rows, whatever the provider makes available.
• A provider credential that reaches every customer: in the ConnectWise Cloud Backup Breach 2026, a stolen secret for a multi-tenant backup application signed in to over 160 Microsoft 365 tenants without any user or MFA involved. It was not a card data incident, but it shows why provider machine identities, their permissions and per-customer separation belong in third-party due diligence.

Practitioner checklist

• Maintain a 12.8.1 list that includes every provider that manages in-scope components or could impact security, with service descriptions.
• Confirm each agreement contains the responsibility acknowledgement required by 12.8.2 and 12.9.1.
• Record due diligence before engagement, including PCI DSS status and the services covered.
• Check every TPSP's compliance status at least every 12 months and track AOC dates.
• Hold a per-service responsibility matrix at sub-requirement level, with owners for every customer and shared row.
• Match every TPSP-owned row to the AOC scope or specific evidence.
• As a provider, run the six-monthly scope confirmation, quarterly reviews and six-monthly segmentation tests.
• Require unique credentials per customer for provider remote access and inventory provider applications in your environment.

Standards and references

• PCI SSC: PCI DSS v4.0.1 Requirements and Testing Procedures
• PCI SSC: Information Supplement, Third-Party Security Assurance
• PCI SSC: PCI DSS v4.0.1 Attestation of Compliance for Service Providers
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · PCI DSS Scoping and Network Segmentation Guide · Third-Party Risk Management Guide · Shared Responsibility Models Guide · PCI DSS Readiness Checklist