PCI DSS

Why it matters

PCI DSS is not a law. It is a condition of the contract between a merchant (or service provider) and its acquiring bank, which in turn answers to Visa, Mastercard and the other brands. That makes enforcement commercial rather than regulatory: non-compliance means fines passed down by the acquirer, higher transaction fees, and after a breach, liability for the fraud and the card reissuance. Losing the ability to accept cards is the existential version.

How you prove compliance depends on volume. Small merchants complete a Self-Assessment Questionnaire (SAQ) — the SAQ A for a site that fully outsources the payment page, up to the SAQ D for one that handles card numbers itself. Level 1 merchants (over six million transactions a year) and most service providers need an on-site assessment by a Qualified Security Assessor (QSA) producing a Report on Compliance. The scope is the cardholder data environment (CDE) plus anything connected to it — which is why the standard's most cost-effective control is segmentation: shrink the CDE and you shrink the audit.

The 12 requirements, and what v4 changed

Six goals, twelve requirements: build and maintain a secure network (1 network security controls, 2 secure configurations); protect account data (3 stored data, 4 strong cryptography in transit over open networks); vulnerability management (5 malware, 6 secure systems and software); access control (7 need-to-know, 8 identification and authentication, 9 physical access); monitoring and testing (10 logging, 11 testing); and a security policy (12).

Version 4.0 (March 2022) replaced 3.2.1, which was retired on 31 March 2024; the corrective 4.0.1 (June 2024) is the current text. Sixty-four requirements were future-dated and became mandatory on 31 March 2025. The ones that changed engineering work most:

• 6.4.3 and 11.6.1 — every script on a payment page must be inventoried, authorised and integrity-checked, and the page must have a change-and-tamper detection mechanism (a response to Magecart skimming). Content Security Policy and Subresource Integrity are the usual answers.
• 8.3.6 and 8.4.2 — passwords of at least 12 characters (8 where the system cannot), and multi-factor authentication for all access into the CDE, not just administrators.
• 12.3.1 — a targeted risk analysis documented for every requirement that says "periodically", so the frequency you chose is defended rather than guessed.
• The customized approach — an alternative to prescriptive controls where you show your own control meets the stated objective, with QSA sign-off.

Common misreadings

• "We use Stripe/Adyen, so PCI is their problem." Outsourcing the payment form reduces your scope to SAQ A, it does not remove it — and SAQ A itself gained the script-integrity requirements in v4.
• PAN vs cardholder data. The 16-digit number (PAN) is what triggers most controls; a name plus a truncated number (first six, last four) is not PAN. Never store the CVV after authorisation — there is no compliant way to do so.
• Compliance is a point in time; security is not. Most breached merchants had a valid attestation. Requirement 12.4's "compliance programme" language exists for exactly that reason.

Related terms

• ISO 27001 — ISO/IEC 27001 is the international standard for running an information security management system (ISMS) — a certifiable, risk-driven way of deciding which security controls you need and proving you operate them.
• CSP — CSP is an HTTP response header that tells the browser which sources a page may load scripts, styles, images and frames from — so an injected script tag, even one that reaches the HTML, does not run.
• GDPR — The GDPR is the EU regulation, in force since 25 May 2018, that governs any processing of personal data — including the IP addresses, usernames and e-mail addresses in your logs — and requires security "appropriate to the risk" plus breach notification within 72 hours.