PCI DSS v4.0 explained for the team that has to implement it. Merchant levels, the right SAQ, the 12 requirements, and the scope-reduction moves that turn a six-month project into a six-week one.
What PCI DSS is
The Payment Card Industry Data Security Standard (PCI DSS) is the contractual security standard imposed by Visa, Mastercard, AmEx, Discover and JCB on any organisation that stores, processes or transmits cardholder data. It is enforced through your acquirer (your payment processor's bank), not by a government — but the contractual penalties and breach liabilities are substantial.
v4.0 is the current version. v3.2.1 was retired on 31 March 2024, and the future-dated v4.0 requirements become mandatory on 31 March 2025.
The 12 requirements (six goals)
Build and maintain a secure network (1–2): firewalls, no vendor defaults
Protect cardholder data (3–4): storage, transmission encryption
Maintain a vulnerability programme (5–6): anti-malware, secure development
Strong access control (7–8–9): need-to-know, MFA, physical access
Monitor and test networks (10–11): logging, scanning, pen testing
Information security policy (12): governance and awareness
A practical implementation path
Step 1
Reduce scope first
Every system that stores, processes or transmits card data — plus anything connected to it — is in scope. Tokenisation, hosted payment pages and segmentation can shrink that list dramatically. Do this before requirement 1.
Step 2
Pick the right SAQ
The Self-Assessment Questionnaire you complete depends on how you handle card data. Wrong SAQ = invalid attestation. When in doubt, default to SAQ D and exclude what doesn't apply, rather than picking a thinner SAQ you don't qualify for.
Step 3
Implement the 12 requirements
Map current controls to each requirement. Document the gaps, assign owners, set dates. v4.0 introduces a "customised approach" — you can meet a requirement's objective using alternative controls, with a documented Customised Approach Object.
Step 4
Quarterly scans, annual pen test
Approved Scanning Vendor (ASV) scans every quarter — clean scan required for attestation. Internal vulnerability scans every three months. Penetration test annually and on significant change.
Step 5
Complete and submit your attestation
Sign the Attestation of Compliance (AOC). Submit to your acquirer or directly to the card brands if you are Level 1. Keep evidence for the next assessment cycle.
PCI without spreadsheets
PCI DSS is the densest of the standards we cover — twelve requirements, dozens of sub-requirements, evidence per quarter. A workspace that ties requirements to controls, owners and evidence saves more time here than anywhere else.
ISO-STANDARD.app ships a ready-to-adopt PCI DSS workspace with the risk register, controls catalogue, policies and audit-ready exports already wired together — no spreadsheet sprawl, no consultant lock-in.
Prefer a conversation? Email hello@iso-standard.app — a real human responds within one business day.
Frequently asked questions
Which SAQ do we need?
Depends on how you handle card data. SAQ A: fully outsourced e-commerce. SAQ A-EP: e-commerce with payment page that touches your servers. SAQ D: everyone else, plus all Level 1 merchants. Pick wrong and your attestation is invalid.
When did v4.0 become mandatory?
PCI DSS v4.0 was published in March 2022. v3.2.1 was retired on 31 March 2024. From 31 March 2025, the 'future-dated' v4.0 requirements (about 50 of them) also become mandatory.
What are merchant levels?
Level 1: >6M card transactions/year (Visa) — requires annual on-site QSA assessment. Level 2: 1–6M — usually self-assessment with QSA review. Level 3: 20k–1M e-commerce. Level 4: <20k e-commerce or <1M total — self-assessment via the appropriate SAQ.
Can we reduce PCI scope?
Yes, and it's usually the highest-leverage thing you can do. Tokenisation, hosted payment pages, network segmentation, and never storing the PAN in your environment are the four big moves. Done well, you go from SAQ D to SAQ A.