PCI DSS 4.0

International

12 domains

168 controls

Payment Card Industry Data Security Standard version 4.0, published by PCI Security Standards Council.

Unverified

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

27 controls

Controls in the Req 10: Logging and Monitoring domain of PCI DSS 4.0 — 27 controls
Code	Title	Description
10.1.1	Policy on the use of cryptographic controls (cloud)	Cryptographic controls shall be applied to data in transit and at rest within cloud services, with clear key custody.
10.1.2	Key management (cloud)	Cryptographic key lifecycle in cloud must define generation, storage in HSM or KMS, rotation, revocation, and separation...
10.2.1	Audit logs enabled on system components	Audit logs are enabled and active for all system components and cardholder data.
10.2.1.1	Log all user access to CHD	Audit logs capture all individual user access to cardholder data.
10.2.1.2	Log all admin actions	Audit logs capture all actions taken by any individual with administrative access, including any interactive use of appl...
10.2.1.3	Log access to audit logs	Audit logs capture all access to audit logs.
10.2.1.4	Log invalid logical access attempts	Audit logs capture all invalid logical access attempts.
10.2.1.5	Log changes to identification and authentication	Audit logs capture all changes to identification and authentication credentials, including creation, elevation, and modi...
10.2.1.6	Log initialization, stopping, or pausing of logs	Audit logs capture all initialization of new audit logs and all starting, stopping, or pausing of existing audit logs.
10.2.1.7	Log creation and deletion of system level objects	Audit logs capture all creation and deletion of system-level objects.
10.2.2	Audit log content	Audit logs record at least user identification, type of event, date and time, success or failure indication, origination...
10.3.1	Read access to logs restricted	Read access to audit log files is limited to those with a job-related need.
10.3.2	Logs protected from modification	Audit log files are protected to prevent modifications by individuals.
10.3.3	Logs backed up to central server	Audit log files, including those for external-facing technologies, are promptly backed up to a secure, central, internal...
10.3.4	File integrity or change detection on logs	File integrity monitoring or change-detection mechanisms are used on audit logs to ensure that existing log data cannot...
10.4.1	Daily log review for critical systems	The following audit logs are reviewed at least daily: all security events, logs of all CDE system components, logs of cr...
10.4.1.1	Automated mechanisms for log review	Automated mechanisms are used to perform audit log reviews.
10.4.2	Periodic review of other system component logs	Logs of all other system components (those not specified in 10.4.1) are reviewed periodically.
10.4.2.1	Frequency defined by TRA	The frequency of periodic reviews for all other system components is defined in the entity's targeted risk analysis.
10.4.3	Exceptions and anomalies addressed	Exceptions and anomalies identified during the review process are addressed.
10.5.1	Audit log retention 12 months	Audit log history is retained for at least 12 months, with at least the most recent three months immediately available f...
10.6.1	Time synchronization in use	System clocks and time are synchronized using time-synchronization technology.
10.6.2	Time settings consistent and accurate	Systems are configured to the correct and consistent time, with central time servers receiving time from external indust...
10.6.3	Time settings protected	Time synchronization settings and data are protected, with access to time data restricted and changes logged and monitor...
10.7.1	Critical security control failure detection (SP)	Additional requirement for service providers: failures of critical security control systems are detected, alerted, and a...
10.7.2	Critical security control failure detection (all entities)	Failures of critical security control systems are detected, alerted, and addressed promptly for all entities (not just s...
10.7.3	Failure response timeline	Failures of critical security control systems are responded to promptly, including restoring functions, identifying caus...

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	Testing policy documented	Security policies and operational procedures for Requirement 11 are documented, kept up to date, in use, and known to af...
11.1.2	Testing roles assigned	Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood.
11.2.1	Wireless AP detection	Authorized and unauthorized wireless access points are managed, with testing for the presence of wireless APs at least o...
11.2.2	Authorized wireless AP inventory	An inventory of authorized wireless access points is maintained, including a documented business justification.
11.3.1	Internal vulnerability scans quarterly	Internal vulnerability scans are performed at least once every three months, with high-risk and critical vulnerabilities...
11.3.1.1	Address non-high vulnerabilities per TRA	All other applicable vulnerabilities (not classified as high-risk or critical) are managed via the entity's targeted ris...
11.3.1.2	Authenticated internal scans	Internal vulnerability scans are performed via authenticated scanning, with credentials, where supported.
11.3.1.3	Internal scans after significant changes	Internal vulnerability scans are performed after any significant change, with high-risk and critical vulnerabilities res...
11.3.2	External vulnerability scans quarterly by ASV	External vulnerability scans are performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV)...
11.3.2.1	External scans after significant change	External vulnerability scans are performed after any significant change, with vulnerabilities scored 4.0 or higher by CV...
11.4.1	Penetration testing methodology defined	A penetration testing methodology is defined, documented, and implemented covering industry-accepted approaches, CDE per...
11.4.2	Internal penetration testing annually	Internal penetration testing is performed at least once every 12 months and after any significant infrastructure or appl...
11.4.3	External penetration testing annually	External penetration testing is performed at least once every 12 months and after any significant infrastructure or appl...
11.4.4	Pen test findings remediated	Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected, with penetration tes...
11.4.5	Segmentation testing	If segmentation is used to isolate the CDE, penetration testing is performed at least every 12 months and after changes...
11.4.6	Segmentation testing (service providers) every 6 months	Additional requirement for service providers: if segmentation is used, segmentation penetration testing is performed at...
11.4.7	Multi-tenant pen test support	Additional requirement for multi-tenant service providers: support customer requests for external penetration testing of...
11.5.1	IDS/IPS in place	Intrusion detection or intrusion prevention techniques are used to detect or prevent intrusions into the network, monito...
11.5.1.1	Covert malware channel detection (SP)	Additional requirement for service providers: intrusion detection or prevention techniques detect, alert on, or prevent...
11.5.2	Change detection mechanism (FIM)	A change-detection mechanism (e.g., file integrity monitoring) is deployed to alert personnel to unauthorized modificati...
11.6.1	Payment page change and tamper detection	A change- and tamper-detection mechanism is deployed for payment pages to alert personnel to unauthorized modifications...

