PCI DSS v4.x requirements that applied to your environment became assessment requirements on 31 March 2025. To prepare now, confirm your scope and validation route, map payment data and providers, maintain a requirement-by-requirement evidence register, address e-commerce controls where relevant, and use the current PCI SSC reporting documents. PCI DSS v4.0.1 did not postpone that deadline.
What changed in PCI DSS 4.0, and are the requirements mandatory now?
PCI DSS v4.0.1 was a limited revision. It did not add or remove requirements and did not change the 31 March 2025 effective date for requirements that had been deferred. PCI SSC explains the revision here: PCI DSS v4.0.1.
Before 31 March 2025, an assessment completed before the effective date could mark an unimplemented future-dated requirement Not Applicable. From that date onward, every requirement applicable to the entity’s assessment, including those newly effective requirements, must be fully considered. See PCI SSC FAQ 1585.
PCI SSC’s March 2025 e-commerce guidance describes 64 new requirements in the v4.x transition, 51 of which were future-dated. Those are historical transition counts for v4.x, not changes introduced by v4.0.1. The Council’s summary of changes is useful for triage, but it is not a substitute for the current standard or your applicable validation document.
Recommended Free Tools
#1 Best Overall
How should you prepare for PCI DSS 4.0?
1. Confirm your scope and validation route
Start with facts about your organization, not a generic checklist. Document whether you are a merchant or service provider, every system and process that stores, processes or transmits payment-card data, connected security systems, payment-page components, and the providers that support them.
Then confirm which validation route your compliance-accepting organization requires. Eligibility for a Self-Assessment Questionnaire (SAQ), a Report on Compliance (ROC), or another reporting package depends on your entity and the instructions of your acquirer, payment brand or other accepting organization.
| Route | Preparation focus | Who confirms it |
|---|---|---|
| SAQ | Use the SAQ that matches your payment flows and eligibility, and retain evidence for every applicable answer. | Your acquirer, payment brand or other compliance-accepting organization |
| ROC | Prepare the current ROC documentation and assessor evidence for the full applicable scope. | Your assessor and the compliance-accepting organization |
Using a payment processor or other service provider can reduce the systems you operate, but it does not automatically remove your own assessment responsibilities. Record each provider dependency and obtain the provider’s current responsibility and compliance information.
2. Build a requirement-by-requirement gap register
Use the current PCI DSS v4.x text together with the exact SAQ or ROC materials that apply to you. For each requirement, record:
- the requirement and any applicable sub-requirements;
- the control owner and affected system;
- your current implementation status;
- the policy, configuration, log, review record or test that proves operation;
- the remediation task, accountable person and target date; and
- the assessor question or reporting treatment you expect.
Do not leave future-dated items in a deferred-work column. If they apply, they belong in the active assessment and remediation plan.
3. Map payment data flows and service-provider dependencies
Trace a transaction from the customer-facing payment page or terminal through gateways, processors, databases, support tools, backups and administrative access. Mark where cardholder data enters, leaves or could be exposed, and identify which party controls each component.
This map establishes the boundary for testing and prevents a hosted page, script, API or support connection from being overlooked. Recheck the map whenever a payment method, vendor, integration or checkout design changes.
4. Collect operating evidence, not just policies
Assessors need to see that controls work during the assessment period. Organize evidence by requirement, such as:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- approved policies and procedures;
- system and cloud configurations;
- access reviews and change records;
- vulnerability, malware, penetration or security-test results where applicable;
- training, incident and service-provider records; and
- dated management reviews showing that recurring controls were performed.
Keep the evidence tied to the in-scope asset, responsible owner and testing period. A policy with no operating record is not a complete demonstration of control operation.
What should e-commerce teams do about requirements 6.4.3 and 11.6.1?
PCI SSC identifies requirements 6.4.3 and 11.6.1 among the future-dated e-commerce requirements that became effective on 31 March 2025. Review your payment-page architecture, including scripts, third-party content, change control and monitoring, against the current requirements and the Council’s guidance for e-commerce requirements effective after 31 March 2025.
Assign ownership for every script and page component, document why each component is present, and retain the monitoring or review records required by your applicable validation document. The exact implementation depends on whether the page is hosted by you, a provider or a mixture of both; do not assume that outsourcing the checkout settles applicability.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Should you use the defined approach or a customized approach?
PCI DSS v4.x provides both a defined approach and a customized approach. Compare them before designing controls, and involve your assessor early if you are considering customization.
| Consideration | Defined approach | Customized approach |
|---|---|---|
| Control design | Implement the requirement as written and follow its stated testing expectations. | Use an alternative control design only where the current standard permits it, with documented rationale and evidence that the security objective is met. |
| Evidence planning | Map evidence directly to the requirement and its testing procedures. | Document the design, risk analysis, testing method and results in addition to ordinary operating evidence. |
| Practical fit | Usually simpler when your environment aligns with the standard’s prescribed controls. | May fit unusual architectures, but normally requires more design documentation and assessor discussion. |
PCI SSC published guidance on compensating controls and the customized approach on 10 June 2026. Use it with the current standard and your assessor; a customized or compensating control is not an informal exception.
How should superseded requirements appear in the assessment?
After 31 March 2025, requirements that were superseded in the transition should be reported as Not Applicable in the ROC or SAQ, according to PCI SSC FAQ 1593. The FAQ discusses requirements 6.4.1 and 6.4.2 as examples. Follow the current template and your assessor’s instructions rather than carrying obsolete items forward as active controls.
What documents and deadlines should you verify?
Use the current PCI DSS version, the applicable SAQ or ROC, and any instructions issued by the organization that accepts your compliance result. Confirm submission dates, attestation requirements, quarterly or annual evidence expectations and any payment-brand or acquirer-specific forms directly with that organization.
PCI SSC’s implementation timeline can help organize transition work, but its historical milestones do not override the current effective status. The applicable requirements must be assessed now, even if an older project plan treated them as future work.
Quick Recap
What are the most common preparation mistakes?
- Assuming v4.0.1 created a new grace period after 31 March 2025.
- Selecting an SAQ without confirming eligibility with the compliance-accepting organization.
- Leaving payment-page scripts, APIs, cloud services or support paths outside the scope map.
- Relying on a provider’s compliance statement without documenting your own responsibilities.
- Listing a policy as evidence when no dated operating record exists.
- Using the change summary instead of reading the applicable current requirement and validation document.
- Marking a superseded requirement as active instead of following the current ROC or SAQ reporting treatment.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
