PCI DSS v4.0.1 · free readiness check

PCI DSS v4.0.1: Requirements, Checklist & Readiness

PCI DSS — the Payment Card Industry Data Security Standard — is the global standard every business that stores, processes or transmits payment-card data has to meet. This page explains what PCI DSS is, who must comply, and the 6 goals and 12 requirements of v4.0.1 accurately, then hands you a free interactive PCI DSS checklist you can filter by SAQ type, track and export. Start with the checklist, or read the plain-language explainer below it.

TL;DR

PCI DSS in brief

5 points

PCI DSS (Payment Card Industry Data Security Standard) is the global security standard that any organisation storing, processing or transmitting payment-card data must meet. It is maintained by the PCI Security Standards Council (PCI SSC).
It organises controls under 6 goals and 12 top-level requirements, covering network security, protecting stored and transmitted account data, vulnerability management, access control, monitoring and an information security policy.
v4.0.1 is the current version of the standard. v3.2.1 has been retired, and the requirements that were "future-dated" best practice in v4.0 became mandatory on 31 March 2025 — confirm exact dates with the PCI SSC.
Merchants are placed in one of four levels by annual card-transaction volume; the level drives whether you validate with a Self-Assessment Questionnaire (SAQ) or a formal Report on Compliance (ROC) from a Qualified Security Assessor.
The interactive checklist below covers all 12 v4.0.1 requirements, lets you filter by SAQ type, auto-saves your progress in the browser — free, no signup. Download is Pro: exporting the checklist to your clipboard.

What is PCI DSS, and who must comply?

PCI DSS (Payment Card Industry Data Security Standard) is a security standard that protects payment-card account data. It is maintained by the PCI Security Standards Council (PCI SSC), the body founded by the major card brands — Visa, Mastercard, American Express, Discover and JCB. The standard applies to any entity that stores, processes or transmits cardholder data, and to any entity that could affect the security of the cardholder data environment (CDE). In practice that covers merchants of every size, payment processors, acquirers, issuers and third-party service providers. Compliance is enforced through the agreements that let a business accept cards, not by a single government regulator.

The 6 goals and 12 requirements

PCI DSS groups its controls under six overarching goals, which break down into twelve top-level requirements. These are the 12 requirements, worded as they appear in v4.0.1:

Build and maintain a secure network and systems

1Requirement 1: Install and maintain network security controls.
2Requirement 2: Apply secure configurations to all system components (no vendor-supplied defaults).

Protect account data

3Requirement 3: Protect stored account data.
4Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks.

Maintain a vulnerability management program

5Requirement 5: Protect all systems and networks from malicious software.
6Requirement 6: Develop and maintain secure systems and software.

Implement strong access control measures

7Requirement 7: Restrict access to system components and cardholder data by business need to know.
8Requirement 8: Identify users and authenticate access to system components.
9Requirement 9: Restrict physical access to cardholder data.

Regularly monitor and test networks

10Requirement 10: Log and monitor all access to system components and cardholder data.
11Requirement 11: Test security of systems and networks regularly.

Maintain an information security policy

12Requirement 12: Support information security with organisational policies and programs.

The four merchant levels

Merchants are placed into one of four levels based primarily on their annual card-transaction volume. The exact thresholds and reporting obligations are set by each card brand rather than by a single table, so treat the following as the shape of the model rather than fixed numbers:

Level 1 — highest volume. The largest merchants (and any merchant that has suffered a breach) typically validate with an assessor-led Report on Compliance and regular network scans.
Level 2 — large volume. Large merchants below Level 1, generally validating with a Self-Assessment Questionnaire, sometimes with an on-site review.
Level 3 — mid volume. Mid-size merchants, commonly e-commerce, typically validating with a Self-Assessment Questionnaire.
Level 4 — lowest volume. The smallest merchants, validating with a Self-Assessment Questionnaire and, where applicable, external scans.

Because each brand publishes its own level definitions, confirm which level and reporting route apply to you with your acquiring bank or the card brands directly.

SAQ vs ROC