Req 12: Information Security Policies

35 controls

Controls in the Req 12: Information Security Policies domain of PCI DSS 4.0 — 35 controls
Code	Title	Description
12.1.3	Capacity management (cloud)	Capacity planning must account for elastic cloud consumption, quota limits, and noisy-neighbour effects, with CSP publis...
12.1.4	CISO or equivalent responsibility	Responsibility for information security is formally assigned to a Chief Information Security Officer or other knowledgea...
12.10.1	Incident response plan	An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident...
12.10.2	IRP reviewed and tested annually	The incident response plan is reviewed at least once every 12 months and updated as needed, and tested annually.
12.10.3	24/7 incident response coverage	Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incident...
12.10.4	Incident responder training	Personnel responsible for responding to suspected or confirmed security incidents are appropriately and periodically tra...
12.10.4.1	Periodic IR responder skill review	Frequency of periodic training for incident response personnel is defined in the entity's targeted risk analysis.
12.10.5	IRP includes monitoring and response to security control alerts	The incident response plan includes monitoring and responding to alerts from security monitoring systems including IDS/I...
12.10.6	IRP refined based on lessons learned	The security incident response plan is modified and evolved according to lessons learned and to incorporate industry dev...
12.10.7	Response procedures for PAN detection in unexpected locations	Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected,...
12.2.1	Acceptable use policies for end-user technologies	Acceptable use policies for end-user technologies are documented and implemented, addressing approval, authentication, i...
12.3.1	Information backup (cloud)	Backups of cloud-hosted data shall be defined, performed and tested in line with retention needs.
12.3.2	TRA for customized approach	A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach, i...
12.3.3	Cryptographic cipher suites and protocols inventory	Cryptographic cipher suites and protocols in use are documented and reviewed at least every 12 months, with a plan to ad...
12.3.4	Hardware and software technologies reviewed annually	Hardware and software technologies in use are reviewed at least once every 12 months to confirm vendor support and addre...
12.4.1	Event logging (cloud)	Event logs from cloud services shall be produced, kept and reviewed.
12.4.2	Quarterly PCI compliance reviews (SP)	Additional requirement for service providers: reviews are performed at least once every three months to confirm that per...
12.4.2.1	Documentation of quarterly reviews (SP)	Additional requirement for service providers: reviews per 12.4.2 are documented and include results, remediation actions...
12.5.1	Inventory of system components in scope	An inventory of system components in scope for PCI DSS is maintained and kept current, including a description of functi...
12.5.2	PCI DSS scope documented and confirmed annually	PCI DSS scope is documented and confirmed at least once every 12 months by identifying all data flows, system components...
12.5.2.1	Service provider scope confirmed every 6 months	Additional requirement for service providers: PCI DSS scope is documented and confirmed at least once every six months a...
12.5.3	Impact analysis on org structure changes (SP)	Additional requirement for service providers: significant changes to organizational structure result in a documented rev...
12.6.1	Management of technical vulnerabilities (cloud)	Vulnerability management must cover cloud workloads, container images, serverless functions, and platform configurations...
12.6.2	Security awareness program reviewed annually	The security awareness program is reviewed at least once every 12 months and updated as needed to address emerging threa...
12.6.3	Security awareness training delivered	Personnel receive security awareness training upon hire and at least once every 12 months, covering threats and vulnerab...
12.6.3.1	Training on phishing and social engineering	Security awareness training includes threats and vulnerabilities that could impact the security of cardholder data inclu...
12.6.3.2	Training on acceptable use of end-user technologies	Security awareness training includes acceptable use of end-user technologies in accordance with the entity's policies.
12.7.1	Personnel screening	Potential personnel who will have access to the CDE are screened, within the constraints of local laws, to minimize the...
12.8.1	Third-party service provider inventory	A list of all third-party service providers (TPSPs) with which account data is shared, or that could affect the security...
12.8.2	Written agreements with TPSPs	Written agreements with TPSPs are maintained, including acknowledgement by the TPSP that they are responsible for the se...
12.8.3	TPSP due diligence	An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.
12.8.4	TPSP compliance monitored	A program is implemented to monitor TPSPs' PCI DSS compliance status at least once every 12 months.
12.8.5	Responsibility matrix with TPSPs	Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, an...
12.9.1	TPSP written acknowledgement of responsibility (SP)	Additional requirement for service providers: TPSPs acknowledge in writing to customers that they are responsible for th...
12.9.2	TPSP supports customer requests for compliance info (SP)	Additional requirement for service providers: TPSPs support their customers' requests for information to meet Requiremen...

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	NSC policies and procedures documented	All security policies and operational procedures for Requirement 1 are documented, kept current, in use, and known to af...
1.1.2	Roles and responsibilities for Requirement 1	Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.
1.2.1	NSC configuration standards defined	Configuration standards for network security controls are defined, implemented, and maintained.
1.2.2	Changes to NSC reviewed and approved	All changes to network connections and configurations of NSCs are approved and managed via the formal change control pro...
1.2.3	Network diagrams maintained	An accurate network diagram is maintained showing all connections between the CDE and other networks.
1.2.4	Data flow diagram of account data	A current data flow diagram is maintained showing all account data flows across systems and networks.
1.2.5	Services, protocols, ports inventoried and justified	All services, protocols, and ports allowed are identified, approved, and have a documented business need.
1.2.6	Security features for insecure services defined	Security features are defined and implemented for all services, protocols, and ports in use that are considered to be in...
1.2.7	NSC rule sets reviewed every six months	Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.
1.2.8	Configuration files secured and synchronised	Configuration files for NSCs are secured from unauthorized access and kept consistent with active configurations.
1.3.1	Inbound traffic to CDE restricted	Inbound traffic to the CDE is restricted to only that which is necessary; all other traffic is denied.
1.3.2	Outbound traffic from CDE restricted	Outbound traffic from the CDE is restricted to only that which is necessary; all other traffic is denied.
1.3.3	NSCs between wireless and CDE	NSCs are installed between all wireless networks and the CDE, denying all wireless traffic except authorized flows.
1.4.1	NSCs between trusted and untrusted networks	NSCs are implemented between trusted and untrusted networks.
1.4.2	Inbound traffic from untrusted networks restricted	Inbound traffic from untrusted networks to trusted networks is restricted to communications with authorized publicly acc...
1.4.3	Anti-spoofing measures implemented	Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.
1.4.4	Account data not stored on internet-accessible systems	System components that store cardholder data are not directly accessible from untrusted networks.
1.4.5	Internal IP and routing information protected	The disclosure of internal IP addresses and routing information is limited to authorized parties.
1.5.1	Security controls on dual-connected computing devices	Security controls are implemented on any computing devices that connect to both untrusted networks and the CDE to preven...

