PCI DSS 4.0

International (payment card industry; enforced contractually by payment brands and acquirers)

v4.0.1 (June 2024), current; the graph name keeps 4.0: v4.0 (March 2022) was retired on 31 December 2024 and v4.0.1 is a limited revision with the same requirement numbering

16 domains

280 controls

PCI DSS, the PCI Security Standards Council's minimum set of technical and operational controls for every entity that stores, processes or transmits payment card account data or can affect its security, in twelve principal requirements (network security controls, secure configuration, stored account data, transmission encryption, anti-malware, secure software, need-to-know access, identification and authentication, physical security, logging and monitoring, security testing, policy and programs) plus Appendix A for multi-tenant providers, SSL/early TLS POS terminals and designated entities. Read against v4.0.1 (June 2024), the current edition: 280 requirements.

Verified

PCI DSS 4.0 is a compliance framework from International (payment card industry; enforced contractually by payment brands and acquirers) with 16 domains and 280 controls that map to 198 other frameworks. The largest domains are Req 12: Information Security Policies (37 controls), Req 3: Protect Stored Account Data (29 controls), Req 8: Identify and Authenticate Users (29 controls). Every control below carries what it requires and what an assessor expects to see.

Maintained by Gerard BlokdykControl text last updated 21 May 2026

Framework summaries on this platform are AI-assisted interpretations for educational and compliance planning purposes. They do not reproduce or replace the official standards. Refer to the authoritative source for the definitive text. Framework names and trademarks belong to their respective organisations.

Framework Domains (16)

Appendix A1: Additional requirements for multi-tenant service providers – PCI DSS 4.0

7 controls

Controls in the Appendix A1: Additional requirements for multi-tenant service providers – PCI DSS 4.0 domain of PCI DSS 4.0 — 7 controls
Code	Title	Description
pci-dss-4-0::A1.1.1	A1.1.1 Logical separation between provider and customer environments	A multi-tenant service provider must implement logical separation so that: (1) the provider itself cannot reach into any...
pci-dss-4-0::A1.1.2	A1.1.2 Customers limited to their own cardholder data and CDE	The provider must implement controls ensuring every customer is permitted to access only its own cardholder data and its...
pci-dss-4-0::A1.1.3	A1.1.3 Customers restricted to their allocated resources	Controls must ensure each customer can access only the resources the provider has allocated to it. Guidance: the purpose...
pci-dss-4-0::A1.1.4	A1.1.4 Penetration testing of tenant separation every six months	The provider must confirm with a penetration test, at least once every six months, that the logical separation controls...
pci-dss-4-0::A1.2.1	A1.2.1 Per-customer audit logging consistent with Requirement 10	The provider must enable audit logging for every customer environment, in line with PCI DSS Requirement 10, such that: l...
pci-dss-4-0::A1.2.2	A1.2.2 Support for prompt forensic investigation of any customer	The provider must have processes or mechanisms that support or enable fast forensic examination of the relevant servers...
pci-dss-4-0::A1.2.3	A1.2.3 Customer reporting and remediation of incidents and vulnerabilities	The provider must have processes or mechanisms to report and deal with security incidents and vulnerabilities, whether s...

Appendix A2: Entities using SSL/early TLS for card-present POS POI terminal connections – PCI DSS 4.0

3 controls

Controls in the Appendix A2: Entities using SSL/early TLS for card-present POS POI terminal connections – PCI DSS 4.0 domain of PCI DSS 4.0 — 3 controls
Code	Title	Description
pci-dss-4-0::A2.1.1	A2.1.1 Confirm SSL/early TLS POS POI devices resist known exploits	Where POS POI terminals at a merchant or payment acceptance site still use SSL or early TLS, the entity must verify that...
pci-dss-4-0::A2.1.2	A2.1.2 Risk Mitigation and Migration Plan for SSL/early TLS connections	Service providers with existing connection points serving POS POI terminals that rely on SSL or early TLS must maintain...
pci-dss-4-0::A2.1.3	A2.1.3 Service providers offer a secure protocol option	Every service provider must provide a secure service offering. The testing procedure reads this as offering customers a...

Appendix A3: Designated Entities Supplemental Validation (DESV) – PCI DSS 4.0

20 controls

Controls in the Appendix A3: Designated Entities Supplemental Validation (DESV) – PCI DSS 4.0 domain of PCI DSS 4.0 — 20 controls
Code	Title	Description
pci-dss-4-0::A3.1.1	A3.1.1 Executive management responsibility for the PCI DSS compliance program	Executive management must take responsibility for protecting account data and for a PCI DSS compliance program covering:...
pci-dss-4-0::A3.1.2	A3.1.2 Formal PCI DSS compliance program elements	The entity must run a formal compliance program for PCI DSS that covers: defined activities to maintain and monitor over...
pci-dss-4-0::A3.1.3	A3.1.3 Defined and assigned PCI DSS compliance roles	Roles and responsibilities for PCI DSS compliance must be defined specifically and assigned formally to one or more peop...
pci-dss-4-0::A3.1.4	A3.1.4 Annual PCI DSS training for compliance personnel	Staff whom A3.1.3 names as holding responsibility for PCI DSS compliance must be trained on current PCI DSS or informati...
pci-dss-4-0::A3.2.1	A3.2.1 Quarterly and change-driven scope documentation and validation	PCI DSS scope must be documented and checked as accurate every three months at a minimum, and again whenever the in-scop...
pci-dss-4-0::A3.2.2	A3.2.2 Scope impact of every system or network change	For every change to systems or networks, including new systems and new network connections, the entity must determine th...
pci-dss-4-0::A3.2.2.1	A3.2.2.1 Post-change confirmation that PCI DSS controls are in place	Once a change is complete, the entity must confirm that every relevant PCI DSS requirement is in place on all new or mod...
pci-dss-4-0::A3.2.3	A3.2.3 Scope review after organizational structure changes	Any change to the organizational structure must trigger a formal internal review of how it affects PCI DSS scope and whi...
pci-dss-4-0::A3.2.4	A3.2.4 Six-monthly penetration testing of segmentation controls	Where segmentation is in use, PCI DSS scope must be confirmed by: following the entity's methodology defined in Requirem...
pci-dss-4-0::A3.2.5	A3.2.5 Data-discovery methodology for cleartext PAN	A data-discovery methodology must be in place that: confirms PCI DSS scope; locates every source and location of clearte...
pci-dss-4-0::A3.2.5.1	A3.2.5.1 Annual confirmation of data-discovery effectiveness	The entity must confirm its data-discovery methods by: testing their effectiveness; making sure they can find cleartext...
pci-dss-4-0::A3.2.5.2	A3.2.5.2 Response procedures when cleartext PAN is found outside the CDE	Response procedures must be ready to be triggered whenever cleartext PAN turns up outside the CDE and must include: deci...
pci-dss-4-0::A3.2.6	A3.2.6 Mechanisms to detect and block cleartext PAN leaving the CDE	The entity must have mechanisms that spot cleartext PAN leaving the CDE by any channel, method or process that is not au...
pci-dss-4-0::A3.2.6.1	A3.2.6.1 Response procedures for attempted removal of cleartext PAN	Response procedures must start when an attempt to move cleartext PAN out of the CDE through an unauthorized channel, met...
pci-dss-4-0::A3.3.1	A3.3.1 Prompt detection and alerting of critical security control failures	Failures of critical security control systems must be detected, alerted on and addressed promptly, covering, as a minimu...
pci-dss-4-0::A3.3.1.1	A3.3.1.1 Prompt response to critical security control failures	When a critical security control system fails, the failure must be responded to promptly, with processes covering: resto...
pci-dss-4-0::A3.3.2	A3.3.2 Annual review of hardware and software technologies	Hardware and software technologies must be reviewed every 12 months at a minimum to confirm whether they continue to sat...
pci-dss-4-0::A3.3.3	A3.3.3 Quarterly review that BAU activities are followed	Reviews must be carried out at least every three months, by PCI DSS compliance program personnel identified under A3.1.3...
pci-dss-4-0::A3.4.1	A3.4.1 Six-monthly review of user accounts and access privileges	User accounts and access privileges on in-scope system components must be reviewed at least every six months so the revi...
pci-dss-4-0::A3.5.1	A3.5.1 Methodology for prompt detection of attack patterns	A methodology must be implemented to promptly identify attack patterns and undesirable behaviour across systems, includi...

Req 10: Logging and Monitoring

27 controls

