PCI DSS in Cloud Environments

PCI DSS compliance in the cloud is simultaneously easier and harder than on-premises. Easier because cloud providers handle physical security, hardware lifecycle, and some network controls for you. Harder because the shared responsibility model means you need to know exactly which controls are yours, which are the provider’s, and which fall in the gap between.

PCI DSS Requirements Overview

Requirement	Category	Engineering Focus
1. Network segmentation	Build and maintain secure network	VPC design, security groups, WAF
2. Secure configurations	Protect system components	Hardened images, no defaults
3. Protect cardholder data	Protect stored data	Encryption, tokenization, masking
4. Encrypt transmission	Encrypt data in transit	TLS 1.2+, certificate management
5. Anti-malware	Maintain vulnerability management	Container scanning, endpoint protection
6. Secure development	Develop secure systems	SAST, DAST, code review
7. Restrict access	Access control	RBAC, least privilege, MFA
8. Identify and authenticate	Authentication	Unique IDs, MFA, password policy
9. Physical security	Restrict physical access	Cloud provider responsibility
10. Logging and monitoring	Track and monitor access	Audit logs, SIEM, alerting
11. Security testing	Regular testing	Pen testing, vulnerability scanning
12. Security policy	Maintain security policy	Documentation, training

Reducing PCI Scope with Tokenization

Without tokenization (full PCI scope):
    Customer → Your app → Your database (stores card numbers)
    → Your app, servers, databases, network ALL in PCI scope

With tokenization (minimal PCI scope):
    Customer → Stripe.js/Braintree Drop-in (card never touches your server)
    → Stripe returns token → Your app stores token only
    → Your app, servers, databases are OUT of PCI scope

Payment Approach	PCI Scope	SAQ Level
Hosted payment page (Stripe Checkout)	Minimal	SAQ A
iFrame embed (Stripe Elements)	Low	SAQ A-EP
Direct API with tokenization	Medium	SAQ D
Store card data yourself	Full	SAQ D (hardest)

Cloud Network Segmentation

CDE (Cardholder Data Environment) Isolation

VPC Architecture:
    ┌─────────────────────────────────────┐
    │            Public Subnet            │
    │   Load Balancer (WAF-protected)     │
    ├─────────────────────────────────────┤
    │         Application Subnet          │
    │   App servers (no card data)        │
    ├─────────────────────────────────────┤
    │           CDE Subnet                │ ← PCI scope
    │   Payment processing service        │
    │   No internet access                │
    │   Restrictive security groups       │
    ├─────────────────────────────────────┤
    │          Database Subnet            │ ← PCI scope if stores CHD
    │   Encrypted RDS/Cloud SQL           │
    │   No internet access                │
    └─────────────────────────────────────┘

Security Group Rules for CDE

Direction	Source/Destination	Port	Protocol	Purpose
Inbound	App subnet only	443	HTTPS	Payment API calls
Inbound	Management subnet	22/3389	SSH/RDP	Admin access (MFA required)
Outbound	Payment processor	443	HTTPS	Stripe/Braintree API
Outbound	None	All	All	Default deny outbound

Encryption Requirements

Data State	Requirement	Implementation
Card data at rest	AES-256, keys rotated annually	Cloud KMS + application-layer encryption
Card data in transit	TLS 1.2+	Enforce HTTPS, HSTS, strong cipher suites
Key management	Dual control, split knowledge	Cloud KMS with IAM-restricted access
PAN display	Mask all but first 6 / last 4	Application-level masking
PAN in logs	Never log full PAN	Log redaction + automated scanning

Logging and Monitoring (Requirement 10)

Event	Log Fields	Retention
All access to cardholder data	User, timestamp, data accessed, action	1 year (3 months immediately available)
Admin actions	User, action, system, timestamp	1 year
Authentication events	User, success/failure, IP, timestamp	1 year
Access to audit logs	User, timestamp	1 year
Changes to security configurations	User, setting, before/after, timestamp	1 year

Monitoring Alerts

Alert	Trigger	Response
Multiple failed login attempts	> 5 failures in 10 min	Investigate, potentially lock account
Access to CDE from new IP	IP not in allowlist	Verify authorization
Bulk data export	> N records accessed in M minutes	Investigate potential exfiltration
Security group change	Any change to CDE security groups	Verify change was authorized

Cloud Provider Shared Responsibility

Control	AWS	Azure	GCP	Your Responsibility
Physical security	✅	✅	✅	None
Hypervisor security	✅	✅	✅	None
Network infrastructure	✅	✅	✅	Security group configuration
OS patching	Shared	Shared	Shared	Apply patches on your VMs/containers
Application security	❌	❌	❌	Full responsibility
Data encryption	Tools provided	Tools provided	Tools provided	Configuration and key management
IAM	Tools provided	Tools provided	Tools provided	Policy configuration and review

Anti-Patterns

Anti-Pattern	PCI Risk	Fix
Card numbers in application logs	PAN exposure	Log redaction + automated PAN scanning
Flat network (no CDE segmentation)	Entire infrastructure in PCI scope	VPC segmentation, CDE subnet isolation
Shared admin accounts	No individual accountability	Unique IDs + MFA + audit trail
Annual vulnerability scan only	Missed vulnerabilities between scans	Quarterly scans + continuous container scanning
Storing card data “for convenience”	Maximum PCI scope	Use tokenization (Stripe, Braintree)

Checklist

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For PCI compliance consulting, visit garnetgrid.com. :::