PCI DSS Compliance on AWS: Protecting Cardholder Data in the Cloud

PCI DSS compliance on AWS has a fundamental characteristic that distinguishes it from other compliance frameworks: scoping. The entire burden of PCI DSS requirements applies only to systems within the Cardholder Data Environment (CDE) — systems that store, process, or transmit cardholder data, and systems that can affect the security of those systems. Aggressively minimizing CDE scope is the single highest-leverage activity in a PCI DSS implementation, because every system removed from scope is a system that doesn't need to meet all 300+ requirements.

AWS provides a PCI DSS Level 1 Service Provider attestation covering the managed infrastructure components. Like HIPAA and SOC 2, this means AWS's responsibility covers the cloud itself; your responsibility covers how you configure and use it.

Scoping the Cardholder Data Environment

The CDE includes all systems that store, process, or transmit Primary Account Numbers (PAN) and other cardholder data, plus all systems connected to them. "Connected" is defined broadly — a monitoring system that receives log data from a CDE server is in scope. A deployment system that pushes code to CDE servers is in scope. This network connectivity requirement is what drives teams to aggressively segment CDE infrastructure from the rest of their environment.

The most effective scoping strategy for cloud environments: use a payment processor that handles all cardholder data directly, avoiding storing or transmitting PAN through your own systems entirely. With Stripe, Braintree, or similar processors using tokenization, your application receives a token (not the actual PAN) which it uses for future operations. The token has no value outside your integration — it can't be used for card-not-present fraud. This approach may reduce your CDE to a very small set of systems or eliminate it entirely (for some assessors, tokenization moves you to SAQ A, the simplest PCI assessment).

VPC Architecture for CDE Segmentation

If you do maintain an in-scope CDE, the AWS architecture for proper segmentation uses a dedicated VPC or subnet structure with strict network controls:

Separate VPC for CDE: Place all CDE components in a dedicated VPC. This provides a clean network boundary. VPC peering and Transit Gateway connections to non-CDE VPCs place those systems in scope due to network connectivity — avoid these connections or implement compensating controls with strict traffic filtering.

No direct internet access: CDE systems should not have public IP addresses. Inbound traffic should flow through a WAF and load balancer that terminates external connections before passing requests to CDE systems. Outbound traffic from CDE systems should route through a controlled NAT gateway with allowlisted destinations.

Network segmentation evidence: Document firewall rules (security groups and NACLs) that enforce segmentation. Requirement 1.2 requires documentation of all network connections to and from the CDE. AWS Config can generate this documentation automatically — configure it to record security group changes and use AWS Firewall Manager to enforce consistent security group rules across CDE components.

Requirement 2: Secure Configurations

PCI DSS Requirement 2 prohibits vendor-supplied defaults for system passwords and other security parameters. On AWS, this means:

• No IAM users with default or weak passwords
• No EC2 instances with default AMI passwords
• SSH key pairs instead of password-based authentication for all instances
• All services with authentication enabled (RDS, ElastiCache, MSK)
• Use SSM Session Manager instead of SSH for interactive access where possible

Use AWS Config managed rules to detect configuration drift. The rule ec2-security-group-attached-to-eni catches unused security groups; restricted-ssh catches open SSH rules; rds-instance-public-access-check catches publicly accessible databases. Set these rules to continuously evaluate and alert on violations.

Requirement 6: Secure Development and Patch Management

Requirement 6 covers secure software development practices and vulnerability management. For AWS environments:

Patch management: Systems within the CDE must have critical patches applied within one month. Use Systems Manager Patch Manager with a maintenance window that meets this timeline. Enable AWS Inspector to continuously scan for vulnerabilities and alert when critical vulnerabilities appear on in-scope systems.

WAF for web-facing applications: Requirement 6.4 requires protecting public-facing web applications against known attacks using either code review, automated vulnerability scanning, or a web application firewall. AWS WAF satisfies the WAF requirement when configured with appropriate managed rule groups (AWS Managed Rules or OWASP-aligned rules from AWS Marketplace).

Requirement 10: Logging and Monitoring

PCI DSS Requirement 10 is extensive — it specifies exactly what activities must be logged, requires timestamps synchronized to a reliable time source, and mandates log retention for at least 12 months with 3 months immediately available.

CloudTrail satisfies the API activity logging requirement. Enable CloudTrail in all regions with multi-region logging and send logs to an S3 bucket with a restricted bucket policy (no deletion, no modification). Enable CloudTrail log file integrity validation. Configure S3 lifecycle policies that retain logs for 12 months in standard storage and archive to Glacier after 3 months to meet the retention requirement cost-effectively.

For additional log sources required by Requirement 10.2 (individual user activities, all actions taken by root or administrator, access to audit trails, invalid logical access attempts, use of identification mechanisms, initialization of audit logs, creation and deletion of system-level objects), supplement CloudTrail with CloudWatch Logs from application servers and RDS audit logs.

Requirement 11: Regular Testing

Requirement 11 mandates quarterly vulnerability scans by an Approved Scanning Vendor (ASV) for external-facing systems, and annual penetration testing. AWS Inspector can supplement internal vulnerability scanning but doesn't replace the ASV requirement. Engage an ASV for quarterly scans of any external IP addresses associated with in-scope systems.

For penetration testing on AWS, AWS requires notification before testing begins. The AWS penetration testing policy allows customers to conduct penetration tests against their own AWS resources without prior approval for most services. Review the current policy in the AWS documentation before scheduling tests.

Related Reading

• SOC 2 compliance on AWS — overlapping controls and audit evidence approaches
• HIPAA compliance on AWS — comparison with HIPAA technical safeguards
• Compliance risk scoring — tracking PCI DSS control coverage with risk scoring
• AWS WAF monitoring — WAF configuration for Requirement 6.4

FAQ

Does using Stripe or another payment processor eliminate PCI DSS requirements?

Using a processor with full payment page hosting (Stripe Checkout, PayPal-hosted pages, Braintree Drop-in) and not storing cardholder data yourself dramatically reduces your PCI scope. You may qualify for SAQ A (Self-Assessment Questionnaire A), the simplest form with about 20 requirements. You don't eliminate PCI DSS entirely — you still need to maintain your payment integration securely — but the compliance burden is far lower than a full CDE. Discuss your specific integration model with a Qualified Security Assessor.

What's the difference between SAQ and ROC?

A Self-Assessment Questionnaire (SAQ) is a self-administered compliance assessment. A Report on Compliance (ROC) is conducted by a Qualified Security Assessor (QSA) and required for large merchants and service providers at Level 1. Service providers processing more than 300,000 Visa or MasterCard transactions annually typically need a ROC. Smaller service providers and merchants may qualify for SAQ. Your card brand and acquiring bank determine which assessment type applies to your organization.

How often does PCI DSS change?

PCI DSS version 4.0 became effective in 2022, with v3.2.1 sunset in March 2024. Version 4.0 introduced new requirements around authentication (FIDO2 support), software supply chain, and monitoring. Future versions are issued by the PCI Security Standards Council on a multi-year cycle. Subscribe to PCI SSC updates to stay current on requirement changes and upcoming compliance deadlines.