A PCI compliance audit is a formal review of how your business handles card payments. An assessor — usually a Qualified Security Assessor (QSA) or your own internal security team — checks your systems, policies, and day-to-day practices against the Payment Card Industry Data Security Standard (PCI DSS).
It's not a pop quiz. It's a structured validation that every part of your payment flow protects cardholder data the way PCI DSS says it should.
What the Audit Is Actually For#
The audit exists to protect customers' card data from theft and fraud — and to give the card schemes confidence that businesses processing their cards are doing it properly. Pass the audit and you keep the right to take card payments. Fail it, and you're facing fines, higher transaction fees, or a compliance programme forced on you by your acquirer.
Most audits are led by a QSA, an independent assessor certified by the PCI Security Standards Council. They check your setup against the 12 core PCI DSS requirements — how depth of review scales depends on your transaction volume and the level that puts you in.
Card-not-present fraud — payments taken over the phone or online — accounts for the bulk of UK card fraud losses. UK Finance's annual fraud report has tracked this pattern for years; CNP consistently runs over 80% of total card fraud value. The audit isn't a formality. It's the mechanism that makes sure your controls actually hold up against the threat that's actually out there.
The Four Compliance Levels#
Your PCI level is set by how many card transactions you process a year, and it dictates how the audit works. The more transactions, the more rigorous the review.
- Level 1 — over 6 million transactions a year. Requires an annual Report on Compliance (ROC), conducted on-site by a QSA. This is the full audit: every applicable control, tested with evidence.
- Level 2 — 1 to 6 million transactions. Normally validated with a Self-Assessment Questionnaire (SAQ) plus Attestation of Compliance (AOC). Some acquirers still insist on a ROC.
- Level 3 — 20,000 to 1 million transactions. Annual SAQ.
- Level 4 — fewer than 20,000 e-commerce transactions (or up to 1 million total across all channels). Annual SAQ.
Getting your level wrong is expensive either way — over-scoping means you pay for an audit you didn't need; under-scoping means you haven't actually met your obligations. If you're unsure which level applies, your acquiring bank will confirm it.
PCI compliance levels at a glance
| Level | Annual transactions | Validation required |
|---|---|---|
| Level 1 | Over 6 million | Annual ROC by a QSA |
| Level 2 | 1 to 6 million | Annual SAQ and AOC |
| Level 3 | 20,000 to 1 million | Annual SAQ |
| Level 4 | Fewer than 20,000 e-commerce (or up to 1 million total) | Annual SAQ |
For a closer look at each level, read our guide on the PCI compliance levels.
Preparing for a PCI DSS v4.0.1 Audit#
PCI DSS v4.0.1 is the current standard. The new requirements became mandatory from 31 March 2025, and the mood of the audit has shifted with it. Assessors want to see ongoing, evidenced security rather than a snapshot that happens to line up on audit day.
In practice, that means three areas are getting a much closer look than they used to:
Multi-factor authentication. Vague, partial MFA doesn't pass any more. Auditors want to see MFA enforced for every path into the cardholder data environment — not just remote access or admin accounts.
Vulnerability management. You need regular scanning, documented risk ratings, and a clear remediation track record. Patching when you remember no longer counts.
Data retention and disposal. Written policies covering exactly how long sensitive data is kept and how it's destroyed. If you're retiring hardware, keep the certificates of destruction.
The customised approach
V4.0 introduced a customised approach, which lets mature organisations meet a requirement using alternative controls rather than the prescribed ones. In theory, that's flexibility. In practice, it's a heavier burden of proof — detailed risk analysis for every custom control, and enough evidence to convince the QSA that your alternative is at least as strong as the one you replaced.
It's designed for organisations with serious risk management in-house. For most businesses, the defined approach is still the cleaner path to a clean audit.
What evidence you'll need
Audits under v4.0.1 are evidence-heavy. The earlier you pull this together, the smoother the assessment goes. You'll want firewall, server, and application logs covering access and monitoring; signed and dated policies for information security, incident response, and staff training; scan reports from your Approved Scanning Vendor (ASV) and any internal scans, with records of what was fixed; and training records showing every relevant team member has completed their annual security awareness training.
If you take payments by phone, our guide on PCI DSS v4.0.1 requirements for telephone payments covers the changes that hit March 2025.
Where Audits Most Commonly Go Wrong#
The same few mistakes come up again and again — and they're all avoidable if you know where to look.
An unsegmented network
A flat network — where the systems handling card data sit alongside workstations, printers, and guest Wi-Fi — forces the auditor to bring most of your infrastructure into scope. That turns a small audit into a sprawling one.
Fix it with proper segmentation: firewalls and strict access controls that isolate the cardholder data environment (CDE) from everything else. Segmentation alone can cut the scope of an audit dramatically.
Scope creep
A new payment method gets launched — web chat, a mobile app, a partner API — and nobody tells compliance. Those new data flows aren't mapped or secured, and the auditor finds them.
The fix is process: keep a current inventory of every system that touches cardholder data, build a PCI check into any new technology launch, and use discovery tools if you're operating at a scale where rogue systems can appear without anyone noticing.
Third-party vendor management
Your vendor says they're PCI compliant. That's not enough. You're still responsible for the data, and if a vendor breach affects your customers, the liability lands on you.
Get your vendor's AOC annually. Get a written agreement that spells out which PCI DSS requirements they handle and which you handle. And monitor — don't assume the compliance they had two years ago is the compliance they have today.
Cutting Audit Scope With the Right Technology#
The single most effective way to simplify a PCI audit is to keep cardholder data out of your environment in the first place. If the data never touches your systems, those systems aren't part of the CDE — and they aren't part of the audit.
Two technologies do most of the heavy lifting here.
DTMF suppression catches the tones generated when a customer keys their card details in on a phone call. The tones are replaced with a flat beep before they reach the agent or the call recorder, so the actual digits never touch your infrastructure. The agent stays on the call, but they never hear or see the card number.
Tokenisation handles the storage side. The payment gateway returns a random token that represents the card — useless to an attacker, but good enough for you to store in your CRM for recurring billing or refunds. The real card number stays with the gateway.
Together, these two techniques create a secure path that bypasses your systems entirely. Agents, their desktops, your recordings, your CRM — none of them ever handle raw card data.
For contact-centre operations, this can take audit responsibilities down by up to 95%. Instead of a full ROC, you may qualify for a much simpler SAQ. See our guide on how Paytia helps with PCI compliance for the detail.
Scope comparison: with and without descoping technology
| Audited area | Without scope reduction | With scope reduction |
|---|---|---|
| Agent desktops | In scope — hardening, monitoring, regular review | Out of scope — no card data reaches the desktop |
| Call recordings | In scope — pause/redact required | Out of scope — DTMF suppression keeps card data out of the recording |
| CRM and internal apps | In scope if storing card data — full PCI controls | Out of scope — only tokens stored |
| Internal network | Partial or full scope — segmentation, monitoring | Largely out of scope — minimal network requirements |
Your Audit Readiness Checklist#
A smooth audit is the result of preparation, not luck. For any business taking card payments by phone or online, the preparation work falls into three phases.
Phase 1 — Scoping and discovery
You can't secure what you don't know about. Start with mapping every data flow: where card data comes in (phone, web form, payment link, chat), where it goes, and where it exits. Build a complete inventory of every system that stores, processes, or transmits that data — this is your CDE. Then list every third-party vendor involved in the payment flow and collect their AOCs.
Phase 2 — Remediation and hardening
With a clear scope, close the gaps. Verify your network segmentation — firewall rules, access controls, traffic patterns — and make sure the CDE is genuinely isolated. Run internal and external vulnerability scans, fix anything flagged, and keep the clean reports. Review every user account and strip access that isn't needed; dormant accounts are a classic finding.
Phase 3 — Documentation and evidence
If it isn't documented, the auditor will treat it as if it didn't happen. Pull together your information security policy, incident response plan, and data retention rules — signed off, in date. Gather at least three months of logs from firewalls, servers, and critical applications. Confirm that staff training records are current for everyone with access to card data.
Common Questions#
How much does a PCI audit cost?
It depends on your level and how clean your environment is. A small business filling in an SAQ may pay very little directly. A Level 1 merchant going through an on-site ROC with a QSA typically pays £15,000 to over £50,000 a year — before factoring in remediation work. The cost of getting sensitive data out of your environment usually pays for itself many times over through a smaller audit footprint.
How long does an audit take?
A well-prepared business with a tight CDE can be through an audit in a few weeks. A larger, less prepared organisation with a sprawling scope can easily take three to six months. Preparation is what closes the gap — the audit itself is short; the remediation it surfaces is where time disappears.
Do I still need an audit if my payment processor is PCI compliant?
Yes. Your processor being compliant covers their part of the flow, not yours. You're still responsible for how you integrate with them, how you handle any data that touches your systems, and the processes your team follows. Your SAQ type depends on how you integrate, but you don't opt out of PCI DSS by using a compliant processor.
Take the Data Out of Scope#
The cleanest path to a straightforward PCI audit is to redesign the payment flow so sensitive data never enters your environment. Paytia's SecureFlow platform does exactly that — DTMF suppression and tokenisation at the point of capture, keeping card data out of your desktops, recordings, and CRM. If you want to see what this looks like on your actual call flow, get in touch.
