PCI Compliance 101: What PCI DSS v4.0.1 Is and How You Meet It

PCI DSS is the security standard every business that takes payment cards has to meet. This article covers what it is, who it applies to, what it covers, how a business shows it complies, and what the current version, v4.0.1, changed. Each section links the page on this site that goes further.

What PCI DSS is

The Payment Card Industry Data Security Standard is a set of technical and operational requirements for protecting payment account data. It is maintained by the PCI Security Standards Council, which the payment brands founded. The Council writes the standard; it does not enforce it. The payment brands and the acquiring banks do that, through their own compliance programmes and their contracts with merchants. PCI DSS is not a law, which is why the consequences of ignoring it come from those contracts rather than from a regulator.

The standard has twelve requirements grouped under six goals, from network security controls (Requirement 1) to organisational policy (Requirement 12). The PCI DSS v4.0.1 overview lists all twelve and links each one's controls.

Who it applies to

Any entity that stores, processes or transmits account data, and any entity that could affect its security. That includes merchants of every size and every service provider that handles card data for others: processors, gateways, hosting and cloud providers, and companies that support payment systems. Outsourcing payment to a third party does not take a merchant out of PCI DSS; it changes which requirements the merchant still has to meet.

What is in scope

Scope is the set of systems, people and processes PCI DSS applies to. It is the cardholder data environment (CDE), meaning everything that stores, processes or transmits the data plus anything with unrestricted connectivity to it, and everything that could affect the security of that data, such as authentication, logging and remote access servers. The entity has to confirm its scope at least once every 12 months under 12.5.2. Network segmentation is the usual way to keep that scope small.

Which data may be stored

Account data has two parts, and the standard's Table 3 treats them differently:

Data	May it be stored?	Must stored data be unreadable?
Primary account number (PAN)	Yes, kept to a minimum	Yes, under 3.5
Cardholder name, expiration date, service code	Yes, kept to a minimum	No
Full track data, card verification code, PIN and PIN block	Not after authorisation	Before authorisation, with strong cryptography

The first two rows are cardholder data; the last is sensitive authentication data, which 3.3.1 says must not be kept once authorisation completes, even if encrypted. Issuers and companies supporting issuing services are the only exception, under their own conditions. Storing CVV covers the rule most merchants trip over.

How compliance is validated

There are two routes, and the payment brands and your acquirer decide which one you take:

• a Report on Compliance by a Qualified Security Assessor, for the largest merchants and service providers and anyone an acquirer or brand requires it of;
• a Self-Assessment Questionnaire for everyone eligible to self-assess.

Both end with an Attestation of Compliance. The brands group merchants into levels by transaction volume to decide this, and the thresholds are theirs, so your acquirer is the place to confirm your level. Do you need a PCI DSS audit? goes through it.

If you can self-assess, the questionnaire depends on how you take payments. The SAQ Instructions and Guidelines (v4.0.1 r1) describe them as follows:

SAQ	Who it is for, in short
A	Card-not-present merchants that completely outsource all account data functions to validated third parties
A-EP	E-commerce merchants whose website does not receive card data but affects the security of the payment page
B	Imprint machines or standalone dial-out terminals only
B-IP	Standalone PTS-approved terminals with an IP connection to the processor
C-VT	Card data keyed one transaction at a time into a validated virtual terminal
C	Payment application systems connected to the internet
P2PE	Only a validated, listed point-to-point encryption solution
SPoC	A phone or tablet with a secure card reader from the Council's SPoC list (new in v4.x)
D	Every merchant not covered above, and every SAQ-eligible service provider

Each one also has storage and channel conditions the table leaves out. Find my SAQ applies them to your answers.

What changed in v4.x

The dates come from the standard's own version table:

• March 2022: PCI DSS v4.0 published, a major revision. It introduced the customised approach as an alternative to meeting a requirement as written, and many new requirements, a large number of them future-dated.
• 31 March 2024: v3.2.1 retired.
• June 2024: v4.0.1 published, a limited revision that corrects and clarifies v4.0 rather than adding requirements.
• 31 December 2024: v4.0 retired, leaving v4.0.1 as the only version.
• 31 March 2025: the future-dated requirements took effect.

The future-dated requirements are the ones most likely to be missing from an older compliance programme. They include, among others: targeted risk analyses for flexible frequencies (12.3.1), keyed hashes for PAN (3.5.1.1), phishing protection (5.4.1), automated protection for public-facing web applications (6.4.2), payment page script management and change detection (6.4.3 and 11.6.1), 12-character passwords (8.3.6), multi-factor authentication for all non-console access into the CDE (8.4.2), automated log review (10.4.1.1) and authenticated internal scanning (11.3.1.2). All of them are now assessed like any other requirement.

What happens if you do not comply

The consequences come from the payment brands and your acquirer, not from the standard, so they vary. They can include fines passed on by the acquirer, higher fees, a requirement to validate by the more demanding route, and in serious cases losing the ability to accept cards. After a breach, the brands can require a forensic investigation. The standard's own part in that is the incident response plan in 12.10.1.

Between assessments

PCI DSS is written to be run all year, not prepared for once. The recurring work includes:

• vulnerability scans at least every three months (11.3.1 and 11.3.2);
• penetration tests at least every 12 months (11.4.2 and 11.4.3);
• a review of network security control configurations at least every six months (1.2.7);
• a review of user accounts and access at least every six months (7.2.4);
• security awareness training on hire and at least every 12 months (12.6.3);
• a review of the information security policy at least every 12 months (12.1.2).

The PCI DSS v4.0.1 overview is the place to go from here: every control page shows the requirement, the testing procedures an assessor uses, and what to prepare.