The Complete Guide to PCI DSS Compliance

If your business accepts card payments — whether online, in-store, or over the telephone — you are required to comply with PCI DSS. There are no exceptions, no minimum thresholds, and no grace periods. Every organisation that stores, processes, or transmits cardholder data must meet the standard.

Yet for many businesses, PCI DSS compliance remains confusing, intimidating, and easy to put off. This guide cuts through the jargon. It explains exactly what PCI DSS is, what you need to do, and how to make compliance as painless as possible — especially if you take payments over the telephone.

What Is PCI DSS and Why Does It Exist?

PCI DSS stands for the Payment Card Industry Data Security Standard. It is a global set of security requirements created by the major card brands — Visa, Mastercard, American Express, Discover, and JCB — through the PCI Security Standards Council (PCI SSC).

The standard exists for one reason: to protect cardholder data from theft and fraud. Every year, payment card fraud costs businesses and consumers billions of pounds. PCI DSS sets a baseline of security controls that any organisation handling card data must follow.

The current version is PCI DSS 4.0.1, which became mandatory in April 2025, replacing the earlier 3.2.1 framework. If your business has not updated its compliance programme for 4.0.1, you need to act now — the transition period is over.

Non-compliance carries real consequences. Your acquiring bank can levy fines of up to £100,000 per month. If a breach occurs while you are non-compliant, you face additional penalties, legal liability, and the cost of forensic investigations. Worse, you could lose the ability to accept card payments altogether.

The Four Merchant Levels

Not every business faces the same compliance burden. The card brands assign merchants to one of four levels based on annual transaction volume:

Most small and medium-sized businesses fall into Level 3 or Level 4. That means you will not need an expensive on-site audit. Instead, you complete a Self-Assessment Questionnaire (SAQ) each year and submit an Attestation of Compliance (AoC) to your acquiring bank.

Which SAQ Applies to You?

The SAQ you need to complete depends on how you accept payments and how much cardholder data your systems touch. There are several versions:

• SAQ A — For merchants that have fully outsourced all cardholder data functions to a PCI-compliant third party. The simplest questionnaire, with around 30 questions.
• SAQ A-EP — For e-commerce merchants that partially outsource payment processing but whose website can affect the security of the transaction.
• SAQ B — For merchants using standalone, dial-out payment terminals with no electronic cardholder data storage.
• SAQ C — For merchants with payment application systems connected to the internet but no electronic cardholder data storage.
• SAQ C-VT — For merchants who manually enter a single transaction at a time via a virtual terminal on an internet-connected device.
• SAQ D — The full questionnaire with over 300 questions. Required for any merchant that does not fit the criteria for the other SAQ types, or that stores cardholder data electronically.

The difference between SAQ A (around 30 questions) and SAQ D (over 300) is enormous. Reducing your PCI scope — so you qualify for a simpler SAQ — can save weeks of work and thousands of pounds each year.

The 12 PCI DSS Requirements

PCI DSS is built around 12 core requirements, grouped into six objectives. Here is a plain-English summary of each:

Build and Maintain a Secure Network and Systems

1. Install and maintain network security controls — Use firewalls (or their modern equivalents) to protect cardholder data environments. PCI DSS 4.0.1 broadened this from traditional firewalls to include any network security controls.
2. Apply secure configurations — Do not use vendor-supplied defaults for system passwords or security settings. Change them before deploying any system.

Protect Account Data

3. Protect stored account data — If you must store cardholder data, encrypt it and limit retention to the minimum necessary. Better yet, do not store it at all.
4. Encrypt cardholder data in transit — Use strong encryption (such as TLS 1.2 or higher) whenever card data is sent across open or public networks.

Maintain a Vulnerability Management Programme

5. Protect against malware — Deploy and regularly update anti-malware software on all systems commonly affected by malicious software.
6. Develop and maintain secure systems — Patch vulnerabilities promptly. Under 4.0.1, this means applying critical security patches within one month of release.

Implement Strong Access Controls

7. Restrict access to cardholder data by business need — Only people whose job requires it should have access. Everyone else is locked out.
8. Identify users and authenticate access — Every person with access must have a unique ID. Multi-factor authentication (MFA) is now required for all access to the cardholder data environment under 4.0.1.
9. Restrict physical access to cardholder data — Lock down server rooms, workstations, and any physical media containing card data.

Regularly Monitor and Test Networks

10. Log and monitor all access — Track who accessed what, when, and from where. Automated log review mechanisms are now required under 4.0.1.
11. Test security systems regularly — Run vulnerability scans quarterly and penetration tests annually. Internal scans must be authenticated under the updated standard.

Maintain an Information Security Policy

