ISpectra Technologies
By Industry / Use CaseGuideUpdated Jun 2026·6 min read

PCI DSS in the Cloud: AWS, Azure & GCP

Cloud changes how PCI DSS responsibilities are divided. Here is how compliance works on AWS, Azure, and GCP under the shared responsibility model.

Share

As organizations move payment systems to the cloud, a common question arises: how does PCI DSS apply when your infrastructure runs on AWS, Azure, or Google Cloud? The cloud does not exempt you from PCI DSS, but it does change how responsibilities are divided, how scope is defined, and how controls like segmentation are implemented. Understanding these differences is essential for any organization handling card data in the cloud.

This guide explains the shared responsibility model that underpins cloud compliance, how PCI DSS works on the major cloud platforms, how scope and segmentation translate to cloud environments, and the best practices for staying compliant in the cloud. Getting cloud PCI right means understanding precisely where the provider's responsibility ends and yours begins.

The cloud does not remove PCI DSS

The first thing to understand is that running in the cloud does not remove your PCI DSS obligations. If cardholder data is stored, processed, or transmitted in your cloud environment, that environment is in scope just as an on-premises one would be. The cloud changes how compliance is achieved and shared, but it does not make the requirements disappear.

This matters because some organizations assume that using a major, compliant cloud provider means the provider handles PCI for them. In reality, the provider's compliance covers only the parts of the stack they control. The way you configure and use the cloud — your applications, your data, your access controls — remains your responsibility, and that is where most cloud PCI work actually lies.

The shared responsibility model

Cloud compliance is governed by the shared responsibility model, which divides security obligations between the cloud provider and the customer. Broadly, the provider is responsible for the security of the cloud — the physical infrastructure, the hardware, and the foundational services — while the customer is responsible for security in the cloud — their data, applications, configurations, identities, and access.

This division is the central concept in cloud PCI DSS. The major providers maintain their own PCI DSS compliance for the infrastructure they operate, which the customer can rely upon for that layer. But the customer must implement and validate the controls for everything they build on top. Misunderstanding this split — assuming the provider covers more than it does — is the most common and dangerous cloud compliance mistake.

Free resource

The Ultimate Guide to PCI DSS

Download our practical resource to fast-track your PCI DSS compliance.

How PCI works on AWS, Azure, and GCP

The major cloud platforms — AWS, Azure, and Google Cloud — are themselves validated as compliant service providers for the infrastructure services they offer, and they publish documentation and attestations that customers can use. They also provide a range of services and tools that help customers build compliant environments, from encryption and key management to logging, monitoring, and identity management.

However, using a compliant platform is only the starting point. The customer must select and configure these services correctly, design a compliant architecture, and validate their own environment. Each platform offers the building blocks for compliance, but assembling them into a genuinely compliant cardholder data environment — and proving it — remains the customer's task, regardless of which provider they choose.

Defining scope in the cloud

Scoping in the cloud follows the same principle as anywhere else — scope follows cardholder data — but the cloud's elasticity and complexity can make it harder to pin down. Card data may flow through compute instances, storage services, managed databases, queues, and serverless functions, and the dynamic nature of cloud resources means the environment can change rapidly.

Accurately defining the cloud cardholder data environment requires mapping how card data moves through the cloud services in use and identifying every service that touches it or could affect its security. Because cloud resources can be spun up and torn down quickly, maintaining an accurate, current picture of scope is an ongoing discipline rather than a one-time exercise, and it is essential to keeping the environment manageable.

Segmentation in the cloud

Segmentation, the key scope-reduction tool, is achieved in the cloud through different mechanisms than on-premises. Instead of physical firewalls and VLANs, cloud environments use security groups, network access control lists, virtual private clouds, subnets, and identity-based access controls to isolate the cardholder data environment from other workloads.

These cloud-native controls can provide strong, precisely defined segmentation, and they have the advantage of being configurable as code and applied consistently. But misconfiguration is a leading cause of cloud exposure, so the controls must be carefully designed, reviewed, and tested, with particular attention to overly permissive rules. As on-premises, cloud segmentation must be validated through testing to confirm the isolation genuinely holds.

