The PCI DSS Shared Responsibility Matrix, Explained — AWS, Azure, GCP and Alibaba Cloud

What Is a PCI DSS Shared Responsibility Matrix?

A PCI DSS shared responsibility matrix is a document from a third-party service provider that states, for every PCI DSS requirement, whether the provider, the customer, or both are responsible for meeting it. For a cloud platform it is the practical expression of the shared responsibility model: the provider secures the cloud, the customer secures what runs in it, and the matrix records where the line sits requirement by requirement.

The document has a formal basis in the standard. PCI DSS v4.0.1 Requirement 12.8 requires you, as the customer, to maintain a list of every third-party service provider (TPSP) that handles cardholder data or could affect the security of your cardholder data environment, to hold written agreements with them, to monitor their PCI DSS status at least annually, and, under 12.8.5, to keep information about which requirements each provider manages, which you manage, and which are shared. Requirement 12.9 is the mirror image for the provider: 12.9.1 requires written acknowledgement of responsibility, and 12.9.2 requires the provider to support its customers' requests under 12.8.4 and 12.8.5 by supplying PCI DSS compliance status and the responsibility split on request.

The PCI Security Standards Council has published guidance on this for years, first in the Information Supplement: Third-Party Security Assurance and in the Cloud Computing Guidelines, both available from the PCI SSC document library. The guidance is provider-neutral and describes exactly the failure the matrix exists to prevent: the customer assumes the provider covers a control, the provider assumes it is the customer's, and nobody operates it.

Where Does Each Cloud Provider Publish Its Matrix?

All four major providers publish a PCI DSS responsibility matrix alongside their Attestation of Compliance, but in different places and under different names. Ask your assessor for both documents at the start of the engagement, and check the dates: the AOC is renewed annually and the matrix is revised when the standard changes.

One caution applies to all four. The matrix is generic across the provider's whole customer base; it cannot know your architecture. Two organisations on the same platform can have very different splits depending on whether they run virtual machines, managed databases, containers or serverless functions. The matrix is the starting point for your own, environment-specific version, not the finished article.

How Do You Read a Responsibility Matrix?

Read each row as a question: for this requirement, in the service model I actually use, who has to do the work and who has to prove it? Providers typically present three categories per requirement or sub-requirement: the provider's responsibility, the customer's responsibility, and shared responsibility. The first two are self-explanatory. The third is the one that causes trouble, because in almost every case "shared" means the provider supplies a capability, such as an encryption service or a logging pipeline, and you are responsible for switching it on, configuring it correctly, operating it, and evidencing it.

The split also moves with the service model. For infrastructure services (virtual machines, virtual networks, block storage) the provider stops at the hypervisor and you own everything above it. For platform services (managed databases, application platforms, managed Kubernetes control planes) the provider takes the operating system and runtime, but identity, network exposure, encryption choices, application code and logging configuration remain yours. The table below shows the typical pattern by requirement family; the provider's own document is authoritative for the specific services you use.

Two families never move to the provider, whichever model you use. Requirement 9 is inherited for the provider's facilities but still applies to your own premises, and Requirement 12, including the service-provider management controls in 12.8 that this article is about, has no cloud service that can perform it for you.

Inherited vs Evidenced: How a QSA Uses the Matrix

A QSA uses the matrix and the AOC together to sort every requirement into two lists: controls inherited from the provider, and controls that must be evidenced from your environment. A control goes on the inherited list only when three things are true: the provider's matrix marks it as the provider's responsibility, the provider's AOC is current, and the specific service and region you use appear in the AOC's scope. If any of the three fails, the control is evidenced, which means the QSA tests it using artefacts from your accounts.

The last condition catches people out. An AOC lists services, not configurations. It confirms that the provider's managed database service, for example, was assessed as operated by the provider. It says nothing about whether your instance of that service has encryption enabled, public access disabled, or audit logging switched on. That is why the evidenced list is long even in a fully managed environment: the provider validated the service, and you must validate your use of it.

