PCI compliance (formally PCI DSS, the Payment Card Industry Data Security Standard) is a mandatory security framework covering any business that stores, processes, or transmits payment card data. It defines 12 requirements across 6 goals, is governed by the PCI Security Standards Council, and failure to comply can result in fines, breach liability, and loss of card-acceptance rights.
TL;DR: what is PCI DSS
- What it is: Twelve security requirements from the PCI Security Standards Council for anyone who stores, processes, or transmits cardholder data.
- Current version: Current version is 4.0.1. Requirements 6.4.3 (script inventory) and 11.6.1 (payment-page tamper detection) enforced from 31 March 2025.
- Non-compliance cost: Non-compliance means fines, possible loss of card-brand acceptance, and full liability for breach costs.
Short on time? See cside PCI Shield. It covers everything below in one deployment.
What PCI DSS is and who runs it
The standard is published by the PCI Security Standards Council, an entity founded in 2006 by American Express, Discover, JCB, Mastercard, and Visa to standardize card data security across the payment ecosystem. Before the council, each card brand had its own security program. Consolidating them into PCI DSS meant merchants and service providers could target one framework instead of five.
PCI DSS is not a law, but it is contractually required by every card brand and acquirer that lets you accept cards. Non-compliance can result in fines, higher processing rates, forensic investigation costs after a breach, and loss of the ability to process card payments at all.
Who Has to Comply with PCI DSS?
Any business that accepts, stores, processes, or transmits payment card data. The obligation applies at different levels depending on transaction volume:
| Merchant level | Transaction volume | Validation |
|---|---|---|
| 1 | Over 6M/year (Visa/Mastercard) | Annual RoC signed by QSA |
| 2 | 1M-6M/year | Annual SAQ (typically SAQ D) + ASV scans |
| 3 | 20K-1M e-commerce/year | Annual SAQ + ASV scans |
| 4 | Under 20K e-commerce or 1M total | Annual SAQ, ASV scans as required |
| Service Provider | Any entity handling card data for others | Annual RoC signed by QSA |
The specific SAQ variant depends on how you handle card data. For the differences see our SAQ D guide and our PCI DSS Report on Compliance guide.
What Is Cardholder Data (CHD)?
Cardholder data (CHD) is any data printed, processed, transmitted, or stored in connection with a payment card. Under PCI DSS, CHD includes the primary account number (PAN), cardholder name, expiration date, and service code. Client-side attacks target CHD before it reaches the server, capturing it directly from payment forms in the browser. This is the exposure that PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 are designed to address.
The primary account number (PAN) is the core of CHD, the 13-19 digit number on the card. PCI DSS requires its protection at every point in the payment chain: from the browser where it is entered, through the network where it is transmitted, to the systems where it may be stored.
The cardholder data environment (CDE) is the scope of systems and networks that store, process, or transmit CHD. Scoping the CDE correctly is the starting point for every PCI DSS assessment. Modern e-commerce checkout flows often expand the CDE implicitly: any third-party script loading on a payment page is in scope for Requirements 6.4.3 and 11.6.1, regardless of whether that script directly handles card data.
What Are the 12 PCI DSS Requirements?
PCI DSS 4.0.1 organizes its controls under six goals containing 12 requirements:
Goal 1: Build and Maintain a Secure Network and Systems
- Requirement 1: Install and maintain network security controls
- Requirement 2: Apply secure configurations to all system components
Goal 2: Protect Account Data
- Requirement 3: Protect stored account data
- Requirement 4: Protect cardholder data with strong cryptography during transmission
Goal 3: Maintain a Vulnerability Management Program
- Requirement 5: Protect all systems and networks from malicious software
- Requirement 6: Develop and maintain secure systems and software
Goal 4: Implement Strong Access Control Measures
- Requirement 7: Restrict access by business need to know
- Requirement 8: Identify users and authenticate access
- Requirement 9: Restrict physical access to cardholder data
Goal 5: Regularly Monitor and Test Networks
- Requirement 10: Log and monitor all access
- Requirement 11: Test security of systems and networks regularly
Goal 6: Maintain an Information Security Policy
- Requirement 12: Support information security with organizational policies and programs
Each requirement has multiple sub-requirements. The full standard runs to hundreds of pages.
What changed in PCI DSS 4.0.1
Version 4.0.1 replaced PCI DSS 3.2.1 as the mandatory standard on March 31, 2025. The major additions relative to 3.2.1 are around client-side security:
- Requirement 6.4.3: maintain a script inventory on payment pages, document business justification, verify integrity, detect unauthorized change
- Requirement 11.6.1: monitor HTTP headers on payment pages, detect and alert on unauthorized change
- Requirement 8.3.6: password complexity strengthened
- Requirement 8.4.2: MFA required for all non-console administrative access to the cardholder data environment
- Requirement 12.3.3: cryptographic cipher and protocol inventory
- Requirement 10.7.2/3: expanded logging and monitoring
The client-side additions matter most because they close a gap traditional security tools do not cover. Attacks like formjacking and Magecart-style script skimming happen entirely in the browser, and until 4.0.1 there was no explicit PCI DSS requirement to detect them.
For the deeper walk-through see our PCI DSS 4.0 complete guide and the 4.0.1 implementation webinar summary.
What Are the Most Common PCI DSS Compliance Mistakes?
Working with merchants going through their first 4.0.1 assessment, the same gaps show up repeatedly:
- No script inventory on payment pages: required by 6.4.3, absent in most environments before 2025
- No HTTP header monitoring: required by 11.6.1
- Underestimating scope: assuming SAQ A applies when SAQ A-EP or SAQ D is actually required
- Manual evidence collection: QSAs need continuous evidence, not screenshots taken during the assessment
- Compensating controls without formal documentation: QSAs will not accept undocumented compensating controls
- Treating vendor certifications as your compliance: your payment processor being PCI compliant does not make you PCI compliant
Where cside fits
Requirements 6.4.3 and 11.6.1 are the two most under-prepared areas in most PCI DSS assessments. cside produces continuous script inventory, integrity monitoring, HTTP header monitoring, and change alert history, the exact evidence a QSA needs to sign off on those requirements.
For the practical implementation guide see how to comply with PCI 6.4.3 and the QSA guide for 6.4.3 and 11.6.1.
Getting started
If you are new to PCI DSS, the sequence looks like:
- Identify your merchant level and which SAQ (or RoC) applies
- Complete a scope diagram, covering every system that stores, processes, or transmits card data
- Perform a gap assessment against the applicable requirements
- Remediate gaps, prioritizing anything blocking transaction processing
- Complete the SAQ or engage a QSA for the RoC
- Maintain continuous evidence for the next annual cycle
Compliance is an ongoing program, not a one-time project. Merchants that treat it as continuous end up spending less time and money per cycle than merchants who reconstruct evidence every year.