There are two main ways to validate compliance. A Self-Assessment Questionnaire (SAQ) is a tool that eligible merchants and service providers use to self-assess and attest to their compliance. There are several SAQ types — such as A, A-EP, B, B-IP, C, C-VT, P2PE and D — each scoped to a particular payment-acceptance method, so you complete only the one that matches your environment. A Report on Compliance (ROC) is a formal, evidence-based assessment, typically performed by a Qualified Security Assessor (QSA) or an Internal Security Assessor (ISA). Higher-volume merchants and many service providers are required to produce a ROC rather than self-assess with an SAQ. Not sure which SAQ fits how you take payments? The SAQ selector walks you through it.

Where v4.0.1 stands

v4.0.1 is the current version of PCI DSS. It is a limited revision that corrects errata and clarifies the intent and wording of v4.0 rather than adding new requirements, and the earlier v3.2.1 has been retired. Many of the new requirements introduced in v4.0 were "future-dated" — treated as best practice first and becoming mandatory on 31 March 2025, so they are now in force. For authoritative publication and effective dates, and for the full standard and its supporting documents, see the PCI Security Standards Council.

Note: the checklist above is a self-assessment aid that reflects PCI SSC guidance; it is not a formal compliance assessment. Always confirm your scope, applicable SAQ and validation route with your acquirer or a Qualified Security Assessor.

Frequently asked questions

What is PCI DSS?

PCI DSS stands for the Payment Card Industry Data Security Standard. It is a set of security requirements designed to protect payment-card account data, maintained by the PCI Security Standards Council (PCI SSC) — the body founded by the major card brands (Visa, Mastercard, American Express, Discover and JCB). It applies to any entity that stores, processes or transmits cardholder data, as well as entities that could affect the security of the cardholder data environment (CDE). The standard groups its controls under 6 goals and 12 top-level requirements and is validated through a Self-Assessment Questionnaire or a formal Report on Compliance.

Who needs to comply with PCI DSS?

Any organisation that stores, processes or transmits cardholder data must comply, along with any entity whose systems could affect the security of that data. In practice that means merchants of every size, payment processors, acquirers, issuers and third-party service providers. Compliance is not optional for taking card payments — it is required under the acquiring-bank and card-brand agreements that let a business accept cards. How you validate compliance (a Self-Assessment Questionnaire versus an assessor-led Report on Compliance) depends on your merchant level and how you accept payments, but the underlying requirements apply to everyone in scope.

What are the 12 requirements of PCI DSS?

The 12 PCI DSS requirements are: (1) install and maintain network security controls; (2) apply secure configurations to all system components; (3) protect stored account data; (4) protect cardholder data with strong cryptography during transmission over open, public networks; (5) protect all systems and networks from malicious software; (6) develop and maintain secure systems and software; (7) restrict access to system components and cardholder data by business need to know; (8) identify users and authenticate access to system components; (9) restrict physical access to cardholder data; (10) log and monitor all access to system components and cardholder data; (11) test security of systems and networks regularly; and (12) support information security with organisational policies and programs. They sit under six overarching goals.

What changed in PCI DSS v4.0.1?

PCI DSS v4.0 was a major revision of the standard. v4.0.1 is a limited follow-up revision that corrects errata and clarifies wording and intent rather than adding new requirements; it is the current version of the standard, and v3.2.1 has been retired. Many of the new requirements introduced in v4.0 were "future-dated" — treated as best practice first and becoming mandatory on 31 March 2025. If you need exact publication or effective dates, check the PCI Security Standards Council, which publishes the authoritative standard and its supporting documents.

What is the difference between an SAQ and a ROC?

A Self-Assessment Questionnaire (SAQ) is a validation tool that eligible merchants and service providers use to self-assess and attest to their PCI DSS compliance. There are several SAQ types (such as A, A-EP, B, B-IP, C, C-VT, P2PE and D), each scoped to a particular way of accepting payments, so you complete only the one that matches your environment. A Report on Compliance (ROC) is a formal, documented assessment — typically performed by a Qualified Security Assessor (QSA) or an Internal Security Assessor (ISA) — that evaluates each requirement with evidence. Higher-volume merchants and many service providers are required to produce a ROC rather than self-assess with an SAQ.