12. Maintain a policy that addresses information security — Document your security policies, ensure all staff are aware of them, and review them at least annually. Under 4.0.1, targeted risk analyses are required for several controls.

For a deeper look at each requirement, see our PCI DSS compliance resource page.

How Telephone Payments Create PCI Scope

This is where many businesses get caught out. If your staff take card payments over the telephone — which is extremely common in contact centres, hospitality, professional services, and public sector organisations — your telephony environment is in PCI scope.

Here is why: when a customer reads their card number aloud, it can be heard by the agent, picked up by call recording systems, and captured in screen recordings or CRM logs. The dual-tone multi-frequency (DTMF) tones generated when a customer enters their card number on a telephone keypad can also be recorded and decoded.

This means your call recording platform, your telephony infrastructure, your agents' workstations, and potentially your entire network are all in scope for PCI DSS compliance. That is a huge footprint to secure, audit, and maintain.

Common approaches that do not solve the problem include:

• Pausing call recordings — Relies on the agent pressing a button at the right moment. Human error is inevitable, and many compliance assessors will not accept this as a reliable control.
• Agent-entered card details — The agent still hears and handles the card number, keeping your environment in scope.
• Asking customers to use a separate IVR — Creates a disjointed experience where the customer is transferred away from the agent, increasing call times and abandonment rates.

How to Reduce Your PCI Scope

The most effective strategy for PCI compliance is not to harden every system in your environment. It is to shrink the scope so that fewer systems need to be compliant in the first place. There are three key technologies that achieve this:

DTMF Masking

DTMF masking (also called DTMF suppression) intercepts the tones generated when a customer enters their card number on their telephone keypad. The tones are replaced with flat, monotone sounds in real time, so the agent hears only uniform beeps and call recordings capture nothing usable.

The card data is routed directly to the payment processor without ever entering your telephony or IT environment. The agent stays on the line, guiding the customer through the payment — but never hears or sees the card number.

This is the single most effective way to descope telephone payment environments from PCI DSS.

Tokenisation

Tokenisation replaces sensitive card data with a non-sensitive substitute — a token — that has no exploitable value. The real card number is stored securely by the payment processor, and your systems only ever see the token.

If a breach occurs, the attacker gets a list of meaningless tokens. Combined with DTMF masking, tokenisation ensures that card data never enters your environment at any point in the transaction.

Channel Separation

Channel separation is the architectural principle behind both technologies. By creating a separate, secure channel for card data that is completely isolated from your business systems, you remove those systems from PCI scope entirely.

With channel separation in place, your agents, workstations, CRM, call recordings, and network infrastructure are all out of scope. Your compliance burden drops dramatically, and you may qualify for SAQ A instead of the much more demanding SAQ D.

How Paytia Makes Compliance Simple

Paytia provides a cloud-based telephone payment solution that uses DTMF suppression and channel separation to remove your entire telephony environment from PCI scope.

Here is how it works:

1. The agent initiates a payment — During a live call, the agent opens the Paytia payment screen (which integrates with your existing telephony and CRM systems).
2. The customer enters their card details — Using their telephone keypad. The DTMF tones are masked in real time — the agent hears only flat tones and cannot identify the card number.
3. Card data is routed securely — Directly from the telephone network to the payment processor via Paytia's PCI DSS Level 1 certified platform. The data never touches your systems.
4. Payment is confirmed — The agent sees the payment result on screen and can continue the conversation with the customer. The entire process takes seconds.

The result: your contact centre is descoped from PCI DSS. Your agents stay on the line (so customer experience is unaffected), your call recordings continue uninterrupted (so you maintain quality assurance and regulatory compliance), and your annual SAQ is dramatically simpler.

Paytia is certified to PCI DSS Level 1 — the highest level of compliance — so you can rely on our platform to handle card data securely. Take a look at our product tour to see the solution in action.

Common Compliance Mistakes

After working with hundreds of businesses on payment security, we see the same mistakes repeatedly. Avoid these:

1. Assuming Compliance Is Optional for Small Businesses

PCI DSS applies to every business that accepts card payments, regardless of size. Level 4 merchants still need to complete an SAQ and may face fines for non-compliance. Your acquiring bank sets the enforcement terms.

2. Relying on Pause-and-Resume for Call Recordings

Manual pause-and-resume is not a reliable compliance control. Agents forget, the timing slips, and card data ends up in recordings. Automated DTMF masking eliminates this risk entirely.

3. Storing Card Data You Do Not Need

The safest card data is the card data you never store. If your systems hold card numbers, expiry dates, or CVVs — even temporarily — they are in scope. Use tokenisation and ensure your payment processes do not leave card data in logs, emails, or databases.

4. Treating Compliance as a One-Off Exercise

