What’s New in PCI DSS v4.0?
The PCI Security Standards Council (PCI SSC) issued version 4.0 of the PCI Data Security Standard (PCI DSS) on March 31, 2022. The PCI DSS is a global standard that establishes a baseline of technical and operational standards for protecting account data.
PCI DSS v4.0 replaces PCI DSS version 3.2.1 to address emerging threats and technologies better and provide innovative ways to combat new threats. You can find and review the updated standard and Summary of Changes on the PCI SSC website.
Feedback from the global payments industry has resulted in many changes to the PCI DSS standard. Over the past three years, more than 200 organizations supplied over 6,000 pieces of feedback to ensure that the standard remains relevant in the complex and ever-changing payment security environment.
PCI DSS v4.0 – What you need to know now
Updates to PCI DSS v4.0 aim to meet the evolving security needs of the payment industry, promote security as a continuous process, increase flexibility, and improve procedures for organizations using different methods to achieve their security goals.
Details on updates can be found in the PCI DSS v4.0 Change Summary document on the PCI SSC website.
In addition to the updated PCI DSS standard, supporting documents published in the PCI SSC Document Library include the PCI DSS Summary of Changes v3.2.1 to v4.0, v4.0 Compliance Report (ROC) Template, ROC Compliance Certifications (AOC), and ROC and Frequently Asked Questions.
Additionally, Self-Assessment Questionnaires (SAQs) will be published in the coming weeks. In addition, training, including PCI DSS 4.0 version for evaluators, will be offered in June. The standard and the Amendment Summary will be translated into several languages to support the global adoption of PCI DSS. These translations are also scheduled to be published in the next few months, between March and June 2022.
What will the transition period to PCI DSS v4.0 be like?
After v4.0 is launched, PCI DSS v3.2.1 will be operational for two years. This transition period from March 2022 to March 31, 2024, is intended to provide organizations with time to familiarize themselves with the changes in PCI DSS v4.0, update their reporting templates and forms, and plan and implement changes to meet updated requirements.
As of March 31, 2024, PCI DSS v3.2.1 will be retired, and PCI DSS v4.0 will be the only active version of the standard. However, the existing version of PCI DSS v3.2.1 will be valid for two years until it is discontinued on March 31, 2024, to allow organizations time to grasp the changes in PCI DSS version 4.0 and apply the necessary changes adjustments.
Assessors can undertake assessments using PCI DSS v4.0 or PCI DSS v3.2.1 after completing PCI DSS v4.0 training. In addition, the PCI DSS v4.0 standard gives organizations more time to implement numerous new requirements.
What’s New in PCI DSS v4.0?
Many changes are included in the latest version of the PCI DSS standard. Below are examples of some of these changes. For a comprehensive view of all changes, you can review the Summary of Changes document from PCI DSS version 3.2.1 to version 4.0 available in the PCI SSC Document Library.
In addition to the transition period when PCI DSS v3.2.1 and v4.0 will be active, organizations must implement new requirements identified as best practices in PCI DSS v4.0 by March 31, 2025.
Before March 31, 2015, organizations are not required to meet these new requirements fully. However, organizations that have implemented controls to meet new requirements and are prepared to evaluate controls before the effective date can also audit through these requirements.
After March 31, 2025, these new requirements will apply, so these requirements should also be considered part of a PCI DSS assessment and fully met for PCI compliance.
PCI DSS (Payment Card Industry Data Security Standard) is a global standard that establishes technical and operational criteria for protecting payment data. PCI DSS v4.0 is the next generation of the standard, and it has the following objectives:
- Security methods must develop as threats change to continue to fulfill the security needs of the payments industry.
- The requirements for multi-factor authentication (MFA) are more stringent.
- Password requirements have been updated.
- To address current concerns, new e-commerce and phishing standards have been implemented.
- New requirements have been added with an ongoing understanding of security to promote security as a continuous process.
- Assigned roles and responsibilities for each requirement.
- Adding guidance to help people better understand how to implement and maintain security.
- The new reporting option highlights areas for improvement and provides greater transparency for report reviewers.
- Added new requirements to enable more options and support payment technology innovation to increase flexibility for organizations using different methods to achieve their security goals.
- Permissions for the group, shared, and public accounts.
- Targeted risk analyses aim to enable organizations to establish the frequency of performing certain activities.
- A customized approach, a new way to enforce and validate PCI DSS requirements, gives organizations another option that uses innovative methods to achieve their security goals.
- Detailed verification and reporting options have been developed to improve verification methods and procedures.
- Increased congruence between information reported in a Compliance Report or Self-Assessment Questionnaire and information summarized in the Attestation of Compliance.
Changes and Added New Requirements in PCI DSS version 4.0
Below you can find a high-level summary and explanation of the changes made in the transition from PCI DSS v3.2.1 to PCI DSS v4.0, but not all revisions. The standard should be examined on its whole rather than focusing just on the summary below due to the scope of the changes.
Requirement 1 – Updated the core requirement heading to reflect the focus on network security controls. “Firewalls” and “routers” have been replaced by “network security controls” to support a broader range of technologies used for security objectives traditionally met by firewalls.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| 1.1.5 | 1.1.2 | The requirement “Definition of groups, roles, and responsibilities for managing network components” has been replaced by the general requirement for roles and responsibilities in Requirement 1. |
Requirement 2 – The core requirements header has been updated to reflect a general focus on secure configurations, not just manufacturer-provided defaults.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 2.1.2 | Added new requirements for roles and responsibilities regarding secure configurations. |
Requirement 3 – Added updated main requirement header to reflect the focus on account data.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 3.1.2 | Added new requirements for roles and responsibilities regarding account data security. |
| 3.1 | 3.2.1 | Added new requirement addressing SAD retained before completion of authorization through the implementation of data retention and destruction policies, procedures, and processes. |
| – | 3.3.2 | Added a new requirement to encrypt electronically stored SAD before completion of authorization. |
| 3.3 | 3.4.1 | Clarified that the PAN is masked when displayed so that only the person in need of work can see more than the last four digits of the PAN. |
| 12.3.10 | 3.4.2 | Added new requirements for technical controls to prevent copying and/or migration of PAN when using remote access technologies. Extended from Legacy Requirement 12.3.10. |
| 3.4 | 3.5.1 | Removed pads from “Index tokens and pads” to make the PAN unreadable. |
| – | 3.5.1.1 | Added new requirement for keyed cryptographic hashes when hashes are used to render the PAN unreadable. |
| – | 3.5.1.2 | An added new requirement that disk-level or partition-level encryption be used only to render the PAN unreadable on removable electronic media, or if used on non-removable electronic media, the PAN should also be rendered unreadable via a mechanism that satisfies Requirement 3.5.1. |
| 3.5.1 | 3.6.1.1 | Added a new requirement for service providers to include it in the documented description of the cryptographic architecture to prevent them from using the same cryptographic keys in live and test environments. |
Requirement 4 – Added an updated core requirement header to reflect a focus on “strong cryptography” to protect the transmission of cardholder data.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 4.1.2 | Added new requirements for roles and responsibilities regarding the transmission of cardholder data. |
| 4.1 | 4.2.1 | Added new requirement to verify that certificates used for PAN transmissions over open, public networks are valid and not expired or revoked. |
| – | 4.2.1.1 | Added new requirement to keep an inventory of trusted keys and certificates. |
Requirement 5 – Added an updated core requirement header to reflect the focus on protecting all systems and networks from malware. “anti-virus” has been replaced by “anti-malware” to support a broader range of technologies used for security goals traditionally met by anti-virus software.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 5.1.2 | Added new requirements for roles and responsibilities regarding anti-malware. |
| – | 5.2.3.1 | Added a new requirement to define the frequency of periodic evaluations of system components that are not at risk for malware in targeted risk analysis. |
| – | 5.3.2.1 | Added a new requirement to define the frequency of periodic malware scans in targeted risk analysis. |
| – | 5.3.3 | Added new requirement for a malware solution for removable electronic media. |
| – | 5.4.1 | Added new requirements to detect and protect staff from phishing attacks. |
Requirement 6 – Updated the core requirement header to include “software” instead of “applications.” Clarified that Requirement 6 applies to all system components, except Requirement 6.2, which applies only to custom-developed software.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 6.1.2 | Added new requirements for roles and responsibilities related to software development. |
| – | 6.3.2 | Added new requirements to keep an inventory of custom-developed software. |
| – | 6.4.2 | Added new requirement to deploy an automated technical solution for public web applications that continuously detects and prevents web-based attacks. This new requirement removes the option in Requirement 6.4.1 to inspect web applications through manual or automated application vulnerability assessment tools or methods. |
| – | 6.4.3 | Added a new requirement for managing all checkout page scripts loaded and executed in the user’s browser. |
Requirement 7 – Added updated main requirement header to include system components and cardholder data.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 7.1.2 | A new article has been added to define duties and responsibilities regarding managing and reviewing accounts. |
| – | 7.2.4 | Added a new requirement to review all user accounts and associated access privileges. |
| – | 7.2.5 | Added new assignment and management requirements for all application and system accounts and associated access privileges. |
| – | 7.2.5.1 | Added a new requirement to review all access by application and system accounts and their respective access privileges. |
Requirement 8 – It is standardized with “authentication factor” and “authentication information.” “Non-consumers” has been removed and clarified that the requirements do not apply to accounts used by consumers (cardholders). The remark stating requirements that do not apply to user accounts that only have access to one card number at a time has been removed and appended to each applicable criterion to facilitate a single action.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 8.1.2 | Added requirements for duties and responsibilities. |
| 8.5 | 8.2.2 | Added changed the requirement to focus on allowing shared authentication credentials, but only on an exception basis. |
| 8.1.7 | 8.3.4 | Increased the number of invalid authentication attempts before locking a user ID from six to 10. |
| 8.2.3 | 8.3.6 | Added a new requirement to increase password length from at least seven characters to at least 12 characters (or at least eight characters if the system does not support 12 characters). Added a note that this requirement is not intended to apply to user accounts in point-of-sale terminals that only have access to one card number at a time to facilitate a single transaction. |
| 8.2.4 | 8.3.10 | Added the option to automatically determine access to resources by dynamically analyzing the security status of accounts instead of changing passwords at least every 90 days. |
| – | 8.3.10.1 | New requirement for service providers only – If passwords are the only authentication factor for customer user access, passwords are changed at least every 90 days, or access to resources is determined automatically by dynamically analyzing the security status of accounts. |
| – | 8.4.2 | Added a new requirement to implement multi-factor authentication (MFA) for all access to CDE. Added a note to clarify that MFA is required for both types of access specified in Requirements 8.4.2 and 8.4.3 and clarified that applying MFA to one access type should not replace the need to use another instance of MFA to the other access type. |
| – | 8.5.1 | Added new requirements for secure implementation of multi-factor authentication systems. |
| – | 8.6.1 | Added new requirement for system or application accounts management that can be used for interactive login. |
| – | 8.6.2 | An added new requirement that passwords not be hard-coded into files or scripts for any application and system account that can be used for interactive login. |
| – | 8.6.3 | Added new requirement to protect passwords of application and system accounts from misuse. |
Requirement 9 – Clarified three different areas (sensitive areas, CDE, and facilities) covered in Requirement 9. Explained thoroughly whether each requirement applies to CDE, sensitive areas, or facilities.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 9.1.2 | Added requirements for duties and responsibilities. |
| – | 9.5.1.2.1 | Added new requirement to define the frequency of periodic POI device inspections based on targeted risk analysis. |
Requirement 10 – Added updated core requirement header to reflect a focus on audit logs, system components, and cardholder data. It was stated that these requirements do not apply to the user activities of consumers (cardholders). “Audit traces” have been completely replaced with “Audit logs.”
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 10.1.2 | Added requirements for duties and responsibilities. |
| – | 10.4.1.1 | Added new requirements for automated mechanisms to perform audit log reviews. |
| – | 10.4.1.2 | Added a new requirement for a targeted risk analysis to define the frequency of periodic log reviews for all other system components. |
| – | 10.7.2 | Added new requirements for all organizations to detect, alert, and promptly address critical security control systems failures. |
| – | 10.7.3 | Added new requirements to instantly respond to failures of any critical security control. |
Requirement 11 – Updated the main requirement header.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| – | 11.1.2 | Added requirements for duties and responsibilities. |
| – | 11.3.1.1 | Added new requirement to manage all other valid vulnerabilities (those not rated high risk or critical) found during internal vulnerability scans. |
| – | 11.3.1.2 | Added a new requirement to perform internal vulnerability scans via authenticated scan. |
| – | 11.4.7 | Added new requirements for service providers to support their customers for external penetration testing. |
| – | 11.5.1.1 | Added new requirement for service providers to use intrusion detection and/or intrusion prevention techniques to detect, warn/prevent and address covert malware communication channels. |
| – | 11.6.1 | Added a new requirement for a change and tamper detection mechanism to warn of unauthorized changes to HTTP headers and content of payment pages as received by the user browser. |
Requirement 12 – Added an updated core requirement heading to reflect the focus on corporate policies and programs that support information security.
| PCI DSS v3.2.1 | PCI DSS v4.0 | Definition of Change |
| 12.2 | – | The requirement for a formal organization-wide risk assessment has been removed and replaced with specifically targeted risk analyzes (12.3.1 and 12.3.2). |
| 12.4 | 12.1.3 | Added formal acknowledgment of their responsibilities by staff. |
| 12.3.10 | 3.4.2 | Removed requirement for technical controls and added new Requirement 3.4.2 to prevent PAN duplication when using remote access technologies. |
| – | 12.3.1 | Added new requirements to perform a targeted risk analysis for any PCI DSS requirement, providing flexibility in execution frequency. |
| – | 12.3.2 | Added new requirements to perform a targeted risk analysis for each PCI DSS requirement met with a customized approach. |
| – | 12.3.3 | Added new requirements to document and review cryptographic cipher suites and protocols at least once every 12 months. |
| – | 12.3.4 | Added new requirements to review hardware and software technologies used at least every 12 months. |
| – | 12.5.2 | A new requirement is to document and certify PCI DSS scope at least once every 12 months and anytime the in-scope environment changes significantly. |
| – | 12.5.2.1 | Added new requirement for service providers to document and certify PCI DSS scope at least every six months and whenever there is a significant change in the in-scope environment. |
| – | 12.5.3 | Added new requirements for service providers for a documented review of the impact on PCI DSS scope and controls’ enforceability over significant organizational structure changes. |
| – | 12.6.2 | Added new requirement to review security awareness program at least every 12 months and update if necessary. |
| – | 12.6.3.1 | Added new requirement for security awareness training, which includes awareness of threats and vulnerabilities that may affect the security of the CDE. |
| – | 12.6.3.2 | Added new requirement for security awareness training to include awareness of acceptable use of end-user technologies by Requirement 12.2.1. |
| – | 12.9.2 | Added new requirements for service providers to support their customers’ information requests to meet Requirements 12.8.4 and 12.8.5. |
| – | 12.10.4.1 | Added a new requirement to perform a targeted risk analysis to define the frequency of periodic training for incident response personnel. |
| 12.10.5 11.1.2 11.5.1 | 12.10.5 | The security monitoring systems to be monitored and responded to as part of the consolidated requirements and incident response plan have been updated to include: Detection of unauthorized wireless access points (previous 11.1.2), Change detection mechanism for critical files (previously 11.5.1), New requirement clause for using a change and tamper detection mechanism for checkout pages (new requirement relates to 11.6.1). |
| – | 12.10.7 | Added new requirements to implement and initiate incident response procedures upon detecting PAN hiding in an unexpected location. |
Discover more from Chad M. Barr
Subscribe to get the latest posts sent to your email.
