Home / Controls lists / PCI DSS v4.0

PCI DSS v4.0 Controls List

PCI DSS is the security standard for organisations that store, process or transmit payment card data. Version 4.0 has twelve principal requirements under six goals. This list gives the second-level requirements under each, which is the level at which most programmes plan work.

Download PCI DSS controls list Read the list

Free account needed to download. You come straight back to the file.

Who it is for. Merchants, payment processors and service providers that handle card data, and any company whose systems could affect the security of that data. Card brands and acquirers decide how compliance is validated.

What this list covers. PCI DSS v4.0, requirement 1 to 12 and their second-level requirements: 63 requirements. Each has a reference, a heading and a sentence in plain English.

Read it here, download it when you want it. The download is a CSV that opens in Excel or Google Sheets, with blank columns for whether each item applies to you, its status, owner and evidence, so you can use it as a working tracker.

Requirement 1. Network security controls

Ref	Control	What it asks for
1.1	Ownership and procedures	Define, document and assign responsibility for how network security controls are run.
1.2	Configure and maintain controls	Configure firewalls and similar controls to a documented standard, and review rules and diagrams regularly.
1.3	Restrict access to the cardholder data environment	Allow only the traffic the environment needs, in and out, and deny the rest.
1.4	Control trusted and untrusted connections	Filter traffic between untrusted networks and the trusted network, and limit what can be reached.
1.5	Mitigate risk from dual-homed devices	Protect the environment from devices that connect both to untrusted networks and to it.

Requirement 2. Secure configurations

Ref	Control	What it asks for
2.1	Ownership and procedures	Define, document and assign responsibility for secure configuration.
2.2	Configure system components securely	Harden systems to a standard, change vendor defaults and run only the services that are needed.
2.3	Secure wireless environments	Change wireless defaults, use strong encryption and rotate keys when people with access leave.

Requirement 3. Protect stored account data

Ref	Control	What it asks for
3.1	Ownership and procedures	Define, document and assign responsibility for protecting stored account data.
3.2	Keep storage to a minimum	Store account data only where the business needs it, and delete it when it is not.
3.3	Do not keep sensitive authentication data	Never keep card verification codes, PINs or full track data after authorisation.
3.4	Restrict display and copying of the card number	Mask the card number on screen and limit who can see it in full or copy it.
3.5	Render stored card numbers unreadable	Use encryption, truncation, tokenisation or strong hashing wherever the card number is stored.
3.6	Protect cryptographic keys	Control access to the keys that protect stored account data and keep them in as few places as possible.
3.7	Manage the key life cycle	Define and follow processes for generating, distributing, storing, rotating and retiring keys.

Requirement 4. Protect data in transit

Ref	Control	What it asks for
4.1	Ownership and procedures	Define, document and assign responsibility for protecting data in transit.
4.2	Use strong cryptography on open networks	Encrypt the card number whenever it crosses public or untrusted networks, with trusted certificates.

Requirement 5. Protect against malware

Ref	Control	What it asks for
5.1	Ownership and procedures	Define, document and assign responsibility for malware protection.
5.2	Prevent, detect and address malware	Deploy anti-malware on systems at risk and assess the rest for whether they need it.
5.3	Keep anti-malware active and monitored	Keep it updated, scanning and logging, and stop users from turning it off.
5.4	Defend users against phishing	Use technical controls that detect and block phishing before it reaches users.

Requirement 6. Secure systems and software

Ref	Control	What it asks for
6.1	Ownership and procedures	Define, document and assign responsibility for developing and maintaining secure software.
6.2	Develop bespoke software securely	Train developers, review code before release and follow secure development practices.
6.3	Find and fix vulnerabilities	Identify vulnerabilities from trusted sources, rank them and patch in line with that ranking.
6.4	Protect public-facing web applications	Detect and block web attacks continuously, using a review process or an automated solution.
6.5	Manage changes securely	Document, approve and test changes, and keep production and test environments separate.

Requirement 7. Restrict access by need to know

Ref	Control	What it asks for
7.1	Ownership and procedures	Define, document and assign responsibility for access restriction.
7.2	Define and assign access appropriately	Give each user only the access their job needs, and review it regularly.
7.3	Manage access with an access control system	Enforce access decisions through a system that denies by default.

Requirement 8. Identify users and authenticate access