Req 2: Secure Configurations

7 controls

Controls in the Req 2: Secure Configurations domain of PCI DSS 4.0 — 7 controls
Code	Title	Description
2.2.3	Primary functions isolated or secured to highest level	Primary functions requiring different security levels are managed so that only one primary function exists per component...
2.2.4	Only necessary services enabled	Only necessary services, protocols, daemons, and functions are enabled. All unnecessary functionality is removed or disa...
2.2.5	Insecure services or protocols documented	If any insecure services, protocols, or daemons are present, business justification is documented and additional securit...
2.2.6	System security parameters configured	System security parameters are configured to prevent misuse.
2.2.7	Non-console administrative access encrypted	All non-console administrative access is encrypted using strong cryptography.
2.3.1	Wireless vendor defaults changed before installation	For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at...
2.3.2	Wireless encryption keys rotated	For wireless environments connected to the CDE, encryption keys are changed when personnel with knowledge of the key lea...

Req 3: Protect Stored Account Data

22 controls

Controls in the Req 3: Protect Stored Account Data domain of PCI DSS 4.0 — 22 controls
Code	Title	Description
3.3.1.1	Full track data not stored after authorization	The full contents of any track are not retained after authorization.
3.3.1.2	Card verification code not stored after authorization	The card verification code is not retained after authorization.
3.3.1.3	PIN and PIN block not stored after authorization	Personal identification number (PIN) and the encrypted PIN block are not retained after authorization.
3.3.2	SAD stored prior to authorization is encrypted	SAD stored electronically prior to completion of authorization is encrypted using strong cryptography.
3.3.3	SAD storage by issuers limited	For issuers and entities supporting issuing services that store SAD, SAD storage is limited to that needed for legitimat...
3.4.2	Technical controls prevent unauthorized PAN copy	When using remote-access technologies, technical controls prevent copy and relocation of PAN for all personnel except th...
3.5.1	PAN rendered unreadable wherever stored	PAN is rendered unreadable anywhere it is stored using one of: one-way hashes, truncation, index tokens with secure pads...
3.5.1.1	Hashes of PAN use keyed cryptographic functions	Hashes used to render PAN unreadable are keyed cryptographic hashes of the entire PAN with associated key management pro...
3.5.1.2	Disk-level encryption with logical access controls	If disk-level or partition-level encryption is used to render PAN unreadable, it is implemented only on removable media...
3.5.1.3	Disk-level encryption key management	If disk-level or partition-level encryption is used, cryptographic keys are managed in accordance with Requirements 3.6...
3.6.1.1	Documented description of cryptographic architecture	A documented description of the cryptographic architecture is maintained, including algorithms, protocols, keys, key str...
3.6.1.2	Secret and private keys restricted to fewest custodians	Secret and private keys used to protect stored account data are stored in encrypted form, within a secure cryptographic...
3.6.1.3	Access to cryptographic keys restricted	Access to cleartext cryptographic key components is restricted to the fewest custodians necessary.
3.6.1.4	Cryptographic keys stored in fewest possible locations	Cryptographic keys are stored in the fewest possible locations.
3.7.2	Secure key distribution	Key management policies and procedures address secure distribution of cryptographic keys.
3.7.3	Secure key storage	Key management policies and procedures address secure storage of cryptographic keys.
3.7.4	Cryptoperiod and key changes	Key management policies and procedures address cryptographic key changes for keys that have reached the end of their cry...
3.7.5	Retirement or replacement of keys	Key management policies and procedures address retirement, replacement, or destruction of keys when integrity has been w...
3.7.6	Manual cleartext key operations use split knowledge	Where manual cleartext key management operations are performed, they use split knowledge and dual control.
3.7.7	Prevent unauthorised substitution of keys	Key management policies prevent unauthorized substitution of cryptographic keys.
3.7.8	Custodians acknowledge responsibilities	Key custodians formally acknowledge in writing that they understand and accept their key custodian responsibilities.
3.7.9	Service provider customer key responsibilities	Additional requirement for service providers: cryptographic keys used to protect stored customer account data are manage...