Controls in the Req 10: Logging and Monitoring domain of PCI DSS 4.0 — 27 controls
Code	Title	Description
10.1.1	10.1.1 Requirement 10 policies and procedures maintained and in use	Every security policy and operational procedure that Requirement 10 calls for must meet four conditions: it is written d...
10.1.2	10.1.2 Roles for logging and monitoring assigned and understood	Responsibilities for carrying out the activities in Requirement 10 must be written down, allocated, and understood by th...
10.2.1	10.2.1 Audit logging enabled on all system components	Audit logging must be switched on and actively recording for every system component and for cardholder data. Applies to...
10.2.1.1	10.2.1.1 Logs capture individual user access to cardholder data	Audit logs must record each instance of an individual user reaching cardholder data. Applies to all entities. The guidan...
10.2.1.2	10.2.1.2 Logs capture all administrative actions	Audit logs must record every action carried out by anyone who holds administrative access, and this includes any interac...
10.2.1.3	10.2.1.3 Access to the audit logs is itself logged	Audit logs must record every access made to the audit logs themselves. Applies to all entities. The guidance explains th...
10.2.1.4	10.2.1.4 Logs capture invalid logical access attempts	Audit logs must record every invalid logical access attempt. Applies to all entities. The guidance notes that repeated i...
10.2.1.5	10.2.1.5 Logs capture changes to identification and authentication credentials	Audit logs must record every change to identification and authentication credentials, including at minimum: the creation...
10.2.1.6	10.2.1.6 Logs capture initialization and stopping of audit logs	Audit logs must record the following: every initialization of new audit logs, and every start, stop or pause of existing...
10.2.1.7	10.2.1.7 Logs capture creation and deletion of system-level objects	Every time a system-level object is created or deleted, the audit logs must record it. Applies to all entities. The guid...
10.2.2	10.2.2 Required details recorded for each auditable event	For every auditable event in 10.2.1.1 to 10.2.1.7, audit logs must record: the user identification; the type of event; t...
10.3.1	10.3.1 Audit log read access limited to job need	Read access to audit log files must be limited to people whose job requires it. Applies to all entities. The guidance ad...
10.3.2	10.3.2 Audit log files protected from modification	Audit log files must be protected so that individuals cannot modify them. The testing procedure looks at physical segreg...
10.3.3	10.3.3 Audit logs promptly backed up to central secure storage	Audit log files, including logs from external-facing technologies, must be promptly backed up to one or more secure, cen...
10.3.4	10.3.4 File integrity monitoring on audit logs	Audit logs must be covered by file integrity monitoring or by change-detection tooling so that existing log data cannot...
10.4.1	10.4.1 Daily review of security-relevant logs	Every day, at a minimum, the entity must review: all security events; the logs of each critical system component; the lo...
10.4.1.1	10.4.1.1 Automated mechanisms used for audit log review	Audit log reviews must be carried out using automated mechanisms. Applies to all entities. The guidance gives log collec...
10.4.2	10.4.2 Periodic review of all other system component logs	Logs from every other in-scope system component, meaning those not covered by the daily review in 10.4.1, must be review...
10.4.2.1	10.4.2.1 Periodic log review frequency set by targeted risk analysis	The frequency for periodically reviewing logs of every other system component (those outside 10.4.1) must be set by the...
10.4.3	10.4.3 Exceptions and anomalies from log review addressed	Exceptions and anomalies found while reviewing logs must be addressed. Applies to all entities. As good practice, the gu...
10.5.1	10.5.1 Keep logs 12 months, latest three months online	Audit log history must be kept for at least 12 months, and at least the latest three months must be ready for immediate...
10.6.1	10.6.1 System clocks synchronized with time-sync technology	System clocks and time must be synchronized using time-synchronization technology. Applies to all entities. Applicabilit...
10.6.2	10.6.2 Systems configured to correct and consistent time	Systems must be set to correct and consistent time as follows: at least one designated time server is in use; no system...
10.6.3	10.6.3 Time sync configuration and time data protected	Time synchronization settings and data must be protected as follows: only personnel with a business need may access time...
10.7.1	10.7.1 Service providers detect critical control failures (superseded)	Service providers only (an additional requirement). When a critical security control system fails, the failure must be d...
10.7.2	10.7.2 Detect and alert on critical security control failures	When a critical security control system fails, the failure must be detected, alerted and addressed promptly, covering at...
10.7.3	10.7.3 Respond promptly to critical security control failures	When any critical security control system fails, the entity must respond promptly, including at least by: restoring the...

Req 11: Test Security Regularly

21 controls

