PCI DSS v4.0.1 — Payment Card Data Security

The Payment Card Industry Data Security Standard governs how organisations that store, process or transmit cardholder data protect it. It is maintained by the PCI Security Standards Council and enforced through the payment brands and acquiring banks rather than by legislation.

Where the standard actually stands

Two dates get confused constantly, so both are worth stating plainly.

v4.0.1 is the only active version. It was published on 11 June 2024 as a limited revision — correcting errors and clarifying intent, adding no requirements and deleting none. v3.2.1 retired on 31 March 2024 and v4.0 retired on 31 December 2024.

The 51 future-dated requirements became mandatory on 31 March 2025. When v4.0 introduced 64 new or updated requirements, 13 applied immediately and 51 were designated future-dated — best practice only until that date. That window has closed. Every assessment now tests the full set with no exceptions and no remaining transition phase.

The deeper change in v4.x is philosophical: security as a continuous, business-as-usual practice rather than an annual compliance event. Assessors expect evidence the standard is lived in the operating rhythm of the business, not assembled the month before.

Validation is by Self-Assessment Questionnaire or a QSA-led Report on Compliance, depending on your merchant or service provider level.

Merchants accepting card payments

With obligations scaled by transaction volume, which determines the validation path.

Service providers in the payment chain

Payment gateways, processors, hosting providers and any organisation that could affect the security of a customer's cardholder data environment.

Software vendors handling card data

Where the platform stores, processes or transmits card data on behalf of merchants.

Organisations that validated before March 2025

A specific and exposed group. If your last assessment predates the deadline, or treated the future-dated controls as optional — as many quietly did — your next assessment tests them in full.

• It is contractually enforced. Obligations flow through acquiring bank and payment brand agreements, with financial consequences and, in serious cases, loss of the ability to process cards.
• Breach exposure is direct. Cardholder data compromise carries penalties, forensic investigation costs and remediation obligations that dwarf the cost of the programme.
• Scope reduction pays for itself. Segmentation, tokenisation and redirect can remove most systems from scope. This is the highest-leverage work in any PCI engagement.
• The controls are substantive. Payment page integrity, expanded MFA and authenticated scanning address live attack paths — script-based skimming on checkout pages is a real and current threat.
• It overlaps with other frameworks. Much of the control set maps onto ISO 27001, so an existing ISMS reduces the work materially.

1. Establish scope, then reduce it

Identify everything that stores, processes or transmits cardholder data, plus connected systems. Then work out what can be taken out of scope through segmentation, tokenisation or redirect. This is the single largest cost lever in any PCI programme, and it is worth doing properly before anything else.

2. Determine the validation path

Merchant or service provider level determines whether you validate by Self-Assessment Questionnaire or a QSA-led Report on Compliance, and which SAQ applies.

3. Gap assessment against the full v4.0.1 set

Including the once future-dated controls. Payment page and script integrity, expanded authentication, automated logging and monitoring, vulnerability management rigour, scope discipline and formalised risk analysis are where most of the remediation burden sits.

4. Remediate

Payment page integrity, web application firewalls, expanded MFA and authenticated scanning typically need the most lead time. Start there.

5. Build the year-round evidence habit

This is the philosophical shift in v4.x. Assessors expect evidence that the standard is lived in the operating rhythm of the business, not reconstructed before the assessment.

6. Validate

SAQ or QSA-led Report on Compliance, then repeat annually.

Soveriq starts with scope reduction, because nothing else moves the cost of a PCI programme as much. Segmentation, tokenisation and redirect decisions made properly at the start save more than any efficiency later in the engagement.

We then assess against the full v4.0.1 set including the once future-dated controls, build the remediation plan around the items with real lead time, and put in place the continuous evidence routines v4.x assumes.

Being direct about the boundary. Soveriq is not a Qualified Security Assessor. We prepare you for validation; the formal assessment is performed independently. That separation exists for a reason and we do not blur it.

On internal review. Where Soveriq has built your control set, we do not then assess it and present that as independent assurance. We provide readiness validation, labelled as such, with genuine independence supplied by someone independent of the build and disclosed in writing.

• Module 01 — Gap analysis against the full v4.0.1 requirement set, including the once future-dated controls, with scope and segmentation review.
• Module 02 — Build. Segmentation, control implementation and the continuous evidence routines the standard now assumes.
• Module 03 — Internal review ahead of validation, subject to the impartiality position above.
• Module 04 — Validation support, whether SAQ or QSA-led Report on Compliance.
• Module 05 — Continuous compliance across the year, which is what v4.x actually requires.

Engagements in this area are scoped and priced in writing after a scoping call, usually within one business day. QSA fees, where applicable, are separate.