PCI DSS 4.0.1 · Payment Card Industry Security Standards Council
PCI DSS 4.0.1 on AWS — Scope Reduction Before Compliance
PCI DSS 4.0.1 enforced from 31 March 2025. The audit fails on scope, not technical controls. We reduce the cardholder data environment first, then implement controls — so your QSA reviews 30% of the surface area instead of 100%.
Framework
Payment Card Industry Data Security Standard
Version
PCI DSS 4.0.1 — published June 2024, enforceable from 31 March 2025 (replaces 4.0)
Regulator
Payment Card Industry Security Standards Council (PCI SSC) — enforced via card brands and acquirers
Assessor type
Level 1 (≥6M transactions/year per brand): Qualified Security Assessor (QSA) on PCI SSC list. Level 2 (1M–6M): may use Self-Assessment Questionnaire D + Internal Security Assessor depending on brand.
Scope: Any organization that stores, processes, or transmits cardholder data — typical for fintechs, payment processors, e-commerce platforms, and card-on-file SaaS.
Part of the AWS Security & Compliance hub .
Who needs this
Teams that typically engage on PCI DSS 4.0.1 on AWS
E-commerce platforms storing card-on-file or processing recurring payments
SaaS platforms that touch primary account numbers (PANs) even briefly
Companies migrating off legacy payment infrastructure to AWS-native architectures
Shared Responsibility
AWS Shared Responsibility for PCI DSS 4.0.1 on AWS
What AWS does, what you do, and where the line moves under this specific framework.
AWS owns
- AWS publishes its PCI DSS 4.0.1 Attestation of Compliance (AoC) on AWS Artifact — covers AWS as a Level 1 service provider
- AWS Foundational Security Best Practices Security Hub standard maps to PCI DSS controls
- AWS Config publishes a PCI DSS conformance pack for continuous evaluation
Joint
- Vulnerability management — AWS Inspector v2 scans, you triage and remediate by CVSS + KEV
- Network segmentation — AWS provides VPCs, security groups, NACLs, Network Firewall; you design the CDE topology
- Logging and monitoring — AWS provides CloudTrail/CloudWatch; you configure 1-year hot retention + 1-year cold for PCI
You own
- Req 1: Network security controls (segmentation, ingress/egress filtering, no direct internet to CDE)
- Req 2: Secure configuration (CIS AWS Foundations baseline, no defaults, hardened AMIs)
- Req 3: Protect stored account data (tokenization, KMS encryption, key rotation)
- Req 4: Protect data in transit (TLS 1.2+, no unencrypted PAN over public networks)
- Req 5: Anti-malware (GuardDuty Malware Protection, Inspector v2)
- Req 6: Secure development (CodeGuru, Inspector code scanning, peer review, **Req 6.4.3 script integrity** for payment pages)
- Req 7: Restrict access by need-to-know (IAM least privilege, ABAC, no broad IAM:* policies)
- Req 8: Identify users (MFA, no shared accounts, password policy)
- Req 9: Restrict physical access (mostly inherited from AWS)
- Req 10: Log and monitor all access (CloudTrail multi-region with log file validation)
- Req 11: Test security regularly (quarterly external scans, annual penetration testing)
- Req 12: Maintain information security policy
Control-by-control AWS implementation
Each control mapped to the AWS service that satisfies it
Excerpts from the full control matrix we deliver in the engagement. Not exhaustive — your audit scope drives the final mapping.
Requirement 1 — Network Security Controls
Req 1 is where most CDE scope creep originates. Bad segmentation pulls every workload into PCI scope.
| Control | AWS services | Implementation note |
|---|---|---|
| 1.2 Network security controls (NSCs) configured and maintained | VPC Security Groups Network ACLs Network Firewall Firewall Manager | CDE in dedicated VPC; security-group-as-policy enforced via Firewall Manager Org-wide. |
| 1.3 Network access to and from CDE is restricted | Network Firewall (Suricata IPS) AWS PrivateLink Transit Gateway with route filtering | No direct internet ingress to CDE; egress via Network Firewall with stateful domain filtering. |
| 1.4 Network connections between trusted and untrusted networks are controlled | VPC Endpoints (Gateway + Interface) PrivateLink AWS Site-to-Site VPN | AWS-internal CDE traffic stays on PrivateLink; partner connectivity via VPN with IPsec. |
1.2
Network security controls (NSCs) configured and maintained
AWS services
VPC Security Groups Network ACLs Network Firewall Firewall Manager
CDE in dedicated VPC; security-group-as-policy enforced via Firewall Manager Org-wide.
1.3
Network access to and from CDE is restricted
AWS services
Network Firewall (Suricata IPS) AWS PrivateLink Transit Gateway with route filtering
No direct internet ingress to CDE; egress via Network Firewall with stateful domain filtering.
1.4
Network connections between trusted and untrusted networks are controlled
AWS services
VPC Endpoints (Gateway + Interface) PrivateLink AWS Site-to-Site VPN
AWS-internal CDE traffic stays on PrivateLink; partner connectivity via VPN with IPsec.
Requirement 6 — Develop and Maintain Secure Systems
PCI DSS 4.0.1 added Req 6.4.3 (script integrity for payment pages) and 11.6.1 (change-and-tamper detection on payment pages) — both enforceable from 31 March 2025.
| Control | AWS services | Implementation note |
|---|---|---|
| 6.2 Bespoke and custom software developed securely | CodeGuru Reviewer Inspector v2 (Lambda code, ECR) Amazon Q Developer (security suggestions) | Static analysis on every PR; ECR image scanning blocks deploys with critical CVEs. |
| 6.3.3 All system components are protected from known vulnerabilities | Inspector v2 Systems Manager Patch Manager AWS Backup | Critical CVEs patched within 30 days; CVSS-and-KEV-aware prioritization. |
| 6.4.3 Scripts on payment pages are managed (NEW in 4.0.1, enforceable 31 March 2025) | AWS WAF managed rules — Common Rule Set + custom JavaScript SRI rules CloudFront Functions for SRI hash validation | Inventory of all scripts on payment pages; integrity check via Subresource Integrity (SRI); change detection via CloudFront log analysis. |
6.2
Bespoke and custom software developed securely
AWS services
CodeGuru Reviewer Inspector v2 (Lambda code, ECR) Amazon Q Developer (security suggestions)
Static analysis on every PR; ECR image scanning blocks deploys with critical CVEs.
6.3.3
All system components are protected from known vulnerabilities
AWS services
Inspector v2 Systems Manager Patch Manager AWS Backup
Critical CVEs patched within 30 days; CVSS-and-KEV-aware prioritization.
6.4.3
Scripts on payment pages are managed (NEW in 4.0.1, enforceable 31 March 2025)
AWS services
AWS WAF managed rules — Common Rule Set + custom JavaScript SRI rules CloudFront Functions for SRI hash validation
Inventory of all scripts on payment pages; integrity check via Subresource Integrity (SRI); change detection via CloudFront log analysis.
Requirement 11 — Testing
Req 11.6.1 (payment page tamper detection) added in 4.0.1 — same enforcement date as 6.4.3.
| Control | AWS services | Implementation note |
|---|---|---|
| 11.3.1 External vulnerability scans (quarterly + after significant change) | Approved Scanning Vendor (ASV) on PCI SSC list Inspector v2 for internal | External scans by ASV; internal scans by Inspector v2 with weekly cadence. |
| 11.4 External and internal penetration testing | AWS Penetration Testing program (no pre-approval needed for most services since 2019) | Annual external pen test + segmentation testing; AWS-aware pen test scope (IAM, S3, IMDS, container). |
| 11.6.1 Change-and-tamper detection on payment pages (NEW in 4.0.1) | CloudFront real-time logs CloudWatch Logs Insights Lambda for SRI hash comparison | Weekly automated integrity check on payment-page DOM and headers; alerts on unexpected changes. |
11.3.1
External vulnerability scans (quarterly + after significant change)
AWS services
Approved Scanning Vendor (ASV) on PCI SSC list Inspector v2 for internal
External scans by ASV; internal scans by Inspector v2 with weekly cadence.
11.4
External and internal penetration testing
AWS services
AWS Penetration Testing program (no pre-approval needed for most services since 2019)
Annual external pen test + segmentation testing; AWS-aware pen test scope (IAM, S3, IMDS, container).
11.6.1
Change-and-tamper detection on payment pages (NEW in 4.0.1)
AWS services
CloudFront real-time logs CloudWatch Logs Insights Lambda for SRI hash comparison
Weekly automated integrity check on payment-page DOM and headers; alerts on unexpected changes.
Evidence pipeline
How PCI DSS 4.0.1 on AWS evidence flows continuously
Audit Manager closed to new customers on 30 April 2026. Our pipeline is what we now ship.
AWS Config conformance pack — PCI DSS 4.0
AWS-published conformance pack updated for PCI DSS 4.0; deployable Org-wide.
Security Hub PCI DSS 4.0 standard
AWS Security Hub publishes a PCI DSS 4.0 standard — continuous controls evaluation.
CloudTrail Lake — 1 year hot + 1 year cold
Req 10.5.1 — 1 year of audit log retention with at least 3 months immediately available.
QSA evidence package
Network segmentation diagrams, CDE inventory, IAM least-privilege evidence, encryption proofs — packaged for the QSA fieldwork.
Engagement timeline
What you get, week by week
Date-bound engagement, not an open-ended retainer. Deliverables are itemised in the SOW.
1
Weeks 1–2 — Scoping
Weeks 1–2
- CDE inventory — every system that stores, processes, or transmits PAN
- Scope reduction plan — tokenization candidates, segmentation moves, third-party hosted payment fields
- PCI level confirmation (Level 1, 2, 3, 4) and assessor type (QSA, ISA + SAQ-D)
2
Weeks 3–6 — Scope Reduction
Weeks 3–6
- Tokenization implementation (typically: stripe.js, Adyen Components, or in-house tokenization service)
- Network segmentation — CDE moved to dedicated VPC + Network Firewall enforcement
- Removal of PAN from logs, backups, analytics pipelines (the largest single source of scope creep)
3
Weeks 7–12 — Control Implementation
Weeks 7–12
- Req 6.4.3 script integrity — SRI hash validation, payment page allow-list
- Req 11.6.1 tamper detection — automated DOM and header monitoring
- IAM least privilege for CDE access, MFA enforcement, quarterly access reviews
- WAF + Shield Advanced + GuardDuty + Inspector v2 + Macie deployed
4
Audit window
4–8 weeks
- QSA fieldwork (Level 1) or SAQ-D completion (Level 2)
- Attestation of Compliance (AoC) — distributable to acquiring banks and customers
- Report on Compliance (RoC) for Level 1
Related guides
Deep-dive guides on PCI DSS 4.0.1 on AWS
From inside paid engagements — same patterns, more depth.
PCI DSS Compliance on AWS: Architecture Guide for Fintech
A practical architecture guide for PCI DSS compliance on AWS — CDE scoping, the 12 requirements mapped to AWS services, network design, encryption, logging, and audit readiness for payment-processing applications.
Learn more
AWS WAF: Web Application Firewall Configuration for Production
AWS WAF blocks attacks. It also blocks legitimate users when the rules are wrong — and that's a worse incident. Managed rule groups, custom rules, rate limiting, bot control, and the layered defense strategy that protects without flooding your support queue.
Learn more
How to Configure AWS WAF for API Protection (Beyond the Basics)
AWS WAF protects APIs from SQL injection, XSS, DDoS, and account takeover attacks. This guide covers advanced WAF rules, rate limiting, bot control, and production patterns for defending REST APIs and GraphQL endpoints.
Learn more
Related frameworks
Frameworks that overlap with this one
Multi-framework scope is the norm. Most teams certify on two or three at once.
SOC 2 Type II on AWS
CC1–CC9 trust services criteria mapped to AWS-native controls, evidence pipeline, and a CPA-firm-ready audit package — for SaaS founders facing enterprise procurement.
Learn more
ISO 27001:2022 on AWS
Annex A.5–A.8 implementation, ISMS scoping, climate-change context (Amendment 1:2024), notified-body audit prep — for SaaS expanding to EU/APAC and regulated B2B vendors.
Learn more
FAQ
Frequently asked questions about PCI DSS 4.0.1 on AWS
The questions buyers ask before signing — assessor type, timeline, cost, and AWS-specific scope.
How does PCI DSS 4.0.1 differ from 4.0?
PCI DSS 4.0.1 was published June 2024 and replaced 4.0 — clarifications and minor changes only, no new requirements introduced. The big enforcement date is 31 March 2025: future-dated requirements from 4.0 became enforceable, including Req 6.4.3 (script integrity for payment pages), Req 11.6.1 (change-and-tamper detection on payment pages), Req 8.4.2 (MFA for all access into the CDE — not just admin), Req 8.6 (passwords for application/system accounts changed periodically), and Req 10.4.1.1 (automated mechanisms to perform audit log reviews). If you certified under 4.0 in 2024, your 2025 renewal must demonstrate the future-dated requirements are operating.
What is CDE scope reduction, and why does it matter?
The Cardholder Data Environment (CDE) is every system that stores, processes, or transmits primary account numbers (PANs). PCI DSS controls apply to every system in the CDE — and to systems that connect to the CDE. Scope reduction is the architectural work of shrinking the CDE: tokenize PAN at the perimeter so internal systems never see raw PAN, segment the CDE into a dedicated VPC, move card capture to hosted payment fields (Stripe Elements, Adyen Components) so PAN never touches your servers. A typical fintech reduces CDE scope by 60–80% before the audit — turning a 12-week QSA engagement into a 4-week one.
What is the new Req 6.4.3 script integrity requirement?
Req 6.4.3 (enforceable 31 March 2025) requires you to inventory all scripts on payment pages, justify each script's presence, and ensure their integrity. The implementation pattern: maintain a script allow-list, use Subresource Integrity (SRI) hashes on every <script> tag, monitor for changes, and alert on unauthorized scripts. Combined with Req 11.6.1 (change-and-tamper detection — weekly automated check), this addresses Magecart-style attacks where attackers inject card-skimming scripts into payment pages. CloudFront Functions + AWS WAF can enforce SRI; CloudFront real-time logs feed the tamper detection.
Do we need a QSA or can we self-assess?
Depends on your level. Level 1 (>6M Visa or MasterCard transactions/year per brand, or any breach victim) requires a QSA-conducted Report on Compliance (RoC). Levels 2–4 may use Self-Assessment Questionnaire D (SAQ-D) — though most acquirers ask Level 2 merchants to use a QSA-supervised SAQ-D or an Internal Security Assessor (ISA). Service providers have a separate level system (Level 1 for >300K transactions/year) and almost always end up with a QSA. American Express, Discover, JCB, and UnionPay each set their own level thresholds; check each brand you accept.
Can we use Stripe / Adyen / Braintree to avoid PCI scope entirely?
Yes — partially. Hosted payment fields (Stripe Elements, Adyen Components, Braintree Hosted Fields) let you accept card data without it ever reaching your servers, and you qualify for SAQ-A (the smallest questionnaire, ~22 questions) instead of SAQ-D (~329 questions). SAQ-A still requires Req 6.4.3 script integrity since 31 March 2025 — even with hosted fields, you control the page that loads them. Server-side card-on-file storage, recurring billing without a token-only flow, or any direct PAN handling still pulls you to SAQ-D or a QSA-led RoC.
How long does PCI DSS Level 1 certification take on AWS?
From scratch: 12–16 weeks for first attestation. Breakdown: 2 weeks scoping, 4 weeks scope reduction (tokenization + segmentation), 6 weeks control implementation (WAF, Inspector v2, Security Hub, GuardDuty, Network Firewall, KMS), 4–6 weeks QSA fieldwork. Renewals are faster — 6–10 weeks if no architectural changes. The variable is scope reduction depth; teams that try to certify with a full-scope CDE consistently take 20+ weeks and rebuild architecture mid-engagement.
Book a Free PCI DSS Scoping Assessment
2-week read-only assessment. We map your CDE, identify scope reduction opportunities, and quote the realistic Level 1 or Level 2 timeline. No retainer commitment.