Controls in the Req 11: Test Security Regularly domain of PCI DSS 4.0 — 21 controls
Code	Title	Description
11.1.1	11.1.1 Requirement 11 policies and procedures managed	Every security policy and operational procedure named anywhere in Requirement 11 (security testing of systems and networ...
11.1.2	11.1.2 Roles for security testing assigned and understood	The responsibilities for carrying out each activity in Requirement 11 must be written down, allocated to named roles or...
11.2.1	11.2.1 Detect authorized and rogue wireless access points	The entity manages wireless access points, authorized or not, by: testing for the presence of Wi-Fi access points; detec...
11.2.2	11.2.2 Inventory of authorized wireless access points	The entity keeps an up-to-date inventory of the wireless access points it has authorized, and each entry carries a docum...
11.3.1	11.3.1 Quarterly internal vulnerability scans	Internal vulnerability scans must be run at least every three months. All vulnerabilities ranked high-risk or critical u...
11.3.1.1	11.3.1.1 Lower-risk vulnerabilities handled per risk analysis	Applicable vulnerabilities that are not ranked high-risk or critical under the entity's Requirement 6.3.1 rankings must...
11.3.1.2	11.3.1.2 Authenticated internal vulnerability scanning	Internal vulnerability scans must use authenticated scanning, with these conditions: systems that cannot accept scanning...
11.3.1.3	11.3.1.3 Internal scans after significant change	After any significant change, internal vulnerability scans must be performed so that: vulnerabilities ranked high-risk o...
11.3.2	11.3.2 Quarterly ASV external vulnerability scans	External vulnerability scans must meet these conditions: they run at least every three months; an Approved Scanning Vend...
11.3.2.1	11.3.2.1 External scans after significant change	After any significant change, external vulnerability scans must be performed so that: vulnerabilities with a CVSS score...
11.4.1	11.4.1 Penetration testing methodology defined and implemented	The entity must define, document and implement a penetration testing methodology that includes: industry-accepted testin...
11.4.2	11.4.2 Internal penetration testing annually and after change	Internal penetration testing must be performed: using the methodology the entity has defined; no less than annually; aft...
11.4.3	11.4.3 External penetration testing annually and after change	External penetration testing must be performed: using the methodology the entity has defined; no less than annually; aft...
11.4.4	11.4.4 Correct exploitable findings from penetration tests	Exploitable vulnerabilities and security weaknesses discovered during penetration testing must be corrected: in line wit...
11.4.5	11.4.5 Annual segmentation penetration testing	Where segmentation is used to separate the CDE from other networks, the segmentation controls must be penetration tested...
11.4.6	11.4.6 Service provider segmentation testing every six months	Where a service provider relies on segmentation to separate the CDE from other networks, it must run penetration tests o...
11.4.7	11.4.7 Multi-tenant providers support customer penetration testing	Multi-tenant service providers must support their customers in external penetration testing as required by Requirement 1...
11.5.1	11.5.1 IDS/IPS monitoring of CDE traffic	Network intrusions must be detected and/or prevented, using IDS and/or IPS techniques, in such a way that: all traffic a...
11.5.1.1	11.5.1.1 Service providers detect covert malware channels	Service providers must apply intrusion-detection and/or intrusion-prevention methods that find the covert channels malwa...
11.5.2	11.5.2 Change detection on critical files	The entity needs a deployed change-detection tool (file integrity monitoring is one example) that: warns personnel when...
11.6.1	11.6.1 Payment page tamper detection	The entity must deploy a mechanism for detecting changes and tampering which: warns personnel of any unauthorized modifi...

Req 12: Information Security Policies

37 controls

Controls in the Req 12: Information Security Policies domain of PCI DSS 4.0 — 37 controls
Code	Title	Description
12.1.1	12.1.1 Overall information security policy established and disseminated	The organisation must have one overarching information security policy that is formally set up, made available in publis...
12.1.2	12.1.2 Security policy reviewed annually and updated as needed	The overall information security policy must be reviewed on a cycle no longer than 12 months, plus revised whenever need...
12.1.3	12.1.3 Security roles defined and acknowledged by all personnel	The security policy must spell out, without ambiguity, the information security roles and responsibilities that apply to...
12.1.4	12.1.4 Executive ownership of information security formally assigned	Accountability for information security must be formally given to a CISO (Chief Information Security Officer) or to anot...
12.10.1	12.10.1 Incident response plan ready for activation	An incident response plan must exist and be ready to activate if a security incident is suspected or confirmed. At minim...
12.10.2	12.10.2 Annual review and testing of the incident response plan	On a cycle of no more than 12 months, the entity must review its security incident response plan, updating the content w...
12.10.3	12.10.3 Incident response personnel available 24/7	The entity must name specific personnel who are reachable around the clock (24/7) to handle any suspected or confirmed s...
12.10.4	12.10.4 Periodic training for incident response personnel	Personnel whose job includes handling suspected or confirmed security incidents must be trained appropriately and period...
12.10.4.1	12.10.4.1 Responder training frequency set by targeted risk analysis	How often incident response personnel receive periodic training must be set out in a targeted risk analysis by the entit...
12.10.5	12.10.5 Plan covers alerts from security monitoring systems	The incident response plan must include monitoring of, and response to, alerts from security monitoring systems, coverin...
12.10.6	12.10.6 Plan evolved from lessons learned and industry developments	The security incident response plan must be changed and developed over time based on lessons learned and to reflect deve...
12.10.7	12.10.7 Response procedures for PAN found in unexpected locations	Incident response procedures must exist, to be started whenever stored PAN is found where it is not expected, and must i...
12.2.1	12.2.1 Rules for acceptable use of end-user technology	Acceptable use policies covering end-user technologies must be written down and put into practice, and must contain: exp...
12.3.1	12.3.1 Targeted risk analysis for flexible-frequency requirements	Wherever a PCI DSS requirement calls for a targeted risk analysis, that analysis must be documented and contain: the ass...
12.3.2	12.3.2 Targeted risk analysis for each customized-approach requirement	For every requirement the entity meets through the customized approach, a targeted risk analysis must be carried out tha...
12.3.3	12.3.3 Cryptographic cipher suite and protocol inventory reviewed annually	The cipher suites and protocols in use must be documented, then checked at least every 12 months, with the review coveri...
12.3.4	12.3.4 Annual review of hardware and software technologies	Hardware and software in use must undergo a check at least every 12 months, covering at minimum: analysis that vendors s...
12.4.1	12.4.1 Executive responsibility for a PCI DSS compliance program	Service providers only: executive management must set up responsibility for protecting cardholder data and for a PCI DSS...
12.4.2	12.4.2 Quarterly reviews that personnel follow security procedures	Service providers only: at least every three months, reviews must confirm that personnel carry out their tasks in keepin...
12.4.2.1	12.4.2.1 Documentation of quarterly operational reviews	Service providers only: the reviews carried out under Requirement 12.4.2 must be recorded, and the records must include:...
12.5.1	12.5.1 Inventory of in-scope system components	The entity must keep a current inventory covering every system component within PCI DSS scope, with a description of eac...
12.5.2	12.5.2 Annual and change-driven scope confirmation	The entity must document its PCI DSS scope and confirm it at least once every 12 months, plus whenever the in-scope envi...
12.5.2.1	12.5.2.1 Six-monthly scope confirmation for service providers	Service providers only: the entity must document its PCI DSS scope and reconfirm it, at least every six months, as well...
12.5.3	12.5.3 Scope review after significant organisational change	Service providers only: when the organisational structure changes significantly, the entity must carry out and document...
12.6.1	12.6.1 Formal security awareness program	A formal security awareness program must be in place so that all personnel know the entity's security policy and its pro...
12.6.2	12.6.2 Awareness program reviewed annually and updated	The security awareness program needs a review, at least every 12 months, with updates made when required to address new...
12.6.3	12.6.3 Security awareness training on hire and annually with acknowledgment	Personnel must be trained in security awareness when hired, then again at least every 12 months; also, the program must...
12.6.3.1	12.6.3.1 Awareness training covers phishing and social engineering	Security awareness training must address threats and vulnerabilities that could affect cardholder data or sensitive auth...
12.6.3.2	12.6.3.2 Awareness training covers acceptable use of end-user technologies	Security awareness training must include awareness of acceptable use of end-user technologies consistent with the polici...
12.7.1	12.7.1 Pre-hire screening of personnel with CDE access	Prospective personnel who will have CDE access must be screened before hiring, within the limits of local law, to reduce...
12.8.1	12.8.1 List of third-party service providers	The entity must keep a list of every TPSP that receives account data from it or that could influence how safe that data...
12.8.2	12.8.2 TPSP contracts acknowledging account data responsibility	The entity must hold written agreements with every TPSP that receives its account data or could influence CDE security,...
12.8.3	12.8.3 Due diligence before engaging TPSPs	An established process must be in place and used for engaging TPSPs, including appropriate due diligence before the enga...
12.8.4	12.8.4 Annual monitoring of TPSP compliance status	The entity must run a program that checks, at least every 12 months, where each TPSP stands on PCI DSS compliance. Appli...
12.8.5	12.8.5 Responsibility allocation between entity and TPSPs	The entity must keep information showing which PCI DSS requirements each TPSP manages, which the entity manages itself,...
12.9.1	12.9.1 TPSP written acknowledgments to customers	Service providers only: TPSPs must give customers written agreements containing an acknowledgment that the TPSP answers...
12.9.2	12.9.2 TPSP support for customer information requests	Service providers only: TPSPs must support customer requests for information they need under Requirement 12.8.4 and Requ...

Req 1: Network Security Controls

19 controls

Controls in the Req 1: Network Security Controls domain of PCI DSS 4.0 — 19 controls
Code	Title	Description
1.1.1	1.1.1 Requirement 1 policies and procedures governed	Every security policy and operational procedure called for under Requirement 1 (network security controls) must meet fou...
1.1.2	1.1.2 Requirement 1 roles and responsibilities assigned	The duties needed to carry out the Requirement 1 activities (network security control design, configuration, change hand...
1.2.1	1.2.1 Ruleset configuration standards for NSCs	The entity must have configuration standards for the rulesets of its network security controls, and those standards must...
1.2.2	1.2.2 Network connection and NSC changes under change control	Every change to network connections and every change to the configuration of network security controls must be approved...
1.2.3	1.2.3 Accurate network diagram of CDE connections	The entity must keep one or more accurate network diagrams that show each connection linking the cardholder data environ...
1.2.4	1.2.4 Accurate data-flow diagram for account data	The entity must keep one or more accurate data-flow diagrams that (a) show every path account data takes through network...
1.2.5	1.2.5 Allowed services, protocols and ports justified	Every service, protocol and port that is permitted must be identified, approved, and supported by a defined business nee...
1.2.6	1.2.6 Security features for insecure services in use	For every service, protocol and port that is in use and regarded as insecure, the entity must define and implement secur...
1.2.7	1.2.7 Six-monthly review of NSC configurations	Network security control configurations must be reviewed at least every six months, confirming each time that they remai...
1.2.8	1.2.8 NSC configuration files secured and consistent	Configuration files for network security controls must be (a) protected against unauthorised access and (b) kept in line...
1.3.1	1.3.1 Inbound CDE traffic restricted	Traffic entering the cardholder data environment must be restricted so that (a) only necessary traffic is permitted and...
1.3.2	1.3.2 Outbound CDE traffic restricted	Traffic leaving the cardholder data environment must be restricted so that (a) only necessary traffic is permitted and (...
1.3.3	1.3.3 NSCs between wireless networks and the CDE	Network security controls must sit between each wireless network and the cardholder data environment, whether or not tha...
1.4.1	1.4.1 NSCs between trusted and untrusted networks	Network security controls must be implemented between trusted and untrusted networks. The guidance explains this lets th...
1.4.2	1.4.2 Restricting traffic entering trusted networks from outside	Traffic coming into trusted networks from untrusted networks must be limited to: (a) communications with system componen...
1.4.3	1.4.3 Anti-spoofing measures at trusted boundary	The entity must implement anti-spoofing measures that detect forged source IP addresses and stop them getting into the t...
1.4.4	1.4.4 Cardholder data stores not reachable from untrusted networks	System components that store cardholder data must not be directly reachable from untrusted networks. Applicability: this...
1.4.5	1.4.5 Internal IP and routing disclosure limited	Internal IP addresses and routing information may be disclosed only to authorised parties. The guidance explains this ke...
1.5.1	1.5.1 Security controls on dual-connected devices	Any computing device, whether owned by the company or by an employee, that connects both to untrusted networks (the inte...

Req 2: Secure Configurations

11 controls

Controls in the Req 2: Secure Configurations domain of PCI DSS 4.0 — 11 controls
Code	Title	Description
2.1.1	2.1.1 Requirement 2 policies and procedures governed	Every security policy and operational procedure required under Requirement 2 (secure configuration of system components)...
2.1.2	2.1.2 Requirement 2 roles and responsibilities assigned	Responsibilities for the Requirement 2 activities (building and maintaining configuration standards, handling vendor def...
2.2.1	2.2.1 System configuration standards maintained	Configuration standards must be developed, implemented and maintained so that they: (a) cover every system component; (b...
2.2.2	2.2.2 Vendor default accounts managed	Vendor default accounts must be handled as follows: (a) where a vendor default account will be used, its default passwor...
2.2.3	2.2.3 Primary functions with different security levels managed	Where primary functions need different security levels, the entity must manage them in one of three ways: (a) a system c...
2.2.4	2.2.4 Only necessary functionality enabled	Only the services, protocols, daemons and functions that are needed may be enabled, and all functionality that is not ne...
2.2.5	2.2.5 Insecure services, protocols or daemons secured	Where any insecure service, protocol or daemon is present on system components: (a) the business justification is docume...
2.2.6	2.2.6 System security parameters configured against misuse	System security parameters must be configured so that they prevent misuse. The guidance recommends that configuration st...
2.2.7	2.2.7 Non-console administrative access encrypted	All non-console administrative access must be encrypted with strong cryptography. The guidance explains the purpose (sto...
2.3.1	2.3.1 Wireless vendor defaults changed or confirmed secure	For wireless environments that connect to the CDE or carry account data, every wireless vendor default must be changed a...
2.3.2	2.3.2 Wireless encryption keys changed on triggers	For wireless environments that connect to the CDE or carry account data, wireless encryption keys must be changed: (a) w...

Req 3: Protect Stored Account Data

29 controls

Controls in the Req 3: Protect Stored Account Data domain of PCI DSS 4.0 — 29 controls
Code	Title	Description
3.3.1.1	3.3.1.1 Full track data not retained after authorization	No complete track contents (from the magnetic stripe, the equivalent chip data, or another source) may be kept once auth...
3.3.1.2	3.3.1.2 Card verification code not retained after authorization	The card verification code must not be kept after authorization is complete. Applicability: this means the 3- or 4-digit...
3.3.1.3	3.3.1.3 PIN and PIN block not retained after authorization	Neither the PIN (personal identification number) nor the PIN block may be kept after authorization completes. Applicabil...
3.3.2	3.3.2 Pre-authorization SAD stored electronically is strongly encrypted	Any SAD kept in electronic form before authorization completes must be encrypted with strong cryptography. Guidance sugg...
3.3.3	3.3.3 Issuer SAD storage limited, justified and encrypted	Extra obligation for card issuers, and for firms supporting issuing services, that hold SAD: any SAD they keep must (1)...
3.4.2	3.4.2 Remote access blocks copying or relocating PAN	When personnel use remote-access technologies, technical controls must stop them from copying and/or moving PAN, apart f...
3.5.1	3.5.1 Stored PAN rendered unreadable	PAN must be made unreadable wherever it is stored, using one of these methods: (1) one-way hashes of the whole PAN based...
3.5.1.1	3.5.1.1 PAN hashes are keyed cryptographic hashes	Where hashing is used to make PAN unreadable (the first method listed in Requirement 3.5.1), the hashes must be keyed cr...
3.5.1.2	3.5.1.2 Disk or partition encryption only on removable media	Where encryption applied to a whole disk or partition, instead of encrypting at database file, column or field level, is...
3.5.1.3	3.5.1.3 Disk encryption access independent of OS authentication	When whole-disk or partition encryption, rather than database file, column or field encryption, makes PAN unreadable, it...
3.6.1.1	3.6.1.1 Service provider cryptographic architecture documented	Service providers only (an additional requirement): a written description of the cryptographic architecture is kept curr...
3.6.1.2	3.6.1.2 Permitted storage forms for secret and private keys	Secret and private keys that protect stored account data must at all times exist in one or more of these forms: (1) wrap...
3.6.1.3	3.6.1.3 Cleartext key component access limited to minimum custodians	Access to cryptographic key components in cleartext must be limited to the smallest number of custodians needed. Guidanc...
3.6.1.4	3.6.1.4 Cryptographic keys kept in fewest locations	Cryptographic keys must be kept in as few locations as possible. Guidance explains that this helps the entity track and...
3.7.2	3.7.2 Secure distribution of cryptographic keys	Key-management policies and procedures must be in place covering the secure distribution of keys that protect stored acc...
3.7.3	3.7.3 Secure storage of cryptographic keys	Key-management policies and procedures must be in place covering how keys that protect stored account data are stored se...
3.7.4	3.7.4 Key changes at end of cryptoperiod	Key-management policies and procedures must be in place to change each key when its cryptoperiod ends, as set by the rel...
3.7.5	3.7.5 Retirement, replacement or destruction of keys	Key-management policies and procedures must be in place for retiring, replacing or destroying keys that protect stored a...
3.7.6	3.7.6 Split knowledge and dual control for manual key operations	Where staff perform manual key-management operations involving cleartext keys, key-management policies and procedures mu...
3.7.7	3.7.7 Prevent unauthorized substitution of keys	Key-management policies and procedures must be in place that stop cryptographic keys from being substituted without auth...
3.7.8	3.7.8 Key custodians formally acknowledge responsibilities	Key-management policies and procedures must be in place requiring each key custodian to confirm formally (on paper or el...
3.7.9	3.7.9 Key guidance for service provider customers	Extra requirement applying to service providers alone: if cryptographic keys for storing or transmitting account data ar...
pci-dss-4-0::3.1.1	3.1.1 Requirement 3 policies and procedures maintained and in use	Every security policy and operational procedure that supports Requirement 3 (protection of stored account data) must be...
pci-dss-4-0::3.1.2	3.1.2 Assigned duties for Requirement 3 activities	The roles and duties for carrying out the activities in Requirement 3 must be written down, allocated to named people or...
pci-dss-4-0::3.2.1	3.2.1 Data retention and disposal minimise stored account data	The entity limits stored account data through policies, procedures and processes governing how long data is kept and how...
pci-dss-4-0::3.3.1	3.3.1 SAD not retained after authorization, even encrypted	Once authorization is complete, sensitive authentication data may not be kept at all, and encrypting it does not make st...
pci-dss-4-0::3.4.1	3.4.1 PAN masked on display except for authorized roles	Whenever PAN is shown, it must be masked so that no more than the BIN and the last four digits appear, and only staff wi...
pci-dss-4-0::3.6.1	3.6.1 Procedures protect keys against disclosure and misuse	The entity defines and carries out procedures to shield the keys securing stored account data against misuse and disclos...
pci-dss-4-0::3.7.1	3.7.1 Generation of strong cryptographic keys	Key-management policies and procedures must be in place covering the generation of strong keys that secure stored accoun...

Req 4: Protect Cardholder Data in Transit

6 controls

Controls in the Req 4: Protect Cardholder Data in Transit domain of PCI DSS 4.0 — 6 controls
Code	Title	Description
4.1.1	4.1.1 Requirement 4 policies and procedures maintained and communicated	The organisation must hold security policies and operational procedures covering every activity named in Requirement 4 (...
4.1.2	4.1.2 Requirement 4 roles and responsibilities assigned	Duties for carrying out each Requirement 4 activity (for example managing transmission keys and certificates, configurin...
4.2.1	4.2.1 Strong cryptography safeguards PAN over public networks	Wherever PAN crosses open, public networks (such as the Internet, Wi-Fi, Bluetooth, cellular and satellite links), PAN m...
4.2.1.1	4.2.1.1 Inventory of trusted transmission keys and certificates	The entity must keep an up-to-date inventory of its own trusted keys and certificates that protect PAN while it is trans...
4.2.1.2	4.2.1.2 Wireless networks use strong cryptography	Any wireless network that either carries PAN or links into the CDE must follow recognised industry practice to implement...
4.2.2	4.2.2 PAN secured when sent by end-user messaging	Whenever PAN is sent through end-user messaging channels (e-mail, instant messaging, SMS, chat and the like), it must be...

Req 5: Anti-Malware

13 controls

Controls in the Req 5: Anti-Malware domain of PCI DSS 4.0 — 13 controls
Code	Title	Description
5.1.1	5.1.1 Requirement 5 policies and procedures maintained and communicated	The organisation must hold security policies and operational procedures covering every activity named in Requirement 5 (...
5.1.2	5.1.2 Requirement 5 roles and responsibilities assigned	Duties for carrying out each Requirement 5 activity (deploying and updating anti-malware, evaluating systems considered...
5.2.3.1	5.2.3.1 Targeted risk analysis sets evaluation frequency	How often the periodic evaluations under 5.2.3 are carried out for components considered not at risk from malware must b...
5.3.2.1	5.3.2.1 Targeted risk analysis sets malware scan frequency	Where the entity relies on periodic malware scans to satisfy Requirement 5.3.2, the scan frequency must be fixed by a ta...
5.3.4	5.3.4 Anti-malware audit logs enabled and retained	Audit logs produced by the anti-malware solution or solutions must be turned on and kept in line with Requirement 10.5.1...
5.3.5	5.3.5 Users cannot disable or alter anti-malware	Users must not be able to turn off or change anti-malware mechanisms, except where this is specifically documented and a...
5.4.1	5.4.1 Mechanisms detect and protect against phishing	The entity must have processes and automated mechanisms that detect phishing attacks and protect personnel from them. A...
pci-dss-4-0::5.2.1	5.2.1 Anti-malware deployed on all system components	An anti-malware solution (one or more) must be installed on every system component, with the only exception being compon...
pci-dss-4-0::5.2.2	5.2.2 Anti-malware detects and handles all known malware	The anti-malware solution or solutions deployed must both: identify all known types of malware; and remove, block or con...
pci-dss-4-0::5.2.3	5.2.3 Periodic evaluation of components not at risk from malware	Any system components treated as not at risk from malware must be evaluated on a periodic basis, and the evaluation must...
pci-dss-4-0::5.3.1	5.3.1 Anti-malware kept current through automatic updates	The anti-malware solution or solutions must be kept up to date by means of automatic updates, covering signatures, secur...
pci-dss-4-0::5.3.2	5.3.2 Periodic and real-time scans or continuous behavioural analysis	The anti-malware solution or solutions must do at least one of the following: run periodic scans combined with real-time...
pci-dss-4-0::5.3.3	5.3.3 Anti-malware covers removable electronic media	For removable electronic media (such as USB and flash drives), the anti-malware solution or solutions must either: scan...

Req 6: Secure Systems and Software

19 controls

Controls in the Req 6: Secure Systems and Software domain of PCI DSS 4.0 — 19 controls
Code	Title	Description
6.1.1	6.1.1 Requirement 6 policies and procedures maintained and communicated	Every security policy and operational procedure that Requirement 6 calls for must meet four conditions: it is written do...
6.1.2	6.1.2 Requirement 6 roles and responsibilities assigned	The roles and responsibilities for carrying out the activities in Requirement 6 must be documented, allocated to named p...
6.2.1	6.2.1 Secure development of bespoke and custom software	Software the entity builds as bespoke or custom code must be produced through a secure development process that: rests o...
6.2.2	6.2.2 Annual secure software training for developers	Staff who develop bespoke and custom software must receive training at least every 12 months that: addresses software se...
6.2.3	6.2.3 Code review before release	Before bespoke and custom software is released to production or to customers, it must be reviewed to find and fix possib...
6.2.3.1	6.2.3.1 Manual code review independence and approval	Where bespoke and custom software is reviewed manually before it goes to production, each code change must be: examined...
6.2.4	6.2.4 Engineering techniques against common software attacks	Developers of bespoke and custom software must have defined and actually use software engineering techniques or other me...
6.4.1	6.4.1 Public web application review or automated protection	Public-facing web applications must have new threats and vulnerabilities handled continuously and the applications prote...
6.4.2	6.4.2 Automated web attack detection and prevention	Public-facing web applications must be protected by an automated technical control that constantly spots and stops web-b...
6.5.5	6.5.5 No live PANs in pre-production	Live PANs must not be used in pre-production environments, unless those environments are inside the CDE and protected in...
6.5.6	6.5.6 Remove test data and accounts before production	Test data and test accounts must be taken off system components before the system is put into production. The testing pr...
pci-dss-4-0::6.3.1	6.3.1 Vulnerability identification and risk ranking	Security vulnerabilities must be identified and managed so that: new vulnerabilities come to light through sources of vu...
pci-dss-4-0::6.3.2	6.3.2 Inventory of bespoke software and components	The entity must keep an inventory covering the custom and bespoke software it runs, together with the third-party softwa...
pci-dss-4-0::6.3.3	6.3.3 Timely installation of security patches	All system components must be shielded from known vulnerabilities by applying relevant security patches or updates such...
pci-dss-4-0::6.4.3	6.4.3 Payment page script management	Every script on the payment page that is loaded and run in the consumer's browser must be controlled such that: a method...
pci-dss-4-0::6.5.1	6.5.1 Change control procedure for production	Every change to a system component in production must follow established procedures that include: the reason for the cha...
pci-dss-4-0::6.5.2	6.5.2 Confirm PCI DSS controls after significant change	When a significant change is complete, the entity must confirm that every applicable PCI DSS requirement is in place on...
pci-dss-4-0::6.5.3	6.5.3 Separate pre-production from production	Pre-production environments, such as development, test and user acceptance testing, must be kept apart from production e...
pci-dss-4-0::6.5.4	6.5.4 Separate roles between production and pre-production	Roles and functions must be divided between production and pre-production environments so that accountability exists and...

Req 7: Restrict Access by Need to Know

12 controls

Controls in the Req 7: Restrict Access by Need to Know domain of PCI DSS 4.0 — 12 controls
Code	Title	Description
7.1.1	7.1.1 Requirement 7 policies and procedures maintained	Every security policy and operational procedure that Requirement 7 calls for must be written down, kept current, actuall...
7.1.2	7.1.2 Requirement 7 roles and responsibilities assigned	Responsibility for carrying out each activity in Requirement 7 (defining the access model, approving privileges, provisi...
7.2.1	7.2.1 Access control model defined	The entity must define an access control model that governs how access is granted. The model must provide: access that f...
7.2.2	7.2.2 User access assigned by job function and least privilege	Access for every user, including privileged users, must be assigned on the basis of the user's job classification and fu...
7.2.3	7.2.3 Privileges approved by authorized personnel	Every privilege a user needs must be approved by personnel authorized to do so. The testing procedures check that docume...
7.2.5.1	7.2.5.1 Application and system account access reviewed periodically	All access held by application and system accounts, together with their related privileges, must be reviewed periodicall...
7.3.2	7.3.2 Access control system enforces role-based permissions	The access control systems must be set up so that they enforce the permissions granted to people, applications and syste...
7.3.3	7.3.3 Access control default deny all	The access control systems must be configured to deny all access by default, so that nobody receives access unless a rul...
pci-dss-4-0::7.2.4	7.2.4 User accounts and privileges reviewed every six months	All user accounts and their related access privileges, including third-party and vendor accounts, must be reviewed at le...
pci-dss-4-0::7.2.5	7.2.5 Application and system accounts least privilege	Every application and system account and its related access privileges must be assigned and managed so that: privileges...
pci-dss-4-0::7.2.6	7.2.6 Query access to stored cardholder data restricted	When users query databases or other stores holding cardholder data, that access must be restricted so that: users get to...
pci-dss-4-0::7.3.1	7.3.1 Need-to-know access control system covers all components	One or more access control systems must be in place that limit access according to each user's need to know and that cov...

Req 8: Identify and Authenticate Users

29 controls

Controls in the Req 8: Identify and Authenticate Users domain of PCI DSS 4.0 — 29 controls
Code	Title	Description
8.2.1	8.2.1 Unique ID assigned to every user	Each user must be given a unique ID before being permitted to reach any system component or cardholder data. The guidanc...
8.2.2	8.2.2 Shared and generic IDs only by exception	Group, shared or generic IDs, and any other shared authentication credentials, may be used only where needed as an excep...
8.2.3	8.2.3 Service provider unique factors per customer	Service providers only (an additional requirement). A service provider with remote access to customer premises must use...
8.2.4	8.2.4 User ID lifecycle changes authorized	Any addition, deletion or modification of a user ID, an authentication factor or another identifier object must be: auth...
8.2.5	8.2.5 Terminated users' access revoked immediately	Access for users who have been terminated must be revoked immediately. The testing procedures check both local and remot...
8.2.6	8.2.6 Inactive accounts removed within 90 days	A user account must be disabled or removed once it has gone unused for 90 days. The guidance explains that unused accoun...
8.2.7	8.2.7 Third-party remote access accounts controlled	Where a third party reaches, supports or maintains system components remotely, the accounts it uses must be: switched on...
8.2.8	8.2.8 Re-authentication after 15 minutes idle	A user must authenticate again before resuming a terminal or session that has been idle for longer than 15 minutes. The...
8.3.1	8.3.1 Access authenticated with at least one factor	All user access to system components by users and administrators must be authenticated with at least one of these factor...
8.3.10	8.3.10 Service provider customer password guidance	Service providers only (an additional requirement). If customers' users rely on passwords or passphrases alone as the au...
8.3.10.1	8.3.10.1 Service provider customer passwords 90 days or dynamic	Service providers only (an additional requirement). If customer user access relies on a password or passphrase alone (th...
8.3.11	8.3.11 Tokens, smart cards and certificates individually assigned	Where the entity relies on authentication factors like physical or logical tokens, smart cards or certificates: each fac...
8.3.2	8.3.2 Authentication factors unreadable with strong cryptography	Strong cryptography must be used to make all authentication factors unreadable both in transit and at rest on every syst...
8.3.3	8.3.3 Identity verified before factor changes	A user's identity must be verified before any authentication factor is modified. The guidance lists modifications this i...
8.3.4	8.3.4 Lockout after 10 attempts for 30 minutes	Invalid authentication attempts must be limited by: locking the user ID after at most 10 attempts; and keeping the accou...
8.3.5	8.3.5 Initial and reset passwords unique and changed	Where passwords or passphrases serve as authentication factors under Requirement 8.3.1, they must be set and reset for e...
8.3.6	8.3.6 Password minimum length 12 and complexity	Where passwords or passphrases are authentication factors for Requirement 8.3.1, they must at minimum: be at least 12 ch...
8.3.7	8.3.7 No reuse of last four passwords	Individuals must not be able to submit a new password or passphrase that matches any of the last four they used. The gui...
8.3.8	8.3.8 Authentication policies communicated to users	Authentication policies and procedures must be documented and communicated to all users, and must include: guidance on c...
8.3.9	8.3.9 Single-factor passwords changed every 90 days or dynamic analysis	If user access relies on a password or passphrase alone (any single-factor implementation), one of these must hold: the...
8.4.1	8.4.1 MFA for non-console administrative CDE access	Personnel with administrative access who reach the CDE through any non-console connection must use MFA. The guidance def...
8.4.2	8.4.2 MFA for all non-console CDE access	Every form of non-console access into the CDE, not only administrative access, must be protected with MFA. Applicability...
8.4.3	8.4.3 MFA for remote access that could reach CDE	MFA must be implemented for all remote access that originates outside the entity's network and could access or affect th...
8.5.1	8.5.1 MFA system resistant to replay and bypass	MFA systems must be implemented so that: the MFA system resists replay attacks; no user, including administrative users,...
pci-dss-4-0::8.1.1	8.1.1 Requirement 8 policies and procedures maintained	Every security policy and operational procedure called for in Requirement 8 must be documented, kept up to date, in acti...
pci-dss-4-0::8.1.2	8.1.2 Requirement 8 roles and responsibilities assigned	Responsibilities for carrying out Requirement 8 activities, such as issuing IDs, managing authentication factors, operat...
pci-dss-4-0::8.6.1	8.6.1 Interactive use of system accounts controlled	Where a system or application account is capable of interactive login, it must be managed so that: interactive use is pr...
pci-dss-4-0::8.6.2	8.6.2 No hard-coded passwords for interactive system accounts	Passwords or passphrases belonging to any application or system account capable of interactive login must never be hard...
pci-dss-4-0::8.6.3	8.6.3 System account passwords protected against misuse	Passwords or passphrases used by system and application accounts must be protected against misuse so that: they are chan...

Req 9: Restrict Physical Access

26 controls

Controls in the Req 9: Restrict Physical Access domain of PCI DSS 4.0 — 26 controls
Code	Title	Description
9.1.1	9.1.1 Requirement 9 policies and procedures maintained	Every security policy and operational procedure called for under Requirement 9 (physical access, visitor handling, media...
9.1.2	9.1.2 Requirement 9 roles and responsibilities assigned	The duties involved in carrying out Requirement 9 activities must be written down, allocated to named roles or people, a...
9.2.1	9.2.1 Facility entry controls for CDE systems	The entity must operate suitable facility entry controls that limit physical access to systems within the cardholder dat...
9.2.1.1	9.2.1.1 Monitoring of entry to sensitive areas	Individual physical entry into sensitive areas within the CDE must be monitored by video cameras, physical access contro...
9.2.2	9.2.2 Controls on publicly accessible network jacks	Physical controls, logical controls, or a mix of the two must be applied within the facility to stop publicly accessible...
9.2.3	9.2.3 Physical protection of network hardware and lines	Within the facility, physical access must be limited for wireless access points, gateways, networking and communications...
9.2.4	9.2.4 Locking of consoles in sensitive areas	Consoles located in sensitive areas must be locked whenever they are not being used, so that no one without authorizatio...
9.3.1	9.3.1 Personnel physical access procedures for the CDE	Procedures must be in operation for authorizing and managing physical entry to the CDE by personnel, covering: how perso...
9.3.1.1	9.3.1.1 Personnel access to sensitive areas controlled	Physical entry by personnel into CDE sensitive areas must be controlled so that: access is approved and tied to the pers...
9.3.2	9.3.2 Visitor access procedures for the CDE	Procedures must be in operation for approving and administering visitor access to the CDE, including that: visitors rece...
9.3.3	9.3.3 Visitor badges returned or deactivated	Visitor badges or other visitor identification must be handed back or deactivated before the visitor leaves the facility...
9.3.4	9.3.4 Visitor logs for facility and sensitive areas	Visitor logs must keep a physical record of visitor activity inside the facility and inside sensitive areas, capturing:...
9.4.1	9.4.1 Physical security of all media	Every item of media that holds cardholder data must be physically secured. The guidance explains that unprotected data o...
9.4.1.1	9.4.1.1 Secure storage location for offline backups	Offline media backups that contain cardholder data must be kept in a secure location. The guidance describes off-site st...
9.4.1.2	9.4.1.2 Annual review of offline backup location security	Each location that stores offline backup media holding cardholder data must have its security reviewed at least every 12...
9.4.2	9.4.2 Classification of media by data sensitivity	Every item of media with cardholder data must be classified according to how sensitive the data is. The guidance adds th...
9.4.3	9.4.3 Securing media sent outside the facility	Media with cardholder data that is sent outside the facility must be protected as follows: each shipment of media is log...
9.4.4	9.4.4 Management approval for media leaving facility	Management must approve every movement of media with cardholder data outside the facility, including media handed out to...
9.4.5	9.4.5 Inventory logs of electronic media	The entity must keep inventory logs covering all electronic media that contains cardholder data. The guidance explains t...
9.4.5.1	9.4.5.1 Annual inventories of electronic media	Inventories of electronic media holding cardholder data must be carried out at least every 12 months to confirm the medi...
9.4.6	9.4.6 Destruction of hard-copy materials	Hard-copy materials containing cardholder data must be destroyed once they are no longer required for legal or business...
9.4.7	9.4.7 Destruction of electronic media	Electronic media containing cardholder data must be destroyed once no longer required for business or legal reasons, usi...
9.5.1	9.5.1 Protection of POI devices from tampering	Point-of-interaction devices that read card data through direct physical contact with the card form factor must be prote...
9.5.1.1	9.5.1.1 Current register of POI devices	The entity must keep a current register of its POI devices that records: the device make and model; where the device is...
9.5.1.2	9.5.1.2 Periodic inspection of POI device surfaces	The surfaces of POI devices must be inspected periodically to detect tampering and unauthorized substitution. The guidan...
9.5.1.3	9.5.1.3 Training for personnel in POI environments	Personnel working in POI environments must receive training to recognise attempted tampering with, or replacement of, PO...

Req 9: Restrict Physical Access – PCI DSS 4.0

1 controls

Controls in the Req 9: Restrict Physical Access – PCI DSS 4.0 domain of PCI DSS 4.0 — 1 controls
Code	Title	Description
pci-dss-4-0::9.5.1.2.1	9.5.1.2.1 Risk-based frequency and type of POI inspections	The entity must set both how often periodic POI device inspections occur and what type of inspection is done through its...

Your Compliance Coverage

If you comply with PCI DSS 4.0, you already cover:

SOC 2

88%

247 controls mapped

Compare →

ISO 27002:2022

88%

247 controls mapped

Compare →

NIST SP 800-53 Rev 5

88%

246 controls mapped

Compare →

+ 195 more: ISO 27001:2022 (88%), FedRAMP Moderate (88%)

See all 198 mapped frameworks ↓

Maps to 198 other frameworks

280 total controls

SOC 2

247 source controls mapped|48 target controls covered

88%

ISO 27002:2022

247 source controls mapped|85 target controls covered

88%

NIST SP 800-53 Rev 5

246 source controls mapped|205 target controls covered

88%

ISO 27001:2022

246 source controls mapped|88 target controls covered

88%

FedRAMP Moderate

245 source controls mapped|265 target controls covered

88%

FedRAMP High

245 source controls mapped|266 target controls covered

88%

Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1

240 source controls mapped|162 target controls covered

86%

NIST Cybersecurity Framework 2.0

215 source controls mapped|87 target controls covered

77%

NIST SP 800-171 Rev 3

211 source controls mapped|87 target controls covered

75%

ISO 27701:2019

206 source controls mapped|71 target controls covered

74%

CMMC 2.0

199 source controls mapped|102 target controls covered

71%

CIS Controls v8

190 source controls mapped|141 target controls covered

68%

C5 (Germany)

168 source controls mapped|94 target controls covered

60%

HIPAA Security Rule

153 source controls mapped|59 target controls covered

55%

NIST SP 800-66 Rev 2

152 source controls mapped|50 target controls covered

54%

Azure Security Benchmark

141 source controls mapped|68 target controls covered

50%

AWS Well-Architected Security Pillar

116 source controls mapped|59 target controls covered

41%

PCI 3DS Core Security Standard

103 source controls mapped|117 target controls covered

37%

ANSSI Guide d'hygiene informatique (42 mesures, v2.0)

97 source controls mapped|41 target controls covered

35%

NIST SP 800-161 Rev 1

82 source controls mapped|70 target controls covered

29%

NIST SP 800-172

79 source controls mapped|33 target controls covered

28%

ISO 22301:2019

65 source controls mapped|44 target controls covered

23%

CFTC System Safeguards (17 CFR 37, 38, 39, 49)

60 source controls mapped|26 target controls covered

21%

ASD Strategies to Mitigate Cyber Security Incidents

57 source controls mapped|34 target controls covered

20%

NIS2 Directive

48 source controls mapped|17 target controls covered

17%

UK Cyber Essentials

44 source controls mapped|28 target controls covered

16%

APRA CPS 234

38 source controls mapped|23 target controls covered

14%

ACSC Essential Eight

37 source controls mapped|18 target controls covered

13%

Australia Consumer Data Right - Banking (CDR)

34 source controls mapped|12 target controls covered

12%

NIST SP 800-218

26 source controls mapped|24 target controls covered

APPI

13 source controls mapped|5 target controls covered

Authorised Economic Operator (AEO) Programmes - Global Standards

9 source controls mapped|6 target controls covered

ISO 27018:2019

8 source controls mapped|8 target controls covered

ISO/IEC 42001:2023

7 source controls mapped|6 target controls covered

NIST SP 800-181

6 source controls mapped|7 target controls covered

NIST SP 800-171A - Assessing Security Requirements for Controlled Unclassified Information (CUI)

5 source controls mapped|2 target controls covered

NIST SP 800-53A Rev. 5

5 source controls mapped|4 target controls covered

PTES

3 source controls mapped|5 target controls covered

PIC/S Guide to Good Manufacturing Practice for Medicinal Products

3 source controls mapped|5 target controls covered

ICH E6(R3) - Good Clinical Practice

3 source controls mapped|2 target controls covered

FDA Quality Management System Regulation (QMSR)

3 source controls mapped|3 target controls covered

ISO 15189:2022 - Medical Laboratories Requirements for Quality and Competence

3 source controls mapped|5 target controls covered

IEC 62304:2015 Medical Device Software Lifecycle Processes

3 source controls mapped|4 target controls covered

ISO/IEC 17025:2017 - General Requirements for Testing and Calibration

3 source controls mapped|3 target controls covered

ISO/IEC 25012:2008 - Data Quality Model

3 source controls mapped|3 target controls covered

FSSC 22000 - Food Safety System Certification

2 source controls mapped|1 target controls covered

GLOBALG.A.P. Integrated Farm Assurance (IFA) Standard v6

2 source controls mapped|2 target controls covered

GS1 Global Standards - Supply Chain Traceability and Data Security

2 source controls mapped|2 target controls covered

SWIFT CSCF

2 source controls mapped|3 target controls covered

SQF Code Edition 9 - Safe Quality Food

2 source controls mapped|1 target controls covered

21 CFR Part 211 - Current Good Manufacturing Practice

2 source controls mapped|3 target controls covered

21 CFR Part 58 - Good Laboratory Practice (GLP)

2 source controls mapped|1 target controls covered

Singapore AI Governance Framework

2 source controls mapped|1 target controls covered

US Foreign Corrupt Practices Act (FCPA)

1 source controls mapped|1 target controls covered

WCAG 2.2

1 source controls mapped|1 target controls covered

W3C Verifiable Credentials (VC) Data Model 2.0

1 source controls mapped|1 target controls covered

Vietnam Law on Cybersecurity (No. 116/2025/QH15)

1 source controls mapped|1 target controls covered

USMCA Chapter 19 - Digital Trade (United States-Mexico-Canada Agreement)

1 source controls mapped|1 target controls covered

UK Gambling Commission LCCP and Remote Technical Standards

1 source controls mapped|2 target controls covered

UK GDPR (UK General Data Protection Regulation)

1 source controls mapped|1 target controls covered

Regional Comprehensive Economic Partnership (RCEP) - E-Commerce Chapter

1 source controls mapped|1 target controls covered

UK Bribery Act 2010

1 source controls mapped|3 target controls covered

Trinidad and Tobago Data Protection Act 2011

1 source controls mapped|3 target controls covered

TEFCA - Trusted Exchange Framework and Common Agreement

1 source controls mapped|1 target controls covered

Tanzania Personal Data Protection Act 2022

1 source controls mapped|2 target controls covered

SLSA

1 source controls mapped|1 target controls covered

SIG (Shared Assessments)

1 source controls mapped|1 target controls covered

Regulation on the European Health Data Space (EHDS)

1 source controls mapped|1 target controls covered

Protective Security Policy Framework (PSPF) Release 2026

1 source controls mapped|1 target controls covered

PSD2 SCA

1 source controls mapped|1 target controls covered

Philippines Cybercrime Prevention Act (RA 10175)

1 source controls mapped|1 target controls covered

PCAOB AS 2201 - Audit of Internal Control Over Financial Reporting (ICFR)

1 source controls mapped|2 target controls covered

Pakistan Personal Data Protection Bill 2023

1 source controls mapped|2 target controls covered

OWASP Top 10:2025

1 source controls mapped|1 target controls covered

OWASP SAMM

1 source controls mapped|1 target controls covered

OWASP MASVS

1 source controls mapped|1 target controls covered

OWASP DevSecOps Maturity Model (DSOMM)

1 source controls mapped|2 target controls covered

OWASP ASVS

1 source controls mapped|1 target controls covered

OSFI B-13

1 source controls mapped|1 target controls covered

OpenSSF Scorecard

1 source controls mapped|1 target controls covered

Open Banking Security

1 source controls mapped|1 target controls covered

OCC Heightened Standards (12 CFR Part 30, Appendix D)

1 source controls mapped|1 target controls covered

O-RAN WG11 Security Specification

1 source controls mapped|3 target controls covered

NRC 10 CFR 73.54 - Nuclear Facility Cybersecurity

1 source controls mapped|5 target controls covered

Notifiable Data Breaches Scheme (Australia)

1 source controls mapped|1 target controls covered

NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems

1 source controls mapped|2 target controls covered

NIST SP 800-92

1 source controls mapped|1 target controls covered

NIST SP 800-88

1 source controls mapped|1 target controls covered

NIST SP 800-82 Revision 3: Guide to Industrial Control Systems (ICS) Security

1 source controls mapped|2 target controls covered

NIST SP 800-63-4

1 source controls mapped|1 target controls covered

NIST SP 800-61 Rev. 3

1 source controls mapped|1 target controls covered

NIST SP 800-146

1 source controls mapped|1 target controls covered

NIST SP 800-145

1 source controls mapped|1 target controls covered

NIST SP 800-144

1 source controls mapped|1 target controls covered

NIST SP 800-137

1 source controls mapped|1 target controls covered

NIST SP 800-123

1 source controls mapped|1 target controls covered

NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment)

1 source controls mapped|1 target controls covered

NIST Post-Quantum Cryptography Standards (FIPS 203, 204, 205)

1 source controls mapped|1 target controls covered

Nigeria Data Protection Act 2023 (NDPA)

1 source controls mapped|3 target controls covered

Nebraska Data Privacy Act

1 source controls mapped|3 target controls covered

NATO STANAG 4774 (Confidentiality Metadata Labels) and STANAG 4778 (Metadata Binding)

1 source controls mapped|2 target controls covered

MTCS (Singapore)

1 source controls mapped|2 target controls covered

Monetary Authority of Singapore Technology Risk Management Guidelines

1 source controls mapped|1 target controls covered

MITRE D3FEND

1 source controls mapped|1 target controls covered

MITRE ATT&CK

1 source controls mapped|1 target controls covered

South Korea PIPA

1 source controls mapped|1 target controls covered

ITU Radio Regulations and Space Security Standards

1 source controls mapped|1 target controls covered

ITAR - International Traffic in Arms Regulations

1 source controls mapped|1 target controls covered

Italy Personal Data Protection Code (Legislative Decree No. 196/2003, amended 2018)

1 source controls mapped|1 target controls covered

Israel Protection of Privacy Law (5741-1981)

1 source controls mapped|2 target controls covered

ISMAP (Japan)

1 source controls mapped|1 target controls covered

India Account Aggregator Framework (RBI)

1 source controls mapped|1 target controls covered

IMO Maritime Cybersecurity Guidelines (MSC-FAL.1/Circ.3/Rev.4)

1 source controls mapped|1 target controls covered

ICH Q10 - Pharmaceutical Quality System

1 source controls mapped|2 target controls covered

ICAO Annex 17 - Aviation Security (AVSEC)

1 source controls mapped|1 target controls covered

IATF 16949:2016 - Quality Management System for Automotive Production

1 source controls mapped|2 target controls covered

IATA Operational Safety Audit (IOSA) Standards Manual

1 source controls mapped|1 target controls covered

IAEA Nuclear Security Series - Computer Security at Nuclear Facilities (NSS-17-T Rev 1)

1 source controls mapped|3 target controls covered

HKMA SPM

1 source controls mapped|1 target controls covered

HKMA Cyber Resilience Assessment Framework (C-RAF)

1 source controls mapped|1 target controls covered

GLI-33 - Gaming Laboratories International Event Wagering Systems

1 source controls mapped|1 target controls covered

GLBA

1 source controls mapped|1 target controls covered

GAMP 5 - Good Automated Manufacturing Practice

1 source controls mapped|2 target controls covered

FTC GLBA Safeguards Rule (16 CFR Part 314)

1 source controls mapped|1 target controls covered

French Sapin II Law (Law No. 2016-1691)

1 source controls mapped|1 target controls covered

Florida Digital Bill of Rights (FDBR)

1 source controls mapped|2 target controls covered

FedRAMP Rev 5

1 source controls mapped|4 target controls covered

Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (UAE PDPL)

1 source controls mapped|2 target controls covered

FCC Customer Proprietary Network Information (CPNI) and Data Breach Rules (47 CFR 64.2001-2011)

1 source controls mapped|2 target controls covered

FATF Recommendation 16 - Payment Transparency (Travel Rule)

1 source controls mapped|1 target controls covered

UK Telecommunications (Security) Act 2021

1 source controls mapped|1 target controls covered

AICPA Privacy Management Framework (PMF)

1 source controls mapped|2 target controls covered

ISO 22320:2018

1 source controls mapped|3 target controls covered

ISO/IEC 29115:2013 - Entity Authentication Assurance Framework

1 source controls mapped|1 target controls covered

Bermuda Monetary Authority (BMA) Cyber Risk Management Code of Conduct

1 source controls mapped|1 target controls covered

DAMA-DMBOK2 - Data Management Body of Knowledge (2nd Edition)

1 source controls mapped|3 target controls covered

IAIS Insurance Core Principles (ICPs)

1 source controls mapped|1 target controls covered

ISO 41001:2018 - Facility Management Systems

1 source controls mapped|2 target controls covered

ISO 14064 - Greenhouse Gas Accounting and Verification (Parts 1-3)

1 source controls mapped|1 target controls covered

Annex 11 to EU GMP - Computerised Systems

1 source controls mapped|3 target controls covered

Connecticut Data Privacy Act (CTDPA)

1 source controls mapped|1 target controls covered

ISO/IEC 29100:2024

1 source controls mapped|3 target controls covered

Kuwait National Cybersecurity Framework

1 source controls mapped|1 target controls covered

ISO/IEC 27557:2022 - Organisational Privacy Risk Management

1 source controls mapped|3 target controls covered

ISO/IEC 27014:2020

1 source controls mapped|2 target controls covered

ISO/IEC 23837:2023

1 source controls mapped|1 target controls covered

WHO Global Strategy on Digital Health 2020-2025

1 source controls mapped|1 target controls covered

ISO/IEC 29147:2018

1 source controls mapped|2 target controls covered

ISO 26262:2018 - Functional Safety for Road Vehicles

1 source controls mapped|1 target controls covered

SANS Incident Handler's Handbook and PICERL Methodology

1 source controls mapped|2 target controls covered

Barbados Data Protection Act 2019

1 source controls mapped|1 target controls covered

ISO/IEC 27004:2016

1 source controls mapped|3 target controls covered

Automotive SPICE (ASPICE) v4.1 - Process Assessment Model

1 source controls mapped|2 target controls covered

Rhode Island Data Transparency and Privacy Protection Act (RIDTPPA)

1 source controls mapped|1 target controls covered

ISO/IEC 27050-1:2019

1 source controls mapped|1 target controls covered

NIST SP 800-190

1 source controls mapped|1 target controls covered

ISO/IEC 27043:2015

1 source controls mapped|1 target controls covered

South Korea ISMS-P

1 source controls mapped|1 target controls covered

NIST SP 800-124 Revision 2 - Guidelines for Managing the Security of Mobile Devices

1 source controls mapped|3 target controls covered

COBIT 2019

1 source controls mapped|1 target controls covered

US SEC Digital Assets and Crypto Regulatory Framework

1 source controls mapped|2 target controls covered

FFIEC IT Examination Handbook

1 source controls mapped|1 target controls covered

Singapore Government Instruction Manual on ICT&SS Management (IM8)

1 source controls mapped|1 target controls covered

ISO/IEC 29134:2023

1 source controls mapped|1 target controls covered

PCI SSF

1 source controls mapped|1 target controls covered

Illinois Biometric Information Privacy Act (BIPA)

1 source controls mapped|1 target controls covered

Austria Data Protection Act (Datenschutzgesetz, DSG, amended 2018)

1 source controls mapped|2 target controls covered

IEC 60601-1 - Medical Electrical Equipment Safety

1 source controls mapped|2 target controls covered

ISO 56002

1 source controls mapped|2 target controls covered

SSAE 18 - Attestation Standards (SOC Reporting)

1 source controls mapped|2 target controls covered

ASIS SPC.1-2009 - Organizational Resilience Standard

1 source controls mapped|1 target controls covered

Switzerland New Federal Act on Data Protection (nFADP/nDSG, 2023)

1 source controls mapped|1 target controls covered

PCI P2PE

1 source controls mapped|1 target controls covered

Science Based Targets Initiative (SBTi) - Net-Zero Standard

1 source controls mapped|2 target controls covered

Singapore Cybersecurity Act 2018

1 source controls mapped|1 target controls covered

Albania Law No. 124/2024 on Personal Data Protection

1 source controls mapped|2 target controls covered

ISO/IEC 30111:2019

1 source controls mapped|2 target controls covered

ISO 8000 - Data Quality

1 source controls mapped|2 target controls covered

ISO/IEC 27400:2022

1 source controls mapped|1 target controls covered

UK Open Banking Standard

1 source controls mapped|1 target controls covered

AWWA Cybersecurity Guidance for the Water Sector (American Water Works Association)

1 source controls mapped|1 target controls covered

Sweden Data Protection Act (Dataskyddslag, 2018:218)

1 source controls mapped|1 target controls covered

ISO 20400:2017 - Sustainable Procurement

1 source controls mapped|2 target controls covered

PCI PIN Security

1 source controls mapped|1 target controls covered

ISO/IEC 27003:2017

1 source controls mapped|1 target controls covered

ISO/IEC 23894:2023

1 source controls mapped|3 target controls covered

ISO 28001:2007 Supply Chain Security Management

1 source controls mapped|1 target controls covered

IEC 62351 - Power Systems Communication Security

1 source controls mapped|1 target controls covered

ISO/SAE 21434

1 source controls mapped|1 target controls covered

Azerbaijan Law on Personal Data (2010)

1 source controls mapped|1 target controls covered

CISA Cross-Sector Cybersecurity Performance Goals (CPG) 2.0

1 source controls mapped|1 target controls covered

ISO/IEC 27031:2011

1 source controls mapped|1 target controls covered

ISO/IEC 27011:2024

1 source controls mapped|2 target controls covered

Belgium Data Protection Act (Wet van 30 juli 2018, Loi du 30 juillet 2018)

1 source controls mapped|1 target controls covered

DFARS 252.204-7012 - Safeguarding Covered Defense Information

1 source controls mapped|1 target controls covered

ISO 19650 - Organisation and Digitisation of Information about Buildings and Civil Engineering Works (BIM)

1 source controls mapped|3 target controls covered

ISO/IEC 27007:2020

1 source controls mapped|1 target controls covered

ISO 37001:2016

1 source controls mapped|1 target controls covered

Compare PCI DSS 4.0 with SOC 2

Coverage is not the same as your position

This page shows what PCI DSS 4.0 overlaps with in general. Where your organisation actually stands, against the standard you are going for and the certifications you already hold, is a different question. Same graph and the same recorded refutations, scoped to you rather than to a pair.

The Compliance Position Diagnostic, $5,000 fixed, ten business days

What is PCI DSS 4.0 and who does it apply to?

PCI DSS 4.0 is a compliance framework from International (payment card industry; enforced contractually by payment brands and acquirers) with 16 domains and 280 controls. PCI DSS, the PCI Security Standards Council's minimum set of technical and operational controls for every entity that stores, processes or transmits payment card account data or can affect its security, in twelve principal requirements (network security controls, secure configuration, stored account data, transmission encryption, anti-malware, secure software, need-to-know access, identification and authentication, physical security, logging and monitoring, security testing, policy and programs) plus Appendix A for multi-tenant providers, SSL/early TLS POS terminals and designated entities. Read against v4.0.1 (June 2024), the current edition: 280 requirements. It is used by organisations to establish and maintain compliance with industry standards and regulatory requirements.

What does PCI DSS 4.0 actually require?

PCI DSS 4.0 has 280 controls organised across 16 domains. The largest domains are Req 12: Information Security Policies (37 controls), Req 3: Protect Stored Account Data (29 controls), Req 8: Identify and Authenticate Users (29 controls). Each control defines specific requirements that organisations must implement to achieve compliance.

If I already comply with another framework, how much of PCI DSS 4.0 do I already cover?

PCI DSS 4.0 maps to 198 other compliance frameworks. The top mapping partners are SOC 2 (88% coverage), ISO 27002:2022 (88% coverage), NIST SP 800-53 Rev 5 (88% coverage). Use our comparison tool to explore control-level mappings between frameworks.

How do I implement PCI DSS 4.0?

Start your PCI DSS 4.0 compliance journey by running a self-assessment on our platform to identify your current compliance posture. Our AI advisory can answer specific questions about PCI DSS 4.0 requirements, and cross-framework mapping helps you leverage existing controls from other frameworks you may already comply with. Create a free account to access all 280 controls and track your progress.

Start Your Compliance Journey

Create a free account to run self-assessments, get AI advisory, and track your compliance progress across 868 frameworks.

Get Started Free →

Free forever — no credit card required