PCI DSS in the Cloud: Shared Responsibility Without the Blind Spots

“Our cloud provider is PCI compliant, so we are covered.” If we could retire one sentence from scoping conversations, it would be this one. AWS, Azure and Google Cloud all hold PCI DSS attestations, and none of those attestations makes your workload compliant. What they do is take a defined slice of the requirements off your plate and leave the rest, and the boundary between the two slices is where cloud card-data breaches actually happen.

This guide explains how PCI DSS responsibility really divides in the cloud, what evidence you need from your providers, and the cloud-specific pitfalls we see most often as assessors working with environments across New Zealand and Australia.

Shared responsibility, in PCI DSS terms

Every cloud model splits responsibility between the provider and you, and the split moves with the service model.

• IaaS (EC2, Azure VMs, GCE): the provider covers physical security, the hypervisor and the underlying infrastructure. You own everything you build on it: operating systems, patching, network security groups, encryption, key management, logging, access control. The majority of requirements stay with you.
• PaaS (managed databases, container platforms, serverless): the provider absorbs the operating system and platform layers. You still own your data, application code and configuration, identity and access, and the correct use of the platform’s security features.
• SaaS (a hosted payment page, a cloud CRM): the provider runs nearly everything, but you retain user management, configuration choices, and oversight of the provider itself.

The constant across all three: accountability never transfers. Under PCI DSS you can outsource operation of a control, but responsibility for your compliance, and for managing the providers you rely on, stays with you. That principle has bitten merchants for years, the same way it does with ASV scanning obligations on “fully outsourced” payment pages.

The paperwork that makes it real: AoCs and responsibility matrices

PCI DSS turns the shared-responsibility diagram into concrete obligations on you as the customer:

• Requirement 12.8 makes you maintain a list of the third-party service providers you share account data with, or who could affect its security, with written agreements and a defined programme for managing them, including monitoring their compliance status at least annually.
• Requirement 12.8.5 requires you to document, precisely, which PCI DSS requirements are managed by each provider, which are yours, and which are shared.
• Requirement 12.9 puts the mirror obligation on service providers: they must acknowledge their responsibilities in writing and, under 12.9.2, support their customers’ requests for compliance information.

In practice this means two documents per provider. First, their Attestation of Compliance: check its date, and more importantly its scope, because “PCI DSS compliant” on a marketing page might cover three services out of the two hundred you use. The hyperscalers publish which services are in scope of their attestations; a niche SaaS provider should hand you an AoC on request, and hesitation there is a signal. Second, their responsibility matrix: the requirement-by-requirement table of who does what. AWS, Azure and Google all publish PCI responsibility matrices, and your assessor will expect your 12.8.5 documentation to be built on them, not on assumptions.

Cloud-specific pitfalls we keep finding

1. Scope sprawl through connected services. Cloud makes it effortless to wire services together, and every integration is a potential scope extension. The analytics pipeline that ingests the transaction database, the shared identity tenant, the DevOps runner with deployment credentials into the CDE: all the connected-to logic from traditional scoping applies, it just multiplies faster.
2. Segmentation by security group is only as good as its rules. Virtual networks, security groups and private endpoints can segment beautifully, but a single permissive rule or peering connection quietly flattens the design, and segmentation testing (Requirement 11.4.5) applies to cloud segmentation exactly as it does on-premises.
3. Ephemeral infrastructure vs evidence. Containers and autoscaled instances that live for an hour still need to satisfy logging and monitoring requirements. Centralise logs off the instances at creation, or the evidence disappears with the workload. Requirement 10 does not accept “the container is gone” as an answer.
4. Key management confusion. Cloud KMS services are excellent, but you must be able to explain who can use which keys, how key custodianship is handled, and whether provider staff could access your data. “It is encrypted” is the start of the conversation with an assessor, not the end.
5. Storage misconfiguration. The classic cloud breach is not a hacked hypervisor; it is a publicly readable storage bucket holding exports with card data. Data discovery and configuration monitoring are your controls, not your provider’s.
6. Console access without hardened authentication. Your cloud management console is effectively an administrator door into the CDE. It needs the same multi-factor authentication rigour as any CDE access, which we cover in our MFA requirements deep-dive.

What “good” looks like

Cloud environments that sail through assessment share a pattern. Scope is engineered deliberately: card data confined to a dedicated account or subscription, with tokenisation keeping PANs out of the wider estate. The provider relationship is documented: current AoCs on file, responsibility matrices folded into the 12.8.5 documentation, provider compliance reviewed annually. Infrastructure is defined as code, which turns configuration standards (Requirement 2) and change control into reviewable artefacts rather than tribal knowledge. And evidence is continuous: centralised logging, automated configuration monitoring, and access reviews that happen on schedule because they are calendared, not remembered.

Cloud does not make PCI DSS harder. Managed well, it makes several requirements easier to demonstrate than legacy infrastructure ever did. What it punishes is the assumption that someone else is doing the work.

Frequently asked questions

Our cloud provider has a PCI DSS AoC. Does that make us compliant?

No. Their attestation covers the infrastructure and services they operate, within the scope stated on their AoC. Everything above that line, your configurations, data, applications, access control, logging and provider oversight, remains yours to secure and validate. Your own validation (ROC or SAQ) covers your side of the split.

What documents should we collect from each cloud or SaaS provider?

Two per provider: a current Attestation of Compliance whose scope actually covers the services you consume, and a responsibility matrix mapping each PCI DSS requirement to provider, customer or shared. Requirement 12.8.5 expects your documentation to reflect exactly this, and service providers are obliged under Requirement 12.9.2 to support the request.

Is a separate cloud account for the CDE really necessary?

It is not mandated, but it is the cleanest segmentation boundary cloud offers. A dedicated account or subscription for card-data workloads gives you a crisp scope line, simpler access control, and a far easier segmentation-testing story than carving a shared account into zones.

How do PCI DSS logging requirements work for containers and serverless?

The requirements are unchanged; the implementation adapts. Logs must be captured, centralised and protected as workloads are created and destroyed, so ship them off the workload in real time to a centralised platform. Design for the requirement before the workload exists, because you cannot retrofit logging onto a container that has already terminated.

Get your cloud scope and evidence right

Cianaa assesses PCI DSS environments on AWS, Azure and Google Cloud, and we have seen every version of the shared-responsibility misunderstanding. If you want your cloud architecture, provider documentation and scope tested against v4.0.1 before assessment time, talk to our assessors or explore our PCI DSS services.