PCI DSS is the Payment Card Industry Data Security Standard is a global baseline of security requirements that helps any organisation that accepts, stores, or transmits payment card data protect that information from theft and fraud. It’s developed and maintained by the PCI Security Standards Council (PCI SSC), which is backed by the major card brands.
Payment Card Industry Data Security Standard.
It’s a single, globally used standard with 12 core requirements (grouped into broader security goals) that cover how you design, run and evidence the security of any systems that touch cardholder data.
Being PCI DSS compliant means you’ve implemented the applicable controls and validated them via a Self‑Assessment Questionnaire (SAQ) or a full QSA assessment for the systems in scope, and you can evidence the results to your acquirer or the relevant brand.
Version 3.2.1 was retired on 31 March 2024. Version 4.0/4.0.1 is now the active standard, and the v4 requirements became mandatory on 31 March 2025.
PCI DSS v4.0 was published 31 March 2022 with a transition period. v3.2.1 remained valid until 31 March 2024; from 1 April 2024, v4.x is the only supported version, with future‑dated controls enforced from 31 March 2025.
There are 12 core requirements covering networks, data protection, vulnerability management, access control, monitoring/testing, and policy.
Merchants are categorised into one of four PCI DSS compliance levels, determined by how many card transactions they handle each year. These levels are set by the PCI Security Standards Council (SSC), which brings together the major card brands such as Visa, Mastercard, American Express, JCB, and Discover.
- Level 1: Over 6 million transactions annually
- Level 2: Between 1 million and 6 million transactions per year
- Level 3: Between 20,000 and 1 million transactions per year
- Level 4: Fewer than 20,000 transactions per year
Key updates include: broader multi‑factor authentication (MFA) expectations across access into the CDE; modernised terminology (e.g., network security controls); a customised approach option for meeting objectives; and stronger e‑commerce client‑side controls (Req. 6.4.3 & 11.6.1) to manage and monitor payment‑page scripts against e‑skimming.
1) Scope correctly – identify your cardholder data environment (CDE) and anything that can impact it.
2) Map to the right SELF‑ASSESSMENT QUESTIONNAIRE (SAQ) (or ROC) and implement the relevant parts of the 12 requirements.
3) Validate (SAQ/QSA ROC) and maintain evidence with ongoing activities like ASV scans and testing.
4) Repeat annually and embed controls into business‑as‑usual.
Not statute law but it’s a contractual requirement from the card brands/acquirers, and non‑compliance can affect your ability to take card payments and may trigger fines or increased fees. You still have separate legal duties (e.g., under UK GDPR) for personal data.
Yes. The PCI SSC develops standards used by payment stakeholders worldwide; PCI DSS is described by the Council and national bodies like BSI as the global standard for securing payment card data.
The Cardholder Data Environment (CDE) is everything – people, processes and technology that stores, processes, or transmits cardholder data or sensitive authentication data (and systems that can impact its security). Getting CDE scope right is critical because PCI DSS applies fully inside that boundary.
To provide a baseline of technical and operational controls that protect account data across the global payment’s ecosystem.
It reduces the likelihood and impact of payment data breaches, protects customers, sustains trust, and keeps your organisation eligible to accept cards while aligning with good security hygiene you can reuse across other frameworks.