What is PCI DSS?

PCI DSS is the security standard that tells every business handling card payments what they have to do to keep cardholder data safe. It doesn't matter if you're a single shop taking the occasional phone order or a bank running a 2,000-seat contact centre — if card data passes through your systems, PCI DSS applies to you. This guide walks through what it actually means in practice, what the main mistakes are, and how to make compliance less painful than it probably looks right now.

What PCI DSS Stands For, and Why It Exists

PCI DSS is the Payment Card Industry Data Security Standard. It was created in 2004 by the five big card schemes — Visa, Mastercard, American Express, Discover, and JCB — who realised they all needed the same thing but had been writing separate rules. They set up the PCI Security Standards Council in 2006 to own the standard, and the Council still runs it today. The current version is 4.0.1, which became mandatory in March 2025.

The reason it exists is simple. When criminals steal card data, someone has to pay for the losses — either the card scheme, the bank, the merchant, or the customer. The card schemes decided the best way to cut those losses was to get out in front of them: make the people handling the data responsible for keeping it safe. PCI DSS is how they spell out what "safe" means.

Who It Applies To

Anyone who stores, processes, or transmits cardholder data. That includes merchants (you), service providers (Paytia, your payment gateway, your hosting company if card data passes through their kit), and sometimes companies that could affect the security of that data even if they don't touch it directly. The card schemes don't chase you themselves — your acquiring bank (the one that gave you your merchant account) is responsible for making sure you comply, and they'll fine you or pull your ability to take cards if you don't.

Most businesses never hear from the PCI Council directly. You hear from your acquirer, usually via an annual questionnaire or audit depending on your size.

The 12 Requirements, in English

PCI DSS is built around 12 requirements grouped into six headings. The official wording is terse and legalistic. Here's what each one actually means.

Build and maintain a secure network

1. Have a firewall that works. Block traffic you don't need. Review the rules regularly. If you have card data on an internal network, make sure it's segmented from the rest of your IT.
2. Change the default passwords. Every device ships with a default admin password. Attackers know every single one. Change them.

Protect account data

