PCI DSS 4.0.1: A Practical Compliance Guide for 2026

If your organisation stores, processes or transmits payment card data, PCI DSS 4.0.1 is now the only version of the standard you can assess against. The transition period is over, the future-dated requirements are mandatory, and assessors expect to see mature, documented controls rather than plans.

This guide explains what changed from earlier versions, how the 12 requirements are organised, the difference between the defined and customised approaches, how targeted risk analyses work, and how to choose between a Self-Assessment Questionnaire (SAQ) and a Report on Compliance (ROC). It finishes with a practical checklist you can use to plan your next assessment.

What PCI DSS is and who it applies to

The Payment Card Industry Data Security Standard (PCI DSS) is maintained by the PCI Security Standards Council. It sets technical and operational requirements to protect account data, which includes cardholder data and sensitive authentication data.

It applies to any entity that stores, processes or transmits account data, or that could affect the security of the cardholder data environment (CDE). That includes:

• Merchants of every size, from online shops to large retailers.
• Service providers such as payment gateways, hosting companies and managed security providers whose services touch the CDE.
• Issuers and acquirers that handle card data as part of their business.

PCI DSS is not a law. It is enforced contractually through the payment brands and acquiring banks, which also decide which validation method each entity must use.

What changed in PCI DSS 4.0.1

Version timeline

PCI DSS v4.0 was published in March 2022. Version 3.2.1 was retired on 31 March 2024, and v4.0.1 was published in June 2024 as a limited revision. Version 4.0 itself was retired on 31 December 2024, which leaves v4.0.1 as the active version.

What v4.0 introduced

The move from 3.2.1 to 4.0 was a major rewrite. It added 64 new requirements, of which 51 were future-dated to give organisations time to prepare. It also introduced the customised approach, targeted risk analyses and a stronger emphasis on security as a continuous process, with documented roles and responsibilities for each requirement.

What v4.0.1 clarified

Version 4.0.1 added and removed no requirements. It corrected formatting and typographical errors and clarified intent. Notable points include:

• Requirement 6.3.3 was returned to applying the 30-day patching window to critical vulnerabilities only.
• A note was added to the multi-factor authentication requirements for certain accounts that use phishing-resistant authentication.
• Applicability for issuers and for keyed cryptographic hashes in Requirement 3 was clarified.
• Requirement 12 guidance on customer and third-party service provider relationships was clarified.
• New glossary definitions were added, including “phishing-resistant authentication” and “legal exception”.

Future-dated requirements are now mandatory

The 51 future-dated requirements became effective on 31 March 2025 and were not changed by v4.0.1. They are now assessed like any other requirement. Key examples include:

• 8.4.2: multi-factor authentication for all access into the CDE, not only remote or administrative access.
• 8.3.6: passwords of at least 12 characters where passwords are used.
• 6.4.3 and 11.6.1: management of scripts on payment pages and detection of unauthorised changes to payment pages.
• 5.4.1: automated mechanisms to protect personnel against phishing attacks.
• 10.4.1.1: automated mechanisms for audit log reviews.
• 11.3.1.2: authenticated internal vulnerability scanning.
• 12.3.1: targeted risk analyses for requirements that allow a flexible frequency.
• 12.5.2.1: service providers must confirm their PCI DSS scope at least every six months and after significant change.

In January 2025 the Council also revised SAQ A, removing 6.4.3 and 11.6.1 for eligible merchants and adding an eligibility criterion that the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

The 12 PCI DSS requirements

The requirements are grouped under six goals. Each has detailed sub-requirements and testing procedures.

Defined approach vs customised approach

PCI DSS v4.x offers two ways to meet a requirement.

Defined approach

This is the traditional method. You implement the requirement as written and the assessor follows the defined testing procedures. If a legitimate technical or business constraint prevents you from meeting a requirement, compensating controls remain available within the defined approach.

Customised approach

The customised approach lets you design your own control to meet the stated customised approach objective of a requirement. It is intended for risk-mature organisations with strong governance, monitoring and documentation. For each customised control you must prepare a controls matrix and a targeted risk analysis under Requirement 12.3.2, and the assessor derives testing procedures from your documentation.

Two practical points matter:

• The customised approach is not supported in SAQs, so it applies to entities validating through a ROC.
• It is a choice to do things differently, not a way to excuse a gap. Compensating controls address constraints; the customised approach addresses alternative implementations.

Most organisations use the defined approach for nearly everything and reserve the customised approach for a small number of controls where they have a genuinely better solution.

Targeted risk analyses

Targeted risk analyses (TRAs) are one of the biggest practical changes in version 4.x. There are two types:

