PCI DSS v4.0: What Changed and How to Scope Your Cardholder Data Environment

PCI DSS v4.0 is now the only active version of the standard, and the future-dated requirements that became mandatory after March 31, 2025 changed the work, not just the paperwork. The standard moved from point-in-time validation toward continuous security, expanded authentication, and tighter controls for service providers and payment pages. This guide explains what changed, walks the twelve core requirements, and shows how to scope and shrink your cardholder data environment so the assessment stays manageable.

If your organization stores, processes, or transmits payment card data, the Payment Card Industry Data Security Standard governs how you protect it. Z Cyber operates as a cybersecurity operating partner for financial institutions, fintechs, merchants, and service providers. We run the PCI program on our AI-native GRC platform, Glance, mapping each requirement to evidence, owners, and recurring tasks so compliance is a continuous state rather than an annual scramble. This guide is the practitioner's view of v4.0 and the scoping decisions that determine how much of your environment falls under assessment.

What PCI DSS v4.0 actually changed

The PCI Security Standards Council released v4.0 in March 2022. Version 3.2.1 was formally retired, and v4.0 became the only active version of the standard after March 31, 2024. A second set of requirements, labeled "future-dated," became mandatory after March 31, 2025. If you assessed against the transitional rules in 2024, those future-dated controls are no longer optional.

The headline shifts are structural, not cosmetic. The standard now offers two paths to meeting most requirements, places far more weight on continuous security than on a single annual snapshot, and tightens the screws on authentication, service-provider obligations, and the scripts that run on payment pages.

Theme	PCI DSS v3.2.1	PCI DSS v4.0
Approach to controls	Single defined approach: meet each requirement exactly as written.	Defined approach plus a new customized approach that lets mature teams meet the control objective with their own design, backed by a targeted risk analysis.
Validation cadence	Largely point-in-time, assessed annually.	Emphasis on continuous security, with controls designed to operate and be evidenced as business-as-usual throughout the year.
Authentication	MFA required for administrative and remote access into the CDE.	MFA expanded under Requirement 8 to cover all access into the cardholder data environment, with stronger guidance on authentication strength.
Risk analysis	General annual risk assessment.	Targeted risk analyses tied to specific requirements that allow flexibility on frequency, documenting why a chosen cadence is sufficient.
Service providers	Provider-specific requirements present but narrower.	Expanded provider obligations, including clearer responsibility documentation shared with customers.
E-commerce scripts	No dedicated payment-page script controls.	New requirements such as 6.4.3 and 11.6.1 to manage and monitor scripts on payment pages, countering digital skimming.

The customized approach is the change most teams misread. It is not a shortcut. It lets an organization with a strong security program meet the objective of a requirement through controls of its own design, but it demands a documented targeted risk analysis and is assessed against that objective. For most merchants, the defined approach remains simpler. The customized approach earns its keep only where a mature control already exists and the prescriptive text does not fit the architecture.

The twelve requirements, grouped into six goals

PCI DSS is built on twelve core requirements organized under six security goals. The numbering is stable across versions, so the structure below is the map you will use to plan evidence and assign owners.

Goal	Requirement
Build and maintain a secure network	1. Install and maintain network security controls.
	2. Apply secure configurations to all system components.
Protect account data	3. Protect stored account data.
	4. Protect cardholder data with strong cryptography during transmission over open, public networks.
Maintain a vulnerability management program	5. Protect all systems and networks from malicious software.
	6. Develop and maintain secure systems and software.
Implement strong access control measures	7. Restrict access to system components and cardholder data by business need to know.
	8. Identify users and authenticate access to system components.
	9. Restrict physical access to cardholder data.
Regularly monitor and test networks	10. Log and monitor all access to system components and cardholder data.
	11. Test security of systems and networks regularly.
Maintain an information security policy	12. Support information security with organizational policies and programs.

Three requirements absorb most of the new v4.0 work. Requirement 8 carries the MFA expansion. Requirement 6 carries the payment-page script management control (6.4.3). Requirement 11 carries the corresponding script-monitoring control (11.6.1) that alerts on unauthorized changes to payment pages. Together, 6.4.3 and 11.6.1 are the standard's direct answer to web-skimming attacks that inject malicious JavaScript into checkout flows.

