What PCI DSS is and who it applies to
PCI DSS (Payment Card Industry Data Security Standard) is the security standard that governs how payment card data is stored, processed, and transmitted. It is published by the PCI SSC (Security Standards Council), a consortium founded in 2006 by the five major card networks: Visa, Mastercard, American Express, Discover, and JCB. No government regulator issues it. Its force is contractual: the networks and acquirers impose it on every company that touches card data.
The current version is v4.0, published in March 2022 and revised as v4.0.1 in June 2024 (editorial corrections, no new requirements). Version 3.2.1 was retired on March 31, 2024. A set of “future-dated” requirements, treated until then as best practice only, became mandatory on March 31, 2025. That transition drives most of the standard's news in 2025 and 2026.
The CDE: defining and reducing scope
The CDE (Cardholder Data Environment) comprises the people, processes, and systems that store, process, or transmit account data, plus any connected system that could compromise them. Defining its boundary is the first step in any compliance project. It sets the list of assets to assess and drives the cost of the assessment, because anything out of scope is exempt from the requirements.
PCI DSS splits account data into two categories with radically different retention rules. Cardholder data may be stored as long as it is protected. Sensitive authentication data (SAD) must never be retained after authorization, even in encrypted form.
| Item | Category | Storage permitted | Must be rendered unreadable |
|---|---|---|---|
| Card number (PAN) | Cardholder data | Yes | Yes |
| Cardholder name | Cardholder data | Yes | No (but in scope and protected) |
| Expiration date | Cardholder data | Yes | No |
| Service code | Cardholder data | Yes | No |
| Full track or chip data | SAD | Never after authorization | N/A |
| Card security code (CVV2 / CVC2 / CID) | SAD | Never after authorization | N/A |
| PIN / PIN block | SAD | Never after authorization | N/A |
Network segmentation isolates the CDE from the rest of the IT environment with VLANs, firewalls, and access controls. It keeps a compromised office workstation from becoming a pivot point into the systems that handle card data. It also takes dozens of machines out of audit scope, which makes it the main lever for reducing scope.
The 12 requirements, grouped under six goals
The standard consists of 12 requirements organized under six broad goals, each broken down into dozens of testable sub-requirements. The table below gives an overview.
| Goal | N° | Requirement | In plain terms |
|---|---|---|---|
| Secure network | 1 | Network security controls | Firewalls and filtering between the CDE and everything else |
| Secure network | 2 | Secure configurations | No default passwords or unnecessary services |
| Protect account data | 3 | Protect stored account data | Encrypt or truncate the PAN; never keep SAD |
| Protect account data | 4 | Encrypt transmissions over open networks | Strong end-to-end TLS over the internet |
| Vulnerability management | 5 | Protect against malware | Anti-malware kept current and monitored |
| Vulnerability management | 6 | Develop and maintain secure systems | Patching, secure development, script management |
| Access control | 7 | Restrict access on a need-to-know basis | Least privilege, role-based access |
| Access control | 8 | Identify and authenticate access | Individual user IDs, MFA across the board |
| Access control | 9 | Restrict physical access | Secure premises, media, and terminals |
| Monitor and test | 10 | Log and monitor access | Audit trails, timestamps, log review |
| Monitor and test | 11 | Test security regularly | ASV scans, penetration tests, tamper detection |
| Policy | 12 | Information security policy | Governance, awareness, third-party management |
New in v4: 6.4.3 and 11.6.1 against e-skimming
Browser-side skimming means injecting malicious code into the payment page as it renders in the customer's browser, a technique known as Magecart-style attacks. Two of the requirements that became mandatory on March 31, 2025 explicitly target this attack. Earlier versions of the standard covered the merchant's server-side systems and did not address code running in the browser.
A modern payment page routinely loads dozens of third-party scripts (analytics, chat, A/B testing), and any one of them can be hijacked to read input fields. Defenses combine CSP (Content Security Policy), Subresource Integrity (SRI), and monitoring of the script inventory. A card entry form in an iframe hosted by the PSP keeps card data out of the merchant's DOM, so the page's scripts can no longer reach it.
Merchant levels, SAQs, and attestation
How a company proves compliance depends on its transaction volume and how it accepts cards. The networks define four merchant levels. Above roughly 6 million card transactions a year (Level 1), the entity must produce a ROC (Report on Compliance) prepared by a QSA (Qualified Security Assessor). Below that, it can use a self-assessment questionnaire (SAQ) that fits its setup.
| Level | Annual card transaction volume | Required validation |
|---|---|---|
| Level 1 | Over 6 million (all channels) or any breached merchant | On-site audit + ROC by a QSA, quarterly ASV scans |
| Level 2 | 1 to 6 million | SAQ (the acquirer sometimes requires an audit), ASV scans |
| Level 3 | 20,000 to 1 million e-commerce | SAQ + quarterly ASV scans |
| Level 4 | Under 20,000 e-commerce; up to 1 million in other channels | SAQ + ASV scans, at the acquirer's discretion |
The SAQ is a family of questionnaires, each designed for a specific way of accepting cards. The right questionnaire depends on how the entity receives and handles card data, and that choice sets how many requirements it must demonstrate.
| SAQ | Typical setup | Number of requirements (approx.) |
|---|---|---|
| A | E-commerce, 100% outsourced (redirect or PSP iframe) | Shortest |
| A-EP | Partially outsourced e-commerce; the merchant's page affects security | Medium, up sharply |
| B / B-IP | Standalone terminals (dial-out or IP) | Short |
| C-VT | Virtual terminal (manual entry in an isolated browser) | Short to medium |
| C | Internet-connected payment application | Method |
| P2PE | PCI-validated P2PE terminal | Greatly reduced by hardware encryption |
| D | All other merchants and all service providers | Most comprehensive (all 12 requirements) |
Costs, scope reduction, and penalties
Compliance costs vary widely from one company to the next, and scope is the first driver. The broader the scope, the more expensive the audit, since the number of systems, data flows, and controls to review grows with it. Tokenization, P2PE, and outsourced card entry shrink the scope, move a merchant from SAQ D down to SAQ A, and cut the workload tenfold.
- Outsource card entry (PSP iframe or redirect) to qualify for SAQ A.
- Tokenize PANs at the point of entry, so no cleartext card data remains at rest.
- Segment the network to isolate and shrink the CDE.
- Choose validated P2PE terminals for in-store payments.
- Map card data flows at least once a year. It is a requirement, and the best way to spot scope that has drifted.