PCI Compliance Requirements: The 12 PCI DSS Requirements Explained (v4.0.1)

The PCI DSS requirements, often called the PCI requirements or PCI compliance requirements, are 12 principal requirements, grouped under six goals, that every organisation storing, processing or transmitting payment card data must meet. They cover network security controls, secure configuration, stored data, data in transit, malware, secure software, access, authentication, physical security, logging, testing and policy. The current version is PCI DSS v4.0.1.

PCI DSS is the card industry’s data security standard, maintained by the PCI Security Standards Council and enforced through the card brands and acquirers, and it applies to merchants and to service providers that handle card data for others. If you need the basics first, start with what is PCI DSS, which explains the standard, what counts as cardholder data and how compliance is validated; our guide to PCI compliance in the UK covers UK acquirers and the law.

This guide explains what each requirement asks for in plain English and the evidence a Qualified Security Assessor (QSA) will expect to see, with a section for each requirement that you can link to directly. If you want a version you can tick off, our PCI compliance checklist turns the same requirements into checkable items.

Key takeaways

• PCI DSS v4.0.1 has 12 principal requirements under six goals, each with detailed sub-requirements.
• How many apply to you depends on your scope and your validation route (SAQ or Report on Compliance).
• Assessors look for evidence that controls operated all year, not just a policy saying they should.
• Reducing where card data goes is the quickest way to reduce the requirements you have to meet.

What are the 12 PCI DSS requirements?

Every requirement also asks for documented policies and procedures, and assigned roles and responsibilities, usually as its first two sub-requirements. Assessors check both. The numbers in brackets below are the v4.0.1 sub-requirements.

Goal 1: Build and maintain a secure network and systems

Requirement 1

Install and maintain network security controls. Firewalls, cloud security groups and any other technology that filters traffic must separate the cardholder data environment (CDE) from everything else. Every allowed port, protocol and service needs a documented business reason (1.2.5), inbound and outbound CDE traffic is restricted to what is necessary (1.3), rule sets are reviewed at least every six months (1.2.7), and laptops and other devices that connect to both untrusted networks and the CDE have their own security controls (1.5.1).

Evidence a QSA asks for: network and data-flow diagrams, configuration standards, the rule base with a justification per rule, six-monthly review records and change tickets. Our guide to PCI DSS firewall requirements covers this in depth, and an independent firewall configuration review is a good check before assessment.

Requirement 2

Apply secure configurations to all system components. Every system in scope is built to a documented hardening standard based on industry guidance (2.2.1). Vendor default passwords are changed or the accounts disabled (2.2.2), only necessary services and functions are enabled (2.2.4), all non-console administrative access is encrypted with strong cryptography (2.2.7), and wireless vendor defaults are changed (2.3.1).

Evidence: configuration standards, a system inventory, sample configurations that match the standard, and records showing default accounts were removed or changed.

Goal 2: Protect account data

Requirement 3

Protect stored account data. Keep as little card data as possible for as short a time as possible, never store sensitive authentication data after authorisation, mask the PAN when it is displayed and render it unreadable wherever it is stored, with keys properly managed. Our guide to PCI DSS encryption requirements explains hashing, tokenisation, the limits of disk encryption and key management in detail.

Evidence: a retention policy, data discovery results, encryption and key-management procedures, and samples showing stored PAN is unreadable.

Requirement 4

Protect cardholder data with strong cryptography during transmission over open, public networks. Card data sent over the internet, wireless or other public networks is protected with strong cryptography and valid, trusted certificates (4.2.1). An inventory of trusted keys and certificates is kept (4.2.1.1), and card numbers are never sent by email, chat or other end-user messaging unless secured with strong cryptography (4.2.2). Stored data is Requirement 3; this requirement covers data on the move.

Evidence: TLS configurations, the certificate inventory, scan results showing no weak protocols, and procedures that stop staff sending card numbers by email or chat.

Goal 3: Maintain a vulnerability management programme

Requirement 5

Protect all systems and networks from malicious software. Anti-malware runs on every system component except those you have evaluated as not at risk, and those evaluations are repeated at a frequency set by targeted risk analysis (5.2). It stays up to date (5.3.1), scans removable media (5.3.3) and cannot be switched off by users without management authorisation (5.3.5). Since 31 March 2025, organisations also need automated controls that detect and protect staff against phishing attacks (5.4.1).

Evidence: console reports showing coverage and update status, evaluations of any systems treated as not at risk, and the configuration of anti-phishing controls such as email filtering.

Requirement 6

Develop and maintain secure systems and software. Vulnerabilities are identified and risk-ranked (6.3.1), and patches for critical vulnerabilities are installed within one month of release (6.3.3). Bespoke and custom software follows a secure development process, with developer training at least every 12 months and code review before release (6.2). Public-facing web applications are protected by an automated solution such as a web application firewall (6.4.2), scripts on payment pages are authorised and inventoried (6.4.3), and changes go through change control (6.5).

