What is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements designed to ensure that all organisations that accept, process, store or transmit credit card information maintain a secure environment. It was created to protect cardholders from fraud and data breaches and applies to any organisation that handles payment card data — from global banks to small online retailers.
Unlike GDPR or HIPAA which are government regulations, PCI DSS is a private industry standard enforced by the major payment card brands — Visa, Mastercard, American Express, Discover and JCB — through the Payment Card Industry Security Standards Council (PCI SSC), which was founded in 2006.
Why Was PCI DSS Created?
In the early 2000s, payment card fraud was rising rapidly. Each card brand had developed its own security programme — Visa had CISP, Mastercard had SDP, American Express had DSOP. This fragmented approach was confusing for merchants and ineffective at preventing breaches. In 2004, the five major card brands collaborated to create a single unified standard — PCI DSS version 1.0 was published in December 2004.
The PCI Security Standards Council was formally established in 2006 to manage, evolve and promote the standard. PCI DSS has since become the global baseline for payment security, with compliance required by virtually every merchant agreement and payment processor contract worldwide.
| Standard Body | PCI Security Standards Council (PCI SSC) |
| Current Version | PCI DSS v4.0 (March 2022) — v3.2.1 retired March 2024 |
| Mandatory or Voluntary | Mandatory — required by payment card brand contracts |
| Geography | Global — applies to any organisation handling card data |
| Who must comply | Any merchant, service provider or financial institution that stores, processes or transmits cardholder data |
| Official Resource | pcisecuritystandards.org |
PCI DSS Merchant Levels
Compliance requirements vary based on transaction volume. Organisations are categorised into four merchant levels, each with different validation requirements.
| Level | Transactions per year | Validation requirement |
|---|---|---|
| Level 1 | Over 6 million card transactions | Annual on-site audit by Qualified Security Assessor (QSA) + quarterly network scan |
| Level 2 | 1 million to 6 million transactions | Annual Self-Assessment Questionnaire (SAQ) + quarterly network scan |
| Level 3 | 20,000 to 1 million e-commerce transactions | Annual SAQ + quarterly network scan |
| Level 4 | Fewer than 20,000 e-commerce or up to 1 million other transactions | Annual SAQ recommended + quarterly network scan recommended |
What Changed from PCI DSS v3.2.1 to v4.0?
Version 4.0, released in March 2022, was the most significant update in over a decade. It introduced a more flexible, outcome-based approach while adding new requirements to address modern threats.
| Area | v3.2.1 | v4.0 |
|---|---|---|
| Approach | Prescriptive only | Prescriptive + new Customised Approach for mature organisations |
| Authentication | Basic MFA requirements | MFA required for all access to cardholder data environment |
| Passwords | Minimum 7 characters | Minimum 12 characters (or 8 if system limits) |
| E-commerce security | Limited guidance | New requirements for payment page scripts and anti-skimming |
| Risk assessments | Annual | Targeted risk analysis required for each requirement |
| Total requirements | 264 requirements | 51 new requirements (13 immediate, 38 future-dated to 2025) |
The 12 PCI DSS Requirements
PCI DSS is organised into six goals containing 12 core requirements. Every organisation in scope must address all 12 requirements regardless of merchant level.
| Req. | Requirement | Description |
|---|---|---|
| GOAL 1 — Build and Maintain a Secure Network and Systems | ||
| 1 | Install and maintain network security controls | Firewalls and other network security controls must protect the cardholder data environment. Network diagrams and data flow documentation required. |
| 2 | Apply secure configurations to all system components | Default passwords must be changed. Vendor-supplied defaults removed. Configuration standards developed and implemented for all system types. |
| GOAL 2 — Protect Account Data | ||
| 3 | Protect stored account data | Sensitive authentication data must not be stored after authorisation. Primary Account Numbers (PAN) must be rendered unreadable anywhere stored — using strong cryptography, tokenisation or truncation. |
| 4 | Protect cardholder data with strong cryptography during transmission | Strong cryptography required for transmitting cardholder data over open, public networks. TLS 1.2 or higher required. Wireless networks must use strong encryption. |
| GOAL 3 — Maintain a Vulnerability Management Program | ||
| 5 | Protect all systems and networks from malicious software | Anti-malware solutions deployed on all systems commonly affected by malicious software. Solutions kept current and actively running. Periodic evaluations for systems not commonly targeted. |
| 6 | Develop and maintain secure systems and software | Security vulnerabilities identified and addressed. Security patches installed in a timely manner. Secure development practices followed. Web-facing applications protected against known attacks. |
| GOAL 4 — Implement Strong Access Control Measures | ||
| 7 | Restrict access to system components and cardholder data by business need to know | Access to system components and cardholder data limited to only those individuals whose job requires it. All other access denied by default. Role-based access control required. |
| 8 | Identify users and authenticate access to system components | Unique IDs assigned to each person with computer access. MFA required for all access into the cardholder data environment. Strong password requirements enforced. |
| 9 | Restrict physical access to cardholder data | Physical access to systems in the cardholder data environment restricted. Visitor logs maintained. Media containing cardholder data physically secured and destroyed when no longer needed. |
| GOAL 5 — Regularly Monitor and Test Networks | ||
| 10 | Log and monitor all access to system components and cardholder data | Audit logs capturing all access to network resources and cardholder data. Logs retained for at least 12 months with 3 months immediately available. Daily log reviews required. |
| 11 | Test security of systems and networks regularly | Quarterly internal and external vulnerability scans. Annual penetration testing. Intrusion detection and prevention systems deployed. File integrity monitoring used on critical files. |
| GOAL 6 — Maintain an Information Security Policy | ||
| 12 | Support information security with organisational policies and programs | Security policy addressing all PCI DSS requirements established, published and maintained. Annual risk assessment conducted. Security awareness programme implemented. Incident response plan developed and tested. |
Cardholder Data Environment (CDE)
The Cardholder Data Environment is the people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Understanding and accurately scoping the CDE is one of the most critical — and most commonly misunderstood — aspects of PCI DSS compliance.
Scope reduction is a key strategy. By segmenting the network so that systems outside the CDE cannot communicate directly with systems inside it, organisations can significantly reduce the number of systems subject to PCI DSS requirements — and therefore the cost and complexity of compliance.
| Data type | Examples | Storage permitted? |
|---|---|---|
| Primary Account Number (PAN) | 16-digit card number | Yes — but must be rendered unreadable |
| Cardholder name | Name on card | Yes — if stored with PAN, same protections apply |
| Service code | 3 or 4 digit code on magnetic stripe | Yes — if stored with PAN, same protections apply |
| Expiry date | MM/YY on card | Yes — if stored with PAN, same protections apply |
| Full magnetic stripe data | Track 1 and Track 2 data | NEVER — must not be stored after authorisation |
| CVV/CVC/CID | 3 or 4 digit security code | NEVER — must not be stored after authorisation |
| PIN / PIN block | Personal identification number | NEVER — must not be stored after authorisation |
Securitora Assessment
PCI DSS is non-negotiable for any organisation handling payment card data. Version 4.0 is a significant improvement over v3.2.1 — the customised approach gives mature organisations flexibility while the new requirements address real modern threats like e-commerce skimming attacks and weak authentication. The biggest challenge for most organisations is accurate scoping — underestimating the cardholder data environment is the single most common compliance failure.
| Recommended for | Any organisation that accepts, processes, stores or transmits payment card data |
| Difficulty to implement | Medium to High — prescriptive requirements with significant technical controls |
| Best used with | ISO 27001 · NIST CSF 2.0 · SOC 2 Type II |
| Official resource | pcisecuritystandards.org → |