In practice, the inherited list on the major platforms is short and stable: physical security of the data centres, the hypervisor, the provider's internal network, provider-side patching of managed runtimes, and the provider's own personnel controls. Everything else is evidenced. For a requirement-by-requirement view of what that evidence looks like on each platform, see the provider guides: AWS, Azure, Google Cloud and Alibaba Cloud.

Five Mistakes We See With Responsibility Matrices

The matrix is a simple document, and the mistakes around it are simple too. These are the ones that recur in cloud-hosted assessments:

1. Treating the matrix as a compliance certificate. Organisations present the provider's matrix and AOC as though they settle the assessment. They settle the inherited list. Everything marked customer or shared still has to be built and proved, and that is most of the standard.

2. Relying on an expired or superseded AOC. Provider AOCs are renewed annually and are now issued against PCI DSS v4.0.1. An AOC that has lapsed, or that was issued against an earlier version of the standard, cannot support inherited controls for a current assessment. Requirement 12.8.4 expects you to check the provider's status at least once a year, and a QSA will ask for the evidence that you did.

3. Assuming platform services are fully inherited. Moving from virtual machines to a managed database or a managed Kubernetes service reduces your responsibilities; it does not remove them. Encryption settings, network exposure, identity, logging and backup handling stay with you, and every one of them produces evidence requests.

4. An incomplete Requirement 12.8 list. The cloud platform is on the service-provider list; the payment gateway, the tokenisation service, the managed SOC, the CI/CD SaaS with deploy rights into the CDE, and the monitoring tool with read access to logs are not. Each of them is a third-party service provider under 12.8, and each needs its PCI DSS status monitored and its responsibility split recorded.

5. No matrix from your own downstream providers. If you are a service provider yourself, your customers will ask you for a responsibility matrix under 12.9.2, and their QSAs will expect it to be consistent with the matrices you rely on from your own providers. Building your matrix as a chain, with your provider's obligations flowing through to what you promise your customers, avoids contradictions that surface during a customer's assessment.

None of these is difficult to fix, and all of them are cheaper to fix before the assessment than during it; our note on what drives PCI DSS compliance cost explains why timing matters.

Multi-Cloud: Build One Consolidated Matrix

A multi-cloud cardholder data environment needs one consolidated responsibility matrix, not one per provider. Each provider's matrix covers only that provider's platform, so a requirement can be inherited on one cloud and evidenced on another, and a control that is centralised, such as logging or identity, must be shown to cover both. The consolidated matrix maps each requirement to the specific control in each cloud and states where the evidence for it will come from.

This is also the document that catches the seams: the peering link between clouds that nobody segmentation-tested, the SIEM that ingests from one platform but not the other, the tokenisation service on one cloud that was assumed to descope a database on the other. The PCI DSS in the Cloud hub guide compares the four providers' controls side by side and is a practical starting point for the consolidated version.

Automating the Evidenced Side of the Matrix

Once the matrix is sorted, the assessment effort concentrates on the evidenced list, and on most cloud platforms that is a long list of configuration states: role assignments, MFA enforcement, firewall rules, encryption settings, log routing and retention, posture findings. Collecting them by screenshot takes weeks and the result is stale on capture.

Complium, EIC's compliance management platform, records the responsibility split against every PCI DSS v4.0.1 requirement so the assessor sees inherited and evidenced controls in one view, and then collects the evidenced side directly. On Azure it connects read-only to Microsoft Entra ID, Azure Activity Logs and Microsoft Defender for Cloud; on AWS to IAM, CloudTrail, Security Hub and AWS Config. Evidence is pulled from the environment, mapped to the requirement it supports, and reviewed by the QSA inside the platform that produces the Report on Compliance. The integrations request zero write permissions.

For Google Cloud and Alibaba Cloud, Complium works today from exported evidence, such as Cloud Audit Logs, IAM policy and Security Command Center exports, or ActionTrail, RAM and Security Center exports, uploaded and mapped by the same engine. Native read-only connectors for both platforms are on the roadmap; we describe integrations as they exist, not as planned.

Frequently Asked Questions

If you are preparing a cloud-hosted environment for assessment, our PCI DSS compliance assessment service starts with exactly this exercise: the provider documents, your service-provider list, and an environment-specific matrix that tells you what you will need to evidence before the assessor arrives.