Compliance

PCI DSS compliance,explained

7 min read · Updated June 2026

PCI DSS is the security standard for any organisation that stores, processes, or transmits payment card data. It sets requirements across network security, data protection, access control, and monitoring. How you validate depends on your card volume: a Self-Assessment Questionnaire for smaller volumes, or an audit by a Qualified Security Assessor for larger ones.

What PCI DSS is

The Payment Card Industry Data Security Standard (PCI DSS) is maintained by the PCI Security Standards Council, which the major card brands founded. The current version is 4.0. It applies to any organisation that handles cardholder data, regardless of size, though what you must do scales with your volume.

It is a contractual standard rather than a law. You are held to it by the card brands and your acquiring bank, and failing to comply can mean fines or losing the ability to process card payments.

What counts as card data

PCI DSS protects two kinds of data. Cardholder data includes the primary account number (PAN) and details such as the cardholder name and expiry. Sensitive authentication data includes the full track data, card verification code, and PIN.

The single most effective way to reduce PCI scope is to handle less of this data: tokenisation and using a compliant payment provider keep raw card data out of your systems entirely.

The requirements at a glance

PCI DSS v4.0 groups its requirements into a set of security goals, including:

  • Build and maintain a secure network, with firewalls and no vendor default passwords.
  • Protect stored cardholder data and encrypt it in transit.
  • Maintain a vulnerability management programme, including anti-malware and secure development.
  • Implement strong access control, on a need-to-know basis and with unique IDs.
  • Monitor and test networks, with logging and regular testing.
  • Maintain an information security policy.

How validation works

Your merchant level, set by annual card transaction volume, decides how you validate. Lower volumes typically complete a Self-Assessment Questionnaire (SAQ), and the SAQ type depends on how you take payments. The highest volume (Level 1) requires a Report on Compliance from a Qualified Security Assessor (QSA).

Many merchants also need quarterly network scans from an Approved Scanning Vendor (ASV). Whichever path applies, the underlying controls must be in place and evidenced; the SAQ or audit just attests to them.

Staying assessment-ready

  1. 1Confirm your scope and reduce it where you can with tokenisation or a compliant payment provider.
  2. 2Identify your merchant level and the right SAQ or assessment path.
  3. 3Maintain the controls continuously, with owners, status, and evidence.
  4. 4Run the required scans and remediate findings before they age out.
  5. 5Treat it as a yearly cycle, not a yearly scramble, so evidence is ready when the assessment comes.

Frequently asked questions

What version of PCI DSS is current?

PCI DSS v4.0 is the current version of the standard, having replaced v3.2.1. It introduced more flexibility through a customised approach and added requirements that organisations have been phasing in. Validate against v4.0 unless your acquirer tells you otherwise.

Do I need a QSA, or can I self-assess?

It depends on your merchant level. Most lower-volume merchants can validate with a Self-Assessment Questionnaire, while the highest-volume merchants (Level 1) need a Report on Compliance from a Qualified Security Assessor. Your acquiring bank confirms which applies to you.

How do I reduce my PCI DSS scope?

Handle less card data. Using a compliant payment provider, tokenisation, and hosted payment pages keeps raw card data out of your environment, which shrinks the systems in scope and can move you to a simpler SAQ.

Do this in a fraction of the time

Diligio centralises your approved answers, drafts each response grounded in your sources, and independently verifies it before you review. RFPs, DDQs, and security questionnaires, answered from one knowledge base.

Related guides

Due diligence

What is a DDQ (due-diligence questionnaire)?

Due diligence

DDQ vs RFP: what is the difference?

RFPs

RFP vs RFI vs RFQ: what is the difference?

RFPs

The RFP response process: a step-by-step guide

RFPs

How to build an RFP content library

RFPs

The bid/no-bid decision: when to respond to an RFP

Security questionnaires

How to respond to security questionnaires faster

Security questionnaires

SIG vs CAIQ vs VSAQ: the security questionnaires explained

Security questionnaires

Vendor security assessment checklist

Compliance

SOC 2 vs ISO 27001: what is the difference?

Compliance

ISO 27001 readiness checklist: how to prepare for certification

Compliance

SOC 2 for startups: a practical guide

Compliance

GDPR compliance for SaaS: a practical guide

Compliance

HIPAA compliance for software vendors

Compliance

The NIST Cybersecurity Framework, explained

Compliance

ISO 42001, the AI management standard, explained

Compliance

ISO 27017 and ISO 27018: cloud security and privacy, explained

Compliance

ISO 22301 and business continuity, explained

Compliance

DORA, explained

Compliance

Cyber Essentials, explained

Compliance

The CCPA and CPRA, explained

Compliance

NIST 800-53, explained

Compliance

NIST 800-171 and CMMC, explained

Compliance

FedRAMP, explained

Compliance

HITRUST CSF, explained

Financial regulation

BSA/AML, explained

Financial regulation

The FATF 40 Recommendations, explained

Financial regulation

MiFID II and MAR, explained

Financial regulation

Consumer credit and fair lending, explained

Due diligence

Third-party risk management (TPRM): a practical guide

Putting PCI DSS into practice? See Diligio Compliance for PCI DSS.