The evidence package arrived on a Tuesday. Seventeen folders, meticulously labelled — policies, network diagrams, scan reports. By Thursday, three of those folders were back on the table with findings against them. This was a bank that had passed PCI DSS v3.2.1 two years running. PCI DSS 4.0 had changed the standard. Their preparation hadn't.
That bank is representative. In the 17 PCI DSS v4.0.1 assessments I've completed since March 31, 2025 — the enforcement date — the pattern repeats with uncomfortable regularity: compliance programmes built for v3.2.1 encountering v4.0.1 in the assessment room for the first time. Not for want of time. The standard was published in March 2022. What banks underestimated was how many of the new requirements they had spent three years treating as optional guidance.
This article is not a framework summary. It is what I observed in 17 live assessments — the four requirement areas where banks fall short most consistently, what failure looks like in practice, and what to prioritise before your next ROC.
What PCI DSS 4.0 Actually Changed — and What Didn't
A brief orientation before the findings, because the numbers matter. PCI DSS v4.0 was published in March 2022 and introduced 64 new requirements across the standard. Thirteen of those were immediately effective for all v4.0 assessments from the point of publication. The remaining 51 were designated best practices — organisations were encouraged to implement them, but assessors could not mark them as findings.
On March 31, 2025, that changed. All 51 best-practice requirements became mandatory. There was no grace period beyond that date. Banks that had been treating those 51 requirements as "future planning" woke up on April 1, 2025 non-compliant. Many had.
PCI DSS v4.0.1, published in June 2024, introduced no new requirements — it was a clarification document correcting ambiguities in v4.0. The enforcement date remained March 31, 2025. v3.2.1 was retired simultaneously. The transition is over. What follows is what 17 assessments in the aftermath actually found.
PCI DSS version history — from publication to full enforcement
All future-dated requirements — designated best practice since 2022 — became mandatory on March 31, 2025. The transition window is closed. The assessments in this article are the first full cycle under the mandatory standard.
Four requirement areas produce findings in almost every assessment. Here is the first — and the one that generates the most immediately visible gap in the evidence package.
Req 6.4.2 and 8.4.2: The End of the Policy Pass
In every v4.0.1 assessment I've run, this is where I see the first gap. The finding shows up in the evidence package before fieldwork begins.
Under v3.2.1, Requirement 6.6 allowed entities to protect web applications using either a WAF or regular application vulnerability assessment tools — manual or automated. That option was removed in v4.0. Requirement 6.4.2 now mandates an automated technical solution that continually detects and prevents web-based attacks. A WAF is the practical implementation. And it must be proven operational — configuration exports, active logging, rule testing records — not documented as a policy intention.
v3.2.1 allowed banks considerable creative latitude in how they evidenced this requirement. v4.0.1 is less creative.
What v3.2.1 allowed
- WAF or regular vulnerability assessment tools (manual or automated)
- Policy document describing WAF/firewall use
- Network diagram with firewall symbol
- MFA for non-console administrative access only (Req 8.3)
- Broad MFA policy statement covering admin accounts
What v4.0.1 requires
- Automated technical solution — continual detection and prevention (Req 6.4.2)
- WAF configuration exports, active logging evidence, rule test records
- Secure WAF implementation evidence (configuration review)
- MFA for ALL access into the CDE — not just administrative (Req 8.4.2)
- MFA systems securely implemented — separate evidence of implementation controls (Req 8.5.1)
The MFA picture is where most banks find their specific exposure. Requirement 8.4.2 extends the scope beyond what v3.2.1's Requirement 8.3 required. All access into the CDE now requires MFA — not just administrative or remote access. One bank I worked with had MFA deployed correctly for administrator accounts and remote access. They failed because internal service desk access to CDE systems — staff using a support tool with CDE connectivity — had no second factor. The accounts were in scope. The MFA wasn't.
Requirement 8.5.1, which many banks hadn't noticed alongside 8.4.2, separately requires that MFA systems themselves are securely implemented — replay attack prevention, no MFA bypass mechanisms, lockout policies. I ask for evidence of the MFA implementation controls separately from the scope review. Most banks producing evidence for 8.4.2 haven't considered 8.5.1 at all.
The compound failure: MFA covers some CDE access paths but not all, and the MFA system implementation controls haven't been documented as a separate evidence item. Assessors look for both. The evidence required is not a policy — it's an access matrix and implementation review.
What the standard required
MFA required for all non-console administrative access into the CDE. Remote access for vendors and users also required MFA.
Evidence that passed
MFA policy; admin account list; MFA configuration screenshots for privileged accounts; vendor access MFA confirmation.
What assessors now test
MFA required for ALL access into the CDE — including non-administrative users, internal access to CDE systems, vendor access, service accounts with CDE connectivity. Scope is explicitly broader than administrative and remote access alone.
Evidence now required
Documented CDE access matrix covering all access paths; MFA configuration evidence for each category; access logs demonstrating enforcement; service account assessment for MFA applicability; Req 8.5.1 implementation controls as separate evidence.
Log management is where the second pattern appears — and it's the one I see most consistently across every bank size and geography. That's next.
Req 10.4.1.1 and 10.4.2.1: Log Automation and the TRA Problem
This is the finding I see most consistently. It's also the hardest to explain to clients who believe their logging programme is already in order. They're right that they have one. That's the problem.
v3.2.1 required log reviews. It was reasonably specific about what to log and how long to retain it. Banks built logging programmes against those requirements and considered the matter closed. What they didn't anticipate is that v4.0 didn't just refine what to log — it changed how the review must happen.
Requirement 10.4.1.1 mandates automated mechanisms for reviewing logs of all critical system components. Manual log review is no longer sufficient for those systems. Assessors ask for evidence of the automated mechanism — the SIEM alert configuration, the automated anomaly detection, the scheduled report that generates without human initiation. "Someone checks the SIEM each morning" is a manual review. It does not satisfy 10.4.1.1.
Requirement 10.4.2.1 is a separate problem layered on top. For all other system components — those not covered by 10.4.1 — a Targeted Risk Analysis is required to define how frequently logs are reviewed. Banks are failing on two counts simultaneously: no automated review evidence for critical systems, and no TRA documenting the frequency decisions they've been making informally for non-critical systems. Both were best practices until March 31, 2025.
No automated log review mechanism for critical systems (10.4.1.1)
Log review for critical system components is performed manually — periodic SIEM checks, morning reviews, ad-hoc investigation. No automated alert mechanism, no automated anomaly detection, no scheduled automated review report. The requirement is explicit that automation is required.
No TRA defining non-critical component review frequency (10.4.2.1)
The organisation has been reviewing non-critical system logs at some informal frequency — monthly, when something triggers attention, when the audit cycle approaches. No Targeted Risk Analysis documenting that frequency decision and connecting it to the CDE risk profile. Informal practice without documented justification doesn't satisfy this requirement.
Log retention period contradicts system configuration (10.5.1)
The policy states 12 months retention with 3 months immediately available. The SIEM is configured for 90-day hot storage with no archive or automated export. Policy and system disagree. Assessors verify retention against system configuration — not the policy document.
usually a compromise made during SIEM setup.
"Someone checks the SIEM each morning" is a manual review. Requirement 10.4.1.1 requires an automated mechanism. These are different things, and assessors distinguish between them.
From 17 PCI DSS v4.0.1 assessments since March 2025
Banks that address both 10.4.1.1 and 10.4.2.1 properly before an assessment don't just satisfy two requirements — they end up with a logging programme that is operationally sound rather than evidentially approximate.
Targeted Risk Analysis is where the third finding becomes interesting — because it's not a failure pattern unique to one requirement. It runs through the entire standard. That's next.
Req 12.3.1: The TRA Requirement That Actually Helps
Targeted Risk Analysis gets framed as administrative overhead. I disagree. It is the most useful thing v4.0 added.
Requirement 12.3.1 is the anchor: for any PCI DSS requirement that provides flexibility in how frequently a security activity must be performed, the entity must conduct a Targeted Risk Analysis. This isn't a single requirement — it threads through the standard. Malware scan frequency (5.2.3.1, 5.3.2.1). POI device inspection frequency (9.5.1.2.1). Log review frequency for non-critical components (10.4.2.1). Incident response training frequency (12.10.4.1). Every frequency decision in the standard now requires a documented risk analysis specific to the entity's CDE.
That sounds like considerably more work. In practice, for banks that engage with it properly, it produces something v3.2.1 never required: explicit, documented thinking about the specific risks in their actual CDE environment. A payment switch operator processing millions of daily transactions justifies its malware scan frequency differently than a small bank with a contained, low-volume CDE. TRA gives both organisations the mechanism to document and defend that difference. I've reviewed TRAs that, once completed properly, identified control gaps the bank wasn't tracking. That's not a compliance exercise — that's security management.
The failure pattern: organisations that receive a TRA template, populate it with standard industry frequencies — quarterly, annually, as-required — add the phrase "based on assessed risk," and submit it. Assessors identify these in minutes. A TRA that reads identically across organisations with different CDE architectures, transaction profiles, and threat landscapes is not a risk analysis. It is a completed form.
What a compliant TRA looks like across your CDE
The CDE environment is specifically described — transaction volumes, third-party dependencies, network architecture — not a generic reference to "our payment systems." Frequency decisions connect to actual, named risk factors. The TRA for malware scan frequency references the entity's specific exposure vectors, not generic industry language. Where the entity chooses a frequency that differs from common practice, the reasoning is explicit and traceable to documented risk factors — not stated as "assessed risk supports this frequency" without elaboration. The TRA is reviewed and updated when the CDE changes: new systems, new access paths, new third-party relationships. Annual-only review cycles are insufficient for dynamic CDE environments.
Banks that treat TRA as a genuine risk management tool come out of assessments with two things: passing findings and a clearer picture of their CDE risk posture than any v3.2.1 assessment ever produced. The ones that phone it in produce documents that assessors return with findings.
Requirement 6.4.3 — and its companion 11.6.1 — was the finding that produced the most genuine surprise in assessments. That's next.
Req 6.4.3 and 11.6.1: The Requirements Nobody Saw Coming
Any entity running v3.2.1 had no framework for this. I've watched compliance teams encounter Requirements 6.4.3 and 11.6.1 for the first time mid-assessment — and the experience is what I would describe as a productive silence.
Requirement 6.4.3 mandates that organisations manage all scripts loaded and executed in the consumer's browser on the payment page: an authorised inventory of every script, a method to confirm the integrity and authenticity of each, and a written justification for why each script is present. This is not a clarification of something that existed in v3.2.1. It is an entirely new operational discipline — front-end web security applied to the cardholder data environment.
Requirement 11.6.1 operates at a different layer. It requires a change-and-tamper-detection mechanism that alerts on unauthorised modifications to HTTP headers and the content of payment pages. This is the defensive control that 6.4.3 complements — the inventory tells you what should be there, and 11.6.1 tells you when something unauthorised appears.
Why do these requirements exist? Payment pages are high-value targets for JavaScript injection attacks — Magecart-style card skimming that intercepts payment data at the point of entry, in the browser. The PCI SSC introduced these requirements to address a threat vector that v3.2.1 had no specific control for. Banks using third-party embedded payment components, analytics scripts, or customer support widgets on their payment pages — with no governance over what those third parties load — are failing Requirement 6.4.3 completely.
In several assessments I've completed, the bank had no idea how many scripts were executing on their payment page. A browser audit during the assessment revealed analytics tools, A/B testing libraries, customer support chat widgets, and third-party payment widget loaders — none of which were inventoried, justified, or integrity-verified. The bank's compliance team had never thought about the payment page as a scope item for script governance. Most v3.2.1 programmes didn't.
Authorised script inventory
A documented list of every script permitted to execute on the payment page — first-party and third-party, including scripts loaded by other scripts. Start with a browser developer tools audit during a live payment page session to identify everything currently running.
Written justification per script
Each script in the inventory requires a documented business reason for its presence and a description of its function. "It came with the payment widget" is not a business justification that satisfies 6.4.3. Assessors look for specificity.
Integrity verification mechanism
A method to verify each script has not been modified. For external scripts, Subresource Integrity (SRI) hashes or Content Security Policy (CSP) headers. For first-party scripts, verified hash records in the change management system. One method per script, documented.
Change-and-tamper detection (Req 11.6.1)
A mechanism that alerts on unauthorised changes to HTTP headers and payment page content. This operates in addition to the script inventory — it is the detection control that identifies when something not in the inventory appears, or when an authorised script is modified without authorisation.
Change control coverage and evidenced review
Any addition, modification, or removal of a payment page script must go through formal change control referencing the script inventory. The inventory must be reviewed at the TRA-defined frequency, with reviews evidenced. An inventory last reviewed two years ago is not compliant.
The most practical starting point for banks encountering 6.4.3 for the first time: run a browser audit of your live payment page, list everything executing, and work backwards from there. The inventory is the foundation. Everything else builds on it.
Four more requirements are catching banks off-guard — not as frequently as the four main findings, but consistently enough to be worth documenting. Those are next.
Beyond the Four: Other Requirements Catching Banks Off-Guard
These four requirements aren't producing findings in every assessment — but they appear frequently enough to warrant specific attention, particularly for banks that consider their PCI DSS programme mature.
PCI DSS scope must be documented and confirmed at least annually and when significant changes occur. This was immediately effective for all v4.0 assessments from 2022 — not a best practice. Banks scope once during an ROC engagement and don't document re-confirmation. Assessors ask for the annual scope review record.
Minimum acceptable password length increased from 7 to 12 characters. Simple on paper. In practice: legacy systems with hardcoded 7-character minimums, authentication systems where the policy was updated but the system configuration wasn't. Policy says 12; the authentication system enforces 7.
All user accounts and all application and system accounts must be reviewed periodically. Legacy service accounts with no documented owner, no access justification, and no periodic review are a consistent finding. Many predate the current compliance programme.
Technical controls must prevent copy and relocation of PAN during remote access sessions. Policy statements asserting this control are not sufficient — actual technical implementation (DLP, remote session controls, copy-paste restrictions in remote desktop environments) must be evidenced. Policy and control are not the same evidence.
Requirement 4.2.1.1 — an inventory of trusted keys and certificates — also appears as a finding in a minority of assessments. Certificate management tends to be distributed across systems without central governance, and no v3.2.1 requirement built the habit of maintaining a certificate inventory.
If your assessment is approaching, here is what I would prioritise — in order of the findings I see most consistently.
What This Means for Your Next Assessment
If your next ROC is in the next 12 months, here is what I would prioritise — in order of assessment impact based on the findings I see across all 17 assessments.
Tap each step as you prepare. Progress saves in your browser.
These five items are not the entirety of what v4.0.1 requires. They are where findings concentrate. Preparation time invested here produces the most direct reduction in assessment risk.
A Note on the Customised Approach
v4.0.1 introduced the Customised Approach alongside the traditional Defined Approach. Most banks are not using it yet — and for straightforward CDE environments, there is no compelling reason to.
The Customised Approach, defined in Appendix D of the standard, allows an entity to meet the security objective of a requirement using controls of their own design, in lieu of the prescriptive implementation the Defined Approach specifies. It requires a Customised Approach controls matrix, a supporting risk analysis, and formal validation by both the entity and the assessor. The documentation burden is significantly higher than the Defined Approach.
Where it makes sense: mature environments with architecturally complex CDEs where the prescriptive implementation in the Defined Approach is genuinely suboptimal for the organisation's specific architecture. Where it doesn't: organisations viewing it as flexibility to implement something simpler than the Defined Approach requires. That's not what it is, and assessors approach Customised Approach submissions with proportionally higher scrutiny than Defined Approach evidence.
A full treatment of the Customised Approach — methodology, controls matrix structure, what "meeting the security objective" means in practice for complex CDEs — deserves its own article. That's coming.
For the full 12-requirement structure and technical depth, see the PCI DSS framework reference on Threat Manifest.
For related assessment methodology context from the financial institution space — evidence preparation disciplines that overlap with PCI DSS ROC work — see SWIFT CSP: The Independent Assessment Process.
The bottom line
v4.0.1 didn't change what good security looks like. It changed how much evidence you need that you're actually doing it — and for 51 requirements that spent three years as optional guidance, it changed whether you need to do it at all.
New PCI DSS, SWIFT CSP, and ISO 27001 practitioner content — when it's published, not on a schedule. If you want notification, the professional track newsletter is at the bottom of this page.
This article reflects the author's observations from professional assessment engagements completed since March 2025. It is practitioner perspective, not legal or compliance advice. Readers should verify all requirements against the current PCI DSS v4.0.1 standard published by the PCI Security Standards Council.