Cloud Compliance Guide

PCI DSS in the Cloud — AWS, Azure & GCP

Moving your cardholder data environment to the cloud does not eliminate PCI DSS obligations — it redistributes them. This guide explains exactly which controls your cloud provider handles, which remain yours, and how to leverage cloud-native services to build a more secure, auditable CDE than traditional on-premises infrastructure allows.

The Shared Responsibility Model and PCI DSS

Every major cloud service provider — AWS, Azure, and GCP — operates under a shared responsibility model. The provider secures the infrastructure of the cloud (physical data centres, hypervisors, global network), while you secure everything you deploy in the cloud (operating systems, applications, data, access controls, network configurations). For PCI DSS, this means your compliance responsibility depends on which cloud service model you consume.

Infrastructure as a Service (IaaS)

When you run virtual machines, manage your own operating systems, and deploy applications directly, the CSP handles physical security (Requirement 9) and low-level network infrastructure. You are responsible for nearly everything else: OS hardening, patching, access controls, encryption key management, logging, firewall rules, application security, and monitoring. IaaS gives you maximum control but also maximum compliance burden. Most organisations running their CDE on IaaS will need to address the vast majority of PCI DSS requirements themselves.

Platform as a Service (PaaS)

PaaS services like AWS RDS, Azure App Service, or Google Cloud Run abstract away the operating system and middleware layers. The CSP handles OS patching, runtime management, and infrastructure hardening. Your responsibility shifts to application-level controls: secure coding, access management, data encryption configuration, and audit logging at the application layer. PaaS reduces your PCI surface area, but you must still validate that the CSP's PaaS security meets PCI DSS requirements for the layers they manage.

Software as a Service (SaaS)

When you use a SaaS payment processor (such as Stripe or Adyen), the provider handles nearly the entire stack. Your responsibility is limited to: managing your account credentials, controlling who in your organisation can access the service, reviewing the provider's PCI compliance status (their AOC), and ensuring your integration does not inadvertently bring cardholder data into your own environment. This maps closely to SAQ A for merchants who fully outsource payment processing.

Obtaining Your CSP's Compliance Documentation

All three major CSPs maintain their own PCI DSS Level 1 compliance and publish attestation documentation. AWS provides its AOC and responsibility matrix through AWS Artifact. Azure publishes compliance documentation in the Azure Trust Center. GCP provides its compliance reports through the Google Cloud Compliance page. Request these documents and use the responsibility matrix to map which PCI DSS requirements each party owns. This mapping is the foundation of your cloud compliance programme and the first document your assessor will request.

AWS-Specific PCI Controls

AWS offers the most mature set of PCI-relevant security services. The following services map directly to PCI DSS requirements and should form the foundation of your AWS-based CDE architecture.

Network Segmentation: VPC, Security Groups, and NACLs

Your CDE should reside in a dedicated VPC with no peering connections to non-CDE VPCs unless traffic passes through an inline firewall or security appliance. Security Groups act as stateful firewalls at the instance level — configure them to allow only the minimum required ports and source IP ranges. Network ACLs provide stateless filtering at the subnet level, adding a second layer of defence. For PCI DSS Requirement 1 (network security controls), document every security group rule and NACL entry, with written business justification for each allowed traffic flow. Use VPC Flow Logs to capture and analyse all traffic entering and leaving the CDE.

Consider AWS Network Firewall or a third-party virtual firewall appliance for stateful inspection between the CDE VPC and connected environments. See the network segmentation guide for detailed architecture patterns applicable to cloud VPC designs.

Encryption: AWS KMS

AWS Key Management Service provides centralised key management that satisfies PCI DSS Requirements 3 and 4 for encryption of stored cardholder data and data in transit. Use customer-managed keys (CMKs) rather than AWS-managed keys for CDE workloads — CMKs give you full control over key policies, rotation schedules, and access grants. Enable automatic key rotation (annual at minimum per Requirement 3.7.4). Enforce envelope encryption for application-level data protection and use KMS key policies to restrict key usage to authorised CDE services only.

Audit Logging: CloudTrail and CloudWatch

AWS CloudTrail logs every API call made in your AWS account, providing a complete audit trail of administrative actions. Enable CloudTrail across all regions with management and data events for CDE resources. Send CloudTrail logs to a dedicated S3 bucket with object lock enabled (WORM) to prevent tampering — this satisfies the tamper-evidence requirement of Requirement 10. CloudWatch Logs captures application and OS-level logs. Configure CloudWatch alarms to alert on security-relevant events such as root account usage, security group changes, and failed authentication attempts.

Threat Detection and Compliance Monitoring

Amazon GuardDuty provides intelligent threat detection by analysing CloudTrail, VPC Flow Logs, and DNS logs for malicious activity. Enable GuardDuty in your CDE account and configure automated responses for high-severity findings. AWS Config continuously evaluates resource configurations against compliance rules. AWS provides a managed PCI DSS conformance pack with pre-built rules covering requirements such as encryption enforcement, logging verification, and public access restrictions. AWS WAF provides web application firewall capabilities for internet-facing CDE applications, addressing Requirement 6.4 protections against common web attacks.

