May 29, 2026

PCI DSS v4.0: How It Reshapes Assessment Engagements

Amanda Waldmann

Increasing trust with AI for audit and advisory firms.

Key Insights

Future-dated requirements are now mandatory, so assessments now surface control gaps that some clients previously deferred.
Customized assessments require assessor-designed testing, which adds planning time and raises evidence demands.
The ROC now depends on structured evidence indexing tied to testing procedures, not narrative support assembled at the end.
Continuous-control evidence must cover the full assessment period, which changes request lists and fieldwork timing.

It's week three of fieldwork, and you're still tracing evidence references back to testing procedures, fielding judgment calls on sampling rationale, and finding readiness gaps the client thought they had closed last quarter. Each of those got harder under v4.0.

That pressure now reaches every phase of the engagement, from scoping through final reporting. This article covers the major v4.0 changes, the ROC template overhaul, and what the Customized Approach means in practice.

What Is PCI DSS v4.0?

PCI DSS is the security standard any organization handling cardholder data has to meet to keep processing payments. It is maintained by the PCI Security Standards Council and enforced through the card brands and acquiring banks, not by a regulator. Version 4.0 is the latest rewrite of the standard, and it shifts the model from a static checklist toward continuous, outcome-based security.

For assessors, the practical difference is straightforward. The standard now expects controls that operate year-round, not just during fieldwork. It gives clients more flexibility in how they meet each requirement, and it raises the bar on the evidence you collect to validate them.

Of the 64 new requirements introduced in v4.0, 51 were future-dated and became mandatory on March 31, 2025. If a client's last assessment predates that shift and they did not get ahead of the new controls, expect to surface gaps. That tends to mean more remediation conversations, more evidence to chase, and more pre-fieldwork readiness work than a routine renewal would have required.

What Changed from v3.2.1 to v4.0

The short version: v4.0 widened scope, raised the evidence bar, and gave organizations a new way to meet requirements through custom controls. The Summary of Changes covers the full list. The changes below are the ones most likely to affect engagement planning, scoping decisions, and the evidence mix.

Expanded Scope Terminology

Some of the most consequential changes are wording changes that widen what you assess:

"Firewall" became "network security controls" in Requirement 1. Cloud security groups, host-based firewalls, and SDN policies all come into scope, not just the perimeter appliance.
"Anti-virus" became "anti-malware" in Requirement 5. EDR and behavior-based tools come into scope alongside traditional AV signatures.
"Cardholder data" became "account data". The population now covers sensitive authentication data alongside the PAN.

None of these are cosmetic. Each one expands the population of systems and evidence you validate during the assessment.

MFA Now Applies to All CDE Access

Multi-factor authentication is no longer limited to remote and administrative access. Any access into the cardholder data environment requires MFA, including console logins from inside the corporate network. For clients who only had MFA on VPN and admin accounts, that is a real implementation lift and usually the first place a readiness gap surfaces.

E-Commerce Payment Page Protections

The new e-commerce requirements close a frequently exploited gap: skimming attacks that inject malicious scripts into payment pages. Clients now need to inventory and authorize every script that runs on a payment page and detect unauthorized changes to those pages and HTTP headers. If you are assessing a merchant that takes card payments through a web checkout and they have not implemented script integrity and change-and-tamper detection, that is going to be a finding.

Targeted Risk Analysis as a Formal Artifact

Several v4.0 requirements let the client choose how often a control runs, provided they back the frequency with a documented risk analysis. The Targeted Risk Analysis is what justifies that choice, and you validate it like any other control artifact. In practice, that means the TRA package becomes part of the standard evidence request, and a missing or thin TRA will block sign-off on the related control.

Two Assessment Pathways

The biggest structural change is the choice between two ways to demonstrate compliance. The Defined Approach is the prescriptive model the standard has always used, with the testing procedures laid out in the requirement. The Customized Approach lets the client design its own control to meet a stated objective, and the assessor derives independent testing procedures from scratch. The Customized Approach is more flexible for mature clients and more work for the assessor, which is why the engagement economics shift the moment a client opts into it.

The 12 Core Requirements: Where Evidence Gaps Surface

PCI DSS is organized around 12 control families that cover network security, data protection, vulnerability management, access control, monitoring, and governance. Most of those families look familiar from prior versions. What changed in v4.0 is the depth of evidence behind each one and a new expectation that runs across all of them: every technical requirement now has an explicit roles-and-responsibilities sub-requirement. Clients have to name who owns each control, and you collect documentation that backs up both the control and the ownership.

Two requirement families carry most of the new weight. The ones below are where readiness gaps and evidence burdens tend to show up first.

Authentication and Access (Requirement 8)

Authentication has the broadest reach because it touches every user, every system, and every login path into the cardholder data environment. Password length and complexity minimums went up, and customer-facing systems that still rely on password-only access now have to either rotate passwords on a defined cadence or run continuous monitoring of the user's security posture. That second path is new territory; there is no v3.2.1 precedent, so the evidence has to demonstrate the mechanism actually works.

Governance and Risk Documentation (Requirement 12)

Requirement 12 has always been the policy-and-program family, but in v4.0 it is where the new documentation burden concentrates. Targeted Risk Analyses justify how often discretionary controls run. Customized Approach implementations need full design and testing documentation. Service providers carry an extra layer: scope is confirmed at least every 12 months, and shared-responsibility documentation has to be current. None of this is technically complex, but the volume of artifacts is what stretches an engagement budget.