• 12.3.1: for requirements that let you set the frequency of an activity, such as how often certain reviews or scans take place. You document the assets, threats, likelihood and resulting frequency, and review each analysis at least every 12 months.
• 12.3.2: for each requirement met using the customised approach.

A TRA should be short, specific and evidence-based. Assessors look for a clear link between the risk identified and the frequency or control you chose, plus proof that the analysis is reviewed and approved.

SAQ vs ROC: choosing the right validation

How you validate compliance depends on your merchant or service provider level, which is set by the payment brands and your acquirer. Always confirm your obligations with them.

• Self-Assessment Questionnaire (SAQ): completed by the entity itself. There are several types, such as SAQ A, A-EP, B, B-IP, C, C-VT, P2PE and D, each matched to a specific payment channel and eligibility criteria. Choosing the wrong SAQ is a common and costly error.
• Report on Compliance (ROC): a detailed assessment performed by a Qualified Security Assessor (QSA), or an Internal Security Assessor where permitted. Larger merchants and service providers usually need one.

Both routes produce an Attestation of Compliance (AOC). Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) are also required where applicable.

Scoping: get it right first

Scope determines the cost and effort of everything else. In-scope components include systems that store, process or transmit account data, and systems that are connected to or could affect the security of the CDE.

• Map every payment channel and data flow, including call centres, mobile apps and third-party integrations.
• Use network segmentation to reduce scope, and test that it works.
• Consider tokenisation, point-to-point encryption or outsourced payment pages to keep account data out of your environment.
• Document and confirm scope at least every 12 months under Requirement 12.5.2, and every six months if you are a service provider.

PCI DSS 4.0.1 compliance checklist

1. Confirm your validation route. Check your level and the SAQ type or ROC requirement with your acquirer or payment brands.
2. Define and document scope. Produce up-to-date data flow and network diagrams and an inventory of in-scope system components.
3. Run a gap assessment against v4.0.1. Pay special attention to the requirements that became mandatory on 31 March 2025.
4. Assign roles and responsibilities. Each requirement now expects documented, assigned and understood roles.
5. Complete your targeted risk analyses. Cover every flexible-frequency requirement and any customised control.
6. Review third-party service providers. Maintain a list, written agreements, a responsibility matrix and evidence of their compliance status.
7. Update policies and procedures. Align them with v4.0.1 wording and review them at least annually.
8. Collect evidence continuously. Store scan reports, log reviews, training records and change approvals as you go, not the week before the assessment.
9. Remediate and retest. Track findings to closure and keep proof of the fix.

Common mistakes to avoid

• Treating scope as fixed and forgetting new payment channels or cloud services.
• Assuming an outsourced payment page removes all obligations. Some requirements still apply to your website.
• Writing generic targeted risk analyses that do not justify the frequency chosen.
• Relying on a service provider’s AOC without checking which requirements it actually covers.
• Viewing compliance as an annual project rather than an ongoing programme.

How Enactia helps

Enactia is a governance, risk and compliance (GRC) platform, not a QSA. It helps you organise and evidence your PCI DSS programme so that assessments run more smoothly.

• Structured assessments. Compliance Assessments let you run gap assessments against PCI DSS, assign owners and track remediation tasks.
• Cross-mapped controls. Compliance Universe uses AI to map controls across more than 50 frameworks and laws, so work done for ISO 27001, SOC 2 or NIST CSF can support PCI DSS requirements.
• Third-party oversight. Vendor and Third Party Management helps you assess service providers and keep their status and responsibilities on record.
• Evidence in one place. The document repository and evidence management module keeps policies, TRAs and test results ready for your assessor.

Frequently asked questions

Is PCI DSS 4.0.1 mandatory?
Yes, for entities that must comply with PCI DSS. Version 4.0 was retired on 31 December 2024, so assessments are now performed against v4.0.1.

Did version 4.0.1 add new requirements?
No. It was a limited revision that clarified wording and intent and corrected errors. The new requirements came with v4.0.

When did the future-dated requirements become mandatory?
On 31 March 2025. Before then they were best practice; they are now assessed in full.

Can I use the customised approach with an SAQ?
No. The customised approach is not supported in SAQs. Entities using it validate through a ROC and must complete a targeted risk analysis for each customised control.

How often do I need to confirm my PCI DSS scope?
At least every 12 months and after significant changes. Service providers must also do so at least every six months.

Conclusion: make PCI DSS a continuous programme

PCI DSS 4.0.1 rewards organisations that treat security as an everyday discipline. Get scope right, document roles, justify your frequencies with targeted risk analyses and collect evidence throughout the year. That makes each assessment a confirmation of work already done.

Want to see how Enactia can help you organise your PCI DSS programme alongside your other frameworks? Contact us or book a demo with our team.