PCI DSS Compliance for UK Businesses: A Practical Guide to v4.0

What Is PCI DSS and Who Enforces It?

PCI DSS is a private information security standard managed by the PCI Security Standards Council (PCI SSC), a body established in 2006 by Visa, Mastercard, American Express, Discover, and JCB. It is not a law. No government agency enforces it or issues fines for non-compliance. Your contract with your acquiring bank enforces it.

Signing up with an acquirer to accept card payments means agreeing to comply with PCI DSS as a condition of that agreement. Acquirers include Barclaycard, Worldpay, Lloyds Cardnet, Stripe, Square, and SumUp. Each acquirer sets its own compliance programme: how often you must submit documentation, whether they require a validated Report on Compliance (RoC) or an Attestation of Compliance (AOC), and how they handle non-compliant merchants.

Merchant levels determine which validation route applies to you:

• Level 1: More than 6 million Visa or Mastercard transactions per year, or any merchant that has suffered a qualifying breach. Requires an annual on-site audit by a Qualified Security Assessor (QSA) and quarterly network scans by an Approved Scanning Vendor (ASV).
• Level 2: 1 million to 6 million transactions per year. Annual Self-Assessment Questionnaire (SAQ) plus quarterly ASV scans.
• Level 3: 20,000 to 1 million e-commerce transactions per year. Annual SAQ plus quarterly ASV scans.
• Level 4: Fewer than 20,000 e-commerce transactions, or fewer than 1 million total transactions. Annual SAQ; ASV scan may be required at the acquirer's discretion.

Most UK SMEs are Level 3 or Level 4. Your acquirer determines your level based on the transaction volumes you report.

The 12 PCI DSS Requirements at a Glance

The PCI SSC built the standard around 12 top-level requirements, each containing specific sub-requirements. Together they form a security framework covering network controls, data protection, access management, monitoring, testing, and policy.

New in PCI DSS v4.0

PCI DSS v4.0 was published in March 2022. The PCI SSC retired version 3.2.1 on 31 March 2024, making v4.0 the only active version from that date. If your last assessment was against v3.2.1, your next one must use v4.0.

The release introduced 64 new requirements. Thirteen took effect on adoption. The PCI SSC classified the remaining 51 as best practices until 31 March 2025, at which point they became mandatory. If you are assessing now, all 64 apply.

The most significant changes are:

• Customised approach: v4.0 introduces a second compliance path alongside the traditional defined approach. The customised approach lets mature organisations design their own controls to meet the stated security objective of each requirement, rather than following the prescriptive implementation. In practice, this option requires substantial documentation and is most suitable for organisations with experienced security teams. Most UK SMEs will continue to use the defined approach.
• MFA expanded: PCI DSS v4.0 now requires multi-factor authentication for all access into the cardholder data environment. Local and remote access both require MFA. This is a hard requirement.
• E-commerce script security (Requirements 6.4.3 and 11.6.1): These requirements target the Magecart attack pattern, where criminals inject malicious scripts into payment pages to capture card data as customers type it. You must maintain an inventory of every script loaded on payment pages, document a business justification for each, and use integrity-checking mechanisms (such as subresource integrity hashes) to detect unauthorised modifications. If your checkout page loads third-party scripts for analytics, customer support, or A/B testing, these requirements apply to you. Review every loaded script before your next assessment.
• Password complexity: The minimum password length for accounts on in-scope systems increased from 7 to 12 characters.
• Targeted risk analysis: You must now justify the frequency of several periodic activities (such as access reviews and security scans) through a documented risk analysis specific to your environment, rather than following a fixed schedule set out in the standard.

Which SAQ Applies to Your Business?

A Self-Assessment Questionnaire (SAQ) is a validation tool that allows eligible merchants to assess their own PCI DSS compliance without a full QSA audit. There are nine SAQ types. The right one depends on how your business accepts and processes card payments. Choosing the wrong SAQ type is a compliance failure in itself.

The most common SAQ types for UK merchants are:

