Preparing for PCI DSS 4.0: What you need to know

User interacts with a payments dashboard

As the payment industry evolves, so do the security standards that protect sensitive information. PCI DSS 4.0 brings new requirements and updates to ensure organizations maintain the highest level of security and minimize risks.

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 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.

Key takeaways

  • Understand the new and updated requirements of PCI DSS 4.0 to ensure compliance by March 2024 (PCI DSS v3.2.1 will be retired on March 31, 2024)
  • 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 document, which can be accessed through the PCI website

Key dates and deadlines for PCI DSS 4.0 compliance

PCI DSS 4.0 was officially released in Q1 2022 with a two-year transition period between March 2022 and March 2024.

The key date to know is the retirement of v3.2.1 on March 31, 2024. After this date, PCI DSS 4.0 will be the only active version of the standard. 

However, the best practices implementation deadline for PCI DSS v4.0 is March 31, 2025. This means allows organizations some time to grasp the changes in PCI DSS version 4.0 and make the necessary changes. Naturally, we do not recommend waiting until the last minute to make those changes.

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.

For a comprehensive understanding of the changes ushered in by PCI DSS 4.0, you are encouraged to refer to the PCI DSS v4.0 Change Summary document available on the PCI SSC website. This summary of changes will help you understand the key differences between PCI DSS v3.2.1 and the new PCI DSS 4.0. We’ll break down the key points in subsequent sections.


Close up of a laptop and checklist
Recommended for you
The 12 requirements of PCI DSS: your compliance checklist

If you’re pursuing PCI DSS, it’s essential to understand the 12 requirements and what’s expected of your business.

Your PCI DSS compliance checklist: The 12 essential requirements 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

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: 

Evolving requirement: 3.3.2: 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.4.1: 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.

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: 

PCI DSS Applicability Information: 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.

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:

PCI DSS 6.2.1 Moved requirement for developing software securely to align all software development content under
Requirement 6.2.

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

PCI DSS 4.0 introduces 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.

 


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.

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:

LinkedIn