Cloud-specific risks and controls

The cloud introduces specific risks that demand attention. Misconfigured storage and access controls are a frequent cause of data exposure, so getting configurations right is paramount. The ease of provisioning resources can lead to unmanaged systems drifting into scope. And the heavy reliance on identity and access management means strong authentication and least-privilege access are especially critical in the cloud.

On the other hand, the cloud offers powerful controls: native encryption and key management, comprehensive logging, infrastructure-as-code that makes configurations consistent and auditable, and automated monitoring. Used well, these capabilities can make cloud environments easier to secure and evidence than traditional ones. The key is to harness the cloud's strengths while guarding diligently against its characteristic risks.

Working with provider documentation and attestations

To rely on a cloud provider's compliance for the infrastructure layer, you need their PCI DSS documentation, including their Attestation of Compliance and responsibility matrices. These materials clarify exactly which controls the provider handles and which remain yours, which is the foundation for scoping your own work and demonstrating the shared responsibility split to your assessor.

Obtaining, reviewing, and retaining these provider documents is a real compliance task. Your assessor will want to see that you understand and have evidenced the division of responsibility, and that you rely on the provider only for what they actually cover. Treating the provider's attestation as part of your own evidence package, and confirming it remains current, is part of doing cloud compliance properly.

Cloud PCI best practices

Best practices for cloud PCI bring these threads together: understand the shared responsibility model precisely and never assume the provider covers more than it does; map your card-data flows through cloud services and keep scope current; use cloud-native segmentation and validate it through testing; configure everything carefully, treating misconfiguration as a primary risk; and leverage the cloud's native encryption, logging, and automation to strengthen and evidence your controls.

Above all, manage the relationship with the provider actively — relying on their attestation for the infrastructure while owning everything you build on top. Organizations that approach cloud PCI this way find that the cloud, used deliberately, can make compliance more consistent and auditable, rather than more confusing, than traditional infrastructure. The discipline the cloud rewards — explicit configuration, least-privilege identity, and continuous monitoring — is exactly the discipline PCI DSS is designed to encourage.

How ISpectra helps with cloud PCI DSS

Cloud environments change how PCI DSS responsibilities are divided and how controls are implemented, and ISpectra Technologies helps organizations navigate this on the path to pci dss certification. ISpectra helps you apply the shared responsibility model correctly, scope your cloud cardholder data environment, design and validate cloud-native segmentation, and configure the platform's services to meet the requirements.

With free vulnerability assessment and penetration testing to find cloud misconfigurations and a 10% discount when PCI DSS is bundled with SOC 2 or ISO 27001, ISpectra helps you achieve compliant payment systems on AWS, Azure, or GCP — harnessing the cloud's strengths while closing the configuration gaps that cause most cloud exposures.

Free consultation

Need help with PCI DSS?

Talk to our certified compliance team — we’ve supported 200+ audits.

Book free assessment
FAQ

PCI DSS in the Cloud — FAQ

Yes. If cardholder data is stored, processed, or transmitted in your cloud environment, that environment is in scope. The cloud changes how compliance is shared and achieved but does not remove your PCI DSS obligations.
It divides security obligations between provider and customer: the provider secures the cloud infrastructure, while the customer secures what they build in the cloud, including data, applications, configurations, identities, and access.
The major platforms are validated as compliant service providers for the infrastructure services they offer and publish attestations. However, customers must still configure services correctly and validate their own environments built on top.
Through cloud-native controls such as security groups, network ACLs, virtual private clouds, subnets, and identity-based access, rather than physical firewalls. These must be carefully configured and validated by testing, as misconfiguration is a common risk.
Misconfiguration, particularly of storage and access controls, is a leading cause of cloud data exposure, along with assuming the provider covers more responsibility than it actually does under the shared responsibility model.
Yes. You need the provider's Attestation of Compliance and responsibility matrices to rely on their infrastructure compliance, clarify the responsibility split, and provide evidence to your assessor.
Ready to take the next step?

Get your free PCI DSS readiness assessment

A 30-minute call with our certified team. We’ll review your current state and map a realistic path to compliance — no pitch.

Book free assessment