PCI DSS v4.0 Changes That Affect Your 2026 Audit

Published April 26, 2026 · 12 min read

PCI DSS v3.2.1 was retired on 31 March 2024. The v4.0 future-dated requirements went mandatory on 31 March 2025. If your 2026 QSA audit is your first under fully-effective v4.0, the controls below will be the ones your assessor focuses on. We map each future-dated change to a concrete remediation a platform team can ship this quarter.

v4.0 in one sentence

PCI DSS v4.0 keeps the 12-requirement structure but adds 64 new sub-requirements (53 of which were future-dated through 2025) and introduces the Customised Approach — an alternative to the prescriptive defined approach where you can implement compensating controls if you document risk analysis.

Requirement 6.4.3 — payment-page script management

Every script loaded on a consumer-facing payment page must be authorised, integrity-assured, and inventoried. Magecart-style skimmer attacks (British Airways USD 230M ICO fine, Ticketmaster) drove this requirement. Implement Subresource Integrity (SRI) hashes plus a Content Security Policy that blocks unknown origins.

<script
  src="https://cdn.example.com/checkout.v3.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

# CSP enforcing allow-list
Content-Security-Policy: script-src 'self' 'sha256-abc...' https://cdn.example.com;

Requirement 8.3.6 — password length

Minimum 12-character passwords (up from 7), or system-generated values of equivalent complexity. Passphrases beat complexity rules — adopt zxcvbn-style strength meters and reject any password appearing in HIBP's breach corpus.

Requirement 8.4.2 — MFA for all CDE access

Multi-factor authentication is now required for all non-console access into the CDE, not just admin access. SMS OTP is allowed but discouraged — phishing-resistant FIDO2/WebAuthn is the QSA-preferred control.

Requirement 11.3.1.1 — quarterly internal vuln scans

Internal vulnerability scans must include all high-risk and critical findings remediated, with rescan. Document the discovery date, fix date, and rescan date for every CVSS ≥ 7.0 finding. A scheduled VAPT cadence with retest output satisfies this neatly.

Requirement 11.4 — penetration testing

Pentest annually and after every significant change. Internal + external + segmentation testing. Methodology must be industry-accepted (PTES, OWASP WSTG, NIST SP 800-115). Report must include: scope, methodology, findings, exploited vulnerabilities, and remediation actions with dates.

Requirement 11.5.1.1 — service-provider IDS/IPS for covert channels

Service providers must implement detection of covert malware communication channels (DNS tunneling, ICMP exfiltration). Network behaviour analytics (Zeek + RITA, Corelight, Vectra) handle this. Sigma rules covering T1071.004 (DNS C2) and T1095 (Non-Application Layer Protocol) belong in your SIEM.

Requirement 11.6.1 — change & tamper detection on payment pages

Detect unauthorised changes to HTTP headers and the script content of payment pages weekly at minimum. Tools: file integrity monitoring on the CDN edge, CSP violation reports, Reflectiz / Source Defense / Jscrambler. A simple cron-based hash diff against a baseline manifest works for small estates.

Requirement 12.6.3.1 — security awareness with phishing

Annual security awareness must include phishing-attack training relevant to current threat landscape. Document phishing simulation results. Vendor lock-in caution: KnowBe4, Hoxhunt, and CofenseAR all satisfy.

Customised approach — when to use it

The Customised Approach lets you implement an alternative control that meets the Customised Approach Objectivestated for each defined requirement. Document a Targeted Risk Analysis (TRA) per the PCI SSC TRA template, get QSA sign-off ahead of time. Use cases: legacy systems where MFA injection isn't feasible, custom HSMs where standard key-rotation cadence isn't supported.

Caution: Customised Approach is more work, not less. Each customised control needs its own risk analysis, control description, evidence-gathering plan, and assessor testing procedure.

SAQ changes

SAQ	v4.0 change
SAQ A	Now requires script management (6.4.3) and tamper detection (11.6.1)
SAQ A-EP	Adds anti-skimmer monitoring on iframe domains
SAQ D	+15 new questions across MFA, scanning, awareness training
SAQ P2PE	Largely unchanged but PIM-token usage clarified

