PCI DSS v4.0.1: close gaps and maintain evidence
The transition deadlines have passed. The practical task now is to identify applicable PCI DSS v4.0.1 gaps, correct them and demonstrate that controls operate consistently. This guide retains its established URL but focuses on current implementation rather than an upcoming migration.
If you are new to PCI DSS, first read the scope and validation guide. Do not begin by copying a generic checklist into an assessment.
Reviewed: 26 October 2026.
The transition dates are historical
| Date | What changed | What it means now |
|---|---|---|
| 31 March 2024 | PCI DSS v3.2.1 retired. | Do not use an old v3.2.1 assessment as the current requirements baseline. |
| 31 December 2024 | PCI DSS v4.0 retired following publication of v4.0.1. | Use v4.0.1 and current supporting documents. |
| 31 March 2025 | The extended implementation date for future-dated v4.x requirements arrived. | Assess those requirements where applicable; they are no longer optional because of that date. |
PCI SSC’s v4.0.1 announcement confirms that the revision did not extend the March 2025 implementation date.
Build a gap register that leads to action
Confirm the payment environment, assessment route and scope before evaluating controls. An old assessment may omit a new checkout integration, cloud service, support account or script. A gap review should identify both missing controls and insufficient evidence of existing controls.
| Field | Example entry |
|---|---|
| Requirement and applicability | Record the exact requirement and why it applies to this system or process. |
| Current state | Describe the setting or practice observed, with dated evidence. |
| Gap and impact | Explain what is missing and how it affects the requirement or payment security. |
| Owner and action | Name the person accountable for a specific change, not just a department. |
| Dependencies and date | Record supplier work, maintenance windows and a realistic due date. |
| Acceptance evidence | Define the test or record that will demonstrate closure. |
| Review status | Open, implemented awaiting verification, verified or formally escalated. |
Defined, customised and compensating controls
The defined approach uses the specified requirements and testing procedures. It remains a valid route; organisations are not required to move to the customised approach.
The customised approach supports a different control design that meets an eligible requirement’s objective. It demands documented design, analysis, operating evidence and assessor-derived testing. Some requirements do not permit it. It is not a way to mark an unmet control as acceptable without equivalent assurance.
Compensating controls address legitimate documented constraints under the standard’s conditions. They are distinct from a deliberate customised design and from simply accepting business risk. Discuss the appropriate route with the assessor.
SAQs do not support documenting the customised approach. Organisations considering it need to confirm the ROC and assessor arrangements and acceptance conditions with their compliance-accepting entity. PCI SSC guidance on customised control responsibilities.
Prioritise implementation and operating evidence
| Review area | Useful question | Evidence to seek |
|---|---|---|
| Scope and suppliers | Have payment channels or shared responsibilities changed? | Current flows, service scope and responsibility agreements. |
| Access | Are required authentication and access restrictions effective across all applicable routes? | Configuration plus representative tests and access reviews. |
| E-commerce | Who can add or change payment-related scripts and pages? | Inventory, authorisation, integrity/change monitoring and integration-specific evidence. |
| Vulnerability management | Are scans, fixes and tests performed at the applicable intervals and after relevant changes? | Results, remediation and retests linked to assets. |
| Risk analyses | Where the standard requires targeted risk analysis, is it specific and maintained? | Approved reasoning, chosen frequencies where permitted and review records. |
| Operational controls | Do logs, alerts, reviews and response procedures work in practice? | Dated activity records and exercised decisions. |
This is a prioritisation aid, not an exhaustive requirements list. Check the current standard and SAQ/ROC instructions. The merchant’s SAQ A eligibility, script protections and scanning obligations depend on the actual payment integration; do not infer them from a provider’s compliance statement alone.
Work through implementation obstacles rather than relabelling documents
| Common obstacle | Practical response | How to demonstrate progress |
|---|---|---|
| Unknown ownership | Identify the payment business owner and the technical or supplier owner for each gap. Resolve shared responsibilities explicitly. | An accepted action with a named decision-maker and completion evidence. |
| Legacy service cannot support the intended control | Document the constraint, applicable requirement and options; involve the assessor and service owner before selecting an approach. | A justified remediation or permitted alternative with an implementation and verification plan. |
| Control exists but evidence is missing | Separate weak operation from weak record keeping. Observe the real process and create a sustainable evidence trail. | Dated records covering the relevant period; no invented retrospective evidence. |
| A new checkout or supplier changes scope | Revisit payment/data flows, eligibility and responsibility assignments before relying on the old assessment. | Updated scope decisions and service-specific supporting documents. |
| Too many unconnected findings | Group dependent work, such as inventory before patch coverage and identity ownership before access reviews. | A realistic sequence that addresses urgent exposure and tracks unresolved dependencies. |
Train the people who will operate changed controls, including finance, support and procurement where relevant. Confirm the effect on customer journeys and operational support before deployment. Ask for a walkthrough: can the control owner explain the requirement, show the actual state and demonstrate how failures are handled?
Use the register as a living management tool. Record the last verification date, the next recurring activity and the trigger for reassessment. A new document title or policy approval alone does not demonstrate that a changed requirement is operating. Keep the historical transition dates visible, but plan against today’s applicable requirements.
A workable remediation sequence
- Address immediate exposure and critical control failures with the relevant operational owners.
- Group related changes so that identity, deployment, supplier and application work is coordinated.
- Define acceptance tests before implementation; a screenshot of a policy is not proof of operation.
- Verify fixes and keep evidence of the period or activity being assessed.
- Escalate unresolved gaps to accountable management and the assessor; do not misstate the compliance position.
For example, if only some administrative paths enforce MFA, list every route, agree changes with each owner and test representative access after deployment. Close the item only when the applicable coverage and evidence are complete.
Common questions
Can we still describe the March 2025 requirements as future-dated?
Only when explaining the historical transition. For a current assessment, evaluate them as effective requirements wherever applicable.
Must every organisation use the customised approach?
No. The defined approach remains available. Choose a customised design only where supported and justified, with the necessary evidence and assessment arrangements.
Will a gap assessment itself make us compliant?
No. It identifies work. Implementation, operating evidence, verification and the correct validation process are still required.
See how scope work informs an engagement
The PCI DSS QSA consultancy case study provides a specific example to discuss alongside this guide. Use it to frame questions about payment flows, assessment scope and the evidence needed for your own environment; do not treat another organisation’s engagement as assurance of your compliance.
Prepare for a review
Bring the previous assessment, current architecture and payment flows, supplier assurance documents, open findings and relevant change records. Use the current PCI SSC documents and confirm reporting requirements with the organisation accepting your validation.
Need Help?
If you have any questions about cyber security or would like a free consultation, don't hesitate to give us a call!
For More Information Please Contact Us
ACCREDITATIONS
