Fast facts
PCI DSS applies to any entity that stores, processes or transmits cardholder data, or that could affect the security of the cardholder data environment. It is enforced contractually through acquirers and payment brands rather than by statute, but the commercial consequences of non-compliance — fines, increased transaction costs, or loss of card acceptance — are direct.
Version 4.0 was a substantial revision, and 4.0.1 clarified it. The most consequential changes are the introduction of the customised approach, which allows an entity to meet a requirement's objective through alternative controls supported by a targeted risk analysis, and significantly strengthened authentication requirements including MFA for all access into the cardholder data environment.
Scope management remains the single largest lever on cost. Reducing the cardholder data environment through tokenisation, hosted payment pages and network segmentation typically reduces assessment effort far more than any efficiency in the assessment itself.
Who it applies to
The commercial and regulatory argument, rather than a restatement of the text. If none of these apply to you, the honest answer is that this framework is not your priority.
Obligations flow through acquirer contracts rather than statute, which means consequences — fines, increased transaction costs, or withdrawal of card acceptance — arrive faster than any regulator would move.
Reducing the cardholder data environment through tokenisation, hosted payment pages and segmentation cuts assessment effort far more than any efficiency within the assessment itself.
MFA is now required for all access into the cardholder data environment, and the future-dated requirements became mandatory from March 2025. Organisations assessing against their last passed version are assessing against the wrong standard.
Scope is the decision that sets the cost, and it is usually made in week one when the team knows least. Both columns matter equally.
In scope
Out of scope
How the boundary is decided: Scope disputes almost always trace to inaccurate cardholder data flow diagrams. Produce accurate ones first — segmentation cannot be validated against a diagram that does not match reality, and assessors test the diagram before the controls.
Stated as the duty rather than the clause number, because clause numbers do not tell an engineering team what to build.
Network security controls and secure configurations applied to all system components, replacing the older firewall-centric language.
Storage minimisation, strong cryptography for stored account data, and protection of cardholder data in transit over open networks.
Protection against malicious software, and development and maintenance of secure systems and software including a software inventory and bill of materials.
Access restricted by business need to know, strong authentication with MFA for all CDE access, and physical access restriction.
Logging and monitoring of all access to system components and cardholder data, plus regular testing of security systems and networks.
An information security policy and programme supported by targeted risk analyses documenting the frequency of periodic activities.
The areas your teams will actually be building in, with control counts where the framework defines them.
Annual scope validation, data flow diagrams and segmentation testing to keep the CDE as small as defensible.
Strong cryptography for storage and transmission, with documented key lifecycle management.
MFA into and within the CDE, unique IDs, password standards and privileged access restriction.
Secure development practices, change control, payment page script integrity and software inventory.
Audit log content, protection, review — including automated review — and time synchronisation.
Vulnerability scanning by an ASV, internal and external penetration testing, and segmentation validation.
Phases overlap deliberately. Design begins before assessment closes, so the programme does not stall waiting for a document to be signed off.
Weeks 1–6
Attack the cardholder data environment first through tokenisation, hosted payment pages and segmentation. This determines the cost of everything that follows.
Weeks 4–8
Produce accurate cardholder data flow diagrams and validate segmentation by testing rather than by assertion.
Weeks 6–10
Gap assessment against the current version including the future-dated requirements, not the version last passed.
Weeks 8–20
Close gaps across network security, cryptography, authentication, secure software, logging and testing, using the customised approach only where it genuinely fits.
Weeks 20–24
QSA engagement and fieldwork, or SAQ completion, with evidence organised requirement by requirement.
Named artefacts, listed in the statement of work. If something is not on this list, we will tell you before you sign rather than after.
Version 4.0 fully superseded 3.2.1 in March 2024, with the future-dated 4.0 requirements becoming mandatory from 31 March 2025. Assessment cycles are annual, with quarterly ASV scanning.
Scope reduction
Weeks 1–8
The phase with the highest return. Every system removed here is removed from every future assessment.
Assessment
Weeks 6–10
Gap analysis against the current version, with flow diagrams validated first.
Remediation
Weeks 8–20
Control implementation across the twelve requirements.
Validation
Weeks 20–24
QSA fieldwork or SAQ completion, then the annual cycle with quarterly ASV scanning.
The sequence we follow, and the parts where first-time implementations most often lose time.
Attack scope first — tokenisation and hosted pages usually save more than any other single intervention.
Produce accurate cardholder data flow diagrams; most scope disputes trace back to inaccurate ones.
Assess against 4.0.1 including the future-dated requirements rather than the version you last passed.
Use the customised approach only where it genuinely fits, with a defensible targeted risk analysis.
Prepare for the QSA with evidence organised requirement by requirement.
Establish the quarterly and annual assurance calendar so compliance is maintained, not re-achieved.
Certification without the eighteen-month scramble.
Readiness, implementation and audit support for ISO 27001, ISO 27701, ISO 42001, SOC 2 and PCI DSS — run as a project with dates, owners and a definition of done.
Explore capabilityDefensible security, built around how your business actually loses money.
Threat-led security strategy, architecture and control design that prioritises the handful of scenarios that would genuinely hurt you — not a generic checklist of 300 controls.
Explore capabilitySecure the control plane, not just the workloads.
Landing-zone design, identity hardening, posture management and Kubernetes security across AWS, Azure and Google Cloud — with guardrails engineers do not route around.
Explore capabilitySequencing matters. Running these together off one control library costs meaningfully less than running them apart.
Including the questions where the honest answer is less convenient than the marketing one.
Ask a practitioner directly. First responses come from the person who would run your engagement, within one business day.
Ask a question
