PCI compliance refers to adherence to the Payment Card Industry Data Security Standard (PCI DSS), a set of security requirements that applies to any organisation that stores, processes, or transmits payment card data. In the UK, PCI compliance is not a statutory legal obligation in the way that GDPR is, but it is a contractual requirement imposed by card schemes including Visa, Mastercard, American Express, and Discover on every business that accepts card payments.
Failing to comply with PCI DSS does not result in a fine from a regulator. It results in penalties from your acquiring bank, potential loss of the ability to accept card payments, and significantly increased liability if a data breach occurs involving cardholder data.
This guide explains what PCI DSS is, who it applies to in the UK, what the compliance levels mean, what the 12 core requirements cover, and what happens if you do not comply.
Key Definitions
| Term | Definition |
|---|---|
| PCI DSS | Payment Card Industry Data Security Standard. A set of security requirements developed and maintained by the PCI Security Standards Council |
| PCI SSC | Payment Card Industry Security Standards Council. The body that develops and maintains PCI DSS, founded by Visa, Mastercard, American Express, Discover, and JCB |
| Cardholder data | The primary account number (PAN) and any associated data including cardholder name, expiry date, and service code |
| Sensitive authentication data | Full track data, card verification codes (CVV/CVC), and PINs. Must never be stored after authorisation |
| Acquirer | The bank or payment processor that processes card transactions on behalf of a merchant |
| Merchant | Any business that accepts payment cards as a method of payment |
| Service provider | Any business that stores, processes, or transmits cardholder data on behalf of merchants, or that provides services that control or could impact the security of cardholder data |
| QSA | Qualified Security Assessor. An organisation certified by the PCI SSC to conduct PCI DSS assessments |
| SAQ | Self-Assessment Questionnaire. A self-validation tool for merchants and service providers that do not require a QSA assessment |
| ROC | Report on Compliance. A formal assessment report produced by a QSA for Level 1 merchants and service providers |
| AOC | Attestation of Compliance. A document signed by the merchant or service provider and, where applicable, the QSA, confirming PCI DSS compliance status |
Who Does PCI Compliance Apply To in the UK
PCI DSS applies to every organisation in the UK that accepts, processes, stores, or transmits payment card data, regardless of size, industry, or the number of transactions processed. There is no minimum threshold below which PCI DSS does not apply.
The obligation to comply is imposed contractually, not by statute. When a business signs up with an acquiring bank or payment processor to accept card payments, it agrees to comply with PCI DSS as a condition of that agreement. The card schemes, Visa and Mastercard principally, impose PCI DSS requirements on acquirers, who pass them down to merchants through their merchant agreements.
| Type of organisation | PCI DSS applies? |
|---|---|
| Retail businesses accepting card payments in store | Yes |
| E-commerce businesses processing card payments online | Yes |
| Businesses using third-party payment processors such as Stripe or Square | Yes, though scope may be significantly reduced |
| Payment processors and gateways | Yes, as service providers |
| Software companies building payment applications | Yes, as service providers |
| Businesses that only accept cash | No |
| Businesses that use payment terminals provided and managed entirely by their acquirer | Yes, though scope may be reduced |
PCI DSS Compliance Levels
The PCI SSC divides merchants and service providers into compliance levels based on annual transaction volumes. The level determines the validation requirements: what documents you must produce and whether you need an independent assessment by a Qualified Security Assessor.
Merchant Levels
| Level | Transaction volume per year | Validation requirement |
|---|---|---|
| Level 1 | More than 6 million Visa or Mastercard transactions | Annual Report on Compliance (ROC) by a QSA. Quarterly network scan by an Approved Scanning Vendor (ASV) |
| Level 2 | 1 million to 6 million transactions | Annual Self-Assessment Questionnaire (SAQ). Quarterly network scan by an ASV |
| Level 3 | 20,000 to 1 million e-commerce transactions | Annual SAQ. Quarterly network scan by an ASV |
| Level 4 | Fewer than 20,000 e-commerce transactions, or up to 1 million other transactions | Annual SAQ. Quarterly network scan by an ASV recommended |
Service Provider Levels
| Level | Transaction volume per year | Validation requirement |
|---|---|---|
| Level 1 | More than 300,000 transactions annually | Annual ROC by a QSA. Quarterly ASV scan |
| Level 2 | Fewer than 300,000 transactions annually | Annual SAQ. Quarterly ASV scan |
Individual card schemes and acquirers may impose stricter requirements than the baseline levels above. A business that has experienced a data breach involving cardholder data may be reclassified to Level 1 regardless of its transaction volume.
The 12 PCI DSS Requirements
PCI DSS version 4.0.1, the current version as of August 2026, organises its security requirements into 12 high-level requirements across six control objectives.
Control Objective 1: Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain network security controls
Implement firewalls and other network security controls to protect cardholder data. Document network security policies and review them at least once every 12 months. Restrict inbound and outbound traffic to only what is necessary.
Requirement 2: Apply secure configurations to all system components
Change all vendor-supplied default passwords before installing systems on the network. Develop configuration standards for all system components and apply them consistently. Remove or disable all unnecessary functionality.
Control Objective 2: Protect Account Data
Requirement 3: Protect stored account data
Store only the cardholder data that is necessary. Never store sensitive authentication data after authorisation. Protect stored primary account numbers using strong cryptography. Document and implement a data retention and disposal policy.
Requirement 4: Protect cardholder data with strong cryptography during transmission
Use strong cryptography and security protocols when transmitting cardholder data over open, public networks. Never send unprotected PANs by email, instant messaging, or any other insecure channel.
Control Objective 3: Maintain a Vulnerability Management Programme
Requirement 5: Protect all systems and networks from malicious software
Deploy anti-malware solutions on all systems that are commonly targeted by malicious software. Keep anti-malware current and generate audit logs. Protect systems against all types of malicious software.
Requirement 6: Develop and maintain secure systems and software
Protect systems and software from known vulnerabilities by installing applicable security patches. Apply patches to critical systems within one month of release. Develop software following secure development practices.
Control Objective 4: Implement Strong Access Control Measures
Requirement 7: Restrict access to system components and cardholder data by business need to know
Limit access to cardholder data to only those individuals whose job requires it. Implement an access control system that denies all access by default.
Requirement 8: Identify users and authenticate access to system components
Assign a unique ID to each person with computer access. Implement multi-factor authentication for all access into the cardholder data environment. Manage passwords and authentication credentials according to defined standards.
Requirement 9: Restrict physical access to cardholder data
Use appropriate controls to limit physical access to systems in the cardholder data environment. Control and monitor access to areas where cardholder data is present. Destroy media containing cardholder data when it is no longer needed.
Control Objective 5: Regularly Monitor and Test Networks
Requirement 10: Log and monitor all access to system components and cardholder data
Implement audit logs to track and monitor all access to network resources and cardholder data. Retain logs for at least 12 months, with at least three months immediately available for analysis. Review logs at least daily.
Requirement 11: Test security of systems and networks regularly
Test for unauthorised wireless access points quarterly. Run internal and external vulnerability scans at least quarterly and after any significant change. Conduct penetration testing at least annually.
Control Objective 6: Maintain an Information Security Policy
Requirement 12: Support information security with organisational policies and programmes
Establish, publish, maintain, and distribute a security policy. Develop and implement a risk assessment process. Implement a programme to manage service providers with whom cardholder data is shared. Maintain an incident response plan.
PCI DSS Requirements Summary Table
| Requirement | Control area | Validation frequency |
|---|---|---|
| 1: Network security controls | Network security | Annual review. Ongoing monitoring |
| 2: Secure configurations | System hardening | Annual review. Applied at implementation |
| 3: Protect stored data | Data protection | Annual review. Ongoing |
| 4: Encrypt transmission | Data in transit | Annual review. Ongoing |
| 5: Anti-malware | Vulnerability management | Annual review. Daily monitoring |
| 6: Secure development | Software security | Annual review. At each release |
| 7: Access restriction | Access control | Annual review. Ongoing |
| 8: User authentication | Identity management | Annual review. Ongoing |
| 9: Physical access | Physical security | Annual review. Ongoing |
| 10: Audit logging | Monitoring | Annual review. Daily log review |
| 11: Security testing | Testing | Quarterly scans. Annual penetration test |
| 12: Security policy | Governance | Annual review |
Reduced Scope: Using Third-Party Payment Processors
Many UK businesses, particularly smaller merchants, use third-party payment processors such as Stripe, Square, PayPal, Worldpay, or Adyen to handle card payments. Using a third-party processor does not remove PCI DSS obligations entirely, but it can significantly reduce the scope of what you are responsible for.
The key concept is the cardholder data environment (CDE): the systems, people, and processes that store, process, or transmit cardholder data. If a third-party processor handles all card data and your systems never touch raw card numbers, your CDE may be minimal or non-existent.
| Payment method | Scope impact |
|---|---|
| Hosted payment page (all card processing on provider’s systems) | Significantly reduced scope. SAQ A typically applies |
| Redirect to third-party checkout | Reduced scope. SAQ A or SAQ A-EP depending on integration |
| iFrame integration | Reduced scope subject to integration specifics |
| Direct API integration (card data passes through your servers) | Full scope. SAQ D or ROC depending on volume |
| Point of sale with provider-managed terminal | Reduced scope. SAQ B or SAQ B-IP typically applies |
Even where scope is reduced, you remain responsible for the security of your own systems and the integrity of the integration with the payment processor. A compromised website that redirects users to a fraudulent payment page is a PCI DSS compliance failure regardless of whether the payment processor itself is compliant.
Self-Assessment Questionnaires: Which One Applies
The SAQ is a self-validation tool for merchants and service providers below Level 1. Different SAQ types apply depending on how your business processes card payments.
| SAQ type | Who it applies to |
|---|---|
| SAQ A | Merchants that have outsourced all cardholder data functions to PCI DSS compliant third parties. Card-not-present merchants only |
| SAQ A-EP | E-commerce merchants with a website that does not directly receive cardholder data but could affect the security of the payment transaction |
| SAQ B | Merchants using only imprint machines or standalone dial-out terminals. No electronic cardholder data storage |
| SAQ B-IP | Merchants using standalone IP-connected payment terminals that do not store electronic cardholder data |
| SAQ C | Merchants with payment application systems connected to the internet. No electronic cardholder data storage |
| SAQ C-VT | Merchants using web-based virtual terminals. No electronic cardholder data storage |
| SAQ D (Merchant) | All other merchants not covered by SAQ A through C-VT |
| SAQ D (Service Provider) | All service providers eligible to complete an SAQ |
PCI Compliance and UK Law
PCI DSS is not a UK law. It is a contractual standard. However, it intersects with UK legal obligations in two important ways.
The UK GDPR and the Data Protection Act 2018 require organisations to implement appropriate technical and security measures to protect personal data. Payment card data, particularly where it is linked to an identifiable individual, is personal data.
A PCI DSS compliance programme that addresses the security of cardholder data will satisfy much of the technical security requirement under UK GDPR, though the two frameworks are not identical and both must be addressed independently.
The Financial Conduct Authority (FCA) regulates payment services in the UK under the Payment Services Regulations 2017. The FCA does not enforce PCI DSS directly, but it expects regulated payment service providers to implement appropriate security measures, and PCI DSS compliance is the recognised standard against which those measures are assessed.
Looking to comply with UK digital regulations? Explore our template pack.
What Happens If You Are Not PCI Compliant
Non-compliance consequences in the UK flow primarily from your contractual relationship with your acquirer and from the card scheme rules, not from a regulator.
| Consequence | How it arises |
|---|---|
| Monthly non-compliance fees | Your acquirer may charge monthly fees ranging from £10 to several hundred pounds per month for failure to complete PCI DSS validation |
| Increased transaction fees | Some acquirers apply higher processing fees to non-compliant merchants |
| Liability shift on fraud | In a card-present environment, liability for fraudulent transactions may shift to the merchant where the terminal does not support EMV chip and the merchant is non-compliant |
| Full liability for breach costs | In the event of a data breach involving cardholder data, a non-compliant merchant bears the full cost of the forensic investigation, card replacement costs, and any fines imposed by the card schemes. These costs can reach hundreds of thousands of pounds for a small merchant |
| Termination of card acceptance | In serious cases, card schemes can instruct acquirers to terminate a merchant’s ability to accept card payments |
| Reputational damage | Notification obligations under UK GDPR require you to inform the ICO within 72 hours of becoming aware of a personal data breach. A card data breach is likely to be a notifiable breach |
PCI DSS and the AI Act: An Emerging Intersection
Businesses incorporating AI into their payment processing workflows face an emerging compliance intersection. An AI system used for fraud detection in payment processing is likely to be classified as high-risk under Annex III of the EU AI Act, specifically under the category of AI systems used for credit decisions and access to essential financial services.
High-risk AI systems used in payment fraud detection must meet AI Act requirements including risk management under Article 9, data governance under Article 10, human oversight under Article 14, and technical documentation under Annex IV, in addition to PCI DSS security requirements. Both frameworks must be satisfied independently. A PCI DSS compliant fraud detection system is not automatically AI Act compliant, and vice versa.
Frequently Asked Questions
Is PCI compliance a legal requirement in the UK?
No. PCI DSS is a contractual requirement, not a statutory one. The obligation to comply arises from your merchant agreement with your acquiring bank, which incorporates the card scheme rules by reference.
However, the consequences of non-compliance, including liability for breach costs and loss of card acceptance rights, are commercially equivalent to a legal requirement for most businesses.
We are a very small business processing fewer than 20,000 card transactions a year. Do we still need to be PCI compliant?
Yes. PCI DSS applies to all merchants that accept card payments regardless of size or transaction volume. Level 4 merchants, the smallest category, must still complete an annual SAQ and are recommended to conduct quarterly vulnerability scans. Your acquirer will typically provide guidance on the specific requirements applicable to your business.
We use Stripe for all our card processing. Are we PCI compliant automatically?
No. Using Stripe reduces your scope significantly but does not remove all obligations. You must still complete the appropriate SAQ for your integration type, ensure your website has not been compromised in a way that could affect payment security, and maintain the security controls that fall within your reduced scope. Stripe’s PCI compliance covers Stripe’s systems. Your compliance covers yours.
What is the difference between PCI DSS 4.0 and previous versions?
PCI DSS version 4.0, released in March 2022 and mandatory since March 2024, introduced several significant changes including a customised approach option allowing organisations to meet the intent of requirements through alternative controls, enhanced multi-factor authentication requirements, increased focus on phishing protections, and new requirements for targeted risk analysis. Version 4.0.1, a limited revision, is the current operative version as of August 2026.
We had a card data breach two years ago. Do we face additional requirements?
Yes. A merchant or service provider that has experienced a data breach involving cardholder data may be reclassified to Level 1 by the card schemes, regardless of transaction volume. This means a full ROC by a QSA rather than a self-assessment SAQ. The card schemes and your acquirer will communicate the specific requirements applicable to your situation following a breach.
How long does it take to become PCI compliant?
This depends entirely on your current security posture, the complexity of your systems, and your compliance level. A small merchant using a hosted payment page with minimal internal systems may be able to complete an SAQ A in a matter of days. A large merchant or service provider undergoing a Level 1 ROC assessment may require six to twelve months of preparation before the assessment and remediation of findings afterwards.
Does PCI compliance expire?
PCI DSS compliance is not a one-time certification. It is an ongoing programme with annual validation requirements. Your SAQ or ROC must be renewed annually, vulnerability scans must be conducted quarterly, and penetration tests must be conducted at least annually. Compliance status lapses if validation is not renewed.
We operate both in the UK and the EU. Do different PCI DSS rules apply?
PCI DSS is a global standard administered by the PCI SSC. The same requirements apply regardless of where you operate. UK and EU acquirers both require PCI DSS compliance under the card scheme rules. There is no UK-specific or EU-specific version of PCI DSS. Post-Brexit, UK businesses operating in the EU face the same PCI DSS obligations as EU-established businesses.
This guide reflects PCI DSS version 4.0.1 and applicable UK regulatory guidance as of August 2026. It is published by European Compliance Suite for general informational purposes and does not constitute legal or security advice. Businesses should obtain advice specific to their payment processing environment, transaction volumes, and applicable acquirer requirements.