PCI DSS 4.0
Payment Card Industry Data Security Standard version 4.0, published by PCI Security Standards Council.
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 (12)
Req 10: Logging and Monitoring
| Code | Title |
|---|---|
| 10.1.1 | Logging policy documented |
| 10.1.2 | Logging roles assigned |
| 10.2.1 | Audit logs enabled on system components |
| 10.2.1.1 | Log all user access to CHD |
| 10.2.1.2 | Log all admin actions |
| 10.2.1.3 | Log access to audit logs |
| 10.2.1.4 | Log invalid logical access attempts |
| 10.2.1.5 | Log changes to identification and authentication |
| 10.2.1.6 | Log initialization, stopping, or pausing of logs |
| 10.2.1.7 | Log creation and deletion of system level objects |
| 10.2.2 | Audit log content |
| 10.3.1 | Read access to logs restricted |
| 10.3.2 | Logs protected from modification |
| 10.3.3 | Logs backed up to central server |
| 10.3.4 | File integrity or change detection on logs |
| 10.4.1 | Daily log review for critical systems |
| 10.4.1.1 | Automated mechanisms for log review |
| 10.4.2 | Periodic review of other system component logs |
| 10.4.2.1 | Frequency defined by TRA |
| 10.4.3 | Exceptions and anomalies addressed |
| 10.5.1 | Audit log retention 12 months |
| 10.6.1 | Time synchronization in use |
| 10.6.2 | Time settings consistent and accurate |
| 10.6.3 | Time settings protected |
| 10.7.1 | Critical security control failure detection (SP) |
| 10.7.2 | Critical security control failure detection (all entities) |
| 10.7.3 | Failure response timeline |
Req 11: Test Security Regularly
| Code | Title |
|---|---|
| 11.1.1 | Testing policy documented |
| 11.1.2 | Testing roles assigned |
| 11.2.1 | Wireless AP detection |
| 11.2.2 | Authorized wireless AP inventory |
| 11.3.1 | Internal vulnerability scans quarterly |
| 11.3.1.1 | Address non-high vulnerabilities per TRA |
| 11.3.1.2 | Authenticated internal scans |
| 11.3.1.3 | Internal scans after significant changes |
| 11.3.2 | External vulnerability scans quarterly by ASV |
| 11.3.2.1 | External scans after significant change |
| 11.4.1 | Penetration testing methodology defined |
| 11.4.2 | Internal penetration testing annually |
| 11.4.3 | External penetration testing annually |
| 11.4.4 | Pen test findings remediated |
| 11.4.5 | Segmentation testing |
| 11.4.6 | Segmentation testing (service providers) every 6 months |
| 11.4.7 | Multi-tenant pen test support |
| 11.5.1 | IDS/IPS in place |
| 11.5.1.1 | Covert malware channel detection (SP) |
| 11.5.2 | Change detection mechanism (FIM) |
| 11.6.1 | Payment page change and tamper detection |
Req 12: Information Security Policies
| Code | Title |
|---|---|
| 12.1.1 | Information security policy established |
| 12.1.2 | Policy reviewed and updated for changes |
| 12.1.3 | Security roles and responsibilities formalized |
| 12.1.4 | CISO or equivalent responsibility |
| 12.10.1 | Incident response plan |
| 12.10.2 | IRP reviewed and tested annually |
| 12.10.3 | 24/7 incident response coverage |
| 12.10.4 | Incident responder training |
| 12.10.4.1 | Periodic IR responder skill review |
| 12.10.5 | IRP includes monitoring and response to security control alerts |
| 12.10.6 | IRP refined based on lessons learned |
| 12.10.7 | Response procedures for PAN detection in unexpected locations |
| 12.2.1 | Acceptable use policies for end-user technologies |
| 12.3.1 | Targeted risk analysis for each PCI requirement allowing flexibility |
| 12.3.2 | TRA for customized approach |
| 12.3.3 | Cryptographic cipher suites and protocols inventory |
| 12.3.4 | Hardware and software technologies reviewed annually |
| 12.4.1 | Executive management responsibility (SP) |
| 12.4.2 | Quarterly PCI compliance reviews (SP) |
| 12.4.2.1 | Documentation of quarterly reviews (SP) |
| 12.5.1 | Inventory of system components in scope |
| 12.5.2 | PCI DSS scope documented and confirmed annually |
| 12.5.2.1 | Service provider scope confirmed every 6 months |
| 12.5.3 | Impact analysis on org structure changes (SP) |
| 12.6.1 | Security awareness program |
| 12.6.2 | Security awareness program reviewed annually |
| 12.6.3 | Security awareness training delivered |
| 12.6.3.1 | Training on phishing and social engineering |
| 12.6.3.2 | Training on acceptable use of end-user technologies |
| 12.7.1 | Personnel screening |
| 12.8.1 | Third-party service provider inventory |
| 12.8.2 | Written agreements with TPSPs |
| 12.8.3 | TPSP due diligence |
| 12.8.4 | TPSP compliance monitored |
| 12.8.5 | Responsibility matrix with TPSPs |
| 12.9.1 | TPSP written acknowledgement of responsibility (SP) |
| 12.9.2 | TPSP supports customer requests for compliance info (SP) |
Req 1: Network Security Controls
| Code | Title |
|---|---|
| 1.1.1 | NSC policies and procedures documented |
| 1.1.2 | Roles and responsibilities for Requirement 1 |
| 1.2.1 | NSC configuration standards defined |
| 1.2.2 | Changes to NSC reviewed and approved |
| 1.2.3 | Network diagrams maintained |
| 1.2.4 | Data flow diagram of account data |
| 1.2.5 | Services, protocols, ports inventoried and justified |
| 1.2.6 | Security features for insecure services defined |
| 1.2.7 | NSC rule sets reviewed every six months |
| 1.2.8 | Configuration files secured and synchronised |
| 1.3.1 | Inbound traffic to CDE restricted |
| 1.3.2 | Outbound traffic from CDE restricted |
| 1.3.3 | NSCs between wireless and CDE |
| 1.4.1 | NSCs between trusted and untrusted networks |
| 1.4.2 | Inbound traffic from untrusted networks restricted |
| 1.4.3 | Anti-spoofing measures implemented |
| 1.4.4 | Account data not stored on internet-accessible systems |
| 1.4.5 | Internal IP and routing information protected |
| 1.5.1 | Security controls on dual-connected computing devices |
Req 2: Secure Configurations
| Code | Title |
|---|---|
| 2.1.1 | Requirement 2 policies and procedures |
| 2.1.2 | Roles and responsibilities for Requirement 2 |
| 2.2.1 | Configuration standards developed |
| 2.2.2 | Vendor default accounts managed |
| 2.2.3 | Primary functions isolated or secured to highest level |
| 2.2.4 | Only necessary services enabled |
| 2.2.5 | Insecure services or protocols documented |
| 2.2.6 | System security parameters configured |
| 2.2.7 | Non-console administrative access encrypted |
| 2.3.1 | Wireless vendor defaults changed before installation |
| 2.3.2 | Wireless encryption keys rotated |
Req 3: Protect Stored Account Data
| Code | Title |
|---|---|
| 3.1.1 | Requirement 3 policies and procedures |
| 3.1.2 | Roles and responsibilities for Requirement 3 |
| 3.2.1 | Account data storage minimised |
| 3.3.1 | SAD not retained after authorization |
| 3.3.1.1 | Full track data not stored after authorization |
| 3.3.1.2 | Card verification code not stored after authorization |
| 3.3.1.3 | PIN and PIN block not stored after authorization |
| 3.3.2 | SAD stored prior to authorization is encrypted |
| 3.3.3 | SAD storage by issuers limited |
| 3.4.1 | PAN masked when displayed |
| 3.4.2 | Technical controls prevent unauthorized PAN copy |
| 3.5.1 | PAN rendered unreadable wherever stored |
| 3.5.1.1 | Hashes of PAN use keyed cryptographic functions |
| 3.5.1.2 | Disk-level encryption with logical access controls |
| 3.5.1.3 | Disk-level encryption key management |
| 3.6.1 | Procedures to protect cryptographic keys |
| 3.6.1.1 | Documented description of cryptographic architecture |
| 3.6.1.2 | Secret and private keys restricted to fewest custodians |
| 3.6.1.3 | Access to cryptographic keys restricted |
| 3.6.1.4 | Cryptographic keys stored in fewest possible locations |
| 3.7.1 | Key generation procedures |
| 3.7.2 | Secure key distribution |
| 3.7.3 | Secure key storage |
| 3.7.4 | Cryptoperiod and key changes |
| 3.7.5 | Retirement or replacement of keys |
| 3.7.6 | Manual cleartext key operations use split knowledge |
| 3.7.7 | Prevent unauthorised substitution of keys |
| 3.7.8 | Custodians acknowledge responsibilities |
| 3.7.9 | Service provider customer key responsibilities |
Req 4: Protect Cardholder Data in Transit
| Code | Title |
|---|---|
| 4.1.1 | Requirement 4 policies and procedures |
| 4.1.2 | Roles and responsibilities for Requirement 4 |
| 4.2.1 | Strong cryptography protects PAN in transit |
| 4.2.1.1 | Inventory of trusted keys and certificates |
| 4.2.1.2 | Wireless networks transmitting PAN use strong cryptography |
| 4.2.2 | PAN secured in end-user messaging |
Req 5: Anti-Malware
| Code | Title |
|---|---|
| 5.1.1 | Requirement 5 policies and procedures |
| 5.1.2 | Roles and responsibilities for Requirement 5 |
| 5.2.1 | Anti-malware solution deployed on all in-scope systems |
| 5.2.2 | Anti-malware addresses all malware types |
| 5.2.3 | Systems not at risk evaluated periodically |
| 5.2.3.1 | Frequency of periodic evaluations per targeted risk analysis |
| 5.3.1 | Anti-malware kept current |
| 5.3.2 | Active scanning or continuous behavioural analysis |
| 5.3.2.1 | Periodic scan frequency per targeted risk analysis |
| 5.3.3 | Removable media scanned |
| 5.3.4 | Audit logs for anti-malware enabled |
| 5.3.5 | Anti-malware cannot be disabled by users |
| 5.4.1 | Anti-phishing mechanisms protect personnel |
Req 6: Secure Systems and Software
| Code | Title |
|---|---|
| 6.1.1 | Requirement 6 policies and procedures |
| 6.1.2 | Roles and responsibilities for Requirement 6 |
| 6.2.1 | Bespoke and custom software developed securely |
| 6.2.2 | Software developers trained annually |
| 6.2.3 | Custom software reviewed prior to production |
| 6.2.3.1 | Code review findings corrected |
| 6.2.4 | Coding practices prevent common attacks |
| 6.3.1 | Security vulnerabilities identified |
| 6.3.2 | Bespoke and third-party software inventory |
| 6.3.3 | Security patches and updates installed |
| 6.4.1 | Public-facing web applications protected from attacks |
| 6.4.2 | Automated technical solution for web app attacks |
| 6.4.3 | Payment page scripts managed and authorised |
| 6.5.1 | Changes follow change control procedures |
| 6.5.2 | PCI DSS compliance confirmed after significant change |
| 6.5.3 | Pre-production environments separated from production |
| 6.5.4 | Roles and functions separated between environments |
| 6.5.5 | Live PANs not used in pre-production |
| 6.5.6 | Test data and accounts removed before production |
Req 7: Restrict Access by Need to Know
| Code | Title |
|---|---|
| 7.1.1 | Access control policy documented |
| 7.1.2 | Roles and responsibilities assigned |
| 7.2.1 | Access control model defined |
| 7.2.2 | Access assigned by job function |
| 7.2.3 | Required privileges approved |
| 7.2.4 | User account reviews |
| 7.2.5 | Application and system accounts managed |
| 7.2.5.1 | App and system account review cadence |
| 7.2.6 | Query repository access by application |
| 7.3.1 | Access control system in place |
| 7.3.2 | ACS configured to enforce permissions |
| 7.3.3 | Default deny on ACS |
Req 8: Identify and Authenticate Users
| Code | Title |
|---|---|
| 8.1.1 | Identification policy documented |
| 8.1.2 | Identification roles assigned |
| 8.2.1 | Unique user IDs |
| 8.2.2 | Group, shared, generic accounts controls |
| 8.2.3 | Service provider unique credentials per customer |
| 8.2.4 | Account lifecycle management |
| 8.2.5 | Terminated user access revoked |
| 8.2.6 | Inactive account disablement |
| 8.2.7 | Third-party access managed |
| 8.2.8 | Session idle timeout |
| 8.3.1 | Strong authentication factor required |
| 8.3.10 | Service provider customer password guidance |
| 8.3.10.1 | SP password rotation or posture |
| 8.3.11 | Hardware token and other factor protection |
| 8.3.2 | Strong cryptography for authentication factors |
| 8.3.3 | User identity verified before credential change |
| 8.3.4 | Invalid auth attempt lockout |
| 8.3.5 | Initial and reset password unique and changed |
| 8.3.6 | Password length and complexity |
| 8.3.7 | Password history |
| 8.3.8 | Authentication policy communicated |
| 8.3.9 | Password change frequency if only factor |
| 8.4.1 | MFA for administrative access |
| 8.4.2 | MFA for all access into CDE |
| 8.4.3 | MFA for remote access from outside network |
| 8.5.1 | MFA system not susceptible to replay or bypass |
| 8.6.1 | Interactive use of system accounts prevented |
| 8.6.2 | App and system account passwords not hardcoded |
| 8.6.3 | App and system account password protection |
Req 9: Restrict Physical Access
| Code | Title |
|---|---|
| 9.1.1 | Physical access policy documented |
| 9.1.2 | Physical security roles assigned |
| 9.2.1 | Facility entry controls |
| 9.2.1.1 | CCTV or access control of sensitive areas |
| 9.2.2 | Physical and logical access to network jacks |
| 9.2.3 | Physical access to wireless and networking restricted |
| 9.2.4 | Console access restricted |
| 9.3.1 | Personnel access to sensitive areas authorized |
| 9.3.1.1 | Personnel access readily revoked |
| 9.3.2 | Visitor authorization and management |
| 9.3.3 | Visitor badges and revocation |
| 9.3.4 | Visitor log retention |
| 9.4.1 | Media physically secured |
| 9.4.1.1 | Offline media backup security |
| 9.4.1.2 | Offsite backup location reviewed |
| 9.4.2 | Media classified by sensitivity |
| 9.4.3 | Media sent outside facility secured |
| 9.4.4 | Media movement authorized |
| 9.4.5 | Inventory logs of electronic media |
| 9.4.6 | Hard copy media destruction |
| 9.4.7 | Electronic media destruction |
| 9.5.1 | POI device protection |
| 9.5.1.1 | POI inventory maintained |
| 9.5.1.2 | POI tamper inspection |
| 9.5.1.3 | POI personnel training |
Your Compliance Coverage
If you comply with PCI DSS 4.0, you already cover:
NIS2 Directive Implementing Acts
2%
6 controls mapped
Compare →UK Telecommunications (Security) Act 2021
2%
6 controls mapped
Compare →OWASP DevSecOps Maturity Model (DSOMM)
2%
5 controls mapped
Compare →+ 567 more: UK Gambling Commission — Cyber Resilience Requirements (2%), C-TPAT — Customs-Trade Partnership Against Terrorism (2%)
See all 570 mapped frameworks ↓Maps to 570 other frameworks
Frequently Asked Questions
What is PCI DSS 4.0?
PCI DSS 4.0 is a compliance framework from International with 12 domains and 248 controls. Payment Card Industry Data Security Standard version 4.0, published by PCI Security Standards Council. It is used by organisations to establish and maintain compliance with industry standards and regulatory requirements.
How many controls does PCI DSS 4.0 have?
PCI DSS 4.0 has 248 controls organised across 12 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.
What frameworks does PCI DSS 4.0 map to?
PCI DSS 4.0 maps to 570 other compliance frameworks. The top mapping partners are NIS2 Directive Implementing Acts (2% coverage), UK Telecommunications (Security) Act 2021 (2% coverage), OWASP DevSecOps Maturity Model (DSOMM) (2% coverage). Use our comparison tool to explore control-level mappings between frameworks.
How do I get started with PCI DSS 4.0 compliance?
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 248 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 769 frameworks.
Get Started Free →Free forever — no credit card required