You will need to be compliant with PCI DSS 4.0 by March 31, 2025. We recommend starting your transition to 4.0 by reading the documents that explain the new PCI standard, including the executive summary, which has a lot of good information in it.
PCI compliance is difficult because there is more and more to watch out for. The tactics of threat actors are always evolving and so sometimes we need to update things to include modern technologies.
See also: PCI DSS 4.0: What's New and How It Affects You
Remembering that PCI DSS is a protection for your business and is intended to keep you safe from threat actors, can help you frame PCI compliance as a positive experience instead of a checklist item.
You will need to be compliant with PCI DSS 4.0 by March 31, 2025. This will give you plenty of time to make the transition from PCI DSS 3.2.1, but only if you start now. We recommend starting your transition to 4.0 by reading the documents that explain the new PCI standard, including the executive summary, which has a lot of good information in it.
The Customized Approach is now available. However, before jumping right in, larger organizations and risk assessment teams may want to look at the Defined Approach and Customized Approach so that they understand the differences between the two and can make the right decisions for their organization.
A lot of people are excited about the Customized Approach because it sounds easier to get compliant. In reality, it’s going to be a pretty heavy lift. The Customized Approach requires a lot of work and effort to define what the actual requirements are and how to measure the requirements.
One of the biggest adjustments to PCI 4.0 is the increased use of risk assessments within the Customized and Defined Approaches. Risk assessments for a Customized Approach are a big part of the new standard. Instead of being a simple 15-minute process, organizations will need to follow a very structured formalized risk assessment.
In the past, people weren’t certain about what risk assessments were or the associated requirements. We’d often ask questions like “have you had a meeting, or have you written a document, or have you done something that shows that you've thought about the risks in your system?”
Now, the expectation is that if you make a change in your environment (e.g., adding a new firewall), you need to do a risk assessment on that change.
If you don’t have a lot of experience with formal risk assessments or don't have a risk department as part of your company, you may need initial help from a third party to get you going and learn how to do these things
Formal risk assessments may not seem like a big change based on some of the other future dated requirements that have been added to the standard, but this change in PCI DSS 4.0 may result in additional effort in the transition process.
Aside from these changes, we would like to quickly go through each section of PCI DSS 4.0 to show you some key new requirement changes.
There were no significant changes in this section..
There were no significant changes in this section.
Requirement 3.2.1 (March 31, 2025)
In the past, if you stored sensitive authentication data before authorization, it was recommended that you should try to encrypt or protect it, but it wasn't required. Now, it is required.
Requirement 3.3.3 (March 31, 2025)
Issuers now must encrypt the sensitive authentication data that they may be storing. This may not be a big deal for most issuers at this point, but may be difficult for some legacy systems where encryption software is not readily available.
Requirement 3.4.2 (March 31, 2025)
If you're using remote access technology to access the cardholder data environment (CDE), then you must prevent the copy and relocation of PAN data. This has been mentioned before, but now it will be a requirement.
Previously, you could just have a policy addressing this, but now it needs to be enforced by some technology. There may be settings in your remote access software that have ways of preventing access to certain functions. Depending on what resources you have and your current processes, this requirement may or may not be difficult to implement.
Requirement 3.5.1.2 (March 31, 2025)
This requirement discusses the removal of disk-level encryption as an option to protect card data. Now it can only be used for removable media (e.g., a USB drive, an external SSD). You can't use it anymore on your computer's hard drive or any kind of non-removable media. If you're using disk-level encryption for protection, you will need to make some changes.
Requirement 3.5.5.1 (March 31, 2025)
PCI DSS 4.0 also changes the security required on hashing functionality if your system is using a hash method for protecting card data.
Organizations will need to use a keyed cryptographic hash method which is different from most common hash algorithms in use. So you may need to change your hashing algorithm to something like HMAC, CMAC, or GMAC, with an effective cryptographic strength of at least 128-bits. A code change of this kind could take some effort so you may want to focus on this earlier rather than later.
Requirement 4.2.1 (March 31, 2025)
A new requirement in this section will be to carefully document, track, and inventory SSL and TLS certificates in use for the transmission of sensitive data across public networks. Increased tracking will help ensure the certificates’ continued strength and validity. So, it's just a new process and tracking that needs to be implemented.
See also: SecurityMetrics PCI Guide
Requirement 5.3.3 (March 31, 2025)
Organizations will need to scan removable media used in the CDE. Since most antivirus solutions do this or have the capability, it may just require some configuration setting changes. Review the capabilities of the malware solution you are using to see if they have these capabilities.
Requirement 5.4.1 (March 31, 2025)
One of the bigger changes is that a requirement to have automatic process mechanisms in place to detect and protect personnel against email phishing attacks has been added.
If you're doing your email in-house, you may or may not have had all the controls in place for this yet. If you've outsourced emails, confirm with your provider and see what sort of protections they have against phishing attacks.
Requirement 6.4.2 (March 31, 2025)
In PCI DSS 3.2.1, a web application firewall or a process to do code reviews was required to protect web applications developed by a company. In March 2025, organizations will need to have a web application firewall in place for any web applications exposed to the Internet.
This standard has been a long time coming and shouldn’t be surprising. There are many solutions, including cloud-based solutions, that can help with this requirement.
Requirement 6.4.3 (March 31, 2025)
To reduce the possibility of malicious scripts making it onto payment pages, organizations need an inventory of all the known scripts used on those pages.
This inventory must be documented and tracked to ensure that all the scripts used are authorized, and that the integrity has been validated. Review the guidance column for further information on this requirement.
Requirements 7.2.4, 7.2.5, 7.2.5.1 (March 31, 2025)
Not much has changed in this section.
It's the basic, role-based access control stuff and most of the changes are just tightening account reviews and processes around reviews for systems, users, and applications.
Requirement 8.3.6 (March 31, 2025)
To strengthen passwords the minimum length is moving from 7 to 12 alpha and numeric characters. Depending on your applications, this could be a simple fix or it may require some code changes. So, start checking now to see if there are any systems in use in your CDE that would have difficulty with this future dated requirement.
Requirement 8.3.10.1 (March 31, 2025)
Another change in section eight around passwords pertains to service providers. Customers of service providers will now have to change their passwords every 90 days if you're using just a password for authentication (i.e - you are not using a multi-factor authentication).
Requirement 8.4.2 (March 31, 2025)
Multi-factor authentication will be required for all access to the CDE, not just from external locations. So this then would apply for internal administrative access to servers, firewalls, networking gear, etc.
Requirement 8.5.1 (March 31, 2025)
PCI DSS 4.0 adds a new detail to MFA requirements that might be a bit tricky. Success of all the factors has to happen before authentication, and it can’t be known from the process which factor has failed.
Presently, most systems ask for a username and password (i.e., something you know) and only move on to the second factor if you have the correct username/password. This will no longer be allowed.
Both factors will have to be presented and entered without revealing any information about which factor might have been wrong if authentication fails.
Requirement 8.6.2 (March 31, 2025)
All application and system passwords that could be used for interactive login have additional approval and tracking controls on their use, and can no longer reside in a script or a file.
There were no significant changes in this section.
Requirement 10.4.1.1 (March 31, 2025)
Organizations can no longer review their logs manually.
Few, if any, companies are manually reviewing logs anymore as it’s just too much data to effectively review manually. There are many log review tools out there so it shouldn’t be difficult to implement a solution. Manual review of logs is time-consuming and easy to do poorly so this is a good change.
Requirement 10.7.2 (March 31, 2025)
All organizations must now detect, alert, and promptly address failures of critical security control systems. This used to be only required for service providers, but has now been extended to everyone.
This means that if you had a firewall or IDS system that went down for some reason, you would have to detect it, generate an alert, and respond to that alert. This update will require additional procedures for merchants to implement. We recommend that you start now to look for solutions.
Requirement 11.3.1.2 (March 31, 2025)
Internal vulnerability scanning must now be authenticated. This means that it's not just a scan of ports and services; now, if a service is exposed that requires a credential to access it (e.g., a web app), you need to use those credentials to gain access and test the authenticated port or service.
An important part of this new requirement will be that the credentials used by the vulnerability assessment (VA) scanner must be entered in the system and stored securely. This will have to be a feature of the VA scanning solution and should be something you check with your vendor carefully on.
Requirement 11.5.1.1 (March 31, 2025)
Another requirement change was on IDS/IPS, so that systems detect and alert on any covert malware communication channels that are being used (i.e., DNS tunneling). This may represent a change to the IDS/IPS system that you are currently using.
Requirement 11.6.1 (March 31, 2025)
Probably one of the biggest things in section eleven was the addition of a requirement to implement a change and tamper detection mechanism for any payment pages. This requirement addition is a direct result of the increase in ecommerce skimming compromises seen on payment pages in recent years.
Before March 31, 2025, companies will have to deploy a solution that will detect changes to those pages (e.g., script additions, changes to known script and code).
This is a great addition to the standard and is absolutely needed for e-commerce.
Requirement 12.5.2 (Immediately Effective for 4.0 Assessments)
An annual scoping of your card data environment was mentioned in the initial discussion section of previous versions of PCI DSS, but now the Council has moved that into the requirements matrix under section 12 and made it a trackable requirement effective immediately for version 4.0.
So a documented scoping exercise will have to be done by merchants annually, or after any significant changes to the in-scope environment (e.g., people, systems, processes).
Requirement 12.5.2.1 (March 31, 2025)
New for service providers will be a future dated requirement to perform this scoping exercise at least every 6 months and after any organizational changes to the company.
Requirement 12.6.2 (March 31, 2025)
Organizations will need to enforce a more formal Security Awareness Program, where before you could get by with some basic security training.
Organizations will need to document and update their Security Awareness Program at least once every 12 months and as needed to address any new threats and vulnerabilities that may impact the security of their CDE or information provided to personnel about their role in protecting cardholder data.
Requirement 12.6.3.1 (March 31, 2025)
The standard now expects a security training program to discuss specific threats and vulnerabilities in your environment, as well as acceptable use of end-user technologies.
For example, if phishing is a big deal for your environment, then you need to address phishing in your training. The training program will also need to be reviewed and updated at least annually.
Requirement 12.10.7 (March 31, 2025)
Incident response procedures will need to be initiated if stored Payment Account Numbers (PAN) is detected anywhere it is not expected. This means that you are always on the watch for new or errant processes creating repositories of stored PAN outside of expected boundaries.
Periodic review of processes dealing with card data and running a good data discovery tool will be needed to fully say you have satisfied this future-dated requirement.
First, read the PCI DSS version 4.0 standard and get familiar with the bigger changes that could impact your compliance process. Then start formulating your plans right now to implement changes for version 4.0. There is plenty of time, so start early and you will not have problems making the transition. During this planning process don't forget to keep working hard to keep your current efforts going to be compliant to PCI DSS version 3.2.1.
Second, start thinking about how you are conducting your risk assessments. More formal risk assessment processes are required in version 4.0 and most organizations will have to add processes and gain skills to do this correctly. Start doing google searches on formal risk assessment and refer to the industry standards out there like NIST 800-30 and OCTAVE to begin getting familiar with them. It may be a good idea to consult with a QSA as you develop these processes.
QSA’s will not be able to conduct a PCI DSS 4.0 assessment until after they have been formally trained by the PCI Council (expected mid-Summer 2022), so it is a bit too early to actually start on a formal assessment to version 4.0, but QSA’s are happy to start consulting on questions you may have as you begin working on your version 4.0 compliance.
Finally, don’t wait until 2024 to begin switching over to PCI DSS 4.0. Spread your efforts over the next couple of years and you will be just fine with the new requirements.
We hope that this was a helpful introduction to what to expect from the new changes in PCI DSS 4.0. Feel free to watch our webinar for a more in-depth discussion on each of these topics.
.svg)
