Preparing for PCI DSS v4.0.1 Audit: Essential updates for 2025 compliance

User interacts with a payments dashboard

As the payment industry evolves, so do the security standards that protect sensitive information. PCI DSS 4.0.1, released in 2024, refines the substantial changes introduced in version 4.0 and clarifies critical requirements as organizations as of the March 2025 deadline for implementing best practices. Understanding these updates is essential to ensure your organization maintains the highest level of security while efficiently navigating compliance requirements.

The Payment Card Industry Security Standards Council (PCI SSC) is responsible for the development and management of the PCI Data Security Standard (PCI DSS). The new PCI DSS v4.0.1 aims to:

  • Meet the changing security needs of the payment industry, including data security standards
  • Promote security as a continuous process
  • Add flexibility
  • Enhance procedures for organizations using different approaches to reach their security objectives

This new version has been designed to tackle emerging threats and technologies better than its predecessor, PCI DSS v3.2.1.

With version 4.0.1 now providing additional clarifications, organizations have a clearer path to implementing these significant changes.

Key takeaways

  • The fundamental goal of PCI DSS continues to be to protect account data, with version 4.0.1 providing enhanced guidance on implementing controls in increasingly complex technology environments
  • Understand the new and updated requirements of PCI DSS 4.0.1 to ensure compliance with best practices by March 31, 2025 (PCI DSS v4.0 has been replaced by v4.0.1 as the current active version)
  • Utilize technology, industry experts, and advisors for robust security measures and ongoing trust with customers
  • Details on updates can be found in the Summary of Changes from PCI DSS Version 3.2.1 to 4.0.1 document, which can be accessed through document library of the PCI website
  • Focus on key areas of refinement in 4.0.1, including clarifications to encryption requirements, supply chain security, and continuous monitoring expectations

Key dates and deadlines for PCI DSS v4 compliance

PCI DSS 4.0 was officially released in Q1 2022, followed by version 4.0.1 in 2024, which includes important clarifications and guidance updates.

The retirement of v3.2.1 occurred on March 31, 2024. After this date, PCI DSS 4.0.1 became the only active version of the standard, replacing version 4.0.

The more recent deadline of March 31, 2025 was when all organizations must implement the best practices identified in PCI DSS 4.0.1. 

As Rob, an information security lead who recently completed PCI DSS compliance, advises from the recent Thoropass webinar:

Here’s an easy at-a-glance visual to help grasp the timelines:

Timeline of when to expect transition from PCI DSS v3.2.1 to v4.0

Overview of new and updated requirements in PCI DSS 4.0

This new version has been designed to tackle emerging threats and technologies better than its predecessor, PCI DSS v3.2.1 A significant update in PCI DSS 4.0 is the introduction of 64 new requirements, which focus on areas such as:

  • Network security
  • Secure configurations
  • Account data
  • Strong cryptography
  • Malware protection
  • System components and cardholder data

Moreover, PCI DSS 4.0 introduces a Customized Approach that allows organizations to adapt the standard to their specific needs as long as the intent of the requirement is met. This approach encourages organizations to consider the specifics and whether they meet the requirements when deciding if they should use the Customized Approach.

PCI DSS 4.0.1 provides essential clarifications to both technical and operational requirements, helping organizations implement effective controls with greater precision and efficiency. While it doesn’t introduce new requirements beyond those in 4.0, these clarifications significantly impact implementation approaches.

For a comprehensive understanding of the specific clarifications in PCI DSS 4.0.1, refer to the PCI DSS v4.0 to v4.0.1 Summary of Changes document available on the PCI SSC website. This document details how these refinements improve the implementation of the security controls introduced in version 4.0.

Recommended for you
Webinar: Accelerating PCI DSS 4.0 compliance
Watch now icon-arrow-long

Change types

PCI DSS 4.0 introduces various changes compared to its predecessor, v3.2.1. These changes can be categorized into three main types: 

  1. Evolving requirement
  2. Clarification or guidance
  3. Structure or format

