What changed from v3.2.1 to v4.0
PCI DSS v4.0 was published in March 2022 with a transition period that ended on 31 March 2024. Requirements marked as "future-dated" became enforceable on 31 March 2025. In 2026 there is no grace period — every v4.0 requirement is live. The structural changes are significant: v4.0 introduces a customized approach (allowing alternative controls that meet the stated objective), expands MFA beyond CDE access to all access into the CDE, adds explicit requirements for scripting and payment page integrity (requirements 6.4.3 and 11.6.1), and formalizes third-party service provider accountability.
The customized approach is valuable but risky. It allows you to meet a requirement's objective through a different control than the one prescribed, provided you document the rationale and the QSA agrees. Most lean teams should stick with the defined approach unless they have a compelling architectural reason and experienced compliance counsel.
SAQ type selection and scope reduction
Choosing the correct Self-Assessment Questionnaire type is the single most impactful decision for compliance effort. The wrong SAQ either under-reports your scope (audit failure) or over-reports it (unnecessary cost). The primary types for e-commerce operators:
- SAQ A: All cardholder data functions are fully outsourced to a PCI DSS validated third party. Your systems never touch, process or store account data. Requires iframe redirect or hosted fields only.
- SAQ A-EP: Your website creates the payment form content (even if data flows directly to the processor). You control the page that could be modified to redirect data. Requires quarterly external scans and more controls than SAQ A.
- SAQ B-IP: Standalone IP-connected payment terminals (not applicable to e-commerce).
- SAQ C: Payment application systems connected to the internet, no electronic cardholder data storage. Small e-commerce with self-hosted payment software.
- SAQ D: Everything else. Full 300+ question assessment. If you store, process or transmit card data on your own systems, this is your SAQ.
The path from SAQ D to SAQ A runs through tokenization. If you can demonstrate that your systems only ever handle tokens — never primary account numbers — and the token vault is managed by a validated TPSP, your CDE shrinks to the point where SAQ A becomes viable.
The 12 requirements mapped to action
PCI DSS v4.0 retains the 12 top-level requirement families. Below is what auditors actually ask for, where teams typically fail, and the practical fix:
| Requirement area | What auditors ask for | Common gap | Practical fix |
|---|---|---|---|
| Req 1 — Network controls | Current network diagram; firewall rule-set review evidence (every 6 months) | Diagram outdated by 2+ quarters | Auto-generate diagrams from IaC (Terraform state); calendar the review |
| Req 3 — Protect stored data | Data retention policy; evidence of secure deletion; PAN masking in logs | Legacy databases retaining full PAN past retention period | Quarterly automated scan for PAN patterns in all data stores |
| Req 6 — Secure systems | Change management records; code review evidence; payment page script inventory (6.4.3) | No inventory of scripts loaded on payment pages | Deploy CSP with strict-dynamic; maintain script allow-list as code |
| Req 8 — Authentication | MFA for all CDE access; password policy enforcement; unique IDs | Shared service accounts without MFA | Eliminate shared accounts; use secrets manager with per-session credentials |
| Req 10 — Logging | 12-month log retention; daily review evidence; time synchronization | Logs retained only 30 days; no documented daily review | Ship to centralized log platform with 13-month retention; automate daily anomaly alerts |
| Req 11 — Testing | Quarterly ASV scans (passing); IDS/IPS alerts; payment page change detection (11.6.1) | ASV scan overdue by days or weeks | Schedule scans in CI/CD pipeline; block deploys if scan is stale |
| Req 12 — Policy & TPSP | Information security policy (annual review); TPSP PCI DSS responsibility matrix; incident response plan tested annually | TPSP acknowledgment letters missing or outdated | Maintain a TPSP register with responsibility matrix; request annual re-confirmation |
Where teams actually fail
Across the assessments we support, five failure patterns account for the majority of findings:
- Log retention below 12 months. Requirement 10.5.1 demands immediate availability of the last three months and total retention of at least 12 months. Teams running ephemeral containers often lose logs on pod termination.
- Missing TPSP management. Requirement 12.8 demands a list of all TPSPs, a written description of their responsibilities, evidence they are PCI DSS compliant, and an annual review. Most teams have the list but lack the written acknowledgment.
- MFA coverage gaps. v4.0 extends MFA to all access into the CDE, not just remote access. API keys used by internal services that can reach the CDE now need compensating controls or MFA-equivalent protection.
- No change management trail. Requirement 6.5.1 requires documented change control procedures for all changes to system components. Teams deploying continuously without a changelog or approval trail cannot evidence this.
- Quarterly ASV scans missed or failed. Requirement 11.3.2 requires passing quarterly scans by an Approved Scanning Vendor. A scan with unremediated critical vulnerabilities does not count as passing.
The cheapest control is the one you never have to evidence because you removed the system from scope entirely.
Evidence collection and ROC/SAQ submission
Whether you submit a SAQ (self-assessed) or undergo a Report on Compliance (QSA-assessed), evidence quality determines audit duration. Prepare a continuously-updated evidence repository structured by requirement number. For each control, store: the policy document, a screenshot or export showing the control in operation, and the date range it covers.
For SAQ submission: complete the questionnaire honestly, attach your Attestation of Compliance (AOC), and submit to your acquirer before the deadline. For ROC: your QSA will request evidence in advance; a well-organized repository reduces billable QSA hours significantly.
Reusing SOC 2 controls
If your organization already maintains SOC 2 Type II, approximately 40% of the evidence overlaps. Common reusable areas: access control policies (SOC 2 CC6 maps to PCI Req 7/8), change management (CC8 maps to Req 6.5), logging and monitoring (CC7 maps to Req 10), and vendor management (CC9 maps to Req 12.8). The mapping is not one-to-one — PCI DSS is more prescriptive about implementation detail — but the underlying evidence artifacts often satisfy both frameworks with minor augmentation.
What to do this quarter
If you have not re-validated since v3.2.1 retired, start immediately. Confirm your SAQ type against your current architecture. Build the TPSP register with written responsibility acknowledgment. Extend log retention to 13 months and automate daily review alerts. Calendar your next ASV scan and block deployments if it lapses. These five actions close the majority of gaps we see in first-time v4.0 assessments.
Compliance is not a one-time project. Build evidence collection into your normal operational cadence — every sprint, every deploy, every vendor onboarding — and audit season becomes a reporting exercise rather than a fire drill.