As companies strive to safeguard the accuracy and protection of their transactions, an exciting new development unfolds with PCI DSS compliance version 4.0.

The latest standard edition introduces innovative changes and improvements that reshape data security practices, preparing organizations for a resilient future.

So, without further ado, let’s delve into what the latest version of PCI DSS compliance has to serve for the best.


The latest version leaps, clarifying and elaborating the requirements by taking a simplistic approach to elaboration.

As per the summary of changes, three significant differences are present in the v4 PCI DSS- addition, modification, and condensation of requirements.

Moreover, the latest version of PCI DSS 4.0, in contrast to the previous version, 3.2.1, now has an additional section of limitations.

PCI DSS requirements are subject to limitations where country, state, or local laws take precedence. In case of conflict with federal laws, the latter supersedes compliance requirements. And implementers should adopt a neutral middle-ground approach for risk mitigation.


PCI DSS compliance v4 clarifies that certain requirements may apply to entities not directly handling a customer’s primary account number (PAN).


Version 4 of PCI DSS compliance clarifies the scope and definition of the cardholder data environment, enhancing compliance understanding.

Moreover, the amending members have considered the cloud and other system components in contrast to the previous version. This ensures the latest amendments remain current with cloud environment adaptation and on-premise infrastructure migration.

Changes in Requirements

In March 2022, authorities introduced PCI DSS v4.0 with significant modifications compared to the previous version. The most significant changes include:

  1. They integrated a tailored validation method allowing organizations to tailor their implementation according to risk evaluation.
  2. New regulations were introduced to enhance security measures for accessing cardholder data environments (CDEs) by authorizing and authenticating user and system access.
  3. They established new requirements for cryptographic controls intended to enforce the use of powerful encryption techniques for protecting cardholder data.
  4. New requirements for security awareness training aim to educate all authorized employees on potential hazards and strategies. Awareness can help protecting cardholder information within CDEs.

Requirement 1: Set Up and Maintain A Firewall

As per the latest update, requirement one shift reflects its focus on network security controls. This section has some minute changes to account for various technologies to implement security controls. Terms like firewalls and routers are interchanged with network security controls. They have included new tools that perform similar functions as traditional firewalls.

Requirement 2: Apply Secure Configurations to All System Components by Changing Default Vendor-supplied Passwords.

In PCI DSS v4, this requirement emphasizes secure configurations and discourages vendor defaults.

Moreover, a new requirement, 2.1.2, has been added to the list of roles and responsibilities. These revolve around understanding processes and mechanisms for implementing secure configurations on all system components.

Requirement 3: Protect Stored Account Data

Several new requirements are a part of requirement 3 in version 4.0. Unless specified in a particular requirement, requirement 3 protects stored account data. Account data security should be good if stored in non-persistent memory, including RAM or volatile memory.

The list of new requirements includes the following:

  • 3.1.2 – Defines roles and responsibilities for personnel protecting stored account data.
  • 3.2.1 – This requirement addresses SAD retention and disposal through data policies, procedures, and processes.
  • 3.3.2- This new requirement expands encryption of electronically stored SAD before authorization completion.
  • 3.4.2– This new requirement expands on the previous condition 12.3.10. It is emphasizing technical controls to prevent duplication or relocation of customer PANs when working remotely. It is a critical implementation in recent versions due to the increasing shift towards remote work. Its purpose is to safeguard CDE and customer PII while accessing company information externally. This requirement is valid until March 31, 2025.
  •– This requirement highlights adding the list for keyed cryptographic hashes while hashing to make PAN unreadable.
  •– This requirement was recently added to the list for disk-level or partition-level encryption. The motive was to render PAN to make it unreadable on removable electronic media or if used on non-removable electronic media.
  •– This new requirement is added for majorly service providers to include a documented description of the cryptographic architecture.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

The experts must manage PAN broadcasts by encrypting the data before transmission and the session sent over, or both. While applying strong cryptography to both levels is not mandatory, it is recommended. Requirement 4 provides further details on PAN transmission.

The list of new requirements is as follows:

  • 4.1.2- This requirement emphasizes defining roles and responsibilities for securely transmitting cardholder data over public networks through robust encryption controls. It aims to inform personnel by documenting and addressing their daily requirements.
  • 4.2.1- This requirement ensures that certificates used for PAN broadcasts over open public networks remain valid and not expired.
  •– This add-on sub-requirement Keeps a list of trustworthy keys and certificates as part of this additional criterion.