Azure and GCP Controls

Azure: Network and Identity Controls

Azure provides Network Security Groups (NSGs) for subnet and NIC-level traffic filtering, Azure Firewall for centralised, stateful network inspection, and Virtual Network (VNet) service endpoints to restrict PaaS service access to your CDE VNet only. For identity and access, Azure Active Directory (Entra ID) supports conditional access policies that enforce MFA, device compliance, and location-based access restrictions — directly addressing PCI DSS Requirements 7 and 8.

Azure Key Vault provides HSM-backed key management for encryption of cardholder data. Use Key Vault with customer-managed keys for Azure Storage, Azure SQL, and Cosmos DB encryption. Enable Key Vault audit logging and configure access policies using the principle of least privilege.

Azure Monitor and Microsoft Sentinel provide log collection, analysis, and SIEM capabilities. Azure Monitor collects platform metrics and resource logs, while Sentinel adds AI-driven threat detection, investigation, and automated response. Azure Policy enforces organisational standards and assesses compliance at scale — deploy the built-in PCI DSS initiative to continuously evaluate your resources against PCI requirements.

GCP: Security and Compliance Services

GCP uses VPC firewall rules at the network level, with support for hierarchical firewall policies that enforce organisation-wide rules. CDE workloads should use a dedicated VPC project with firewall rules explicitly denying all traffic not required for cardholder data processing. VPC Service Controls create a security perimeter around GCP services, preventing data exfiltration even if credentials are compromised — a powerful control for protecting sensitive API-accessible data.

Cloud KMS provides key management with support for software-backed and HSM-backed keys. Use customer-managed encryption keys (CMEK) for all CDE data stores including Cloud SQL, BigQuery, and Cloud Storage. Cloud Audit Logs capture Admin Activity, Data Access, System Event, and Policy Denied logs. Enable Data Access logs for CDE projects (they are disabled by default) and export all audit logs to a locked Cloud Storage bucket or BigQuery dataset for long-term retention.

Security Command Center (SCC) provides asset discovery, vulnerability detection, and threat monitoring across your GCP environment. SCC Premium includes compliance monitoring with built-in PCI DSS benchmarks, identifying misconfigurations that would result in assessment findings. Use SCC findings to drive continuous remediation before your annual assessment.

Cloud-Native vs Traditional Controls Mapping

Organisations migrating from on-premises to cloud often struggle to translate traditional PCI controls into their cloud equivalents. The control objective remains the same, but the implementation mechanism changes. Understanding this mapping prevents both over-engineering (deploying unnecessary traditional appliances in the cloud) and under-engineering (assuming the CSP handles controls that remain your responsibility).

Use the CDE Scoping Tool to map your cloud architecture to PCI DSS scope categories, and the Scope Calculator to estimate how cloud migration affects your compliance cost.

Container and Kubernetes Considerations

Containers and Kubernetes introduce unique PCI DSS challenges that do not map neatly to traditional server-based assessments. The ephemeral nature of containers, shared kernel architecture, and dynamic orchestration require purpose-built controls and careful scope definition. If your CDE runs containerised workloads, these considerations are essential.

Isolating CDE Workloads

CDE containers must be isolated from non-CDE workloads. The most defensible approach is to run CDE workloads on dedicated Kubernetes clusters (or dedicated node pools at minimum) that are not shared with non-CDE applications. This provides clear scope boundaries that assessors can validate. If you must share a cluster, use Kubernetes namespaces combined with network policies to enforce micro-segmentation at the pod level. However, shared clusters increase scope complexity and may result in more systems being pulled into the CDE boundary.

Network Policies