Evidence: patch reports, the inventory of bespoke software and third-party components (6.3.2), secure development procedures, training and code review records, WAF configuration and the payment page script inventory. Our guide to PCI DSS 6.4.3 explains the payment page rules.

Goal 4: Implement strong access control measures

Requirement 7

Restrict access to system components and cardholder data by business need to know. Access is granted by job role, on least privilege, and approved by authorised staff (7.2.1 to 7.2.3). All user accounts and their privileges are reviewed at least every six months (7.2.4), and application and system accounts get only the access they need (7.2.5).

Evidence: the access control model, role definitions, approval records and completed six-monthly access reviews.

Requirement 8

Identify users and authenticate access to system components. Everyone has a unique ID, passwords are at least 12 characters where used, and multi-factor authentication (MFA) is required for all non-console access into the CDE (8.4.2) and for all remote access that could reach it (8.4.3). Our guide to PCI DSS Requirement 8 covers password rules, MFA and service accounts in detail.

Evidence: authentication settings, MFA configuration, user lists and system account management records.

Requirement 9

Restrict physical access to cardholder data. Entry to sensitive areas is controlled and monitored, with records kept for at least three months (9.2), and visitors are authorised, badged and logged (9.3). Media holding card data is secured, inventoried and destroyed when no longer needed (9.4), and point-of-interaction devices such as card terminals are listed and regularly inspected for tampering and substitution (9.5). In a hosted or cloud environment, the data centre’s physical controls are usually evidenced by your provider’s Attestation of Compliance.

Evidence: entry logs or camera records, visitor logs, media inventories, destruction records, and terminal inventories with inspection records.

Goal 5: Regularly monitor and test networks

Requirement 10

Log and monitor all access to system components and cardholder data. Audit logs are enabled, protected and reviewed using automated mechanisms, and kept for at least 12 months with the most recent three months immediately available. Our guide to PCI DSS Requirement 10 covers log content, time synchronisation and how to detect failures of critical security controls.

Evidence: logging configuration, SIEM alerts and review records, and retention settings.

Requirement 11

Test security of systems and networks regularly. This is where most of the recurring work sits:

• Wireless: authorised and unauthorised wireless access points are identified at least every three months (11.2.1). Our wireless security audit checklist shows how to evidence it. To find out whether an attacker could actually get in over Wi-Fi, see wireless penetration testing.
• Vulnerability scans: internal scans at least every three months (11.3.1), using authenticated scanning (11.3.1.2), and external scans at least every three months by a PCI SSC Approved Scanning Vendor, with passing results (11.3.2). Our ASV scans are delivered through our PCI SSC Approved Scanning Vendor partner, and our guide on how to pass a PCI compliance scan covers the common failures.
• Penetration testing: internal and external tests at least every 12 months and after significant change (11.4.2 and 11.4.3), with exploitable findings fixed and retested (11.4.4), plus segmentation testing if you use segmentation to reduce scope (11.4.5). Our PCI DSS penetration testing is scoped to Requirement 11.4.
• Detection: intrusion detection or prevention (11.5.1), change detection on critical files (11.5.2) and change- and tamper-detection on payment pages (11.6.1).

Evidence: four quarters of passing ASV scans, internal scan reports, penetration test reports with retests, segmentation test results, and IDS and change-detection configuration.

Goal 6: Maintain an information security policy

Requirement 12

Support information security with organisational policies and programmes. An information security policy reviewed at least every 12 months (12.1), a targeted risk analysis for each requirement where you set your own frequency (12.3.1), and PCI DSS scope confirmed at least every 12 months and after significant change (12.5.2). It also covers security awareness training on hire and at least every 12 months, including phishing and social engineering (12.6), screening of staff with access to the CDE (12.7), management of third-party service providers (12.8) and an incident response plan tested at least every 12 months (12.10).

Evidence: dated policies, risk analyses, the scope confirmation, training records, the service provider list with their Attestations of Compliance and a record of which requirements each one manages, and incident response test records.

Which PCI compliance requirements apply to you?

All 12 apply in principle, but how many sub-requirements you must validate depends on your scope. A merchant that fully outsources an online checkout completes SAQ A, a short subset. A merchant storing card data completes PCI SAQ D, which covers every applicable requirement. Our guide to which PCI SAQ you need explains the options, our free PCI compliance check suggests the likely one, and your level (see PCI compliance levels) decides whether you self-assess or need a QSA.

The version matters too. If your last assessment was under v3.2.1, read what changed in PCI DSS 4.0.1 before you start. The full requirement text, with testing procedures and guidance, is free from the PCI SSC document library linked above.

How Sovereign Secure can help

Sovereign Secure is a PCI SSC-approved QSA company, Qualified PIN Assessor and Card Production Security Assessor, and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028. Our PCI DSS consultancy runs gap analyses against all 12 requirements and helps you fix what is missing, and our PCI compliance audit service delivers the Report on Compliance or QSA-supported SAQ your acquirer asks for. Advisory and assessment work are kept separate, as the PCI SSC expects of a QSA company.