The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards established in 2004 by major credit card companies, including Visa, MasterCard, American Express, Discover, and JCB. Its primary goal is to enhance the security of cardholder data and reduce credit card fraud.

Throughout its history, PCI DSS has undergone multiple updates, each refining and expanding its requirements to better protect cardholder data and prevent data breaches. Notable updates include versions like PCI DSS 1.1 (2006), PCI DSS 1.2 (2008), PCI DSS 2.0 (2010), PCI DSS 3.0 (2013), and PCI DSS 3.2 (2018), and now PCI DSS 4.0. 

The figure shown below shows the complete timeline of the PCI DSS evolution.

Key changes in PCI DSS v4.0 vs v3.2.1

Several factors contribute to the necessity of PCI DSS v4.0. For instance, PCI DSS v3.2.1 mentions the use of anti-virus solutions. However, nowadays, anti-malware solutions, which are much more holistic in nature, have replaced anti-virus solutions. The new version of PCI DSS has replaced the use of anti-virus with anti-malware. 

Another noteworthy change in PCI DSS v4.0 involves the adoption of the term “network security controls (NSCs)” in lieu of “firewalls and routers.” This adjustment accounts for the diverse array of devices and solutions collaboratively employed to secure network assets, exemplifying the standard’s commitment to a comprehensive security stance.

The following table provides an overview of modifications to individual requirements and sub-requirements, along with any newly introduced requirements, categorized under each main requirement. For a comprehensive understanding of the precise nature of each alteration, please refer to the “PCI DSS Summary of Changes v3.2.1 to v4.0” available on the PCI Security Standards Council website.

The 12 requirements of PCI DSS standard are:

1. Protection of the computing network
2. Alteration to the components of the information structure
3. Protection of cardholder data
4. Protection of  transmitted cardholder data
5. Anti-virus protection of the information infrastructure
6. Development and support of information systems
7. Access control to cardholder data
8. Authentication mechanisms
9. Physical protection of the information infrastructure
10. Information security management
11. Event and action logging
12. Control of the security of the information infrastructure

Some of the key changes in PCI DSS v4.0 are given below:

1. Customized approach

PCI DSS v4.0 introduces a significant shift in how organizations can simplify PCI compliance, offering them the flexibility to tailor their approach to meet specific requirements. For the majority of requirements, organizations now have the option to choose between the Defined Approach, which prescribes precise details on how to fulfill and evaluate the requirement or the Customized Approach, which empowers organizations to devise their own processes as long as they align with the requirement’s objectives. 

However, using a customized approach brings extra duties, including making and testing controls, checking how well they work, filling out the control matrix, and doing a Targeted Risk Analysis (TRA) for each Customized Control.

It is essential to recognize, however, that certain requirements do not permit customization, mandating organizations to adhere to predefined criteria. Such requirements will be clearly marked in the PCI DSS with the statement: “This requirement is not eligible for the customized approach.” You can find these explicitly identified in the PCI DSS documentation for each requirement that falls under this category.

2. Delegating responsibilities

Organizations should clearly outline roles and duties, ensuring that personnel are responsible for their assigned tasks. These roles and responsibilities must be formally designated and recorded. This requirement is in effect immediately for all v4.0 assessments.

It is recommended to take it a bit further with the following tasks by:

1. Defining the roles and responsibilities per control and requirement basis or splitting it further by asset type.
2. Using a RACI – Responsible, accountable, consulted, and informed (RACI matrix) as a starting point.

5 key reasons for clear cybersecurity roles and responsibilities

1. Incident response: Clearly defined roles enable swift and coordinated responses to cyber incidents, reducing damage and data loss.
2. Accountability: Defined roles encourage staff to take responsibility for cybersecurity measures, preventing security gaps and easing transitions during organizational changes.
3. Risk management: Explicit roles help organizations assess and mitigate evolving cybersecurity risks efficiently.
4. Resource optimization: Defined responsibilities enhance resource allocation, reducing duplication and maximizing cybersecurity program effectiveness.
5. Compliance and auditing: Clear roles and responsibilities facilitate compliance with PCI DSS v4.0 and other regulatory standards, simplifying audits and avoiding penalties.

3. Encryption of sensitive authentication data (SAD)

PCI DSS 4.0 requires the organization to “Examine data stores, system configurations, and/or vendor documentation to verify that all SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.” Until March 31, 2025, when v4.0 is fully implemented, this requirement is to be treated as a best practice.

Encryption is mandatory for all SAD, including CVV, irrespective of the presence of the Primary Account Number (PAN). This mandate enhances security when dealing with authentication data.

4. Maintaining key and certificate inventory for PCI DSS v4.0

To comply with PCI DSS v4.0, it’s crucial to keep an updated inventory of trusted keys and certificates, especially for strong encryption. This includes carefully documenting, tracking, and managing SSL/TLS certificates used for transmitting sensitive data over public networks. Increased tracking ensures the ongoing strength and validity of these certificates, akin to existing change control requirements.

To meet this requirement, organizations should document a repeatable process for issuing, maintaining, and storing cryptographic keys and certificates. Strong cryptography and security practices must safeguard private account numbers (PAN) during transmission over open, public networks, using only trusted certificates and keys.

Requirement 4.2.1 mandates that certificates protecting PAN during transmission over public networks must be confirmed as valid and not expired or revoked. This is a best practice until March 31, 2025, but will become mandatory from April 1, 2025, during PCI DSS assessments. It also specifies secure protocol usage without fallback to insecure versions, ensuring suitable encryption strength.

Requirement 4.2.1.1 entails maintaining an inventory of current keys and certificates, tracking their validity, and having procedures to check for expiration or revocation. Certificates trusted by browsers now have a maximum validity of 13 months, necessitating annual renewal. Custom applications should be coded to reject untrusted certificates from presumably PCI-compliant partners or processors.

