PCI DSS Validation: Who Requires It, and What to Do First

Most PCI DSS programmes start by opening the standard at requirement 1 and working downwards. That is the most expensive possible order, and it answers a question nobody asked you.

Two things decide how a PCI DSS validation programme actually goes: who is requiring it of you, and what you tackle first. Neither is in requirement 1.

Who actually requires PCI DSS validation

The PCI Security Standards Council writes the standard. It does not make you comply with it.

The Council states this plainly: whether an entity is required to comply with, or validate compliance to, a PCI SSC standard is at the discretion of the organisations that manage compliance programmes — a payment brand, an acquirer, or another such entity.

That single fact resolves a surprising number of arguments:

• Your PCI DSS validation route is set by your acquirer or payment brand, not by the Council and not by your assessor. Whether you need a Report on Compliance or a Self-Assessment Questionnaire — and which SAQ — comes from them.
• “Is this mandatory?” is a question for your acquirer. The standard has no legal force of its own; the contract you signed does.
• Deadlines are programme deadlines. Payment brands run their own compliance programmes with their own timetables, which is why two organisations reading the same standard can face different dates.

Get that in writing before scoping anything. Programmes routinely over-build because nobody asked the acquirer what was actually required.

What PCI DSS validation covers: who is in scope

The audience is broader than “merchants who take card payments”. PCI DSS applies to entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) — or that could impact the security of the cardholder data environment.

That last clause is the one that expands scope. A system holding no card data at all is in scope if it could affect the security of the environment that does — your identity provider, your jump hosts, your monitoring platform, your network management. Organisations that scope only on data location consistently under-scope.

The standard covers everyone in the chain: merchants, processors, acquirers, issuers and service providers.

The document that should shape your plan

PCI DSS v4.0.1, published June 2024, is the current standard in the PCI SSC document library, and a separate Summary of Changes covers what moved from v4.0.

But the document most teams have never opened is the Prioritized Approach, updated for v4.0.1 in January 2025 — with an accompanying Prioritized Approach Tool as a spreadsheet.

It sequences the requirements into milestones ordered by risk reduction rather than by requirement number. The first milestone is the one that changes programmes: remove sensitive authentication data and limit cardholder data retention.

The logic is blunt and correct. Data you do not hold cannot be stolen, and every requirement that would have applied to it stops applying. Organisations that start here routinely shrink their environment — and their assessment — before implementing a single control.

Alongside it, the Quick Reference Guide v4.x (January 2025) is the document to hand to people who will never read the standard itself.

Who performs PCI DSS validation

The PCI DSS validation ecosystem is worth understanding before you engage anyone, because the roles are not interchangeable.

The ISA route is under-used. For an organisation assessed repeatedly, training internal assessors changes the economics and, more importantly, the quality of what a QSA is eventually handed.

How PCI DSS relates to what you may already hold

Where to start with PCI DSS validation

1. Ask your acquirer what is required — the PCI DSS validation route, SAQ type, and dates — and keep the answer in writing.
2. Scope on influence, not just storage. Anything that could impact the security of the environment is in.
3. Start with the Prioritized Approach, not requirement 1.
4. Delete what you do not need. Removing sensitive authentication data and cutting retention shrinks everything downstream.
5. Use the Tool spreadsheet to track milestone progress rather than building your own tracker.
6. Consider training an ISA if you will be assessed year after year.

This guide reflects the PCI SSC standards pages and document library at 15 August 2026, on which PCI DSS v4.0.1 is the current standard. PCI DSS validation requirements and dates come from your acquirer or payment brand — confirm them there. For the v4.0 changes specifically, see our PCI DSS v4.0 compliance guide.

The PCI-DSS Toolkit provides 180+ editable templates covering the scope and cardholder data environment definition, the requirement-by-requirement implementation records, the policies the standard mandates, and the evidence an assessor asks for.