PCI DSS explained: a plain-English guide for UK organisations

If your organisation takes card payments — online, over the phone or in person — you are almost certainly in scope for the Payment Card Industry Data Security Standard (PCI DSS). This guide explains what the standard is, who it applies to and how you demonstrate compliance, in plain English.

What PCI DSS is

PCI DSS is a global security standard created by the major card brands (Visa, Mastercard, American Express, Discover and JCB) through the PCI Security Standards Council. It sets out the technical and organisational controls an organisation must have in place to protect cardholder data. The current version is v4.0.1.

The standard applies to any organisation that stores, processes or transmits cardholder data — most importantly the Primary Account Number (PAN), the long number on the front of a card. It doesn’t matter whether you are a large retailer or a small care provider taking the occasional payment for a top-up service: if card data touches your systems, people or processes, PCI DSS is relevant to you.

Who has to comply

There is a common misconception that PCI DSS only applies to big businesses. In practice, it applies to merchants of every size and to service providers that handle card data on someone else’s behalf. Your acquiring bank (the bank that settles your card transactions) is usually the party that requires you to validate and report your compliance.

The level of validation depends on your transaction volumes and how you take payments, but the underlying obligation to protect cardholder data is the same for everyone.

The 12 core requirements

PCI DSS is organised around twelve requirements, grouped under six broad goals. At a high level they cover:

Goal	What it means in practice
Build and maintain a secure network	Firewalls, and no vendor-default passwords
Protect account data	Protect stored data and encrypt it in transit
Maintain a vulnerability management programme	Anti-malware, and secure software
Implement strong access control	Restrict access on a need-to-know basis; unique IDs; physical security
Regularly monitor and test networks	Logging, and regular testing
Maintain an information security policy	A policy that everyone understands and follows

Version 4.0.1 also introduces a customised approach, letting mature organisations meet a requirement’s objective using alternative controls, alongside the traditional defined approach. Most smaller organisations will continue to use the defined approach, which spells out exactly what to implement.

What “cardholder data” actually means

It helps to be precise about what the standard is protecting. Cardholder data includes the Primary Account Number (PAN) and, where present, the cardholder name, expiry date and service code. There is also a category called sensitive authentication data — the full magnetic-stripe data, the card verification value (the three or four-digit security code) and the PIN. Sensitive authentication data must never be stored after authorisation, even if encrypted. Understanding which pieces of data you touch, and where, is the starting point for every PCI DSS assessment.

How you prove compliance: the SAQ

Most smaller organisations validate their compliance by completing a Self-Assessment Questionnaire (SAQ) rather than undergoing a full external audit. The SAQ is a checklist of the applicable PCI DSS controls, which you complete and attest to.

Crucially, the type of SAQ you complete depends on how you take card payments — for example whether you use a fully outsourced payment page, a card terminal, or a virtual terminal in a browser. The main types are A, A-EP, B, B-IP, C, C-VT, D and P2PE. Choosing the right one matters, because it defines exactly which controls you must meet. We explain each in our guide to SAQ types.

Scope is everything

The single most important idea in PCI DSS is scope: the people, processes and technology involved in handling cardholder data. Everything in scope must meet the applicable requirements, so the smaller your scope, the simpler and cheaper compliance becomes.

You can shrink your scope by:

• Outsourcing card handling to a compliant payment provider so card data never reaches your systems
• Using redirect or hosted payment pages for online payments
• Segmenting your network so card systems are isolated from the rest of your environment
• Not storing cardholder data unless you genuinely need to

We cover this in detail in reducing your PCI DSS scope. For smaller organisations specifically, see PCI DSS for small businesses.

How PCI DSS relates to data protection

PCI DSS and UK GDPR overlap but are not the same. UK GDPR, overseen by the ICO, governs how you handle personal data generally; PCI DSS is a contractual standard focused specifically on card data security. Card data is also personal data, so good PCI DSS practice supports your broader data protection obligations. If you’d like the wider picture, our glossary explains the key terms.

What good looks like

A well-run PCI DSS programme typically means:

1. You know exactly how card payments flow through your organisation
2. You’ve minimised where card data lives — ideally, nowhere in your own systems
3. You’ve identified the correct SAQ for how you take payments
4. You complete an annual self-assessment and any required scans
5. You keep the supporting evidence and review it each year

Treated this way, PCI DSS becomes a routine annual exercise rather than a scramble.

What happens if you don’t comply

PCI DSS is a contractual requirement rather than a law, but that doesn’t make it optional. If you don’t comply, your acquiring bank or payment provider can apply higher transaction charges, and in the event of a breach involving card data you could face fines passed down through the card brands, the cost of forensic investigation, and the reputational damage of a public incident. Because card data is also personal data, a breach may additionally trigger obligations to the ICO under UK GDPR. Staying compliant is far cheaper and less stressful than dealing with the aftermath of a breach.

Common misconceptions

• “We’re too small for PCI DSS.” Size doesn’t matter — handling card data does.
• “Our payment provider handles it all.” They handle their part; you still have your own SAQ to complete.
• “We did it once, so we’re covered.” Compliance is an annual commitment, not a one-off.
• “We only take a few payments.” Even occasional card handling brings you into scope.

How we can help

Working out your scope and the right SAQ can feel daunting, especially when card payments are only a small part of what you do. We offer a clear, transparent, fixed-fee engagement that maps how you take payments, confirms the correct SAQ, and supports you through completing it with practical guidance at each step. To find out more, explore our PCI DSS service or get in touch for a friendly, no-obligation chat.