• SAQ A: For card-not-present merchants that fully outsource all cardholder data functions to PCI DSS-compliant third parties, with no electronic storage, processing, or transmission of card data on your own systems or premises. Your website must redirect customers to a hosted payment page or use an embedded iframe from the payment provider. Stripe Checkout, PayPal's standard checkout, and similar fully hosted pages qualify as long as card data never passes through your own systems. SAQ A covers 22 requirements and is the simplest path available. It is the most common SAQ type for UK e-commerce SMEs.
• SAQ A-EP: For e-commerce merchants whose website redirects to a third-party payment page but whose website is involved in the payment flow beyond a simple link or redirect, for example by using JavaScript that interacts with the payment form. The v4.0 script security requirements (6.4.3 and 11.6.1) apply here, making this SAQ more demanding than SAQ A.
• SAQ B: For merchants using imprint machines or standalone dial-up terminals with no internet connection and no electronic storage of cardholder data. Applies to some bricks-and-mortar retail environments. 41 requirements.
• SAQ B-IP: For merchants using IP-connected payment terminals (such as a countertop chip-and-pin device on a broadband or Wi-Fi connection) that are not virtualised and do not store cardholder data. 83 requirements.
• SAQ C: For merchants with a payment application system connected to the internet that does not store cardholder data electronically. Covers situations where a POS application or custom payment software is used. 160 requirements.
• SAQ D: The most comprehensive SAQ, covering all merchants and service providers not eligible for A through C-VT. More than 300 requirements, spanning the full set of PCI DSS controls.

Your acquiring bank confirms which SAQ type applies to your environment. If you are unsure, ask them before completing any self-assessment. Submitting an SAQ that does not match your actual payment environment creates compliance exposure rather than reducing it.

Scoping: How to Reduce What You Have to Protect

The cardholder data environment (CDE) is defined as every system component that stores, processes, or transmits cardholder data, plus every system that can connect to or influence the security of those components. Everything in scope requires documentation, controls, and testing. The smaller your CDE, the less you have to manage and the lower your compliance burden.

Four strategies reduce scope:

• Hosted payment pages: Card data entered on a payment page hosted by a compliant payment provider never passes through your own servers or network. Your CDE shrinks to near zero. For most UK e-commerce merchants, this is the single biggest reduction available.
• Network segmentation: If you operate systems that must be in scope, isolate them from the rest of your network using a properly configured firewall. Systems on the other side of that firewall that have no route to in-scope systems fall out of scope. Without documented segmentation, any system that could reach an in-scope system must itself be treated as in scope.
• Tokenisation: For recurring billing, replace stored card numbers (PANs) with tokens issued by your payment provider. The token is meaningless to anyone who intercepts it. Only the token vault, maintained by the payment provider, needs to be in scope. Your systems hold the token reference.
• Do not store what you do not need: Avoid card data storage beyond what a specific business purpose requires. You must never store CVV2 and CVC2 codes after authorisation, even in encrypted form. Holding card data you do not need extends your scope and increases your liability without providing any business benefit.

Key Dates and What to Do Next

PCI DSS v4.0 has been the only active version since 31 March 2024. The 51 requirements the PCI SSC listed as best practices became mandatory from 31 March 2025. There are no further retirement or transition dates pending at the time of writing.

If you are behind on compliance or approaching a deadline set by your acquirer, follow this sequence:

1. Confirm your merchant level with your acquiring bank and establish which SAQ type applies to your payment environment.
2. Complete a gap assessment against the applicable SAQ to identify which controls you fail or lack evidence for.
3. Remediate failing controls before completing and submitting your SAQ.
4. If your SAQ type requires it, commission an Approved Scanning Vendor (ASV) to conduct a quarterly external network scan. Your compliance submission requires the first clean scan result.
5. Submit your Attestation of Compliance (AOC) to your acquirer within their stated timeframe.

If you have not completed a PCI DSS assessment before, start with a gap assessment against your relevant SAQ. It shows where you stand, what needs fixing, and what the remediation effort looks like before you commit resources.

How Cyvra Supports PCI DSS Compliance

Cyvra works with UK merchants and service providers at every stage of PCI DSS compliance. You may arrive with a compliance deadline from your acquirer, or be expanding your payment channels and wanting to understand the PCI DSS implications before you build.

A typical engagement covers your merchant level and the correct SAQ type, a gap assessment, a remediation plan, control implementation support, and the AOC submission for your acquirer.

If you are considering a change to your payment infrastructure, for example moving from a custom payment form to a hosted checkout page, Cyvra assesses the PCI DSS scope impact before the project starts. Scoping decisions at the architecture stage cost far less than fixing compliance gaps after systems are built.

If your acquirer has requested compliance documentation, or you want to understand your current position before your next assessment window, get in touch. Start with a short conversation about your payment environment.