What Is PCI DSS? The Payment Card Industry Data Security Standard Explained

PCI DSS is the Payment Card Industry Data Security Standard: the global set of security requirements for any organisation that stores, processes or transmits payment card data, or could affect the security of that data. It is written by the PCI Security Standards Council (PCI SSC), enforced by the card brands through acquirers, and organised into 12 requirements. The current version is PCI DSS v4.0.1.

PCI compliance is the day-to-day side of the same thing. It means meeting those requirements all year for the systems, people and processes that touch card data, then proving it once a year with a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC). Whether your business has to comply, and how UK acquirers handle it, is covered in our guide to PCI compliance UK.

What does PCI DSS stand for?

PCI stands for Payment Card Industry, and DSS stands for Data Security Standard. Put together, PCI DSS is the Payment Card Industry Data Security Standard, and each part of the name tells you something about it:

In CIA triad terms, PCI DSS is mainly about the confidentiality of card data, with integrity controls such as payment page script monitoring running through it.

You will also see it written as PCIDSS, PCI-DSS or simply “PCI”, although the PCI SSC also publishes other standards for PINs, card production, payment devices, software and 3-D Secure systems (PCI 3DS). The standard and its supporting documents are free to download from the PCI SSC document library.

Who writes PCI DSS, and who enforces it?

The PCI Security Standards Council writes PCI DSS, and the card brands enforce it through acquirers. American Express, Discover, JCB, Mastercard and Visa set up the council in 2006 to manage the common standard they had first published in 2004. It maintains the standards, trains and approves assessors such as Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs), and lists validated products. It does not decide who must validate, and it does not issue fines.

Each card brand runs its own compliance programme and holds acquirers (the banks and payment companies that process card payments for merchants) responsible. Acquirers pass that obligation on through merchant agreements: they set how you validate, collect your evidence and apply charges if you do not. Service providers are held to it by their customers’ contracts as well. Our guide to the PCI Security Standards Council maps the whole standards family, its history and every assessor programme. PCI DSS is not law, but UK GDPR still applies to card data linked to a person; our guide to GDPR and PCI compliance explains where the two meet.

What does PCI compliance mean day to day?

What is PCI compliance? It means your card payment environment meets PCI DSS every day, not only on the day you sign your annual questionnaire. For a typical merchant, that looks like this:

• Keep card data out of your own systems where you can. Hosted payment pages, PCI-listed point-to-point encryption (P2PE) solutions and tokenisation all shrink what you have to protect.
• Never keep what the standard forbids. Card security codes and PINs are never stored after authorisation, and card numbers taken by phone are not written on notepads or saved in emails (our guide to taking card payments over the phone shows the safe methods).
• Use compliant providers and hold their evidence. Keep each payment provider’s Attestation of Compliance and a written record of which requirements it covers for you.
• Patch and protect. Change vendor default passwords, apply security updates promptly and run anti-malware.
• Control access. Give everyone a unique login, use multi-factor authentication for access into the card environment and remove leavers’ access quickly. Our guide to PCI DSS Requirement 8 sets out the authentication rules in full.
• Look after card terminals. Keep a list of devices, inspect them for tampering and train staff to challenge unexpected “engineers”.
• Train your people when they join and at least once a year, including on phishing and social engineering, as our guide to PCI DSS training explains.
• Scan, test and validate. Run quarterly external scans through an ASV where your SAQ requires them, and validate every year.

What counts as PCI data?

What is PCI data? It is what the standard calls account data: cardholder data plus sensitive authentication data. The card number, or primary account number (PAN), is the defining element of cardholder data. PCI DSS applies wherever account data is stored, processed or transmitted, and to any system that could affect its security. Sensitive authentication data is what is used to authorise a payment, and its rules are stricter.