Kubernetes network policies act as firewalls between pods, controlling which pods can communicate with each other. For CDE workloads, implement deny-all default policies and then explicitly allow only the traffic flows required for cardholder data processing. Document each allowed flow with business justification, just as you would for traditional firewall rules under Requirement 1. Use a CNI plugin that supports network policies (Calico, Cilium, or your managed Kubernetes provider's native solution).

Image Security and Supply Chain

Container images must be hardened, scanned for vulnerabilities, and signed before deployment to CDE clusters. Implement an image scanning pipeline that checks for known CVEs, misconfigurations, embedded secrets, and compliance violations before images are pushed to your registry. Use admission controllers to enforce that only signed, scanned images from trusted registries can be deployed to CDE namespaces. This addresses Requirements 6 (secure development) and 11 (vulnerability management).

Secrets Management

Never store encryption keys, database credentials, or API tokens in container images, environment variables, or Kubernetes ConfigMaps. Use a dedicated secrets management solution — AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, or HashiCorp Vault — integrated with your Kubernetes cluster via CSI driver or operator. Secrets should be rotated automatically and audited per PCI DSS key management requirements. Audit logs must capture every access to secrets used for cardholder data encryption.

Runtime Security and Logging

Container runtime security tools monitor running containers for anomalous behaviour: unexpected process execution, filesystem modifications, network connections to unauthorised destinations, and privilege escalation attempts. Deploy runtime security on all CDE nodes to satisfy Requirement 10 (monitoring) and Requirement 5 (malware protection). Ensure container logs are collected centrally with tamper protection, and that log retention meets the minimum one-year requirement.

Multi-Cloud and Hybrid Segmentation Strategies

Many organisations operate across multiple cloud providers or maintain hybrid environments with both cloud and on-premises components in their CDE. This introduces segmentation challenges that can significantly expand PCI scope if not addressed architecturally.

Cross-Cloud Network Connectivity

If cardholder data flows between cloud providers (for example, processing in AWS and disaster recovery in Azure), the network connections between them are in PCI scope. Use dedicated interconnects (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect) or encrypted VPN tunnels with strong cryptography. Document all cross-cloud data flows in your cardholder data flow diagram and ensure that security controls are applied at both ends of the connection. Assessors will validate segmentation at every boundary point.

Hybrid Cloud Segmentation

In hybrid environments, your on-premises CDE and cloud CDE must be treated as a unified scope with segmentation validated at the boundary. The connection between on-premises and cloud (typically a VPN or direct connect) must be secured with proper network segmentation controls. Common mistakes include: allowing broad network access between on-premises and cloud VPCs, failing to apply consistent firewall rules at both ends, and not logging traffic that crosses the hybrid boundary.

Centralised vs Distributed Logging

In multi-cloud and hybrid environments, consolidate audit logs from all environments into a single, centralised SIEM or log management platform. This ensures consistent log review (Requirement 10.4) and correlation of events across environments. Without centralised logging, an attacker could exploit gaps between separately monitored environments. Use log shipping agents or cloud-native log export mechanisms to forward logs from each environment to your central platform.

Consistent Policy Enforcement

The biggest risk in multi-cloud PCI environments is inconsistent policy enforcement. A hardening standard that is applied in AWS but not in Azure creates a compliance gap. Use Infrastructure as Code (Terraform, Pulumi) with shared modules to enforce consistent configurations across providers. Implement policy-as-code tools that evaluate configurations against PCI DSS benchmarks regardless of the underlying cloud provider.

Cloud Compliance Documentation and Evidence Collection

Cloud environments generate an enormous volume of configuration data, logs, and telemetry. Harnessing this data as PCI DSS evidence is one of the key advantages of cloud over on-premises infrastructure. However, you must be deliberate about what you collect, how you organise it, and how you present it to your assessor.

CSP Compliance Reports and Responsibility Matrices

Begin your evidence package with your CSP's PCI DSS Attestation of Compliance and the corresponding shared responsibility matrix. Your assessor needs this to understand which requirements are partially or fully addressed by the CSP. Download these annually from AWS Artifact, Azure Trust Center, or Google's Compliance Reports Manager. Annotate the responsibility matrix to show how your organisation addresses each "customer responsibility" item.

Infrastructure as Code as Evidence

If you use Terraform, CloudFormation, Bicep, or similar tools, your IaC templates serve as evidence of secure configuration (Requirement 2), network segmentation (Requirement 1), and encryption enforcement (Requirements 3 and 4). Store your IaC in version control with change history, code reviews, and approval records — this simultaneously satisfies change management requirements (Requirement 6.5.1). Assessors increasingly accept IaC as primary evidence because it is deterministic: the deployed configuration matches the template.

Automated Evidence Collection

Cloud APIs enable automated evidence collection that was impractical with on-premises infrastructure. Schedule automated exports of: security group rules, encryption configurations, IAM policies, compliance scan results, and access logs. Map each export to the PCI DSS requirement it satisfies and store evidence in a structured repository with timestamps and integrity verification. GRCTrack's platform integrates with major CSP APIs to automate this collection and map artefacts directly to PCI DSS requirements.

Cloud Network Diagrams

Your network diagrams must accurately reflect your cloud architecture including: VPCs/VNets and their CIDR ranges, subnets (public and private), security groups and their rules, NAT gateways, load balancers, VPN connections, peering relationships, and all CDE system components. Tools like AWS VPC Visualiser, Azure Network Watcher, and GCP Network Topology can help generate accurate baseline diagrams. Update these diagrams whenever your cloud architecture changes and include them in your change management records.

Segmentation Validation

PCI DSS Requirement 11.4.5 requires segmentation penetration testing to verify that your network controls effectively isolate the CDE. In cloud environments, this means testing that security groups, NACLs, firewall rules, and VPC boundaries actually prevent traffic flows that are not explicitly permitted. Your penetration tester must understand cloud networking — a tester experienced only with physical network testing may miss cloud-specific bypass scenarios such as metadata service access, cross-account role assumptions, or misconfigured service endpoints. Select a QSA and penetration testing firm with demonstrated cloud expertise from the QSA Directory.

Simplify Cloud PCI Compliance

GRCTrack maps your cloud architecture to PCI DSS requirements, automates evidence collection from AWS, Azure, and GCP, and connects you with QSAs who specialise in cloud assessments.

Frequently Asked Questions