PCI DSS 4.0.1 focuses primarily on “Clarification or Guidance” type changes, with some “Structure or Format” adjustments. According to the official Summary of Changes document, there were no “Evolving Requirement” changes in this version. The majority of the updates in 4.0.1 aim to clarify existing 4.0 requirements and align them with other PCI publications released since version 4.0.

1. Evolving requirements

These refer to modifications made to existing requirements and/or new requirements. These changes often reflect the evolving nature of the payment card industry, including emerging threats and technologies. For example: 

 
Change Type
PCI DSS v4.0
Description of Change
New requirement to encrypt SAD that is stored electronically prior to completion of authorization. This requirement is a best practice until 31 March 2025.
Evolving requirement
3.3.2
Clarified that PAN is masked when displayed such that only personnel with a business need can see more than the BIN/last four digits of the PAN.
Evolving requirement
3.4.1

2. Clarification or guidance

Clarification or guidance are changes made to make the language or intent of a requirement clearer. These changes do not necessarily alter the underlying requirement but provide further explanation or guidance. For example: 

 
Change Type
PCI DSS v4.0
Description of Change
Added sub-headings to increase readability. Clarified that some PCI DSS requirements may apply for entities that do not store, process, or transmit primary account number (PAN). Clarified that terms account data, sensitive authentication data (SAD), cardholder data, and PAN are not interchangeable and are used intentionally in PCI DSS. Clarified table with commonly used elements of cardholder data and SAD, whether storage is permitted, and whether data must be rendered unreadable.
Clarification or guidance
PCI DSS Applicability Information

3. Structure or Format

Structure or format changes involve adjustments to the way the standards are presented or organized. These changes aim to improve the readability and usability of the standards, making it easier for organizations to understand and implement them. For example:

 
Change Type
PCI DSS v4.0
Description of Change
Moved requirement for developing software securely to align all software development content under Requirement 6.2.
Structure or format
6.2.1

Understanding these change types can help organizations better navigate the transition from PCI DSS v3.2.1 to v4.0, ensuring they fully understand and can effectively implement the new and updated requirements.

Summary new requirements

While PCI DSS 4.0.1 doesn’t introduce additional new requirements beyond those in version 4.0, it includes specific clarifications for several of these requirements. For example, it updates language around sensitive authentication data (SAD) storage from “not retained” to “not stored” after authorization, clarifies what constitutes a “legitimate and documented business need” for SAD storage, and provides additional guidance on implementing cryptographic controls to protect stored cardholder data through appropriate hashing functions and encryption algorithms.

PCI DSS 4.0 introduced several new requirements that organizations must adhere to in order to maintain compliance. Here are some of the key new requirements:

  • Defining Roles: Organizations are now required to define the roles of their team members and ensure that everyone understands their responsibilities when it comes to maintaining PCI DSS compliance.
  • Documenting scope: It is now required for organizations to document the scope of their cardholder data environment (CDE), including all people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.
  • Securing network infrastructure files: PCI DSS 4.0 introduces a new requirement for organizations to secure their network infrastructure files. This includes ensuring that these files are stored securely and only accessible to those who need them.
  • Documenting shared requirements with third-party service providers: If an organization uses third-party service providers, they are now required to document any shared responsibilities related to PCI DSS requirements. This is to ensure that both parties understand their responsibilities and there are no gaps in compliance.

These are just some of the new requirements introduced in PCI DSS 4.0. Organizations are encouraged to review the full list of requirements to ensure they are fully prepared for compliance.

New requirements included in PCI DSS v4.0 are either:  

  • Effective immediately for all PCI DSS v4.0 assessments, OR
  • Best practices until 31 March 2025, after which they become effective

A complete summary with applicability and effective dates can be found in the PCI DSS v4.0 Change Summary document available on the PCI SSC website. 

