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 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, Amazon Inspector, 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.

A worn iron lock plate with its key, 1700–1730 — PCI DSS 11.6.1 Change-and-tamper detection on payment pages (NEW in 4.0.1)

PCI DSS 4.0.1 on AWS

Scope Reduction Before Compliance.

Book a Free PCI DSS Scoping Assessment

9 controls Audit once FAQ The hub

PCI DSS at a glance

PCI DSS 4.0.1 has been enforceable since 31 March 2025 — Req 6.4.3 script integrity and Req 11.6.1 tamper detection are now in-scope on every assessment. 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

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.

Who engages on PCI DSS

Fintech CTOs running payment processing on AWS at Level 1 or Level 2 volume
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

Where AWS stopsfor PCI DSS

What AWS does, what you do, and where the line moves under this framework.

The general split

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 — Amazon Inspector 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, Amazon Inspector)
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

Controls

9 PCI DSS controls in 3 families, each mapped to the AWS services that satisfy it.

Excerpts from the full matrix we deliver. Your audit scope drives the final mapping.

Requirement 1 — Network Security Controls3 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.

Requirement 6 — Develop and Maintain Secure Systems3 controls

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, Amazon Inspector (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	Amazon Inspector, 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 (4.0.1 future-dated requirement, enforceable since 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.

Requirement 11 — Testing3 controls

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, Amazon Inspector for internal	External scans by ASV; internal scans by Amazon Inspector 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.

Audit once, evidence four frameworks

Pick the frameworks you are scoped for. The tiles below are the AWS services that produce evidence for each one, with the control IDs they answer. The ones in navy cover every framework you picked: set them up once and the same evidence serves every auditor.

Counts come from the control excerpts on our four framework pages, not from your audit scope. Start from HIPAA, SOC 2, PCI DSS or ISO 27001.

AWS services evidence the 8 PCI DSS controls we map.

41 AWS services in total, mapped across 36 controls.

Amazon CloudWatch

HIPAA §164.312(b)
SOC 2 CC7.1, CC7.2
PCI DSS 11.6.1
ISO 27001 A.8.16

Amazon Inspector

HIPAA §164.308(a)(5)(ii)(B)
SOC 2 CC6.8
PCI DSS 6.2, 6.3.3, 11.3.1
ISO 27001 A.5.7, A.8.28

AWS Backup

HIPAA §164.312(c)(1)
SOC 2 CC7.5
PCI DSS 6.3.3
ISO 27001 A.5.30, A.8.10

AWS PrivateLink and VPC endpoints

HIPAA §164.312(e)(1)
SOC 2 CC6.7
PCI DSS 1.3, 1.4

AWS Systems Manager

HIPAA §164.308(a)(6)
SOC 2 CC7.3
PCI DSS 6.3.3

Amazon CloudFront

HIPAA §164.312(e)(1)
PCI DSS 6.4.3, 11.6.1

Amazon CodeGuru Reviewer

PCI DSS 6.2
ISO 27001 A.8.28

AWS Network Firewall

SOC 2 CC6.7
PCI DSS 1.2, 1.3

Amazon Q Developer

PCI DSS 6.2

Amazon VPC

PCI DSS 1.2

AWS Firewall Manager

PCI DSS 1.2

AWS Lambda

PCI DSS 11.6.1

AWS Site-to-Site VPN

PCI DSS 1.4

AWS Transit Gateway

PCI DSS 1.3

AWS WAF

PCI DSS 6.4.3

Amazon Detective

HIPAA §164.308(a)(1)(ii)(D)
SOC 2 CC7.4
ISO 27001 A.8.16

Amazon GuardDuty

HIPAA §164.308(a)(5)(ii)(B)
SOC 2 CC6.8, CC7.1, CC7.2
ISO 27001 A.5.7, A.8.16

AWS CloudTrail

HIPAA §164.308(a)(1)(ii)(D), §164.312(b)
SOC 2 CC6.2, CC7.4
ISO 27001 A.8.2

AWS Config

HIPAA §164.308(a)(1)(ii)(A), §164.312(b)
SOC 2 CC7.1
ISO 27001 A.5.23

AWS Security Hub

HIPAA §164.308(a)(1)(ii)(A), §164.308(a)(6)
SOC 2 CC7.1, CC7.3
ISO 27001 A.5.23, A.8.16

AWS Signer

HIPAA §164.312(c)(1)
SOC 2 CC6.8
ISO 27001 A.8.24

IAM Access Analyzer

HIPAA §164.308(a)(1)(ii)(A)
SOC 2 CC6.1
ISO 27001 A.5.15

IAM Identity Center

HIPAA §164.312(a)(1)
SOC 2 CC6.1, CC6.2, CC6.6
ISO 27001 A.5.15, A.8.2

Amazon Cognito

HIPAA §164.312(a)(1)
SOC 2 CC6.6

Amazon S3

HIPAA §164.312(c)(1)
ISO 27001 A.8.10

Amazon Security Lake

HIPAA §164.308(a)(1)(ii)(D)
SOC 2 CC7.4

AWS Certificate Manager

HIPAA §164.312(a)(2)(iv)
ISO 27001 A.8.24

AWS CloudHSM

HIPAA §164.312(a)(2)(iv)
ISO 27001 A.8.24

AWS Elastic Disaster Recovery

SOC 2 CC7.5
ISO 27001 A.5.30

AWS IAM

HIPAA §164.312(a)(1)
SOC 2 CC6.1, CC6.6

AWS KMS

HIPAA §164.312(a)(2)(iv), §164.312(c)(1)
ISO 27001 A.8.10, A.8.24

AWS Organizations and SCPs

SOC 2 CC6.1, CC6.2
ISO 27001 A.5.15, A.8.2

EventBridge

HIPAA §164.308(a)(6)
SOC 2 CC7.3

Step Functions

HIPAA §164.308(a)(6)
SOC 2 CC7.3

Amazon Verified Permissions

HIPAA §164.312(a)(1)

API Gateway

HIPAA §164.312(e)(1)

AWS CodePipeline

ISO 27001 A.8.28

AWS Control Tower

ISO 27001 A.5.23

AWS Shield

ISO 27001 A.5.7

AWS Trusted Advisor

HIPAA §164.308(a)(1)(ii)(A)

Elastic Load Balancing

HIPAA §164.312(e)(1)

How the evidence keeps flowing

AWS Audit Manager closed to new customers on 30 April 2026. This pipeline is what we ship now, and it runs after we leave.

AWS-published conformance pack updated for PCI DSS 4.0; deployable Org-wide.

AWS Security Hub publishes a PCI DSS 4.0 standard — continuous controls evaluation.

Req 10.5.1 — 1 year of audit log retention with at least 3 months immediately available.

Network segmentation diagrams, CDE inventory, IAM least-privilege evidence, encryption proofs — packaged for the QSA fieldwork.

What you get, week by week

A date-bound engagement, not an open-ended retainer. Every deliverable is itemised in the statement of work.

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)

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)

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 + Amazon Inspector + Macie deployed

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

Deeper reading on PCI DSS, and the frameworks (in navy) most teams certify alongside it.

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.

Read the guide

AWS WAF: Web Application Firewall Configuration for Production

AWS WAF blocks attacks. It also blocks legitimate users when the rules are wrong, which is a worse incident. Managed rule groups, custom rules, rate limiting, bot control, and the layered defense strategy that protects without flooding your support queue.