PCI DSS 4.0: What Changed and How to Prepare

From v3.2.1 to v4.0: what actually changed

PCI DSS v4.0 replaced v3.2.1, which retired on March 31, 2024. A limited revision, v4.0.1, followed and is now the active standard. The bigger deadline came a year later: dozens of requirements were "best practice" until March 31, 2025, and mandatory after it. If your last assessment leaned on that transition period, your next one will not.

The twelve core requirements and six goals survived intact, so this is not a rewrite. The changes concentrate in a few areas that materially affect how you scope, validate, and operate:

• A new customized approach that lets you meet a requirement's intent with controls of your own design.
• Targeted risk analyses that let you set the frequency of certain periodic activities instead of accepting a fixed cadence.
• Expanded authentication — multi-factor for all access into the cardholder data environment, plus longer passwords.
• Client-side controls aimed squarely at payment-page skimming.
• Tighter, more explicit scoping and segmentation documentation.

Treat 4.0 as a maturity step, not a checklist swap. The standard now expects you to justify decisions, not just tick boxes. For most organizations the groundwork overlaps heavily with a broader security and compliance program rather than a standalone PCI project.

Scope and segmentation: the cheapest way to cut your burden

Everything in PCI DSS starts with scope. Every system that stores, processes, or transmits account data — plus anything connected to or that could impact the security of those systems — is in the cardholder data environment (CDE) and subject to the full standard. The single most effective way to reduce cost and audit effort is to make the CDE smaller.

Figure: segmentation is not a PCI requirement, but it is the control that most directly shrinks what you have to assess.

Segmentation is not mandatory. It is, however, the lever that keeps a flat network from pulling every workstation and server into scope. Two things changed in how you handle it under 4.0:

• Scope must be documented and confirmed at least annually (service providers, at least every six months) and after any significant change. "Significant change" is now something you must define and act on, not hand-wave.
• If you rely on segmentation, you must prove it works. Penetration testing of segmentation controls is required at least annually for merchants and at least every six months for service providers, to confirm the isolation you claim actually holds.

A practical program here looks like a documented data flow, a network diagram that matches reality, firewall rules that enforce the boundary, and scheduled penetration testing against those boundaries. Disciplined network security and segmentation routinely cut the number of in-scope systems by more than half — which is the difference between a manageable assessment and an unmanageable one.

The customized approach and targeted risk analyses

The headline addition in 4.0 is the customized approach. Alongside the traditional "defined approach" — where you implement the control exactly as written — you can now satisfy the intent (the stated Customized Approach Objective) of a requirement using a control you design yourself.

This is powerful for mature organizations with controls that do not map neatly to the prescriptive text, but it is not a shortcut. For every customized control you must:

1. Document the control and how it meets the objective.
2. Perform and maintain a targeted risk analysis specific to that control.
3. Test it and provide evidence that it works as intended.
4. Have your assessor derive and run bespoke testing procedures against it.

The customized approach is validated through a Report on Compliance, not most self-assessment questionnaires, and it shifts effort onto both you and your assessor. Use it where you genuinely have a better control, not to dodge a requirement you would rather not implement.

Targeted risk analyses (TRAs) appear more broadly, too. Several requirements that used to specify a fixed frequency now let you set the cadence based on a documented risk analysis — for example, how often you review certain logs or perform a given check. Each TRA must identify the assets at risk, the threats, the likelihood and impact, and a justification for the frequency you chose, reviewed at least once a year. A defensible TRA is a risk-management exercise, not a compliance form, so it belongs with whoever owns your risk register — not with whoever fills in the questionnaire.

Stronger authentication: MFA everywhere and longer passwords

Authentication saw the most concrete tightening, and these requirements are now mandatory.

• MFA for all access into the CDE. Under 3.2.1, multi-factor was required for remote and administrative access. Under 4.0 it is required for all access into the cardholder data environment, including local and internal access by any user. This is often the single biggest engineering lift in a 4.0 program.
• MFA systems must be robust. They must resist replay, cannot be bypassed (even by administrators, absent a documented exception), and must use at least two distinct factor types.
• Longer passwords. Minimum length increased to at least 12 characters (7 was the old floor), with complexity, for systems that use passwords as an authentication factor.

Rolling MFA to every path into the CDE — service accounts and internal jump hosts included — is where projects stall. Plan it as an identity and access management workstream with phased enforcement and a real inventory of every account and access path, not a switch you flip the week before the assessment.

Client-side script and e-skimming controls

Two future-dated requirements, now in force, respond directly to Magecart-style attacks that inject skimming code into payment pages:

• Requirement 6.4.3 — manage payment-page scripts. You must inventory every script loaded and executed in the consumer's browser on a payment page, authorize each one, and assure its integrity. Third-party tag managers, analytics, and chat widgets all count.
• Requirement 11.6.1 — detect tampering. You must deploy a change- and tamper-detection mechanism that alerts on unauthorized modification to the HTTP headers and the content of payment pages, evaluated at least every seven days.

These controls exist because the merchant's own server logs never see a client-side skim — the malicious code runs in the shopper's browser and exfiltrates card data directly. Meeting them means a script inventory, integrity checks (such as subresource integrity or a content security policy), and monitoring that watches the rendered page, not just the origin server. It sits naturally within an application security program that already governs third-party code and browser-side risk.

SAQ versus ROC: which validation path applies

How you validate depends on how you accept payments and your transaction volume.

• A Self-Assessment Questionnaire (SAQ) is a self-attestation for eligible merchants. The type you use depends on your acceptance channel — for example, SAQ A for fully outsourced e-commerce, SAQ A-EP where your site can affect the payment page, SAQ B for standalone terminals, SAQ C for payment applications, and SAQ D as the comprehensive catch-all.
• A Report on Compliance (ROC) is a formal assessment performed with a Qualified Security Assessor. It is required for Level 1 merchants (broadly, more than six million transactions a year, or any merchant a card brand designates) and for anyone using the customized approach.

Two things to plan around under 4.0. First, the customized approach is only available through a ROC, so choosing it changes your validation path. Second, the SAQs were updated to reflect the new requirements, and eligibility conditions matter more than ever — an e-commerce merchant who assumed the shortest questionnaire should re-read the criteria, because the client-side requirements and self-assessment eligibility were both clarified in 4.0.1. Pick the right SAQ before you start, not after you have answered the wrong one.

Getting to 4.0 without the fire drill

The organizations that handle 4.0 well treat it as an operating posture rather than an annual scramble: scope confirmed on a schedule, segmentation tested, authentication enforced everywhere, TRAs kept current, and payment pages monitored continuously. The organizations that struggle discover the mandatory requirements the month before their assessment.

If you are not sure where your 4.0 gaps are, the fastest first step is a scoping and readiness assessment that turns the standard into a dated remediation plan. Talk to our security team and we will map your cardholder data flow, size the segmentation and authentication work, and get you validated on the right path — SAQ or ROC — without the last-minute fire drill.