The classification drives what you may keep. Sensitive authentication data is not kept after authorisation by anyone except card issuers and companies that support issuing services, and they may hold it only for a legitimate issuing need and under strong protection (3.3.3). Stored PAN is kept only as long as your retention policy allows (3.2.1), and media holding cardholder data is classified by sensitivity (9.4.2). Our guide to protecting stored card data under Requirement 3 covers retention, encryption, hashing and key management in detail.

Where card data flows decides your cardholder data environment (CDE), and so how much of PCI DSS you have to apply. Our PCI DSS scoping guide shows how to draw that boundary and how tokenisation and segmentation reduce it.

What does PCI DSS require?

PCI DSS v4.0.1 has 12 principal requirements. They sit under six goals, often called the six major principles of PCI DSS:

Each breaks down into detailed sub-requirements, and how many apply to you depends on your scope. Our guide to the 12 PCI DSS requirements explains all 12 and the six principles in turn, and our PCI compliance checklist turns them into tasks you can work through.

Most organisations meet each requirement through the defined approach: the requirement and its testing procedures as written. Version 4.0 added the customised approach as an alternative for most requirements. It lets an organisation design its own control to meet the requirement’s stated objective, backed by a targeted risk analysis for each requirement met this way (12.3.2). It must be documented in a Report on Compliance, so it is not available to organisations that validate with an SAQ.

How is PCI DSS compliance validated, and how often?

Every year, by one of two routes, and both end in a signed Attestation of Compliance (AOC). The card brands and your acquirer decide which route applies, mainly from your annual card transaction volume, as our guide to PCI compliance levels explains.

There are several SAQ types, each tied to a way of taking payments, and eligibility depends on the criteria in each questionnaire rather than on business size. Our guide to which PCI SAQ applies sets them out. Where your SAQ or ROC requires it, external vulnerability scans by a PCI SSC Approved Scanning Vendor are needed every three months (Requirement 11.3.2).

The PCI SSC does not issue certificates to merchants or service providers, so a “PCI certificate” from a vendor is not a PCI SSC document: the signed AOC is your evidence of compliance. A ROC or a QSA-signed SAQ has to come from a PCI QSA (or an ISA where the card brand allows it), and our PCI DSS assessment service covers both.

Which version of PCI DSS is current?

PCI DSS v4.0.1 is the only active version, and all of its requirements are now in force. It was published in June 2024 to clarify and correct v4.0 without adding new requirements. Version 3.2.1 was retired on 31 March 2024 and v4.0 on 31 December 2024.

The requirements that v4.0 introduced as future-dated became mandatory on 31 March 2025, so any SAQ or ROC completed now covers them. They include multi-factor authentication for all non-console access into the CDE (8.4.2), control of payment page scripts (6.4.3 and 11.6.1), automated protection against phishing (5.4.1) and a 12-character minimum for passwords (8.3.6). Our PCI compliance blog covers several of these requirements in more depth, including payment page security for e-commerce.

Why Sovereign Secure

Sovereign Secure Ltd has been a UK company since 2012 (Companies House 08334453), headquartered in Accrington, Lancashire, with offices in Los Angeles, Singapore, Dubai and Dhaka. The PCI Security Standards Council has approved us as a Qualified Security Assessor (QSA) company, a Qualified PIN Assessor (QPA), a Card Production Security Assessor (CPSA), a P2PE Assessor and a 3DS Assessor, and we are a member of its Global Executive Assessor Roundtable (GEAR) for 2026 to 2028.

We are also ISO 27001 certified and ICO registered. Our PCI compliance services cover QSA assessments, consultancy, penetration and segmentation testing, and quarterly external scans delivered through our PCI SSC Approved Scanning Vendor partner.

Not sure where your business fits?

For a quick first answer, check your PCI compliance with our free readiness check. Or tell us how you take card payments and we will confirm what PCI DSS means for you: your likely validation route, which SAQ applies or whether you need a ROC, and a fixed quote for any assessment work. Contact our PCI team or call +44 161 523 5276.