PCI DSS — the Payment Card Industry Data Security Standard — is the security framework that governs how organisations handle cardholder data. If your business stores, processes, or transmits card data, you must comply. If your software or service touches card data on behalf of other businesses, you are a service provider and face stricter requirements.
This guide covers what PCI compliance means in practice for both merchants and service providers, the different compliance levels, the SAQ types, what compliance costs, and practical ways to reduce your PCI scope.
What Is PCI DSS?
PCI DSS is maintained by the PCI Security Standards Council (PCI SSC), which was founded by Visa, Mastercard, American Express, Discover, and JCB. The standard defines 12 core requirements across six categories, all designed to protect cardholder data from theft and misuse.
The 12 requirements cover:
Network security — firewalls, secure configurations, no vendor-supplied default passwords
Cardholder data protection — encryption of stored data and data in transit
Vulnerability management — antivirus, secure development practices, regular patching
Access control — role-based access, unique IDs for each user, restricted physical access
Monitoring and testing — logging, regular security testing, penetration testing
Security policies — documented policies covering all personnel
The current version is PCI DSS v4.0.1, which became mandatory in March 2025. Version 4.0 introduced significant changes including a customised approach to validation, expanded multi-factor authentication requirements, and new e-commerce anti-skimming protections.
Service Provider vs Merchant: Why It Matters
PCI DSS categorises organisations into two groups, each with different compliance obligations:
Merchants are businesses that accept card payments for goods or services. A retailer, an online shop, a restaurant — any entity that takes payment from cardholders. Merchants are assessed based on their annual transaction volume across all channels.
Service providers are entities that store, process, or transmit cardholder data on behalf of other businesses — or that could affect the security of cardholder data. This includes payment gateways, payment processors, hosting providers, managed security services, and software platforms that handle card data for their customers.
The distinction matters because service providers face higher compliance requirements at every level. A service provider processing 300,000 transactions requires the same Level 1 assessment (including a Qualified Security Assessor audit) that a merchant would not face until 6 million transactions.
PCI DSS Service Provider Levels
Service providers are classified into two levels based on the number of transactions they store, process, or transmit annually:
Level | Transaction Volume | Validation Requirements |
|---|---|---|
Level 1 | 300,000+ transactions/year | Annual Report on Compliance (ROC) by a QSA, quarterly network scans by an ASV, annual penetration test |
Level 2 | Fewer than 300,000 transactions/year | Annual Self-Assessment Questionnaire (SAQ-D), quarterly ASV scans, annual penetration test |
Level 1 service providers must undergo an on-site assessment by a Qualified Security Assessor (QSA) — an independent security firm accredited by the PCI SSC. This is the most rigorous form of PCI validation and typically costs £50,000-£250,000+ depending on the complexity of the environment.
Level 2 service providers can self-assess using SAQ-D (the most comprehensive self-assessment questionnaire), but must still complete quarterly network vulnerability scans by an Approved Scanning Vendor (ASV) and conduct annual penetration testing.
Important: Card brands (Visa, Mastercard) can override these thresholds. A service provider that has experienced a data breach, for example, may be reclassified as Level 1 regardless of volume.
PCI DSS Merchant Levels
Merchants are classified into four levels. The thresholds vary slightly between card brands, but Visa's widely-used definitions are:
Level | Annual Visa Transactions | Validation Requirements |
|---|---|---|
Level 1 | 6 million+ | Annual ROC by QSA, quarterly ASV scans, attestation of compliance |
Level 2 | 1-6 million | Annual SAQ, quarterly ASV scans, attestation of compliance |
Level 3 | 20,000-1 million (e-commerce only) | Annual SAQ, quarterly ASV scans, attestation of compliance |
Level 4 | Fewer than 20,000 (e-commerce) or up to 1 million (other) | Annual SAQ, quarterly ASV scans (recommended), attestation of compliance |
Most small and mid-sized businesses fall into Level 4. The compliance burden at this level is relatively light — a Self-Assessment Questionnaire (the specific type depends on how you accept payments) and potentially quarterly vulnerability scans.
SAQ Types: Which One Applies to You?
The Self-Assessment Questionnaire (SAQ) comes in several variants, each designed for a different payment acceptance method. Using the right SAQ is critical — it determines how many controls you must validate.
SAQ Type | Applies To | Number of Questions | Typical Use Case |
|---|---|---|---|
SAQ A | Card-not-present, all cardholder data functions outsourced | 22 | E-commerce using a hosted payment page (e.g., Stripe Checkout, PayPal hosted) |
SAQ A-EP | E-commerce merchants with websites that affect transaction security | 191 | Custom checkout that redirects to payment provider, or uses iframes |
SAQ B | Imprint-only or standalone dial-out terminals | 41 | Standalone card terminal with no electronic storage |
SAQ B-IP | Standalone PTS-approved terminals connected via IP | 82 | Card terminal connected to network but isolated from other systems |
SAQ C | Payment application systems connected to the internet | 160 | POS system connected to internet, no electronic card data storage |
SAQ C-VT | Virtual terminal (web-based, no electronic card data storage) | 79 | Agent types card number into web-based virtual terminal |
SAQ D | All other merchants and all service providers | 329 | Any scenario not covered by other SAQ types |
SAQ P2PE | Merchants using validated P2PE solution | 33 | Hardware-encrypted terminals (most restrictive device requirements) |
The key insight is the dramatic difference in scope. SAQ A requires validating 22 controls. SAQ D requires 329. The choice of how you accept payments — specifically, whether cardholder data ever touches your systems — determines which SAQ applies and therefore how much compliance work you face.
PCI Compliance Costs
PCI compliance costs vary enormously based on your level, your payment acceptance method, and the current state of your security infrastructure:
Cost Component | Typical Range | Who Pays |
|---|---|---|
QSA assessment (Level 1) | £50,000-£250,000+/year | Level 1 merchants and service providers |
ASV quarterly scans | £500-£5,000/year | All levels (except some Level 4 merchants) |
Penetration testing | £5,000-£50,000/year | Level 1 and Level 2 |
SAQ completion | £0 (self-service) to £10,000 (consultant-assisted) | Level 2-4 merchants, Level 2 service providers |
Remediation | £10,000-£500,000+ | Any organisation failing assessment |
PCI compliance software/tools | £1,000-£20,000/year | All levels |
Staff training | £500-£5,000/year | All levels |
For service providers, costs are consistently at the higher end. Level 1 service providers typically spend £100,000-£300,000 annually on compliance activities, plus the ongoing cost of maintaining compliant infrastructure, training, and monitoring.
For merchants, the cost depends almost entirely on scope. A merchant using SAQ A (hosted payment page, no cardholder data on their systems) might spend £1,000-£5,000 per year. A merchant using SAQ D could spend ten times that.
How to Reduce Your PCI Scope
PCI scope reduction is the single most effective way to lower compliance costs and risk. The principle is simple: if cardholder data never touches your systems, the systems are out of scope.
Practical scope reduction strategies:
1. Use a hosted payment page or iframe
The most effective scope reduction for e-commerce. Instead of collecting card details on your own server, redirect customers to a PCI-compliant payment page hosted by your PSP (Stripe Checkout, Adyen Drop-In, etc.). Your server never sees card numbers. This drops you from SAQ D (329 controls) to SAQ A (22 controls).
2. Use tokenisation
Replace card numbers with tokens — random strings that have no value if stolen. Your payment provider stores the actual card data. Your systems only store tokens. This is essential for recurring billing and returning customer scenarios where you need to charge the same card again without collecting details each time. For more on how tokenisation works in the payment chain, see our glossary entry on tokenisation.
3. Isolate payment systems
If you must handle cardholder data (e.g., for a call centre or virtual terminal), isolate the payment systems from the rest of your network. Use network segmentation — firewalls, VLANs, separate subnets — so that a breach in one system does not expose cardholder data. Proper segmentation can reduce the number of in-scope systems from hundreds to a handful.
4. Use DTMF masking for phone payments
Contact centres that take card payments over the phone traditionally require agents to hear (and potentially record) card numbers — putting the entire call centre infrastructure in PCI scope. DTMF masking lets callers enter card numbers on their phone keypad, with the tones captured and routed directly to a payment provider. The agent never hears or sees the card data. This can reduce a contact centre from SAQ D to SAQ A scope. See our detailed guide on PCI-compliant contact centre payments.
5. Outsource to a Level 1 service provider
The most comprehensive scope reduction: outsource payment processing, tokenisation, and cardholder data storage entirely to a PCI DSS Level 1 certified service provider. Your systems never touch cardholder data. Your PCI assessment becomes a matter of confirming that you have outsourced correctly and that your service provider is compliant.
PCI DSS v4.0: What Changed
PCI DSS v4.0 (effective March 2025) introduced several significant changes:
Customised approach — organisations can now design their own controls to meet security objectives, rather than following prescriptive requirements. This gives mature security teams more flexibility but requires documented evidence that the custom control achieves the stated objective.
Expanded MFA — multi-factor authentication is now required for all access into the cardholder data environment, not just remote access. This affects internal network access as well.
E-commerce script management — new requirements for managing and monitoring scripts (JavaScript) on payment pages. This targets Magecart-style attacks that inject malicious scripts into checkout pages.
Targeted risk analysis — organisations must conduct targeted risk analyses for specific requirements, documenting why their chosen approach is appropriate for their environment.
Authentication changes — passwords must now be at least 12 characters (up from 7). Service accounts must have strong authentication and be reviewed regularly.
Automated log review — manual log review is no longer sufficient for most environments. Automated mechanisms are required to detect anomalies.
For service providers, v4.0 also introduced new requirements around detecting and reporting failures of critical security controls, and confirming PCI DSS scope at least every 12 months.
PCI Compliance for Software Platforms
If you are a software platform — SaaS, marketplace, or vertical software — that handles payments for your customers, PCI compliance has specific implications:
You are almost certainly a service provider — if your platform processes, transmits, or stores cardholder data on behalf of your customers, you fall under the service provider classification regardless of transaction volume.
Your customers inherit your scope — if your platform handles card data insecurely, your customers' PCI assessments are affected. Conversely, if your platform is Level 1 certified with proper tokenisation, your customers' scope is significantly reduced.
Multi-tenant adds complexity — platforms serving multiple merchants need to demonstrate that one customer's cardholder data cannot be accessed by another. This requires logical or physical separation, access controls, and monitoring per tenant.
Multiple PSPs multiply scope — each payment processor integration is an additional cardholder data flow that must be documented, secured, and assessed. Platforms using multiple PSPs face broader scope than those using a single processor — unless payments are routed through an intermediary that consolidates the PCI scope.
Voice and phone channels expand scope further — if your platform supports phone payments, the call recording, telephony, and agent desktop infrastructure all enter PCI scope. See our guide on voice payments and PCI for the architectural options.
The platform PCI architecture decision often comes down to build vs. buy. Building PCI-compliant payment infrastructure in-house means taking on Level 1 service provider obligations — the QSA assessment, the penetration testing, the ongoing monitoring, and the engineering team to maintain it. Using a PCI-certified payment layer means the compliance surface is outsourced, and the platform operates at SAQ-A scope.
Frequently Asked Questions
What is the difference between PCI compliant and PCI certified?
PCI compliant means an organisation meets the PCI DSS requirements. PCI certified (or more precisely, "validated") means the compliance has been independently verified — either by a QSA audit (Level 1) or through a completed SAQ with an Attestation of Compliance (other levels). Card brands require validation, not just a claim of compliance.
How long does PCI compliance take?
For a small merchant using SAQ A, initial compliance can be achieved in days. For a Level 1 service provider, the first QSA assessment typically takes 3-6 months of preparation plus 2-4 weeks for the on-site audit. Annual recertification is faster but still requires several months of preparation and evidence gathering.
What happens if you are not PCI compliant?
Non-compliance can result in fines from card brands (£5,000-£100,000+ per month), increased transaction fees, mandatory forensic investigations after a breach (£20,000-£100,000+), and loss of the ability to accept card payments. In practice, acquiring banks enforce compliance by requiring merchants and service providers to submit attestations of compliance.
Does using a payment gateway make me PCI compliant?
Using a PCI-compliant payment gateway reduces your scope — potentially to SAQ A (22 controls) — but does not make you automatically compliant. You still need to complete the appropriate SAQ, ensure your integration is secure, and submit your Attestation of Compliance. The gateway handles the hardest part (storing and processing card data), but you must still validate your own compliance.
Can I avoid PCI compliance entirely?
No. If you accept card payments in any form — online, in person, or over the phone — you must comply with PCI DSS. However, you can minimise your compliance burden by choosing payment acceptance methods that keep cardholder data off your systems entirely (SAQ A scope). This is the closest to "avoiding" PCI compliance while still accepting cards.
Reduce Your PCI Scope With the Right Payment Architecture
PCI compliance is a cost of accepting card payments — but the size of that cost is largely determined by your payment architecture. Organisations that handle cardholder data directly face SAQ D (329 controls), annual penetration tests, and ongoing infrastructure costs. Organisations that outsource cardholder data handling to a Level 1 certified provider face SAQ A (22 controls) and significantly lower ongoing costs.
Shuttle is PCI DSS Level 1 certified, ISO 27001 certified, and SOC 2 compliant. Platforms that connect via Shuttle never handle cardholder data directly — payments are processed through Shuttle's secure infrastructure, reducing the platform's PCI scope to SAQ-A regardless of how many PSPs, channels, or markets are involved.
See how Shuttle handles PCI compliance for platforms · Book a discovery call