Moving payment workloads to the cloud does not simplify PCI DSS compliance. It changes where the complexity lives. Instead of managing physical data center security, you are now managing IAM policies, security group configurations, encryption key management, and a shared responsibility model that varies by service type.
All three major cloud providers, AWS, Azure, and GCP, maintain PCI DSS Level 1 Service Provider certifications. This means the physical infrastructure, hypervisor, and certain managed services are covered by their compliance. Everything you build on top of that infrastructure is your responsibility. The shared responsibility model is the central concept that determines your PCI DSS obligations in the cloud.
The Shared Responsibility Model for PCI DSS
Each cloud provider publishes a shared responsibility model that defines what they secure and what you secure. For PCI DSS purposes, the division is straightforward in concept but complex in practice.
| Layer | CSP Responsibility | Your Responsibility |
|---|---|---|
| Physical Security | Data center access, environmental controls, hardware disposal | None (covered by CSP's PCI DSS certification) |
| Network Infrastructure | Physical network, backbone, DDoS protection | VPC configuration, security groups, NACLs, firewall rules, segmentation |
| Compute | Hypervisor security, host OS for managed services | Guest OS patching, application security, instance configuration |
| Storage | Physical storage media, managed service encryption options | Enabling encryption, key management, access policies, data classification |
| Identity & Access | IAM service availability and security | IAM policy design, MFA enforcement, least privilege, access reviews |
| Logging & Monitoring | Service availability (CloudTrail, Monitor, Cloud Audit) | Enabling logging, configuring retention, alerting, log review |
| Application | None | Application code, configuration, dependencies, WAF, input validation |
The critical misconception: "We are on AWS, and AWS is PCI compliant, so we are PCI compliant." This is wrong. AWS's PCI certification covers their infrastructure responsibilities. Your use of AWS is only PCI compliant if you configure and operate it correctly. We find PCI DSS violations in cloud environments on virtually every engagement.
AWS PCI DSS Requirements
AWS provides the most mature PCI DSS compliance program of the three major providers. Over 150 AWS services are included in their PCI DSS scope. Here is what you need to configure correctly for PCI compliance on AWS.
Network segmentation
Use a dedicated VPC for your CDE. Do not peer CDE VPCs with non-CDE VPCs unless absolutely necessary. If peering is required, use the most restrictive security group and NACL rules possible. Consider using AWS Transit Gateway with separate route tables for CDE and non-CDE traffic. AWS PrivateLink provides private connectivity to services without VPC peering.
Encryption
Enable encryption at rest for all storage services in the CDE: EBS volumes, S3 buckets, RDS instances, DynamoDB tables, and any other data stores. Use AWS KMS for key management, preferably with customer-managed keys (CMKs) rather than AWS-managed keys, as CMKs provide better audit trail and access control. Enable TLS for all data in transit, including internal service-to-service communication.
Logging and monitoring
Enable CloudTrail in all regions with log file validation. Send CloudTrail logs to a dedicated S3 bucket with object lock (WORM protection) to satisfy PCI DSS Requirement 10's log integrity requirement. Enable VPC Flow Logs for the CDE VPC. Configure CloudWatch alarms for security-relevant events: root account usage, IAM policy changes, security group modifications, and unauthorized API calls.
IAM hardening
Enforce MFA on all IAM users with CDE access (Requirement 8.4.2). Implement least-privilege IAM policies; avoid using * in resource or action fields for CDE-related policies. Use IAM roles instead of long-term access keys. Enable AWS Organizations SCPs to enforce security guardrails across CDE accounts. Regularly review IAM policies using AWS IAM Access Analyzer.
Azure PCI DSS Requirements
Azure provides PCI DSS compliance coverage across its infrastructure and many managed services. Microsoft publishes a PCI DSS Shared Responsibility Matrix that maps each PCI requirement to Azure and customer responsibilities.
Key Azure configurations for PCI
- Network isolation: Dedicated VNets for CDE workloads with NSGs enforcing microsegmentation. Azure Firewall or NVA for stateful inspection between zones. No VNet peering to non-CDE VNets without documented justification
- Encryption: Azure Storage Service Encryption (SSE) enabled with customer-managed keys in Azure Key Vault. TDE for Azure SQL Database. Always Encrypted for column-level encryption of cardholder data fields
- Identity: Azure AD Conditional Access policies enforcing MFA for CDE access. Privileged Identity Management (PIM) for just-in-time admin access. Regular access reviews using Azure AD Access Reviews
- Logging: Azure Monitor and Azure Activity Log enabled with diagnostic settings sending logs to Log Analytics or Event Hub. Microsoft Defender for Cloud enabled with security contacts configured for alert notifications
GCP PCI DSS Requirements
GCP provides PCI DSS compliance coverage for its infrastructure and managed services. Google publishes a PCI DSS compliance guide specific to GCP that maps requirements to GCP services and configurations.
Key GCP configurations for PCI
- Project isolation: Dedicated GCP project for CDE workloads. Organization policies enforcing security constraints. VPC Service Controls creating security perimeters around CDE resources
- Network: Dedicated VPC with firewall rules restricting all traffic to documented, justified flows. Private Google Access for services that do not need public IP addresses. Cloud NAT for controlled egress
- Encryption: Customer-Managed Encryption Keys (CMEK) for Cloud Storage, BigQuery, and Compute Engine persistent disks. Cloud KMS for key management with key rotation policies
- Logging: Cloud Audit Logs enabled for all CDE projects. Logs exported to BigQuery or Cloud Storage with retention policies meeting PCI DSS Requirement 10.7 (minimum 12 months). Cloud Monitoring alerting for security events
Common Cloud PCI Failures We Find
When we conduct cloud security assessments for PCI DSS, these are the failures that appear most consistently across all three providers.
- Overly permissive security groups. Security groups with 0.0.0.0/0 inbound rules on CDE instances. This is the cloud equivalent of a flat network and immediately brings the entire internet into your scope consideration
- Unencrypted data stores. S3 buckets, RDS instances, or Cloud Storage buckets containing cardholder data without encryption at rest. This is a direct violation of Requirement 3.5
- IAM over-provisioning. IAM policies with AdministratorAccess or equivalent attached to users or roles that access CDE resources. Every IAM principal with CDE access should have the minimum permissions necessary for their function
- Missing or incomplete logging. CloudTrail not enabled in all regions, VPC Flow Logs not enabled for CDE VPCs, or log retention periods shorter than 12 months. PCI DSS Requirement 10 is comprehensive and cloud environments often have gaps
- Cross-account role assumptions. IAM roles in non-CDE accounts that can assume roles in CDE accounts without MFA or IP restrictions. This bridges the segmentation boundary at the identity layer
- Default configurations. Default VPC being used for CDE workloads, default security groups with allow-all rules, or managed services running with default (often permissive) configurations
Our recommendation: Before your PCI assessment, run a cloud-specific penetration test that covers both the application layer and the cloud infrastructure layer. Application-only pentests miss IAM misconfigurations, storage policy gaps, and network segmentation failures that are unique to cloud environments.
Leveraging CSP Compliance Programs
Each cloud provider offers compliance programs and tools that simplify your PCI DSS journey.
| Resource | AWS | Azure | GCP |
|---|---|---|---|
| PCI DSS AOC | Available via AWS Artifact | Available via Service Trust Portal | Available via Compliance Reports Manager |
| Responsibility Matrix | AWS PCI DSS Compliance Guide | Azure PCI DSS Shared Responsibility Matrix | GCP PCI DSS Mapping Guide |
| Compliance Tool | AWS Config, Security Hub, Audit Manager | Microsoft Defender for Cloud, Compliance Manager | Security Command Center, Policy Intelligence |
| PCI DSS Quick Start | AWS PCI DSS Quick Start architecture | Azure PCI DSS Blueprint | GCP PCI on GKE Blueprint |
These resources are genuinely useful. The CSP's Attestation of Compliance (AOC) is evidence your QSA needs to verify the CSP's PCI DSS certification. The responsibility matrices help you and your QSA agree on scope boundaries. The compliance tools automate evidence collection for many PCI DSS requirements. Use them.
Building a PCI-Compliant Cloud Architecture
If you are designing a new cloud architecture for PCI DSS compliance, or refactoring an existing one, here are the architectural principles that consistently pass assessment.
Dedicated accounts or projects for the CDE. Account-level isolation is the strongest segmentation boundary available in cloud environments. CDE workloads should run in accounts or projects that are dedicated to PCI-scoped workloads. Use AWS Organizations, Azure Management Groups, or GCP Organization Policies to enforce security guardrails at the account level.
Minimize what touches cardholder data. The fewer systems that process, store, or transmit cardholder data, the smaller your CDE. Use tokenization from a PCI-compliant provider to replace cardholder data with tokens as early as possible in the data flow. Ideally, cardholder data never enters your cloud environment at all.
Encrypt everything by default. Enable encryption at rest and in transit for every service in the CDE. Use customer-managed keys for audit trail and control. Configure key rotation policies. This satisfies PCI DSS Requirements 3 and 4 and eliminates an entire category of compliance findings.
Log everything, retain it, and alert on it. Enable comprehensive logging for all CDE resources. Send logs to a centralized, tamper-protected location. Configure alerts for security-relevant events. Implement automated log review to satisfy Requirement 10.4.1.1 (the v4.0 automated log review requirement).
Test the cloud layer, not just the application. Your annual PCI DSS penetration test must cover cloud infrastructure, not just the web application. This means testing IAM configurations, storage access policies, network segmentation, and service configurations in addition to traditional application-layer testing.
Need a PCI DSS cloud assessment?
We test both the application and cloud infrastructure layers for PCI DSS compliance. AWS, Azure, and GCP expertise with reports structured for QSA review.