Common QSA findings on v4.0 first audits

No documented Targeted Risk Analyses for any control performed at custom frequencies (12.3.1).
Payment-page CSP missing or in report-only mode (6.4.3).
Quarterly scans with critical findings open > 90 days (11.3.1.1).
MFA exclusions for service accounts & cron jobs without justification (8.4.2).
Phishing-simulation reports missing or aggregated only at year-end (12.6.3.1).

Quick remediation checklist

Run an in-scope inventory of every payment-page script and SRI-hash them.
Enforce CSP in blocking mode behind a 30-day report-only validation.
Schedule quarterly internal scans with mandatory rescan and ticketing tied to the CVE.
Document at least one TRA — the "password rotation cadence" one is the easiest first.
Run a v4.0-aware VAPT engagement 60 days before your QSA window.

Targeted Risk Analysis (TRA) — the new evidence backbone

v4.0 introduces formal Targeted Risk Analyses for any control performed at a frequency the standard does not prescribe (12.3.1) and for any Customised Approach implementation (12.3.2). The TRA is short — typically two pages — but it must follow the PCI SSC template structure: identification of the asset(s), threats, existing controls, residual risk, justification for chosen frequency or customised control, and a review date. Without a written TRA on file, a QSA will assume the control is non-compliant; with one, the assessor moves on.

The single highest-leverage TRA to write first is the password-change-frequency one (8.3.9). v4.0 allows you to extend the historical 90-day rotation if you can demonstrate a compensating control (typically continuous monitoring of credential breach corpora plus phishing-resistant MFA). The TRA takes an afternoon and saves your users from quarterly password churn — a tangible UX win that pays for itself in helpdesk tickets avoided.

Cardholder data flow — the exercise that grounds scope

Every QSA scoping conversation starts the same way: show me the cardholder data flow diagram. v4.0 does not change the requirement, but it sharpens it: requirement 12.5.2 demands the diagram be reviewed annually (and after any significant change). Build the diagram around the seven actions CDE data takes: capture, transmit, process, store, retrieve, share, delete. For each action, identify the system, the people, the data classification, and the control. The exercise normally uncovers two or three systems quietly handling PAN that everyone forgot existed — usually a customer-service backoffice, a finance reconciliation tool, or a fraud analytics warehouse.

Once the diagram is honest, scope reduction becomes a tractable problem. Tokenise the legacy paths, move the analytics pipeline onto post-tokenisation data, and you can shrink the audited estate substantially. This is the one engineering investment that has the largest pay-back on QSA fees and on the operating cost of running a CDE.

Where the QSA will stress-test you in fieldwork

Sample sizes — for any control evidenced over a period, the QSA samples 25-40 instances. Make sure your evidence store can produce them on request, not after a two-day forensics sprint.
Contractor access — third-party developers, ops vendors, MSPs are in scope for 8.x controls. Their MFA, off-boarding, and access reviews must match the rigour of your own employees'.
Encryption key custody — split-knowledge and dual-control on KEK material (3.6.x). HSM evidence (FIPS 140-2/3 certs) needs to be on file for every key custodian role.
Logging completeness — 10.x is where many programmes lose points. Every privileged action, every access-control decision, every cryptographic operation, in a tamper-evident store with at least one year online and three years archived.
Change-management traceability — every production change must trace to an approved ticket, a code review, and a deployment record. CD pipelines that auto-merge dependabot PRs into prod will be flagged unless the auto-merge gate is itself documented as a control.

PCI DSS roadmap to v4.0.1 and beyond

The PCI SSC published v4.0.1 in June 2024 — a clarifications-only update, no new controls. v4.0.1 is the version your QSA will assess against from 2025 onward. The Council's public documents confirm there is no immediate v4.1 / v5 work scheduled — instead expect targeted guidance documents (web-application script management, AI/ML usage in CDE) issued through the document library. Plan for an annual reassessment under the same v4.0.1 framework for at least the next 24 months.