TL;DR: what is PCI DSS
- Twelve security requirements from the PCI Security Standards Council for anyone who stores, processes, or transmits cardholder data.
- 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 means fines, possible loss of card-brand acceptance, and full liability for breach costs.
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
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.
The 12 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 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.
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.