Below summarizes the list of new requirements as outlined in the Change Summary document published by the PCI Security Standards Council:

 
4.1.2 Roles and responsibilities for performing activities in Requirement 4 are
documented, assigned, and understood.
4.2.1 Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked.
4.2.1.1 An inventory of the entity’s trusted keys and certificates is maintained.
5.1.2 Roles and responsibilities for performing activities in Requirement 5 are
documented, assigned, and understood.
5.2.3.1 A targeted risk analysis is performed to determine frequency of periodic evaluations of system components identified as not at risk for malware.
5.3.2.1 A targeted risk analysis is performed to determine frequency of periodic malware
scans.
5.3.3 Anti-malware scans are performed when removable electronic media is in use.
5.4.1 Mechanisms are in place to detect and protect personnel against phishing
attacks.
6.1.2 Roles and responsibilities for performing activities in Requirement 6 are
documented, assigned, and understood.
6.3.2 Maintain an inventory of bespoke and custom software to facilitate vulnerability
and patch management.
6.4.2 Deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks.
6.4.3 Manage all payment page scripts that are loaded and executed in the
consumer’s browser.
7.1.2 Roles and responsibilities for performing activities in Requirement 7 are
documented, assigned, and understood.
7.2.4 Review all user accounts and related access privileges appropriately.
7.2.5 Assign and manage all application and system accounts and related access
privileges appropriately.
7.2.5.1 Review all access by application and system accounts and related access
privileges.
8.1.2 Roles and responsibilities for performing activities in Requirement 8 are
documented, assigned, and understood.
8.3.6 Minimum level of complexity for passwords when used as an
authentication factor.
8.3.10.1 If passwords/passphrases are the only authentication factor for customer user access, passwords/passphrases are changed at least every 90 days, or the security posture of accounts is dynamically analyzed to determine real-time access to resources.
8.4.2 Multi-factor authentication for all access into the CDE.
8.5.1 Multi-factor authentication systems are implemented appropriately.
8.6.1 Manage interactive login for accounts used by systems or applications.
8.6.2 Passwords/passphrases used for interactive login for application and system accounts are protected against misuse.
8.6.3 Passwords/passphrases for any application and system accounts are
protected against misuse.
9.1.2 Roles and responsibilities for performing activities in Requirement 9 are
documented, assigned, and understood.
9.5.1.2.1 A targeted risk analysis is performed to determine frequency of periodic POI
device inspections.
10.1.2 Roles and responsibilities for performing activities in Requirement 10 are
documented, assigned, and understood.
10.4.1.1 Audit log reviews are automated.
10.4.2.1 A targeted risk analysis is performed to determine frequency of log reviews for
all other system components.
10.7.2 Failures of critical security control systems are detected, alerted, and
addressed promptly.
10.7.3 Failures of critical security control systems are responded to promptly.
11.1.2 Roles and responsibilities for performing activities in Requirement 11 are
documented, assigned, and understood.
11.3.1.1 Manage all other applicable vulnerabilities (those not ranked as high-risk or critical).
11.3.1.2 Internal vulnerability scans are performed via authenticated scanning.
11.4.7 Multi-tenant service providers support their customers for external penetration
testing.
11.5.1.1 Covert malware communication channels detect, alert and/or prevent, and address via intrusion-detection and/or intrusion-prevention techniques.
11.6.1 A change-and-tamper-detection mechanism is deployed for payment
pages.
12.3.1 A targeted risk analysis is documented to support each PCI DSS requirement that provides flexibility for how frequently it is performed.
12.3.2 A targeted risk analysis is performed for each PCI DSS requirement that is met with the customized approach.
12.3.3 Cryptographic cipher suites and protocols in use are documented and
reviewed.
12.3.4 Hardware and software technologies are reviewed.
12.5.2 PCI DSS scope is documented and confirmed at least once every 12
months.
12.5.2.1 PCI DSS scope is documented and confirmed at least once every six months and upon significant changes.
12.5.3 The impact of significant organizational changes on PCI DSS scope is documented and reviewed, and results are communicated to executive management.
12.6.2 The security awareness program is reviewed at least once every 12 months and updated as needed.
12.6.3.1 Security awareness training includes awareness of threats that could impact the security of the CDE, to include phishing and related attacks and social engineering.
12.6.3.2 Security awareness training includes awareness about acceptable use of end-user technologies.
12.9.2 TPSPs support customers’ requests to provide PCI DSS compliance status and information about PCI DSS requirements that are the responsibility of the TPSP.
12.10.4.1 A targeted risk analysis is performed to determine frequency of periodic training for incident response personnel.
12.10.5 The security incident response plan includes alerts from the change- and tamper-detection mechanism for payment pages.
12.10.7 Incident response procedures are in place and initiated upon detection of PAN.
A1.1.1 The multi-tenant service provider confirms access to and from customer environment is logically separated to prevent unauthorized access.
A1.1.4 The multi-tenant service provider confirms effectiveness of logical separation controls used to separate customer environments at least once every six months via penetration testing.
A1.2.3 The multi-tenant service provider implements processes or mechanisms for reporting and addressing suspected or confirmed security incidents and vulnerabilities.
A.3.3.1 Failures of the following are detected, alerted, and reported in a timely manner: Automated log review mechanisms and/or automated code review tools.

 