Ref	Control	What it asks for
8.1	Ownership and procedures	Define, document and assign responsibility for identification and authentication.
8.2	Manage accounts across their life	Give every user a unique ID and control the creation, change, use and removal of accounts.
8.3	Establish strong authentication	Enforce strong passwords or other factors, and protect them in storage and transmission.
8.4	Use multi-factor authentication for the environment	Require more than one factor for administrators and for all access into the cardholder data environment.
8.5	Configure multi-factor authentication to resist misuse	Prevent replay, bypass and reuse of authentication factors.
8.6	Manage application and system accounts	Control and limit the use of accounts that are not tied to a person, and their credentials.

Requirement 9. Restrict physical access

Ref	Control	What it asks for
9.1	Ownership and procedures	Define, document and assign responsibility for physical security.
9.2	Control entry to facilities and systems	Use entry controls and limit access to sensitive areas and network jacks.
9.3	Authorise and manage personnel and visitors	Identify, badge and log people, and keep visitor records for a defined period.
9.4	Secure media	Store, move and destroy media holding cardholder data under control.
9.5	Protect point-of-interaction devices	Keep a device inventory, inspect devices for tampering and train staff to spot it.

Requirement 10. Log and monitor access

Ref	Control	What it asks for
10.1	Ownership and procedures	Define, document and assign responsibility for logging and monitoring.
10.2	Record audit logs	Log access, privileged actions and security events with enough detail to reconstruct what happened.
10.3	Protect audit logs	Stop logs from being altered or deleted and limit who can read them.
10.4	Review logs	Review logs and security events regularly, using automation where required, and follow up on anomalies.
10.5	Retain audit log history	Keep log history for at least twelve months, with recent months readily available.
10.6	Synchronise time	Keep clocks consistent across systems from trusted time sources.
10.7	Detect and respond to control failures	Detect failures of critical security controls promptly and restore them with records of the cause.

Requirement 11. Test security regularly

Ref	Control	What it asks for
11.1	Ownership and procedures	Define, document and assign responsibility for security testing.
11.2	Manage wireless access points	Detect and address authorised and unauthorised wireless access points on a regular basis.
11.3	Scan for vulnerabilities	Run internal and external vulnerability scans, rescan until clean and use approved scanners where required.
11.4	Test by penetration testing	Test the environment and segmentation regularly and fix the exploitable findings.
11.5	Detect intrusions and unexpected file changes	Use intrusion detection and change detection and respond to alerts.
11.6	Detect changes to payment pages	Detect and respond to unauthorised changes to payment pages as seen by the consumer's browser.

Requirement 12. Policies and programme

Ref	Control	What it asks for
12.1	Information security policy	Keep a security policy that is published, reviewed at least yearly and communicated.
12.2	Acceptable use of technology	Define what users may do with end-user technologies and what is approved.
12.3	Targeted risk analysis	Identify and assess risks to the environment, and run risk analyses where the standard allows flexible frequency.
12.4	Manage compliance	Assign accountability for compliance and, for service providers, report to executive management.
12.5	Document and confirm scope	Document where account data is, and confirm the scope at least yearly.
12.6	Security awareness	Run an awareness programme and train staff at hire and at least yearly, including on phishing.
12.7	Screen personnel	Screen candidates for roles with access to the environment, as local law allows.
12.8	Manage third-party service providers	Keep a list of providers, agree responsibilities in writing and monitor their compliance.
12.9	Providers support their customers	For service providers: acknowledge responsibility and give customers the information they need.
12.10	Respond to incidents	Have a tested incident response plan with trained staff and 24/7 availability for alerts.

Download PCI DSS controls listFree account needed. You come straight back to the file.

A summary, not the source. The references and short headings identify each item. The wording beside them is our own summary and is not a quotation, a legal opinion or advice. Check the published source for the exact requirement. We help organisations with this: see our VAPT service.

Questions people ask

How many requirements does PCI DSS v4.0 have?

Twelve principal requirements, each broken into second-level requirements and then detailed sub-requirements. This list covers the twelve and their second-level requirements.

Is this the full list of PCI DSS sub-requirements?

No. The detailed sub-requirements and testing procedures are in the standard from the PCI Security Standards Council. Use this list for planning and tracking, and the standard for the exact text.

What changed from version 3.2.1?

Version 4.0 added a customised approach, targeted risk analyses, stronger authentication rules, and new requirements on payment page scripts and phishing. Version 3.2.1 was retired in 2024.

Does PCI DSS apply in India?

It applies wherever card data is handled. Indian acquirers and card brands require it of merchants and service providers, alongside the Reserve Bank of India's own rules.