PCI DSS in the Cloud: Who Secures What in AWS, Azure, and GCP

The most expensive misunderstanding in cloud payments fits in one sentence: our cloud provider is PCI compliant, so we are. It is wrong in a way that has produced some of the largest card-data exposures of the cloud era, almost none of which were the provider’s fault. The major clouds are indeed validated to high PCI DSS levels, but that validation covers their layer of the stack, not yours. The workloads you build on top, and the thousand configuration choices you make, are yours to secure. Getting PCI DSS right in the cloud is almost entirely a matter of knowing precisely where the provider’s responsibility ends and yours begins, and then owning your side completely.

Quick answer: Cloud providers validate PCI DSS for the infrastructure they operate, and supply an Attestation of Compliance covering that layer. The customer remains responsible for everything they configure and deploy: the cardholder data environment they build, access controls, encryption settings, network segmentation, logging, and above all avoiding the misconfigurations (exposed storage, over-permissioned access) that cause most cloud card-data breaches. Compliance is shared, and the dividing line shifts with each service model.

What does the shared responsibility model actually say?

Every major cloud publishes a shared responsibility model, and the headline is consistent: the provider secures the cloud, the customer secures what they put in the cloud. The provider owns physical data centers, the hypervisor, the core network, and the managed-service internals. The customer owns their data, their identity and access configuration, their network and firewall rules, their encryption choices, and their application. This is the same principle our TPSP risk playbook applies to any provider, with one cloud-specific sharpener: the line moves depending on how managed the service is.

The more managed the service, the more the provider carries, but the customer never reaches zero: your data and your access configuration are always yours. A provider’s AOC covers the hypervisor; it does not cover the storage bucket you left public.

Why do cloud card-data breaches keep happening?

Overwhelmingly, through customer-side misconfiguration, not provider failure:

• Exposed storage: object stores (S3 buckets and equivalents) left publicly readable, spilling card data, backups, or logs. This single category has produced a remarkable share of cloud data exposures, and it is entirely on the customer side of the line.
• Over-permissioned access: identity and access management granting far more than needed, so one compromised credential or key reaches the whole cardholder data environment. Least privilege is a customer responsibility that cloud scale makes both easier to get wrong and more damaging.
• Unprotected secrets: API keys, database credentials, and tokens in code, environment variables, or public repositories, the cloud edition of the secrets-management failures our API security guide warns against.
• Logging gaps: cloud control-plane activity, managed-service access, and container events left unlogged, so the Requirement 10 audit trail has holes exactly where cloud intrusions move.
• Default-open configurations: security groups and network rules left broad because a restrictive setting broke something during a rushed deployment.

None of these are the provider’s AOC to fix. They are the customer realizing, too late, which side of the model they were on.

How do you define and secure a cloud cardholder data environment?

The same PCI DSS principles apply; the mechanisms change:

• Scope and segment with cloud-native controls: security groups, network ACLs, private subnets, and separate accounts or projects replace the VLANs of on-premises networks, but the goal from our scoping guide is unchanged: isolate the systems that touch card data and validate the isolation, with the testing rigor of our segmentation testing guide applied to cloud boundaries.
• Encrypt with discipline: managed encryption is easy to switch on, but who holds and controls the keys is the PCI-relevant question. Customer-managed keys and sound key rotation keep control on your side; provider-default keys may suffice for some requirements but shift trust to the provider, a decision to make deliberately.
• Enforce least privilege relentlessly: scoped IAM roles, no long-lived broad credentials, and MFA on console and privileged access per our requirement 8 guide. In the cloud, identity is the perimeter.
• Log the control plane, not just the workloads: capture provider API activity, managed-service access, and container and serverless events into tamper-resistant central storage.
• Use the provider’s compliance artifacts correctly: obtain their AOC and responsibility matrix, map each PCI requirement to provider versus customer, and keep that mapping as assessment evidence. The matrix is the contract that tells your assessor who does what.

What about serverless, containers, and PaaS?

More managed services move more of the stack to the provider but introduce their own scope questions. A managed database holding card data is in scope regardless of who patches it; serverless functions processing card data are in scope even though you never see the server; container orchestration adds a control plane that must be secured and logged. The reassuring part is that heavily managed services can shrink your operational burden and sometimes your scope; the trap is assuming managed means out of scope. If card data flows through it, it is in your environment no matter how abstract the infrastructure, and the data-and-access responsibility stays with you.

Frequently asked questions

If our cloud provider is PCI compliant, are we compliant?

No. Their validation covers the infrastructure they operate; you remain responsible for your data, access, configuration, and applications. Most cloud card-data breaches stem from customer-side misconfiguration, not provider non-compliance.

What is the single biggest cloud PCI risk?

Misconfiguration, led by publicly exposed storage and over-permissioned access. These are entirely on the customer side of the shared responsibility model and cause a large share of real cloud data exposures.

Do we need the provider’s Attestation of Compliance?

Yes. Obtain their AOC and shared-responsibility matrix, and map every PCI requirement to provider or customer responsibility. That mapping is core assessment evidence and clarifies exactly what you must cover.

Does using managed services reduce our PCI scope?

It can reduce your operational responsibility and sometimes narrow scope, but any service that stores, processes, or transmits card data is in scope regardless of how managed it is. Managed never means exempt.

Who manages encryption keys in the cloud?

You choose. Provider-managed keys are convenient but place control with the provider; customer-managed keys keep control and key rotation on your side. For card data, deliberately decide rather than accepting defaults, and document the choice.

Cloud PCI compliance is not about trusting the provider less; it is about knowing exactly where their excellent security stops and yours begins. Draw that line explicitly, own everything on your side of it, and the cloud becomes one of the safest places to run a payment environment. Blur it, and you inherit a breach with your name on it and the provider’s AOC intact.