Requirement 5: Protect All Systems and Networks from Malicious Software

Business-approved activities, like employee email and Internet usage on mobile computers and storage devices, can introduce malware into the network and exploit system vulnerabilities. That’s why requirement 5 entails actions implementers should take to prevent malware attacks.

The list of new requirements is as follows:

  • 5.1.2- This requirement focuses more on the defined roles and responsibilities of individuals acting against malware.
  •– This requirement determines the frequency of evaluating non-malware at-risk system components in the entity’s focused risk analysis.
  • This evolving requirement specifies how frequently the entity’s focused risk analysis will scan for malware regularly.
  • 5.3.3- This amendment is for a malware removal plan for removable electronic media.
  • 5.4.1– This requirement aims to identify and safeguard personnel from phishing attempts.

Requirement 6: Develop and Maintain Secure Systems and Software

Actors with malicious intent can access systems with privileged access by utilizing security flaws. Vendor-provided security patches, which the organizations in charge of managing the systems must install, address many of these vulnerabilities. All system components must install the latest software patches to prevent account data from being misused and compromised by criminal people or malicious software.

The new add-ons are as listed:

  • 6.1.2 – This requirement emphasizes defining roles and responsibilities for identifying security vulnerabilities and managing secure system changes.
  • 6.3.2 – This requirement is for keeping track of a stock of specialized and unique third-party software.
  • 6.4.2– Implementing an automated technical solution to detect and prevent web-based threats continuously is now a prerequisite for public-facing web applications. Additionally, Requirement 6.4.1 no longer allows reviewing online applications using human or automated vulnerability assessment techniques or methods.
  • 6.4.3– This evolution controls how the customer’s browser loads and uses all payment page scripts.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business-Need-to-Know 

Inadequate access control rules and definitions may result in unauthorized individuals obtaining access to crucial data or systems. Establishing systems and procedures that restrict access based on the principle of least privilege and following job responsibilities is essential. 

The list of new requirements includes the following:

  • 7.1.2– This requirement focuses more on defining roles and responsibilities for restricting access to system components.
  • 7.2.4– This requirement examines each user account and its associated access rights.
  • 7.2.5– This prerequisite governs how all application and system accounts are assigned, managed, and given the appropriate access rights.
  • This sub-requirement calls for evaluating every application and system account access and associated access privileges.

Requirement 8: Identify Users and Authenticate Access to System Components

Per PCI DSS compliance requirement 8, enabling individual identification for anyone accessing system components containing sensitive payment information is necessary.

  • 8.1.2– This requirement focuses more on the defined roles and responsibilities for authentication of Users and access.
  • 8.3.6– Passwords must now be 12 characters long (or if the system does not handle 12, at least eight characters long). Previously, passwords had to be at least seven characters long.
  • – For customer user access relying solely on passwords or passphrases, either change them every 90 days or automatically determine resource access based on the security posture of the accounts.
  • 8.4.2– Implementing multi-factor authentication (MFA) is a prerequisite for all CDE access. MFA is essential for both access types mentioned in Requirements 8.4.2 and 8.4.3, and using MFA for one type does not replace the need for another.
  • 8.5.1– This requirement protects the installation of systems for multi-factor authentication.
  • 8.6.1- This prerequisite governs the administration of accounts for systems or programs that permit interactive login.
  • 8.6.2– This stipulation prohibits hard-coding passwords or passphrases for any application and system accounts that provide interactive login into files or scripts.
  • 8.6.3– This requirement is in place to prevent unauthorized use of passwords and passphrases for system and application accounts.

Requirement 9: Restriction of Physical Access to Cardholder Data

Per PCI DSS controls,  One must implement reasonable physical access restrictions to prevent unauthorized individuals from accessing and removing systems or hardcopies containing cardholder data stored, processed, or transmitted within the organization.

  • 9.1.2- This requirement focuses more on defining roles and responsibilities for restricting physical access to hard copies of cardholder data.
  • – Following the entity’s focused risk analysis, this requirement specifies the frequency of recurring POI device inspections.

Requirement 10: Tracking and Monitoring All Access to Network Resources and Cardholder Data.