Req 4: Protect Cardholder Data in Transit

2 controls

Controls in the Req 4: Protect Cardholder Data in Transit domain of PCI DSS 4.0 — 2 controls
Code	Title	Description
4.2.1.1	Inventory of trusted keys and certificates	An inventory of trusted keys and certificates used to protect PAN during transmission is maintained.
4.2.1.2	Wireless networks transmitting PAN use strong cryptography	Wireless networks transmitting PAN or connected to the CDE use industry best practices for strong cryptography for authe...

Req 5: Anti-Malware

4 controls

Controls in the Req 5: Anti-Malware domain of PCI DSS 4.0 — 4 controls
Code	Title	Description
5.2.3.1	Frequency of periodic evaluations per targeted risk analysis	The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entit...
5.3.2.1	Periodic scan frequency per targeted risk analysis	If periodic scans are used to meet 5.3.2, the frequency is defined in the entity's targeted risk analysis.
5.3.4	Audit logs for anti-malware enabled	Audit logs for the anti-malware solution are enabled and retained in accordance with Requirement 10.5.1.
5.3.5	Anti-malware cannot be disabled by users	Anti-malware mechanisms cannot be disabled or altered by users unless specifically documented and authorized by manageme...

Req 6: Secure Systems and Software

5 controls

Controls in the Req 6: Secure Systems and Software domain of PCI DSS 4.0 — 5 controls
Code	Title	Description
6.2.3	Custom software reviewed prior to production	Bespoke and custom software is reviewed prior to release into production or to customers to identify and correct potenti...
6.2.3.1	Code review findings corrected	If manual code reviews are performed, code changes are reviewed by individuals other than the originating author who are...
6.2.4	Coding practices prevent common attacks	Software engineering techniques or other methods are defined and used by software development personnel to prevent or mi...
6.5.5	Live PANs not used in pre-production	Live PANs are not used in pre-production environments except where those environments are included in the CDE and protec...
6.5.6	Test data and accounts removed before production	Test data and test accounts are removed from system components before the system goes into production.

