It’s one of the most common questions businesses ask – and they usually don’t ask it as early as they should. Instead, it tends to come up when something triggers it, such as a new payment provider, a request from a bank, a questionnaire that suddenly asks about compliance or, worse, a security concern.

And at that point, the question tends not to be “do we need to comply with the PCI DSS” but “have we been operating within its scope without realising it”, shortly followed by “how much trouble are we in”.

This guide explains what the PCI DSS is, who it applies to, how it’s enforced and what compliance looks like in practice.

 

What is the PCI DSS?

The PCI DSS (Payment Card Industry Data Security Standard) is a global security framework that applies to any organisation that stores, processes or transmits payment card data.

It was developed by the five major card brands – Visa, Mastercard, American Express, Discover and JCB – and is administered by the PCI SSC (Payment Card Industry Security Standards Council), which they founded jointly.

The current version, PCI DSS v4.0.1, has been in force since March 2024.

The Standard sets out 12 high-level requirements covering network security, data protection, vulnerability management, access control, monitoring and security policy. The scope of these requirements varies depending on your environment, but the underlying obligation – to protect cardholder data – applies to everyone in the payment chain.

 

Who does the PCI DSS apply to?

The Standard applies to two broad categories of organisation:

  • Merchants – any business that accepts card payments; and
  • Service providers – businesses that store, process or transmit cardholder data on behalf of others, such as payment gateways, hosted payment page providers and certain cloud or infrastructure providers.

Who enforces the PCI DSS and how?

The PCI SSC sets and maintains the PCI DSS, and it’s enforced through contracts between merchants, acquiring banks and payment brands.

However, although the PCI DSS is a contractual obligation rather than a legal one, that doesn’t mean you don’t have to worry about compliance.

Payment brands can impose fines on acquiring banks for compliance violations, which pass those costs – and consequences – on to merchants.

These include monthly fines, increased transaction fees or even the removal of your ability to accept card payments altogether.

It’s also worth remembering that a PCI DSS breach is always a GDPR (General Data Protection Regulation) breach as cardholder data is classified as personal data under the Regulation. So, as well as any enforcement action from your acquiring bank, your organisation could also face enforcement action from the ICO (Information Commissioner’s Office).

 

The 12 requirements of the PCI DSS

The PCI DSS specifies 12 requirements, which are organised into six control objectives:

Build and Maintain a Secure Network and Systems

  • Requirement 1: Install and Maintain Network Security Controls
  • Requirement 2: Apply Secure Configurations to All system Components

Protect Account Data

  • Requirement 3: Protect Stored Account Data
  • Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

Maintain a Vulnerability Management Program

  • Requirement 5: Protect All Systems and Networks from Malicious Software
  • Requirement 6: Develop and Maintain Secure Systems and Software

Implement Strong Access Control Measures

  • Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
  • Requirement 8: Identify Users and Authenticate Access to system Components
  • Requirement 9: Restrict Physical Access to Cardholder Data

Regularly Monitor and Test Networks

  • Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
  • Requirement 11: Test Security of systems and Networks Regularly

Maintain an Information Security Policy

  • Requirement 12: Support Information Security with Organizational Policies and Programs

Compliance levels and why they vary

There are different ways of proving your compliance with the Standard, depending on the number of transactions you process. First, let’s look at the levels that merchants and service providers are divided into.

Merchants
For merchants, there are four levels, which are broadly:

  • Level 1: Merchants that process more than 6 million transactions per year – or any merchant that has previously suffered a data breach, or that a card brand designates as high-risk.
  • Level 2: Merchants that process 1 million to 6 million transactions per year.
  • Level 3: Merchants that process 20,000 to 1 million e-commerce transactions per year.
  • Level 4: Merchants that process fewer than 20,000 e-commerce transactions, or up to 1 million total transactions across all channels.

These thresholds can vary slightly between card brands. If you process across multiple brands you’re held to the highest applicable level. Your acquiring bank will confirm your level and is your primary point of contact for compliance.

Service providers
Service providers are divided into two levels, which are defined by the PCI SSC:

  • Level 1: Service providers that process, transmit or store more than 300,000 transactions per year.
  • Level 2: Service providers that process, transmit or store fewer than 300,000 transactions per year.

So, how does these levels affect how you demonstrate your compliance?

 

ROCs and SAQs: how compliance is validated

  • Level 1 merchants must undergo an annual on-site assessment by a QSA (Qualified Security Assessor), resulting in a RoC (Report on Compliance). This is a formal, independent audit covering all 12 requirements of the PCI DSS.
  • Level 2, 3 and 4 merchants are generally eligible to self-assess using an SAQ (Self-Assessment Questionnaire) – a structured set of yes/no questions mirroring the PCI DSS requirements relevant to your specific environment.
  • Level 1 service providers must submit an RoC completed by a PCI QSA organisation or an ISA (Internal Security Assessor), and must undergo quarterly ASV scanning.
  • Level 2 service providers must submit an RoC completed by a PCI QSA organisation or an ISA (Internal Security Assessor), or an SAQ signed by a company officer, and must undergo quarterly ASV scanning.

There are ten SAQs types, and which one applies to your organisation depends on how you actually accept and handle card payments.

Choosing the wrong SAQ – typically a simpler one you’re not actually eligible for – is one of the most common compliance mistakes. Eligibility depends on your technical environment, not your preference.

Learn more about PCI SAQs and how to choose the right one

 

Where to start with PCI DSS compliance

Begin by understanding where cardholder data exists in your business and how it flows.

Map the systems that touch it – directly or indirectly – and from there you can define your scope accurately and determine which SAQ type, if any, applies to your environment. In many cases, scope is smaller than businesses expect. There are also ways of reducing your PCI DSS scope. Read our blog post 8 Ways to Reduce Your PCI DSS Compliance Burden for more guidance.

And if you need further help, contact one of our PCI DSS experts today. As a PCI QSA company, we have everything you need to comply with the Standard.

 

Looking for PCI DSS support?

GRC Solutions can help. Our range of consultancy, technical security, software and training solutions helps organisations meet the requirements of the PCI DSS.

Whether you’re looking to reduce your assessment scope, you need support with an SAQ (self-assessment questionnaire) or you require a gap analysis, we have the right solution.

Speak to an expert