PCI DSS 4.0.1 includes specific clarifications for several of these requirements. For example, it updates language around sensitive authentication data (SAD) storage from “not retained” to “not stored” after authorization, clarifies what constitutes a “legitimate and documented business need” for SAD storage, and provides additional guidance on implementing cryptographic controls like hashing functions and encryption algorithms.

Organizations should pay particular attention to Requirement 11.2.1, which addresses detection of unauthorized wireless access points. PCI DSS 4.0.1 clarifies that this requirement remains relevant even when organizations have policies prohibiting wireless technologies, as unauthorized devices may still be present without management knowledge.

Over the shoulder view of an engineer working on code
Recommended for you
Encryption requirements for PCI DSS

Encryption is an essential element of compliance with PCI DSS and frequently explored during pentests.

Your PCI DSS compliance checklist: The 12 essential requirements icon-arrow-long

How non-compliance can impact your organization

Failing to comply with PCI DSS 4.0 can seriously affect your organization. Non-compliance can result in financial repercussions, such as fines and loss of contracts, which may indicate unaddressed vulnerabilities and increased risk. Ensuring compliance with PCI DSS 4.0 is paramount not just for protecting your organization’s sensitive data but also for preserving a solid reputation and trust with customers and partners in the payment card industry.

In the event of a data breach, your organization may face financial penalties depending on your compliance status. This highlights the importance of staying up-to-date with the latest PCI DSS requirements and implementing the necessary security measures to protect your organization and its stakeholders.

Proper implementation of PCI DSS requirements to restrict access to cardholder data remains one of the most critical aspects of the standard. Organizations should implement role-based access controls with least privilege principles to ensure only authorized individuals can access sensitive information.

By understanding the changes, staying up-to-date with deadlines, implementing the necessary technology, and leveraging available resources and expertise, your organization can navigate the transition to PCI DSS 4.0 compliance with confidence and ease.

Remember, the journey to PCI compliance is not a one-time event, but a continuous process that requires ongoing vigilance and dedication. By staying informed, proactive, and adaptable, your organization will not only meet the requirements of PCI DSS 4.0 but also maintain a strong reputation and trust with customers and partners in the payment card industry.

Share this post with your network:

Related Posts

SOC 2 audit transformation: A modern approach to continuous compliance

For enterprises managing complex technology stacks and sensitive data, SOC 2 audits have become a critical yet increasingly burdensome aspect of maintaining customer trust and market access. The traditional approach...
Read Article icon-arrow

Pentesting or Vulnerability Scanning: Which should you choose?

With cyber attacks becoming increasingly sophisticated and compliance standards more stringent, organizations face mounting pressure to verify their security measures actually work and not just exist on paper. As you...
Read Article icon-arrow