TL;DR
- PCI DSS is the cross-brand security standard for cardholder data, maintained by the PCI Security Standards Council on behalf of Visa, Mastercard, Amex, Discover and JCB.
- Version 4.0 was published in 2022 and became the only valid version in March 2024; further future-dated requirements applied from March 2025.
- It is a contractual standard, not law — but it is mandatory if you accept card payments, and breaches can result in fines and loss of the right to process cards.
- 12 high-level requirements break down into around 250 sub-requirements, with assessment via SAQ or QSA depending on transaction volume.
What PCI DSS Is
The Payment Card Industry Data Security Standard (PCI DSS) is the security standard for the Cardholder Data Environment (CDE) — the systems that store, process, or transmit primary account numbers and related authentication data. It is published by the PCI Security Standards Council, an industry body created jointly by the major card brands.
PCI DSS is contractual, not legal: card brands require acquiring banks to require their merchants to comply, and the obligation flows downstream through processing contracts. Non-compliance discovered after a breach typically attracts fines, increased per-transaction fees, mandatory forensic reviews, and ultimately suspension of the right to process cards.
The 12 Requirements
| # | Requirement |
|---|---|
| 1 | Install and maintain network security controls. |
| 2 | Apply secure configurations to all system components. |
| 3 | Protect stored account data. |
| 4 | Protect cardholder data with strong cryptography during transmission over open public networks. |
| 5 | Protect all systems and networks from malicious software. |
| 6 | Develop and maintain secure systems and software. |
| 7 | Restrict access to system components and cardholder data by business need to know. |
| 8 | Identify users and authenticate access to system components. |
| 9 | Restrict physical access to cardholder data. |
| 10 | Log and monitor all access to system components and cardholder data. |
| 11 | Test security of systems and networks regularly. |
| 12 | Support information security with organisational policies and programmes. |
What Changed in 4.0
PCI DSS 4.0 introduced material updates compared to 3.2.1:
- Customised approach option — alongside the prescriptive 'defined' approach, organisations may design their own controls and demonstrate equivalence.
- Multi-factor authentication required for all access into the CDE, not just remote access.
- Stronger requirements on password length and complexity.
- Targeted Risk Analysis (TRA) replaces the previous one-size-fits-all parameters for several controls.
- Anti-phishing technical controls required on email and web channels.
- E-commerce script-integrity controls (requirement 6.4.3 / 11.6.1) — payment-page scripts must be inventoried, justified, and integrity-monitored.
Warning: Several 4.0 requirements were 'future-dated' to 31 March 2025 to give organisations time to adapt. Many of these — including the e-commerce script-integrity controls and the expanded MFA requirements — caught organisations off-guard. If you have not refreshed your 4.0 readiness review recently, do.
Merchant and Service Provider Levels
PCI DSS scales the validation burden to transaction volume. Both merchants and service providers are sorted into levels:
| Role | Level 1 trigger | Validation |
|---|---|---|
| Merchant | Over 6 million card transactions per year (varies by brand). | Annual on-site QSA Report on Compliance (ROC). |
| Merchant L2-L4 | Lower volumes. | SAQ + quarterly external network scan. |
| Service provider L1 | Over 300,000 transactions per year, or any provider with sufficient downstream merchant impact. | Annual QSA ROC + AOC. |
| Service provider L2 | Under 300,000 transactions per year. | Annual SAQ + AOC. |
Scope Reduction
Most successful PCI programmes start by reducing the size of the Cardholder Data Environment. Common patterns:
- Tokenisation — replace PANs with tokens so downstream systems never see cardholder data.
- Payment processor iframes / redirects — push the actual card entry into the processor's environment.
- P2PE (Point-to-Point Encryption) at the payment terminal so cleartext PAN never enters merchant systems.
- Network segmentation — isolate the CDE on a dedicated VLAN with strict ingress/egress controls.
Where Yobitel Sits
Yobitel does not operate as a payment processor and so does not enter scope as a Level 1 service provider. Yobibyte deployments hosting customer payment workflows can be configured to keep cardholder data out of the platform via tokenisation; where customers do require in-scope hosting, we partner with PCI-DSS-attested platform providers for the CDE.