PCI DSS compliance is continuous, not annual. You need ongoing monitoring, regular vulnerability scans, staff training, and policy reviews. Your SAQ or audit validates a point in time — but you must maintain compliance every day of the year.

5. Ignoring Telephone Payments

Many businesses focus their PCI compliance efforts on e-commerce and forget about the telephone channel. If agents handle card data verbally, your telephony environment is in scope. This is often the largest and most expensive part of a compliance programme to manage.

6. Not Validating Third-Party Compliance

If you outsource payment processing, you must verify that your provider is PCI DSS compliant and obtain their Attestation of Compliance. Their compliance does not automatically cover your obligations — you are still responsible for securing your own environment.

PCI DSS 4.0.1: What Has Changed

PCI DSS 4.0.1 replaced version 3.2.1 as the mandatory standard in April 2025. If you have not yet updated your compliance programme, here are the key changes you need to know:

Customised Approach

Version 4.0.1 introduced the "customised approach" as an alternative to the traditional "defined approach." Instead of implementing controls exactly as prescribed, organisations can design their own controls — provided they demonstrably meet the security objective of each requirement. This is mainly relevant for large, mature organisations with sophisticated security programmes.

Expanded Multi-Factor Authentication

MFA is now required for all access to the cardholder data environment, not just remote access. This affects any staff member who interacts with systems that process or store card data.

Targeted Risk Analysis

Several requirements now demand a documented, targeted risk analysis rather than a one-size-fits-all approach. You must assess risks specific to your environment and justify the frequency and scope of your security controls accordingly.

Enhanced Logging and Monitoring

Automated log review mechanisms are now required. Manual log reviews are no longer sufficient on their own. Your systems must be capable of detecting and alerting on anomalous activity.

Stronger Encryption Requirements

Outdated cryptographic protocols must be retired. TLS 1.0 and 1.1 are explicitly prohibited, and organisations must maintain an inventory of all cryptographic cipher suites and protocols in use.

Client-Side Security for E-Commerce

New requirements address threats from malicious scripts on payment pages (such as Magecart-style attacks). E-commerce merchants must implement controls to detect and prevent unauthorised script execution on their payment pages.

For most small and medium businesses, the practical impact of 4.0.1 is manageable — especially if you have already reduced your PCI scope through technologies like DTMF masking and tokenisation. The fewer systems in scope, the fewer of these enhanced requirements you need to implement.

Frequently Asked Questions

What happens if we are not PCI DSS compliant?

Your acquiring bank can impose monthly fines, increase your transaction fees, or terminate your merchant account. If a data breach occurs, you face additional penalties, forensic investigation costs, card replacement costs, and potential legal action from affected cardholders.

How long does it take to become compliant?

It depends on your current state and the scope of your cardholder data environment. A business that has already minimised its PCI scope (for example, by using Paytia for telephone payments) can typically complete SAQ A in a few hours. A business completing SAQ D for the first time may need several months of preparation.

Do we need PCI compliance if we use a third-party payment processor?

Yes. Using a third-party processor reduces your scope but does not eliminate your compliance obligation. You must still complete the appropriate SAQ and ensure your own environment meets the applicable requirements.

What is the difference between PCI DSS compliance and PCI DSS certification?

Compliance means meeting all applicable PCI DSS requirements. Certification (Level 1 validation) means a Qualified Security Assessor has audited your environment and confirmed compliance. Most small businesses demonstrate compliance through self-assessment rather than formal certification.

How does DTMF masking work with our existing telephony system?

Paytia's DTMF suppression solution works with any telephony platform — traditional PBX, hosted VoIP, Microsoft Teams, or mobile. It sits between the telephone network and your environment, intercepting and masking tones before they reach your infrastructure. No hardware installation is required.

Is PCI DSS compliance required by law?

PCI DSS is not a law — it is a contractual requirement imposed by the card brands through your acquiring bank. However, data protection laws such as the UK GDPR do require you to protect personal data (which includes payment card details) with appropriate technical measures. In practice, PCI DSS compliance is the accepted benchmark for meeting this obligation.

How often do we need to validate compliance?

You must complete your SAQ and submit your Attestation of Compliance annually. Quarterly network vulnerability scans are also required if applicable to your SAQ type. Internal security reviews and policy updates should happen on an ongoing basis.

What is the cost of PCI DSS compliance?

Costs vary enormously depending on scope. A Level 4 merchant qualifying for SAQ A might spend very little beyond the cost of their payment solution. A Level 1 merchant requiring a full QSA audit can expect to spend tens of thousands of pounds annually on assessments alone, plus the ongoing cost of maintaining all required security controls.

The most cost-effective approach is to minimise scope first, then comply with what remains. That is exactly what Paytia helps you do. See how it works.