Req 7: Restrict Access by Need to Know

1 controls

Controls in the Req 7: Restrict Access by Need to Know domain of PCI DSS 4.0 — 1 controls
Code	Title	Description
7.2.5.1	App and system account review cadence	Application and system account access is reviewed at a frequency defined in the entity's targeted risk analysis (TRA).

Req 8: Identify and Authenticate Users

8 controls

Controls in the Req 8: Identify and Authenticate Users domain of PCI DSS 4.0 — 8 controls
Code	Title	Description
8.2.7	Third-party access managed	Accounts used by third parties to access, support, or maintain system components via remote access are managed and monit...
8.2.8	Session idle timeout	If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the ses...
8.3.10	Service provider customer password guidance	Additional requirement for service providers: guidance is provided to customers on changing passwords periodically when...
8.3.10.1	SP password rotation or posture	Additional requirement for service providers: customer passwords used as sole factor are changed at least every 90 days,...
8.3.11	Hardware token and other factor protection	When authentication factors such as physical or logical security tokens, smart cards, or certificates are used, the fact...
8.3.7	Password history	Individuals are not allowed to submit a new password or passphrase that is the same as any of the last four used.
8.3.8	Authentication policy communicated	Authentication policies and procedures are documented and communicated to all users, including guidance on selecting str...
8.3.9	Password change frequency if only factor	If passwords are the only authentication factor, they are changed at least every 90 days, or access to resources is dyna...