How v4.0 Changes the Assessment Engagement

The ROC template overhaul is where you will likely feel the difference most in day-to-day fieldwork. Assessor feedback on the original v4.0 template centered on length, redundant fields, and performance issues with large final reports. The v4.0.1 revisions responded to those concerns and formalized several workflow changes that affect how your engagement team operates.

Several workflow changes drive most of the difference. Each one moves work earlier in the engagement and tightens the link between evidence, testing, and the final report.

Structured evidence references: Each testing procedure in the ROC now links to specific evidence entries in a structured index, replacing the narrative evidence cataloging at the end of prior templates. The index has to be built during fieldwork and stay internally consistent, because QA reviewers will trace every reference. That coordination across team members is where platform-based engagement management earns its keep, keeping references consistent in real time rather than reconciled at the end.
Approach declared per requirement: For every requirement, you formally declare whether the Defined Approach or Customized Approach was used, with a separate flag for compensating controls. The template moved this section earlier, which signals the expectation: approach selection happens in planning, not in report writing.
No more "In Place with Remediation": PCI SSC removed that status. The valid statuses are now In Place, In Place with CCW, Not in Place, and Not Applicable. The path that previously let QSAs issue ROCs while remediation was still in progress is gone, which puts more weight on pre-engagement readiness confirmation.
Sampling is fully assessor judgment: Explicit sampling references were removed from individual testing procedures. Sampling decisions sit entirely with the assessor, with full rationale required in the ROC, and year-over-year sample rotation remains a QA checkpoint in the QSA Program Guide v3.0.
Evidence covers the period, not the moment: Several requirements push beyond point-in-time collection. Initial evidence request letters now need to capture periodic review documentation across the full assessment period, including scope validation, TRA updates triggered by environmental changes, and ongoing change-detection monitoring under Req. 11.6.1.

The common thread: the engagement is built around a continuous evidence record, declared decisions, and finalized statuses. The work that used to happen in the report-writing phase now belongs in planning and fieldwork.

What the Customized Approach Means in Practice

The Customized Approach is where v4.0 engagements can diverge most sharply from prior versions. The client designs its own controls to meet a stated objective, and you build the testing procedures from scratch to validate them. That flexibility is the point, and it is also why these engagements run longer and lean more on senior judgment.

A few practical realities shape whether the Customized Approach is a fit:

It requires a full ROC: No SAQ variant covers it, and compensating controls don't apply within a Customized Approach implementation.
Planning collaboration is non-negotiable: Designing defensible testing depends on fully understanding the custom control, which typically means more time with the client before fieldwork starts.
Independence has to be documented: QSA employees conducting or assisting the assessment must be free of conflicts of interest. If the client needs your help designing or running the control, they likely are not the right candidate for this path.
The client has to sustain the control alone: Maintaining the custom control independently over time is part of the Customized Approach requirement, not a one-time hurdle at validation.

In practical terms, the Customized Approach fits clients with mature security programs and the in-house capacity to design, document, and sustain bespoke controls. For everyone else, the Defined Approach is the cleaner path.

Non-Compliance Risks Worth Communicating to Clients

PCI itself is enforced contractually by card brands and acquiring banks, not by a regulator. The PCI SSC doesn't fine anyone directly. Penalties flow through the merchant processing agreement: fees, monthly fines for non-compliance, higher transaction rates, and ultimately loss of the ability to process cards.

Public company clients face a second layer. The SEC's cybersecurity disclosure rules require material incident disclosure on Form 8-K within four business days of the company determining the incident is material. The clock runs from materiality determination, not from breach discovery, which matters when a client asks how much room they have to investigate before disclosing. The SEC's October 2024 charges against four companies for misleading cybersecurity disclosures show the agency does enforce these rules.

The v4.0 controls that raise the readiness bar most are also the ones aimed at the breach patterns still dominating payment data compromise: script integrity monitoring and expanded MFA. That connection is worth making in client conversations. Compliance under v4.0 isn't a once-a-year box to check; it's a set of controls embedded in daily operations.

How to Run a More Efficient PCI DSS v4.0 Engagement

Hours go up under v4.0 without deliberate engagement design. The largest efficiency gains tend to come from two areas:

Scoping and evidence standardization up front: Scope creep drives most PCI budget overruns, so settling network diagrams and data-flow boundaries before fieldwork is high-leverage. Standardized evidence requests let automated scan outputs do the work manual config reviews used to. For AWS-hosted CDEs, AWS Audit Manager generates assessor-ready output against a v4.0 framework.
Framework mapping and senior TRA review: For clients running PCI DSS alongside SOC 2 or ISO 27001, a Common Control Framework at engagement inception cuts duplicate walkthroughs, testing, and evidence pulls. The TRA artifact volume favors a standardized process and senior QSA judgment over spreadsheet tracking.

Both moves push work earlier, which is where v4.0 wants it anyway.

Run PCI DSS v4.0 Engagements with Fieldguide

PCI DSS v4.0 increases the coordination burden across scoping, evidence collection, testing, and reporting. Fieldguide brings that engagement lifecycle onto one platform, with structured workflows that fit how v4.0 assessments are now documented and reviewed. Field Agents extend the team: Request Agent reviews client evidence the moment it's submitted and flags gaps before testing starts, while Testing Agent executes control testing end-to-end. AI-assisted reporting pulls findings and evidence directly from the engagement file into the ROC, with practitioners reviewing every output and applying professional judgment. To see how this looks for PCI engagements, request a demo.