5. Hashing and disk encryption

• Hashing methods must be updated as specified.
• Key lifecycle management controls apply to all keys.
• Organizations need to update data storage and internal code using hashing.
• Full Disk Encryption (FDE) is required (Requirement 3.5.1.2) to protect data in case of physical disk loss. FDE prevents unauthorized access even if authentication credentials are compromised. It can be used for portable devices and requires separate keys for drive unlocking and OS access.
• Companies using disk encryption for data storage or sharing must employ file-level encryption for data protection.

6. Multi-factor authentication (MFA) for CDE Access

In PCI DSS v4.0, multi-factor authentication (MFA) is mandatory for any access to the cardholder data environment (CDE) to enhance user identification confidence. This means:

• All users must use MFA for authentication.
• Single-factor authentication (SFA) access to the CDE should be restricted.
• Users should validate at least two out of three authentication factors to access resources.
• All remote network access from outside the organization’s network impacting the CDE must use MFA.
• Users, including administrators, cannot bypass MFA systems unless approved by management for a limited time with documented exemption.

7. Cryptographic cipher management

This new requirement mandates documenting and reviewing cryptographic cipher suites and protocols on an annual basis. Until March 31, 2025, this is considered a best practice. Here’s what it involves:

• Maintaining a list of all existing cryptographic cipher suites and protocols, including details on their uses and locations.
• Keeping an eye on market trends to ensure the continued suitability of currently used cryptographic cipher suites and protocols.
• Having a plan in place to address any changes in cryptographic vulnerabilities.

Identifying which cipher suites and protocols are in use across the organization may require reverse engineering various application implementations. This requirement applies to both applications and security/management tools, as they may not clearly indicate the cipher suites in use. Note that TLS 1.2 and 1.3 support numerous cipher suites (up to 40+), some of which are outdated and should not be used, even if they are correctly implemented.

8. Cryptographic architecture (Service providers only)

This requirement focuses on safeguarding cardholder information and primary account numbers (PANs) using cryptographic methods. Key aspects of protecting account data include encryption, truncation, masking, and hashing. Even if a hacker breaches other security measures and accesses encrypted account data, they can’t use it without the right cryptographic keys.

To minimize potential risks effectively, additional data protection methods must be considered. Service providers are now required to provide a documented description of their cryptographic setup for both production and test environments to prevent the use of duplicate cryptographic keys. Test environments are often less secure, making cryptographic keys more susceptible to interception and decoding. This requirement helps reduce such risks.

Timeline for PCI DSS v4.0 adoption

Organizations will be given until March 31, 2024 to undergo assessments using either PCI DSS v3.2.1 or v4.0. However, as of March 31, 2024, PCI DSS v3.2.1 will be retired, and all organizations will be subject to assessments based on PCI DSS v4.0.

An additional important deadline to keep in mind pertains to certain new requirements within v4.0. Organizations are required to fully implement the requirements categorized as “best practice” by March 31, 2025. 

The extended timeline is introduced to ensure the organizations falling under PCI DSS are well-versed with the requirements of v4.0 before it is fully implemented.

The following timeline illustrates the phased adoption of these requirements.

7 Steps to a smooth transition to PCI DSS v4.0

With the significant changes in the PCI DSS scope, it’s crucial for organizations to begin assessing compliance with v4.0 promptly. Starting the transition to v4.0 early allows ample time to address potential challenges posed by new or modified requirements and decide whether a customized approach is necessary.

Here are the steps to initiate your organization’s transition to v4.0:

1. Appoint a project lead to oversee the v4.0 transition.
2. Evaluate your current environment against the new or revised v4.0 requirements.
3. Decide which requirements, if any, will use the customized approach.
4. Follow the steps outlined in Appendix D – Customized Approach in the PCI DSS for each applicable requirement.
5. Reassess the requirements once all necessary steps are completed.
6. Identify issues where new or revised requirements cannot be currently met and create a remediation plan.
7. Continuously reassess requirements as remediation activities progress.

Additionally, collaborate with your organization’s Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) if applicable, and utilize PCI SSC resources for further guidance.

How can Scrut help you in implementing PCI DSS v4.0 compliance?

Scrut can automate many labor-intensive tasks for your organization. It can perform the following functions:

• Continuous monitoring: Scrut enables continuous monitoring of network and system activity, helping to detect and respond to security threats in real-time.
• Vulnerability scanning:  Scrut can regularly scan for vulnerabilities, identify weaknesses, and automate the remediation of known vulnerabilities.
• Log management and analysis: Automation by Scrut centralizes log collection, parses log data, and generates alerts for suspicious activities, aiding in meeting PCI DSS logging and monitoring requirements.
• Patch management: Scrut helps schedule, test, and deploy security patches, reducing the risk of vulnerabilities and ensuring systems are up to date with PCI DSS requirements.

Summary

In summary, the migration from PCI DSS 3.2.1 to 4.0 is essential for adapting to evolving cybersecurity threats and enhancing the security of cardholder data. Key changes include more flexible compliance approaches, clear role definitions, improved encryption, and mandatory multi-factor authentication. To prepare, organizations should appoint leaders, assess compliance, and develop remediation plans. 

Collaboration with experts and automation tools can streamline the process. The deadline for compliance is March 31, 2025, making early action imperative to protect cardholder data and maintain customer trust. Embracing PCI DSS v4.0 is crucial for robust cybersecurity practices in the digital era.
Ready to simplify your PCI DSS 4.0 compliance journey? Let Scrut automate and streamline your security tasks. Get started now to enhance your data protection and meet the latest PCI standards. Contact us today!