Logging methods and user activity monitoring are vital to prevent, identify, or mitigate the impact of a data breach. All system components, including the Cardholder Data Environment (CDE), have logs for comprehensive tracking, alerting, and analysis in the event of an incident. Identifying a compromise’s root cause is challenging, if not impossible, without system activity logs.

  • 10.1.2- This requirement focuses more on defining roles and responsibilities for tracking and monitoring access to network systems.
  •– This stipulation pertains to using automated tools for audit log reviews.
  • These prerequisites call for a focused risk analysis to specify how frequently all other system components will undergo periodic log reviews.
  • 10.7.2– All entities must be able to identify, notify, and quickly address failures of crucial security control systems.
  • 10.7.3- This requirement calls for rapid responses to critical security control failures. This is to note that this requirement pans for both service and non-service providers. For non-service providers, this requirement is a new need.

Requirement 11: Test the Security of Systems and Networks Regularly

Malicious individuals and researchers constantly uncover vulnerabilities. Meanwhile, new software introduces additional risks. Regularly testing system components, processes, and custom software is crucial to maintain adequate security controls in a changing environment.

  • 11.1.2- This requirement defines roles and responsibilities for testing network security measures.
  • This requirement relates to managing all other pertinent vulnerabilities (those not classified as critical or high-risk) discovered during internal vulnerability scans.
  •– As per this requirement, one must employ authorized scanning for internal vulnerability scans.
  • 11.4.7– (specifically for multi-tenant service providers):- This requirement supports their clients’ external penetration testing according to this criteria.
  • for service providers)- This requirement states that specialists must find covert malware communication channels, alert them, prevent them from occurring, and address them using intrusion detection and intrusion-prevention techniques.
  • 11.6.1– This requirement calls for a change-and-tamper detection mechanism to notify users of unauthorized changes to payment pages’ HTTP headers and content as the user’s browser receives them.

Requirement 12: Support Information Security with Organizational Policies and Programs

The comprehensive information security policy of the organization establishes a foundation for the entire entity and communicates expectations to personnel. All staff members must know the sensitivity of cardholder data and understand their obligations in safeguarding it.

  • 12.3.1– This requirement highlights that any PCI DSS compliance obligation that allows flexibility for how frequently it must be completed must perform a targeted risk analysis.
  • 12.3.2-(New add-on for entities utilizing a custom-based pursuit)- Per this criterion, Each PCI DSS criteria that the company satisfies using the tailored method must be subject to targeted risk analysis.
  • 12.3.3- Using cryptographic cypher suites and protocols must be documented and reviewed at least once every 12 months under this requirement.
  • 12.3.4– This requirement calls for reviewing current hardware and software at least once every 12 months.
  • 12.5.2- It is necessary to document and confirm the PCI DSS compliance checklist scope at least once every 12 months and if the in-scope environment significantly changes.
  •– According to this sub-requirement, it is necessary to document and confirm PCI DSS scope at least once every six months and if the in-scope environment significantly changes.
  • 12.5.3-(specifically for service providers)- This requirement calls for a written assessment of how significant changes to the organizational structure would affect the scope of the PCI DSS and the applicability of controls.
  • 12.6.2– As per this amendment, at least once every 12 months, the security awareness program must be reviewed and updated (as necessary).
  • This criterion ensures that security awareness training covers risks and vulnerabilities that can compromise the CDE’s security.
  •– The instruction on security awareness must cover the proper use of end-user technology, per the criterion.
  • 12.9.2– (specifically for service providers)- The purpose of this requirement is to support their clients’ information requirements.
  • This criterion aims to conduct a focused risk analysis to specify how frequently incident response staff should get periodic training.
  • 12.10.5-(An additional sub-requirement)- The implementers must employ a change- and tamper-detection method for payment pages.
  • 12.10.7- According to this criterion, organizations must ensure that incident response processes are prepared and operational in case stored PAN (Primary Account Number) is discovered in an unexpected location.


The new PCI DSS compliance v4.0 promotes the exploration of a domain that combines compliance and innovation, resulting in improved security measures for our interconnected society. Join us as your compliance consultants to uncover the exciting advancements and implementation strategies offered by PCI DSS v4.0.

Leave a comment

Your email address will not be published. Required fields are marked *