Req 9: Restrict Physical Access

17 controls

Controls in the Req 9: Restrict Physical Access domain of PCI DSS 4.0 — 17 controls
Code	Title	Description
9.2.3	Management of privileged access rights (cloud)	Privileged cloud roles (root, owner, global admin) must be limited, time-bound where possible, monitored, and subject to...
9.2.4	Management of secret authentication information (cloud)	Cloud API keys, access tokens, and service-account credentials must be stored in a secret manager, rotated, and never em...
9.3.1.1	Personnel access readily revoked	Physical access to sensitive areas within the CDE for personnel is revoked immediately upon termination, with all physic...
9.3.4	Visitor log retention	Visitor logs are retained for at least three months unless restricted by law, and include visitor name, firm, sponsor, d...
9.4.1	Information access restriction (cloud)	Access to information in cloud services must use least-privilege IAM policies with deny-by-default, scoped to resource a...
9.4.1.1	Offline media backup security	Offline media backups containing cardholder data are stored in a secure location, with security reviewed at least once e...
9.4.1.2	Offsite backup location reviewed	The security of the offline media backup location is reviewed at least once every 12 months.
9.4.2	Media classified by sensitivity	All media with cardholder data is classified in accordance with the sensitivity of the data.
9.4.3	Media sent outside facility secured	Media with cardholder data sent outside the facility is secured using a tracked secured courier or other delivery method...
9.4.4	Use of privileged utility programs (cloud)	CSP must control use of utilities capable of overriding system or application security in the cloud platform, with stric...
9.4.5	Inventory logs of electronic media	Inventory logs of all electronic media with cardholder data are maintained, and inventories are conducted at least once...
9.4.6	Hard copy media destruction	Hard copy materials with cardholder data are destroyed when no longer needed for business or legal reasons via crosscut...
9.4.7	Electronic media destruction	Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons, rendering cardho...
9.5.1	POI device protection	Point-of-interaction (POI) devices that capture payment card data are protected from tampering and unauthorized substitu...
9.5.1.1	POI inventory maintained	An up-to-date list of POI devices is maintained, including make, model, location, serial number, and other device charac...
9.5.1.2	POI tamper inspection	POI device surfaces are periodically inspected to detect tampering and unauthorized substitution, with frequency defined...
9.5.1.3	POI personnel training	Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of devices.

Your Compliance Coverage

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

ISO 27018:2019

8 controls mapped

Compare →

ISO 27002:2022

3 controls mapped

Compare →

NIST SP 800-218

3 controls mapped

Compare →

+ 2 more: ISO 50001:2018 - Energy Management Systems (1%), ISO 37001:2016 (1%)

See all 5 mapped frameworks ↓

Maps to 5 other frameworks

168 total controls

ISO 27018:2019

8 source controls mapped|8 target controls covered

ISO 27002:2022

3 source controls mapped|3 target controls covered

NIST SP 800-218

3 source controls mapped|7 target controls covered

ISO 50001:2018 - Energy Management Systems

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 ISO 27018:2019

Frequently Asked Questions

What is PCI DSS 4.0?

PCI DSS 4.0 is a compliance framework from International with 12 domains and 168 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 168 controls organised across 12 domains. The largest domains are Req 12: Information Security Policies (35 controls), Req 10: Logging and Monitoring (27 controls), Req 3: Protect Stored Account Data (22 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 5 other compliance frameworks. The top mapping partners are ISO 27018:2019 (5% coverage), ISO 27002:2022 (2% coverage), NIST SP 800-218 (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 168 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 718 frameworks.

Get Started Free →

Free forever — no credit card required