What’s New in PCI DSS 4.0? The Major Changes You Need to Know
Launched in 2006, the Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards intended to ensure that all companies that process, store, transmit, or impact the security of cardholder data maintain a secure environment.
Now, the standard is evolving to keep up with the state of e-commerce and more sophisticated cyber threats. The latest evolution of the standard — PCI DSS v4.0 — was released on March 31, 2022.
We understand keeping up with the latest changes to compliance requirements like PCI DSS can be difficult. That’s why we make it part of our mission to keep our customers informed regarding any changes that could affect their environment and to keep our platform up-to-date.
In this article, we explain the changes made to PCI DSS and what they mean for your organization.
What is PCI 4.0?
PCI 4.0 is the latest major iteration of the payment card industry standard and implements significant changes in requirements, focusing more on maintaining continuous security as well as adding new methods to meet requirements.
The main goal of PCI DSS 4.0 is to continue to evolve the standard to meet the changing needs of the payment card industry and the new technologies being implemented daily.
Recommended reading
PCI History: How the Standard Came To Be
PCI DSS 4.0 changes at a glance
PCI DSS v4.0 includes a variety of changes that aim to meet four key objectives:
- continuing to meet the needs of the payment industry
- promoting security as a continuous process
- adding flexibility and additional methods to maintain payment security
- enhancing payment validation methods and procedures
Below is a high-level overview of these changes. You can find a more detailed summary at the end of the blog post.
1. Adding a customized approach for implementing and validating PCI DSS
The most significant change is its implementation of a brand new method of meeting requirements called the customized approach.
Customized approach provides organizations with the flexibility to meet the security objectives of PCI DSS requirements using new technology and innovative controls. This allows organizations to meet strict PCI DSS requirements in a more customized and flexible way.
The assessor will validate that the customized controls meet the PCI DSS requirements by reviewing the entity's customized approach documentation (including a controls matrix and targeted risk analysis) and developing a procedure for validating the controls.
It’s important to understand that customized controls are not compensating controls. Compensating controls are mitigating controls that are required when an organization is unable to meet a requirement for a legitimate and documented technical or business constraint. Customized controls, on the other hand, are a flexible alternative to meeting strict requirements.
2. Updated requirements
In addition, there have been major improvements to requirements in PCI DSS 4.0. These include:
- Additional authentication controls, including strict multi-factor authentication requirements when accessing the cardholder data environment
- Updated password requirements, including increasing password length requirement from 8 characters to 12
- Changing requirements around shared, group, and generic accounts
- Clearly defined roles and responsibilities needed for each requirement
3. New requirements
New requirements have also been implemented to prevent and detect new and ongoing threats against the payment industry, including phishing, e-commerce, and e-skimming attacks.
4. Enhanced PCI DSS assessment reports
Finally, enhancements have been made to the self-assessment questionnaire (SAQ) document as well as to the Report on Compliance (RoC) template to help guide organizations when self-attesting and assessors when documenting results.
For a more detailed breakdown of the changes between PCI DSS 3.2.1 and 4.0, check out the table at the end of this post.
Recommended reading
PCI DSS 4.0 Requirements: A Deep Dive into the Latest Changes and How They Affect Your Organization
When does PCI DSS 4.0 go into effect?
PCI DSS 4.0 was released on March 31, 2022 and is in effect today. Until March 31, 2024, the previous version of PCI DSS — v3.2.1 — will also remain active to give organizations time to adopt the latest version of the standard. There are also additional requirements that will only be considered best practice until March 31, 2025.
Let’s take a closer look at the PCI DSS 4.0 implementation timeline below.
Source: PCI SSC website
Transition period from PCI DSS v3.2.1 to v4.0
PCI DSS v3.2.1 will remain active from March 2022 until March 31, 2024. These two years after the publication of v4.0 are meant to provide organizations with enough time to review the changes in v4.0, update their reporting templates and forms, and implement new controls to meet the updated requirements in v4.0.
During this transition period, an organization’s Cardholder Data Environment (CDE) can be assessed using PCI DSS v3.2.1 or v4.0.
On March 31, 2024, PCI DSS v3.2.1 will be retired and v4.0 will become the only active version of the standard.
Implementation of future-dated requirements in PCI DSS 4.0
Organizations will have another year after the retirement of v3.2.1 to adopt requirements that have been identified as future dated in v4.0.
Before March 31, 2025, organizations are not required to validate these new requirements. However, if organizations have implemented controls to meet the new requirements, they are encouraged to have them assessed earlier.
After March 31, 2025, these future dated requirements go into effect and must be fully considered as part of a PCI DSS assessment.
What do these changes mean for organizations that are already PCI certified?
In response to PCI DSS 4.0 changes, organizations that are already PCI certified should start by doing some research. Organizations should review the changes in the official PCI DSS 4.0 document from the PCI Security Standards Council (PCI SSC) website to see what steps they would need to take in order to be prepared for the implementation of version 4.0 in March 2024.
Organizations looking for guidance in regards to the changes they would need to make can reach out to their PCI DSS qualified security assessor or a Secureframe compliance manager. A Secureframe compliance manager will help you understand new requirements, the changes to current requirements, and how you can implement controls within your environment in order to meet the changes in version 4.0.
What do these changes mean for organizations that are pursuing PCI certification for the first time?
Organizations pursuing PCI DSS should take a similar approach with 4.0 as they would have with 3.2.1.
Start by reaching out to a Secureframe compliance manager to help determine the scope of your service and environment. This will help you understand which requirements you need to meet. Then use the Secureframe platform to complete platform tasks and remediate automated tests with the support of our compliance managers. Finally, select one of our partner QSAs to perform fieldwork directly within the platform.
Recommended Reading
Fast-Track PCI DSS Compliance with Secureframe
How Secureframe can help you meet PCI DSS 4.0 requirements
PCI DSS 4.0 compliance will be required beginning on March 31, 2024. If you’re not sure how to meet the requirement changes, Secureframe can help.
Use the table below to see the PCI 4.0 requirement changes and how Secureframe helps customers meet them side-by-side.
| PCI DSS 4.0 requirement change | How Secureframe helps support customers |
| Roles and responsibilities for performing activities in each requirement must be documented, assigned, and understood. | Utilize our policy templates to assign responsible teams and individuals to PCI DSS principles allowing personnel to acknowledge their responsibility regularly, and assign individual responsibility to specific PCI DSS requirements. |
|---|---|
| Perform a targeted risk analysis to determine frequency of regularly recurring tasks | For each applicable targeted risk analysis required, use Secureframe’s risk management platform to specifically identify the factors that contribute to risk, resulting analysis, and automate the notifications for regular review. |
| Document and confirm PCI DSS scope at least every 12 months | Manage PCI DSS scope within the Secureframe platform, utilize our scoping template for proper documentation, and assign owners to be automatically notified when a review needs to be performed. |
| Authentication updates such as password policy and MFA | Integrate your technology to the Secureframe platform to automatically monitor new PCI DSS authentication requirements such as multi factor authentication for all access, 12 character password requirements, and dynamic analysis of access. |
| Payment page security | Secureframe has established and vetted partners in the script management space to help our customers manage the inventory and integrity of scripts affordably and effectively. |
| Security Awareness Training | Secureframe offers PCI DSS and security awareness training including content related to phishing and social engineering to keep your personnel aware of current common attacks. |
How Secureframe can help you get and stay compliant with PCI DSS over time
PCI DSS will continue to evolve along with new technologies, payment options, and threats.
Secureframe can help ensure your business stays up-to-date with the latest version. With on-staff PCI DSS experts, you’ll be alerted to any PCI SSC updates that might affect you. Secureframe’s automatic evidence collection will also send real-time alerts for any non-conformities so you’re able to maintain PCI DSS compliance with less stress on your team.
Request a demo today to see how Secureframe can help you achieve and maintain PCI compliance with speed and ease.
PCI DSS 4.0 summary of changes
The PCI SSC made significant changes to PCI DSS 4.0. The most notable type of change is evolving requirements, which refers to requirements that were added, updated, or deleted to ensure that the standard is up to date with emerging threats and technologies as well as changes in the payment industry.
Below we’ve listed out all the new requirements in PCI DSS 4.0 that apply to all entities and to service providers only. For both groups, we’ve separated the new requirements that are effective immediately for v4.0 assessment and those that are effective on March 31, 2025.
New requirements for all entities
The requirements and subrequirements below are effective immediately for v4.0 assessments for all entities.
| Requirement 1: Install and Maintain Network Security Controls | |
|---|---|
| 1.1.2 | The roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood. |
| Requirement 2: Apply Secure Configurations to All System Components | |
| 2.1.2 | The roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood. |
| Requirement 3: Protect Stored Account Data | |
| 3.1.2 | The roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood. |
| Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | |
| 4.1.2 | The roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood. |
| Requirement 5: Protect All Systems and Networks from Malicious Software | |
| 5.1.2 | The roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood. |
| Requirement 6: Develop and Maintain Secure Systems and Software | |
| 6.1.2 | The roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood. |
| Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know | |
| 7.1.2 | The roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood. |
| Requirement 8: Identify Users and Authenticate Access to System Components | |
| 8.1.2 | The roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood. |
| 8.3.4 | Increased the number of invalid authentication attempts before locking out a user ID from six to ten attempts. |
| 8.3.9 | Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days. |
| Requirement 9: Restrict Physical Access to Cardholder Data | |
| 9.1.2 | The roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood. |
| 9.2.4 | New requirement. A sub-requirement has been added to an existing requirement to restrict access to consoles in sensitive areas via locking when not in use. |
| Requirement 10: Log and Monitor All Access to System Components and Cardholder Data | |
| 10.1.2 | The roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood. |
| Requirement 11: Test Security of Systems and Networks Regularly | |
| 11.1.2 | The roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood. |
| Requirement 12: Support Information Security with Organizational Policies and Programs | |
| 12.1.3 | Added formal acknowledgment by personnel of their responsibilities. |
| 12.3.2 | New requirement for entities using a Customized Approach to perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach. |
| 12.5.2 | New requirement to document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. |
| 12.8.5 | Clarified that the information about PCI DSS requirements managed by the TPSP and the entity should include any that are shared between the TPSP and the entity. |
Future-dated new requirements for all entities
The requirements and subrequirements below will go into effect on March 31, 2025 for all entities. Until then, they are considered best practices.
| Requirement 3: Protect Stored Account Data | |
|---|---|
| 3.1.3 | New requirement to address former testing procedures that any storage of SAD by issuers is limited to that which is needed for a legitimate issuing business need and is secured. |
| 3.2.1 | A sub-requirement has been added to an existing requirement to address SAD stored prior to completion of authorization through implementation of data retention and disposal policies, procedures, and processes. |
| 3.3.2 | New requirement to encrypt SAD that is stored electronically prior to completion of authorization. |
| 3.4.2 | New requirement for technical controls to prevent copy and/or relocation of PAN when using remote-access technologies. Expanded from former Requirement 12.3.10. |
| 3.5.1.1 | New requirement for keyed cryptographic hashes when hashing is used to render PAN unreadable. |
| 3.5.1.2 | New requirement that disk-level or partition-level encryption is used only to render PAN unreadable on removable electronic media or, if used on non-removable electronic media, the PAN is also rendered unreadable via a mechanism that meets Requirement 3.5.1. |
| Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | |
| 4.2.1 | New requirement. A sub-requirement has been added to an existing requirement to confirm certificates used for PAN transmissions over open, public networks are valid and not expired or revoked. |
| 4.2.1.1 | New requirement to maintain an inventory of trusted keys and certificates. |
| Requirement 5: Protect All Systems and Networks from Malicious Software | |
| 5.2.3.1 | New requirement to define the frequency of periodic evaluations of system components not at risk for malware in the entity’s targeted risk analysis. |
| 5.3.2.1 | New requirement to define the frequency of periodic malware scans in the entity’s targeted risk analysis. |
| 5.3.3 | New requirement for a malware solution for removable electronic media. |
| 5.4.1 | New requirement to detect and protect personnel against phishing attacks. |
| Requirement 6: Develop and Maintain Secure Systems and Software | |
| 6.3.2 | New requirement to maintain an inventory of bespoke and custom software. |
| 6.4.2 | New requirement to deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks. This new requirement removes the option in Requirement 6.4.1 to review web applications via manual or automated application vulnerability assessment tools or methods. |
| 6.4.3 | New requirement for management of all payment page scripts that are loaded and executed in the consumer’s browser. |
| Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know | |
| 7.2.4 | New requirement for review of all user accounts and related access privileges. |
| 7.2.5 | New requirement for assignment and management of all application and system accounts and related access privileges. |
| 7.2.5.1 | New requirement for review of all access by application and system accounts and related access privileges. |
| Requirement 8: Identify Users and Authenticate Access to System Components | |
| 8.3.6 | New requirement to increase password length from a minimum length of seven characters to minimum length of 12 characters (or if the system does not support 12 characters, a minimum length of eight characters). Clarified that until 31 March 2025, passwords must be a minimum length of at least seven characters in accordance with v3.2.1 Requirement 8.2.3. Clarified that this requirement applies only if passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1. Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction. |
| 8.4.2 | New requirement to implement multi-factor authentication (MFA) for all access into the CDE. |
| 8.5.1 | New requirement for secure implementation of multi-factor authentication systems. |
| 8.6.1 | New requirement for management of system or application accounts that can be used for interactive login. |
| 8.6.2 | New requirement for not hard-coding passwords/passphrases into files or scripts for any application and system accounts that can be used for interactive login. |
| 8.6.3 | New requirement for protecting passwords/passphrases for application and system accounts against misuse. |
| Requirement 9: Restrict Physical Access to Cardholder Data | |
| 9.5.1.2.1 | New requirement to define the frequency of periodic POI device inspections based on the entity’s targeted risk analysis. |
| Requirement 10: Log and Monitor All Access to System Components and Cardholder Data | |
| 10.4.1.1 | New requirement for the use of automated mechanisms to perform audit log reviews. |
| 10.4.2.1 | New requirement for a targeted risk analysis to define the frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) |
| 10.7.2 | New requirement for all entities to detect, alert, and promptly address failures of critical security control systems. This requirement applies to all entities – it includes two additional critical security controls not included in Requirement 10.7.1 for service providers. |
| 10.7.3 | New requirement to respond promptly to failures of any critical security controls. For service providers: this is a current PCI DSS v3.2.1 requirement. For all other (non-service provider) entities: this is a new requirement. |
| Requirement 11: Test Security of Systems and Networks Regularly | |
| 11.3.1.1 | New requirement to manage all other applicable vulnerabilities (those not ranked as high-risk or critical) found during internal vulnerability scans. |
| 11.3.1.2 | New requirement to perform internal vulnerability scans via authenticated scanning. |
| 11.6.1 | New requirement to deploy a change-and-tamper detection mechanism to alert for unauthorized modifications to the HTTP headers and contents of payment pages as received by the consumer browser. |
| Requirement 12: Support Information Security with Organizational Policies and Programs | |
| 12.3.1 | New requirement to perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently it is performed. |
| 12.3.3 | New requirement to document and review cryptographic cipher suites and protocols in use at least once every 12 months. |
| 12.3.4 | New requirement to review hardware and software technologies in use at least once every 12 months. |
| 12.6.2 | New requirement to review and update (as needed) the security awareness program at least once every 12 months. |
| 12.6.3.1 | New requirement for security awareness training to include awareness of threats and vulnerabilities that could impact the security of the CDE. |
| 12.6.3.2 | New requirement for security awareness training to include awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1. |
| 12.10.4.1 | New requirement to perform a targeted risk analysis to define the frequency of periodic training for incident response personnel. |
| 12.10.5 | Merged requirements and updated the security monitoring systems to be monitored and responded to as part of the incident response plan to include the following: Detection of unauthorized wireless access points (former 11.1.2). Change-detection mechanism for critical files (former 11.5.1). New requirement. A sub-requirement has been added to an existing requirement for use of a change- and tamper-detection mechanism for payment pages (relates to new requirement 11.6.1). |
| 12.10.7 | New requirement for incident response procedures to be in place and initiated upon detection of stored PAN anywhere it is not expected. |
New requirements for service providers only
The requirements and subrequirements below are effective immediately for v4.0 assessments for service providers only.
| Requirement 12: Support Information Security with Organizational Policies and Programs | |
|---|---|
| 12.9.2 | New requirement to support customers’ requests for information to meet Requirements 12.8.4 and 12.8.5. |
Future-dated new requirements for service providers only
The requirements and subrequirements below will go into effect on March 31, 2025 for service providers only. Until then, they are considered best practices.
| Requirement 3: Protect Stored Account Data | |
|---|---|
| 3.6.1.1 | New requirement. A sub-requirement has been added to an existing requirement to maintain a documented description of the cryptographic architecture that includes prevention of the use of the same cryptographic keys in production and test environments. |
| Requirement 8: Identify Users and Authenticate Access to System Components | |
| 8.3.10.1 | New requirement - if passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days or access to resources is automatically determined by dynamically analyzing the security posture of the accounts. |
| Requirement 10: Log and Monitor All Access to System Components and Cardholder Data | |
| 10.7.2 | New requirement to detect, alert, and promptly address failures of critical security control systems. It will supersede requirement 10.7.1 for service providers on March 31, 2025. |
| Requirement 11: Test Security of Systems and Networks Regularly | |
| 11.4.7 | New requirement for multi-tenant service providers to support their customers for external penetration testing. |
| 11.5.1.1 | New requirement to use intrusion-detection and or intrusion-prevention techniques to detect, alert on/prevent, and address covert malware communication channels. |
| Requirement 12: Support Information Security with Organizational Policies and Programs | |
| 12.5.2.1 | New requirement for service providers to document and confirm PCI DSS scope at least once every six months and upon significant change to the in-scope environment. |
| 12.5.3 | New requirement for service providers for a documented review of the impact to PCI DSS scope and applicability of controls upon significant changes to organizational structure. |
FAQs
Has PCI DSS 4.0 been released?
Yes, PCI DSS 4.0 was released on March 31, 2022.
How many immediately applicable requirements are there in PCI DSS v4.0?
PCI DSS v4. 0 goes into effect on March 31, 2024, and has64new requirements.
Do we need to implement PCI DSS 4.0 now?
Organizations that process, store, transmit, or impact the security of cardholder data must comply with PCI DSS 4.0 by March 31, 2024. They will also have to adopt requirements that have been identified as future dated in v4.0 by by March 31, 2025. Since failure to comply by this deadline can result in fines, penalties, and other consequences, organizations should review the changes in v4.0, implement new controls to meet the updated and new requirements in v4.0, update their reporting templates and forms, and start implementing future-dated requirements as soon as possible.
What are the changes from 3.2.1 to 4.0 in PCI DSS?
The major changes from PCI DSS 3.2.1 to 4.0 focus on meeting the changing needs of the payment card industry and new technologies, promoting continuous security, allowing for flexibility, and enhancing validation. To accomplish these focus areas, PCI 4.0:
- has updated or new requirements related to multi-factor authentication, password, security awareness, and ecommerce
- has new requirements for accountability and annual PCI DSS scope confirmation
- allows organizations to take a customized approach to meet strict PCI DSS requirements
- enhanced PCI DSS assessment reports and allows organizations to complete partial assessments