Scope first: defining the cardholder data environment

Scope is the single most consequential decision in a PCI program. The cardholder data environment, or CDE, is the people, processes, and technology that store, process, or transmit cardholder data, together with any system component connected to or that could affect the security of that environment. Get the boundary wrong and you either under-protect data, which fails the assessment, or over-scope and pay to secure systems that never touch a card number.

The connected-systems clause is where most teams stumble. A jump host that administers CDE servers, a directory service that authenticates CDE users, a logging server that receives CDE events, all of these can pull adjacent systems into scope even when no card data lives on them. Mapping data flows end to end, from capture through processing to storage and transmission, is the prerequisite for any credible scope statement.

Reducing scope: segmentation, tokenization, and validated providers

Once the boundary is mapped, the goal is to shrink it. A smaller CDE means fewer systems to harden, fewer controls to evidence, and a cheaper, faster assessment. Three techniques do most of the work.

Network segmentation. Segmentation isolates the CDE from the rest of the corporate network using firewalls, access controls, and network design so that out-of-scope systems cannot reach in-scope ones. Segmentation is not mandatory, but without it the entire flat network can fall into scope. When you rely on segmentation to reduce scope, you must validate that it works, and v4.0 expects that validation to be tested on a defined cadence.

Tokenization. Replacing the primary account number with a non-sensitive token means downstream systems handle the token rather than the live card number. Systems that only ever see tokens, and have no ability to retrieve the underlying account data, can be removed from scope. Tokenization is one of the most effective ways to pull order management, analytics, and support tooling out of the CDE.

Outsourcing to validated providers. Pushing card capture and storage to a PCI-validated service provider, for example a hosted payment page or an external gateway, transfers much of the control burden to that provider. You remain responsible for the parts you still touch and for documenting the split of responsibilities, but you shrink your own footprint substantially. This is why so many fintechs and merchants route card data through a validated processor and never let a raw account number land in their own systems.

For financial institutions weighing these trade-offs alongside other obligations, our financial services security practice sequences PCI scoping with adjacent regimes so the controls are built once and evidenced across frameworks rather than duplicated. Card-data scoping rarely lives in isolation. The same access, logging, and vendor controls feed obligations such as the NYDFS Part 500 cybersecurity regulation and the GLBA Safeguards Rule.

Validation: ROC, SAQ, and your level

How you prove compliance depends on whether you are a merchant or a service provider and on your transaction volume. The card brands define merchant and service-provider levels by annual volume, and your level dictates the validation method.

Larger merchants and service providers validate through a Report on Compliance, or ROC, performed by a Qualified Security Assessor (QSA). The ROC is a full, evidence-backed assessment of every applicable requirement. Smaller merchants typically validate through a Self-Assessment Questionnaire, or SAQ, which comes in several variants matched to how the merchant handles card data, such as fully outsourced e-commerce versus on-site card-present processing. Choosing the correct SAQ type is itself a scoping exercise, because the wrong questionnaire either asks for controls you do not need or skips ones you do.

Across both paths, the through-line of v4.0 is the same: controls must be demonstrably operating all year, not assembled the week before the assessor arrives. That is precisely the operating problem Glance is built to solve, by holding each requirement, its owner, its evidence, and its recurring cadence in one place and surfacing drift before it becomes a finding.

How Z Cyber runs PCI DSS v4.0 as a program

PCI DSS is not a document you produce once. It is a program you operate. As your operating partner, Z Cyber maps your card-data flows, defines and reduces the CDE, assigns every requirement an owner inside your organization, and runs the continuous evidence collection that v4.0 now expects. We coordinate with your QSA for the ROC or guide the correct SAQ, and we keep the controls live between assessments so the next cycle starts from a maintained baseline rather than a cold start. The result is a card-data program that holds up under assessment because it is genuinely running, not staged.

For neighboring assurance work that shares evidence with your PCI program, see our SOC 2 compliance guide. To learn how Glance turns these requirements into a living, evidenced program, explore the platform or talk to an advisor. The full standard and supporting documents are published by the PCI Security Standards Council.