PCI DSS is the security baseline the card schemes impose on anyone who stores, processes or transmits cardholder data. It is not law — it is contract. But lose it and your acquirer can switch you off. Here is the current standard, what it asks, and how to make your scope small.
If you take card payments in any channel, PCI DSS applies to you. The only real question is how much of your environment it touches — and that you can engineer down.
PCI DSS — the Payment Card Industry Data Security Standard — is maintained by the PCI Security Standards Council, a body the card brands (Visa, Mastercard, Amex, Discover, JCB) founded together. The standard sets out how account data must be protected. The enforcement, though, sits with the brands and your acquirer through your merchant agreement.
That distinction matters. PCI DSS is not legislation, so no regulator fines you for breaching it directly. Your acquirer does — via non-compliance fees, higher assessments, withheld funds, or in the worst case termination. After a breach, the brands can levy substantial penalties on the acquirer, who passes them down. Treat PCI as a commercial obligation with security teeth.
The current version is PCI DSS v4.0.1, a limited-revision clean-up of v4.0 published in June 2024. v3.2.1 retired on 31 March 2024. The headline shift in v4.x is a move toward outcome-based security and a long list of new requirements that were "future-dated" as best practice — and became mandatory on 31 March 2025.
| Goal | Requirements | What it covers |
|---|---|---|
| Build & maintain a secure network | 1 · 2 | Network security controls (firewalls); secure configurations, no vendor defaults. |
| Protect account data | 3 · 4 | Protect stored account data (encryption, truncation, masking); strong cryptography over open/public networks. |
| Maintain a vulnerability programme | 5 · 6 | Anti-malware; secure software and systems, patching, change control. |
| Strong access control | 7 · 8 · 9 | Need-to-know access; identify and authenticate users (incl. MFA); restrict physical access. |
| Monitor & test networks | 10 · 11 | Log and monitor all access; test security regularly (scans, pen tests). |
| Maintain a security policy | 12 | An information security policy and programme that ties it all together. |
The standard organises into 12 core requirements under six security goals. Knowing the grouping is more useful than memorising the numbers — it tells you where a control lives.
| Level (Visa/MC) | Annual card txns | Validation |
|---|---|---|
| Level 1 | > 6 million | Annual RoC by a QSA (or ISA) + quarterly ASV scans. |
| Level 2 | 1M – 6M | Annual SAQ (often QSA-assisted) + ASV scans. |
| Level 3 | 20k – 1M (e-comm) | Annual SAQ + ASV scans. |
| Level 4 | < 20k e-comm / < 1M total | Annual SAQ + ASV scans (acquirer discretion). |
How you prove compliance depends on volume and how you handle data. The brands set merchant levels by annual transaction count; the Council provides SAQs (Self-Assessment Questionnaires) for the lower-risk acceptance models. Level 1 cannot self-assess — it needs a QSA-signed Report on Compliance (RoC) or an Internal Security Assessor.
Three levers do most of the work: network segmentation (isolate the CDE so the rest of the estate falls out of scope), tokenization (replace the PAN with a token your systems can hold freely), and P2PE (encrypt at the point of interaction so plaintext card data never lands in your environment). Combine tokenization with a validated P2PE solution and a merchant can drop from SAQ D to SAQ P2PE.
The cardholder data environment (CDE) is everything that stores, processes or transmits account data, plus any system that can connect to or affect it. PCI applies to the whole CDE and to connected-to systems. The single highest-leverage move in any PCI programme is to make the CDE smaller.
This is built for mature security teams with controls that do not map neatly to the rulebook — modern cloud-native or zero-trust architectures, for example. The cost is real: you must produce a Targeted Risk Analysis and full documentation per customized control, and your assessor must independently derive and run testing procedures. It is more work, not less, and it is not a shortcut for the under-resourced. Compensating controls still exist separately for genuine, time-bound constraints.
v4.x introduced a second way to meet most requirements: the customized approach. Instead of the prescribed "defined approach" control, an entity can design its own control that meets the requirement’s stated objective, then prove it works.
Multi-factor authentication for all access into the CDE, not just remote/admin. Properly implemented anti-replay MFA.
Inventory and authorise every script on the payment page; detect unauthorised changes. The anti-skimming controls.
Where a control’s frequency is "periodic", you must justify the frequency with a documented risk analysis — reviewed at least annually.
Minimum 12-character passwords (or complexity equivalent), and tighter rules around shared/service accounts.
Audit-log reviews must use automated mechanisms — manual eyeballing of logs no longer cuts it at scale.
Every one of the 12 requirements now needs explicitly assigned and documented ownership.
v4.0 shipped ~64 new requirements; 51 were future-dated as best practice through 31 March 2025. As of that date they are mandatory — v4.0.1 did not move the deadline. If your last assessment treated them as optional, they are not anymore. The ones that bite hardest:
The cost of PCI is dominated by scope, not by the standard. Two merchants of identical size can sit at SAQ A (a dozen controls, a few thousand rand of effort) or SAQ D (hundreds of controls, a QSA engagement, six figures) purely on architecture. Decide architecture first, validation second.
Use a full redirect or a PCI-listed embedded field service (so CHD never touches your servers) and you can target SAQ A — but you still owe the 6.4.3 / 11.6.1 script controls. Direct-post and self-hosted fields drop you to A-EP. The difference is enormous; choose deliberately.
A validated P2PE solution + tokenization gets you to SAQ P2PE (~33 questions). Without P2PE you are likely in SAQ B/C/D territory. The P2PE premium pays for itself in audit cost alone at scale. See the PIN & P2PE leaf.
You are SAQ D / Level 1 RoC, full stop, plus you must support your merchants’ compliance (responsibility matrices, AOCs on request). Your merchants’ ability to claim SAQ A depends on your attestation. That is a sales asset — treat it like one.
A breach of unencrypted CHD means forensic investigation (PFI), brand penalties via your acquirer, card reissuance costs, and reputational damage. In South Africa it also triggers POPIA breach-notification duties to the Information Regulator. PCI failure and a POPIA incident now arrive together — see the data-protection leaf.
Bottom line: spend on architecture that keeps card data out of your environment (P2PE, tokenization, redirects). Money spent there reduces both audit scope and breach blast-radius. Money spent on documenting a sprawling CDE is money spent on the wrong problem.