3. Don't keep card data you don't need. And what you do keep, encrypt. You can't store the CVV after authorisation at all — that's non-negotiable.
4. Encrypt data on the move. Any card number travelling across a network (your agent's headset audio, a gateway API call, a wifi link) has to be encrypted end to end.

Maintain a vulnerability management programme

5. Run anti-malware everywhere it's relevant. Keep it updated.
6. Patch your software. Known vulnerabilities are how most breaches start. 4.0.1 tightened the patch timelines — critical fixes inside a month, others on a defined schedule.

Implement strong access control

7. Need-to-know access only. If someone doesn't need to see card data to do their job, they shouldn't see it.
8. Unique login per person. No shared accounts. Every action has to be traceable. Multi-factor authentication is required for any remote access and any admin access to cardholder data environments.
9. Physical access matters too. Lock the server room, log the visitors, destroy old hard drives.

Regularly monitor and test networks

10. Log everything relevant and keep the logs for at least a year. Card data access, admin actions, failed logins, system errors. If a breach happens, the logs are how you find out what went wrong.
11. Test your security. Quarterly external vulnerability scans from an Approved Scanning Vendor (ASV), annual penetration testing, and testing after any significant change.

Maintain an information security policy

12. Write it down, train your people, review it. Having technical controls isn't enough. You need a policy that says what the rules are, and evidence that your staff know them.

SAQs: The Questionnaires You'll Actually Deal With

Most merchants never do a full PCI audit. Instead, you complete an annual Self-Assessment Questionnaire — an SAQ — that confirms you're following the parts of PCI DSS relevant to how you take payments. Which SAQ you fill in depends entirely on how card data flows through your business. The letter codes aren't obvious, so here's the practical translation.

• SAQ A (22 controls). The easy one. You're fully outsourced — card data never touches your systems. You use a hosted payment page, a redirect to a gateway, or a service like Paytia that intercepts the data before it reaches you. Most of PCI DSS simply doesn't apply to you.
• SAQ A-EP (~190 controls). E-commerce sites that host their own checkout but offload the card capture to an iframe or JavaScript from a third party. More on you than SAQ A, still less than SAQ D.
• SAQ B (~40 controls). Standalone card terminals — the classic dial-up PDQ machine with no connection to anything else. Very rare in 2026.
• SAQ B-IP (~80 controls). IP-connected card terminals. The modern version of the old SAQ B.
• SAQ C (~160 controls). A card-present merchant with a payment application on their network.
• SAQ C-VT (~80 controls). Virtual terminal — staff type card details into a web form provided by the processor. No card storage on your side, but the staff workstations are in scope.
• SAQ D (329 controls). The full one. You've got card data living on your network or systems. This is where most businesses land if they haven't actively designed the problem away.

The big prize is SAQ A. Going from SAQ D to SAQ A isn't about doing less paperwork — it's about not being in scope for most of PCI DSS in the first place. That's what matters.

Merchant Levels

On top of the SAQ question, Visa and Mastercard classify you into one of four merchant levels based on how many card transactions you process a year:

• Level 1 6 million+ transactions a year, or any merchant that's had a breach. Requires an annual on-site audit by a Qualified Security Assessor (QSA). This is the level Paytia operates at as a service provider.
• Level 2 1 to 6 million. SAQ or QSA audit, depending on the card scheme.
• Level 3 20,000 to 1 million e-commerce transactions. SAQ.
• Level 4 Under 20,000 e-commerce or under 1 million total. SAQ.

Most UK SMEs sit in Level 4. That's fine — the controls are the same, you just self-certify instead of bringing in a QSA.

Reducing Scope (Where The Real Savings Live)

The cost of PCI compliance is driven by scope. Scope is the set of systems and people that touch cardholder data. The bigger your scope, the more systems you have to secure, monitor, patch, and audit. So the single biggest thing you can do for PCI is shrink your scope.

Three methods do most of the heavy lifting:

DTMF masking (for phone payments). When a customer types their card on the phone keypad, the tones get intercepted before they reach your agent, your call recording, or your systems. The card goes straight to the gateway. Your contact centre — phones, agents, recordings, network — drops out of scope. This is what Paytia does, and it's how most of our customers move from SAQ D to SAQ A. We cover this in depth in the DTMF masking guide.

Tokenisation. If you need to store card details for recurring payments, don't. Store a token instead — a reference number meaningless to anyone outside the tokenisation service. When you want to charge the card again, you send the token to the payment provider, who swaps it back internally. Your database holds tokens; the real data lives with someone else.

Point-to-point encryption (P2PE). For card-present transactions, a P2PE-certified solution encrypts the card data inside the terminal itself, before anything leaves the tamper-evident hardware. Your checkout lane, your network, your back office — none of them ever see the raw card number.

Between them, these three techniques are how businesses drop from a full 329-control SAQ D to a 22-control SAQ A. It's not a loophole — it's the outcome the card schemes are trying to encourage.

What Changed in PCI DSS 4.0.1

Version 4.0 was published in 2022 with a long transition period; 4.0.1 (published June 2024) became the mandatory baseline in March 2025. If you haven't been audited against 4.0.1 yet, you will be at your next assessment.

The headline changes:

• Targeted risk analysis. You're now expected to document why you do things the way you do — frequency of reviews, retention periods, testing intervals — based on your own risk profile. Saying "because the standard says so" isn't enough anymore.
• Customised approach. For advanced organisations, 4.0 lets you meet the intent of a requirement with alternative controls rather than the prescribed ones. More flexible, but the documentation burden is higher.
• Multi-factor authentication everywhere. MFA was required for remote access under 3.2.1; 4.0 extends it to all access into the cardholder data environment, including on-premises administrative access.
• Stricter phishing and malware controls. E-mail and browser-based threats get their own explicit controls. Anti-phishing training is now required, not optional.
• DTMF suppression called out explicitly. If your telephony system captures DTMF tones containing card data (in recordings, logs, or otherwise), those tones have to be suppressed or the logs have to be treated as card data. This closes a gap that caught a lot of contact centres out.
• Inventory of scripts. For e-commerce, you now have to inventory and monitor every third-party JavaScript that runs on your payment pages. Magecart-style attacks drove this change.

What It Actually Costs

The honest answer is: it depends on your scope. A merchant on SAQ A can finish their annual attestation in an afternoon. A Level 1 service provider running a full QSA audit might spend six figures on assessment, staff time, and remediation. Most businesses sit somewhere in between.

The pattern we see across our customer base:

• SAQ D contact centre (before Paytia) £15,000-£50,000 a year between QSA assessment, vulnerability scanning, staff time, recording scrubbing, network segmentation, and dedicated compliance tooling.
• SAQ A contact centre (with Paytia or equivalent) £3,000-£8,000 a year, mostly for the scans, an hour or two of someone's time on the SAQ itself, and the subscription to the service that took scope off your plate.

The saving isn't the fee to Paytia. The saving is that you stop paying for scope you no longer have.

What Happens If You Don't Comply

The card schemes don't typically fine individual merchants directly. Your acquirer does, and they're responding to pressure from the schemes. The scenarios that usually play out:

• Quarterly non-compliance fees £50-£100 a month added to your acquiring bill if you miss your SAQ deadline. Small but cumulative.
• Post-breach fines Much bigger. Card schemes can levy fines of £50,000-£500,000 per incident against your acquirer, who passes them straight through to you. If the breach involves more than 10,000 card records, you're into six- or seven-figure territory.
• Forensic investigation If a breach is suspected, you're required to fund a PCI Forensic Investigator (PFI) to do a full audit. Typical cost £30,000-£100,000, and they'll invoice you whether or not they find the breach is your fault.
• Loss of ability to accept cards Worst case. If your acquirer pulls the plug, you're off the card schemes entirely and finding a replacement merchant account is hard and expensive.

Beyond the financial hit, there's the reputational one. The ICO has to be notified of any breach involving UK personal data within 72 hours. That becomes public. Customers notice.

Common Misconceptions

"We're too small for PCI to matter." No. The smallest SAQ A merchant and the biggest Level 1 service provider are both subject to the standard. Size changes how you demonstrate compliance, not whether you have to.

"Our payment gateway is PCI compliant, so we are." Partially. Your gateway being compliant lets you use them without inheriting their PCI burden, but it doesn't remove your own obligations. You still have a merchant account, you still have staff who might touch card data, and you still have to complete an SAQ.

"We only take card details once over the phone and don't store them." Doesn't matter. If an agent hears a card number, your contact centre is in scope. PCI doesn't distinguish between "we stored it" and "we just heard it and forgot it" — if card data passed through, you're responsible for the systems it passed through.

"We can pause-and-resume the recording and be fine." You can't, not really. Pause-and-resume removes card data from the recording only. The agent still heard it, the workstation still showed it, the phone system still carried it. Scope stays.

FAQs

Is PCI DSS a legal requirement in the UK? It's a contractual requirement, not a statutory one. You agree to it when you take a merchant account. That said, GDPR covers personal data including card information, so a breach can still bring ICO fines independently.

How long does an SAQ take? An SAQ A, about an hour. SAQ A-EP, half a day. SAQ D, several days to weeks depending on how complete your existing documentation is.

Do I need a QSA? Only if you're Level 1, or if your acquirer specifically requires one. Most Level 2-4 merchants self-assess.

How often is PCI DSS assessed? Annually. Plus quarterly ASV scans for any merchant with an internet-facing card data environment.

What's the difference between PCI DSS and PCI compliance? None. People use them interchangeably. The standard is PCI DSS; being compliant with it is PCI compliance.

Does PCI DSS apply to phone payments? Yes. Phone payments are card-not-present transactions and fall entirely under PCI DSS. The contact centre ecosystem — phones, recordings, agent workstations, CRM — is where most businesses carry the heaviest PCI burden unless they've actively designed it out.

Can I lose my PCI certification? Yes. If you fail an assessment, suffer a breach, or miss deadlines, your acquirer can mark you non-compliant. Practical effects range from fines to loss of card acceptance.

Where This Lives in the Paytia Platform

Paytia is a PCI DSS Level 1 Service Provider — independently audited every year against the full standard. Using Paytia for any of your card-data touchpoints means the work of being audited at Level 1 is done for you; you use us as an outsourced component and your own SAQ shrinks accordingly. Our DTMF Suppression and Channel Separation products are the two specific techniques we offer for phone payments. For the broader platform picture, see Platform overview, or read the DTMF masking guide for the technical mechanism.