What is PCI DSS?
Definition
PCI DSS (Payment Card Industry Data Security Standard) is the security standard for any organisation that stores, processes or transmits cardholder data, or can affect its security. It is published by the PCI Security Standards Council, founded by the major card brands. It is not a law, but card networks and acquiring banks enforce it contractually on merchants and service providers. The current version is v4.0.1.
Also known as: Payment Card Industry Data Security Standard, PCI compliance, PCI DSS v4.0.1, PCI DSS 4.0, PCI
Who it covers and who enforces it
PCI DSS applies to every entity that stores, processes or transmits account data such as the primary account number (PAN), and to systems that could affect the security of that data even without touching it. The PCI Security Standards Council writes and publishes the standard but does not enforce it. Card brands and the merchant's acquiring bank decide how compliance must be validated: high-volume businesses need a report from a Qualified Security Assessor, while smaller merchants usually complete a Self-Assessment Questionnaire (SAQ). "PCI certified" is therefore not a one-off badge but a validation repeated on a regular cycle.
Version timeline
| Date | Milestone |
|---|---|
| March 2022 | PCI DSS v4.0 published |
| 31 March 2024 | v3.2.1 retired; v4.0 becomes the only active version |
| 11 June 2024 | v4.0.1 published: a limited revision with clarifications and corrections, no new or deleted requirements |
| 31 December 2024 | v4.0 retired |
| 31 March 2025 | Future-dated requirements introduced in v4.0 become mandatory |
Current documents live in the PCI SSC document library.
Twelve requirements, six goals
The standard groups twelve principal requirements under six goals: build and maintain secure networks and systems, protect account data, maintain a vulnerability management programme, implement strong access control, regularly monitor and test networks, and maintain an information security policy. In day-to-day terms that means card data protected by TLS in transit and strong encryption if stored, access granted on the principle of least privilege, monitored logs and regular penetration testing. Sensitive authentication data such as the card verification code must not be kept after authorisation, encrypted or not.
Shrinking scope is the biggest win
The most effective PCI decision is keeping systems out of scope altogether. An ecommerce site that fully outsources card handling to a PCI DSS compliant payment gateway through a redirect or iframe may qualify for SAQ A, the shortest questionnaire. Sites whose own pages collect card data with JavaScript and pass it to the provider fall under SAQ A-EP, and those that process card data on their own servers face a far broader set of requirements.
A January 2025 update to SAQ A shifted the balance. Requirements 6.4.3 and 11.6.1 on payment page scripts were removed from SAQ A, and an eligibility criterion was added instead: the merchant must confirm its site is not susceptible to attacks from scripts that could affect its ecommerce systems. Even with an iframe, the security of the page hosting it is still the merchant's concern.
Payment page scripts
Two requirements that became mandatory under v4.x target card skimming in the browser. Requirement 6.4.3 asks for an inventory of every script on the payment page, a justification for each and a way to confirm its integrity; 11.6.1 asks for detection of unauthorised changes to the page's headers and content. Cutting third-party scripts on payment pages and restricting what can load with a Content Security Policy makes both far easier to satisfy.
Common myths
- "My provider is PCI compliant, so I am too." Their compliance reduces your scope; it does not replace your own validation.
- "PCI is a law." It is a contractual obligation. Data protection laws apply separately and on top.
- "We passed once, we're done." Validation recurs, and some merchants also need periodic external vulnerability scans.