PCI DSS v4.0.1 requirements explained: the 12 requirements in plain language

Six goals, twelve requirements: how the standard is built

The twelve requirements sit under six goals: a secure network and systems (requirements 1 and 2), protecting account data (3 and 4), vulnerability management (5 and 6), access control (7 to 9), monitoring and testing (10 and 11) and security policy (12). Version 4.0.1, issued in June 2024, clarified the wording of v4.0 without adding or deleting a requirement.

Each requirement divides into numbered sub-requirements with testing procedures and guidance. Titles are quoted as the standard writes them, in US spelling; our summaries never replace its text.

Scope decides where the requirements apply

The requirements apply to the cardholder data environment (CDE): the system components, people and processes that store, process or transmit cardholder data or sensitive authentication data, plus any component with unrestricted connectivity to them. Cardholder data is, at a minimum, the full primary account number (PAN); sensitive authentication data covers card verification codes, full track data, PINs and PIN blocks.

Systems that connect to the CDE or could affect its security, such as directory services, jump hosts and administrators' workstations, are in scope as connected-to or security-impacting systems. Segmentation is not mandatory, but it can reduce scope once testing proves it works. Requirement 12 has you confirm the scope at least every 12 months; our PCI DSS scoping and segmentation guide shows how to shrink it.

Errors here multiply: call recordings that capture spoken card numbers bring the recording platform, its storage and its administrators into the CDE, so keep the numbers out of the recordings.

Requirements 1 to 6: networks, account data and vulnerabilities

Build and Maintain a Secure Network and Systems

1. Install and Maintain Network Security Controls. Firewalls, cloud security groups and similar controls allow only traffic with a business justification, network and data-flow diagrams stay current, and rule sets are reviewed at least every six months.

2. Apply Secure Configurations to All System Components. Each system type in scope follows a hardening standard: vendor default accounts changed or disabled, unneeded services removed, wireless defaults replaced.

Protect Account Data

3. Protect Stored Account Data. Keep account data only while a defined need exists and, unless you issue cards or support issuing, never retain sensitive authentication data after authorisation, even encrypted. Mask the PAN on screen, make it unreadable wherever stored and manage the keys.

4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks. PAN crossing the internet or wireless links needs strong cryptography and trusted, valid certificates, and so does PAN sent by e-mail, chat or text; banning that practice is easier to evidence.

Maintain a Vulnerability Management Program

5. Protect All Systems and Networks from Malicious Software. Anti-malware stays current, active and monitored; systems judged not at risk are re-evaluated periodically; removable media is scanned; processes and automated mechanisms protect staff from phishing.

6. Develop and Maintain Secure Systems and Software. Rank vulnerabilities by risk, install critical and high-security patches within a month of release, develop bespoke and custom software securely, control changes, and inventory, authorise and integrity-check every payment page script.

Requirements 7 to 12: access, monitoring, testing and policy

Implement Strong Access Control Measures

7. Restrict Access to System Components and Cardholder Data by Business Need to Know. Access follows job function and least privilege, approved before it is granted. User access is reviewed at least every six months; application and system accounts at intervals your risk analysis sets.

8. Identify Users and Authenticate Access to System Components. Every user has a unique ID. Multi-factor authentication covers all non-console access into the CDE and remote access that could reach it, passwords have at least twelve characters where supported, and leavers lose access immediately.

9. Restrict Physical Access to Cardholder Data. Entry to facilities housing the CDE is controlled, visitors are managed, media holding card data is secured and destroyed when no longer needed, and trained staff inspect payment terminals for tampering or substitution.

Regularly Monitor and Test Networks

10. Log and Monitor All Access to System Components and Cardholder Data. Audit logs record user activity and are protected from change. Key logs are reviewed daily with automated mechanisms, a year of history is kept with three months immediately available, and failures of critical security controls are detected and handled.

11. Test Security of Systems and Networks Regularly. Check for wireless access points and run internal scans and Approved Scanning Vendor external scans every three months; penetration test at least yearly and after significant change; test segmentation; detect intrusions and unauthorised payment page changes.

Maintain an Information Security Policy

12. Support Information Security with Organizational Policies and Programs. The umbrella: a policy reviewed yearly, defined roles, targeted risk analyses, a component inventory and yearly scope confirmation, awareness training that covers phishing, personnel screening, oversight of third-party service providers and a tested incident response plan.

Coverage and evidence, requirement by requirement

Assessors sample systems, people and dates, then ask for records showing each control working.

Defined approach or customised approach

The defined approach, used by entities and assessors for years, means implementing each requirement as written while the assessor applies its testing procedures. It suits organisations whose controls already match, and newcomers to PCI DSS.

The customised approach starts from a requirement's stated objective rather than its wording. You design a control that achieves it, document it in a controls matrix, perform a targeted risk analysis and test it; the assessor then derives testing procedures for your control. The Council intends it for risk-mature organisations with robust risk management, and it suits a genuinely different control, never a missing one.

Targeted risk analyses: justifying your own frequencies

A targeted risk analysis examines one requirement, not the whole business. You need one wherever a requirement leaves the frequency to you, such as reviewing logs outside the daily set or inspecting payment terminals, and for every requirement met through the customised approach, under requirement 12.3.2.

Each analysis names the assets protected, the threats, and what makes them more or less likely, then justifies the frequency or control chosen, and it is reviewed at least every 12 months. A frequency picked for convenience will not survive the assessor's questions.

PCI DSS requirements: questions buyers ask