PCI 4.0 Updated Requirements: What This Means for Merchants
The Payment Card Industry Data Security Standard (PCI DSS) is the global standard for ensuring the secure handling of credit card data. It’s designed to protect cardholder data from theft and misuse.
The release of PCI DSS 4.0, commonly referred to as PCI 4.0, marks the most significant update to the standard since its inception, with foundational changes to its 360 pages.
What’s PCI 4.0?
PCI 4.0 is the latest version of the PCI DSS standard, which provides requirements for merchants and service providers that store, process, or transmit credit card information, or could otherwise impact the security of cardholder data.
The new version of the standard has rolled out and can be assessed against today, along with version 3.2.1. The previous version will be retired on March 31, 2024, and only version 4.0 will be assessed after that date.
PCI 4.0 Changes
Jonathan Smith at Moss Adams recently covered the changes organizations will need to implement to comply with PCI 4.0.
In the remainder of this post, we will discuss changes by requirement, as well as the expected impacts to PCI scope for Basis Theory customers. The outlined changes are not comprehensive but will provide general direction for merchants to consider when maintaining compliance in light of these updates.
Likewise, not all of these changes to requirements will be applicable for merchants required to complete the SAQ-A.
Each merchant should reach out to their QSA for specific information and detailed guidance about their use case.
Requirement 1 Changes
4.0 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.
This does not explicitly introduce additional scope for Basis Theory customers.
Requirement 2 Changes
The core requirements header has been updated to reflect a general focus on secure configurations, not just manufacturer-provided defaults.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
2.1.2 |
Added a new requirement for roles and responsibilities regarding secure configurations. |
Shared |
Requirement 3 Changes
Updates to requirement 3 now require stronger encryption algorithms for data at rest, with disk-level encryption no longer being allowed.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
3.1.2 |
Added a new requirement for roles and responsibilities regarding account data security. |
Shared |
|
3.1 |
3.2.1 |
Added a new requirement addressing SAD retained before completion of authorization through the implementation of data retention and destruction policies, procedures, and processes. |
Shared |
|
N/A |
3.3.2 |
Added a new requirement to encrypt electronically stored SAD before completion of authorization. |
Shared |
|
3.3 |
3.4.1 |
Clarifies that the PAN is masked when displayed so that only authorized personnel can see more than the last four digits of the PAN. |
Basis Theory |
|
12.3.10 |
3.4.2 |
Added new requirement for technical controls to prevent copying and/or migration of PAN when using remote access technologies. Extended from Legacy Requirement 12.3.10. |
Basis Theory |
|
N/A |
3.5.1.1 |
Added a new requirement for keyed cryptographic hashes when hashes are used to render the PAN unreadable. |
Basis Theory |
|
N/A |
3.5.1.2 |
Added a new requirement that disk-level or partition-level encryption is 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. |
Basis Theory |
|
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. |
Basis Theory |
Requirement 4 Changes
Updates to Requirement 4 reflect the focus on “strong cryptography” to protect cardholder data transmission, including multi-factor authentication.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
4.1.2 |
Added a new requirement for roles and responsibilities regarding the transmission of cardholder data. |
Shared |
|
4.1 |
4.2.1 |
This new requirement verifies that certificates used for PAN transmissions over open, public networks are valid and not expired or revoked. |
Basis Theory |
|
N/A |
4.2.1.1 |
Added a new requirement to keep an inventory of trusted keys and certificates. |
Basis Theory |
Requirement 5 Changes
“Anti-virus” language has broadened to “anti-malware” to support a broader range of technologies.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
5.1.2 |
Added a new requirement for roles and responsibilities regarding anti-malware. |
Shared |
|
N/A |
5.2.3.1, 5.3.2.1, 5.3.3, 5.4.1 |
Added new requirements to define the frequency of periodic malware scans and periodic evaluations in targeted risk analysis. Added a new requirement to detect and protect staff from phishing attacks. |
Basis Theory |
Requirement 6 Changes
The changes emphasize that secure development practices should be implemented throughout the software development lifecycle.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
6.1.2 |
Added a new requirement for roles and responsibilities related to software development. |
Shared |
|
N/A |
6.3.2 |
Added a new requirement to keep an inventory of custom-developed software. |
Shared |
|
N/A |
6.4.2 |
Added a new requirement that requires an automated technical solution is deployed to detect and prevent web-based attacks |
Basis Theory |
|
N/A |
6.4.3 |
Added a new requirement to document, maintain, and review payment page scripts that are loaded and executed in the consumer's browser |
Shared |
Requirement 7 Changes
Updates to requirement 7 highlight the importance of secure configurations for all system components.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
7.1.2 |
A new article has been added to define duties and responsibilities regarding managing and reviewing accounts. |
Shared |
|
N/A |
7.2.4 |
Added a new requirement to review all user accounts and associated access privileges. |
Shared |
|
N/A |
7.2.5, 7.2.5.1 |
Added new assignment, management, and review requirements for all application and system accounts and associated access privileges. |
Shared |
Requirement 8 Changes
This requirement now details stronger requirements for network segmentation and monitoring suspicious network activity.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
8.1.2 |
A new article has been added to define duties and responsibilities regarding authentication credentials |
Shared |
|
8.5 |
8.2.2 |
Changed the requirement to focus on allowing shared authentication credentials, but only on an exception basis. |
Shared |
|
8.1.7 |
8.3.4 |
Increased the number of invalid authentication attempts before locking a user ID from six to 10. |
Shared |
|
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). |
Shared |
|
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. |
Basis Theory |
|
N/A |
8.4.2, 8.5.1 |
Added new requirements to securely implement multi-factor authentication (MFA) for all access to CDE. |
Shared |
|
N/A |
8.6.1 |
Added a new requirement for system or application accounts management that can be used for interactive login. |
Shared |
|
N/A |
8.6.2 |
Added a 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. |
Shared |
|
N/A |
8.6.3 |
Added a new requirement to protect passwords of application and system accounts from misuse. |
Shared |
Requirement 9 Changes
Updates clarify 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 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
9.1.2 |
A new article has been added to define duties and responsibilities. |
Shared |
Requirement 10 Changes
Updates require stricter controls for cryptographic key management, including secure storage, rotation, and access control.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
10.1.2 |
A new article has been added to define duties and responsibilities. |
Shared |
|
N/A |
10.4.1.1 |
Added a new requirement for automated mechanisms to perform audit log reviews. |
Shared |
|
N/A |
10.7.2, 10.7.3 |
Added new requirements for all organizations to detect, alert, and promptly address critical security control systems failures. |
Basis Theory |
Requirement 11 Changes
Updates center around new mandates to internal audits and penetration testing.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
N/A |
11.1.2 |
A new article has been added to define duties and responsibilities. |
Shared |
|
N/A |
11.3.1.1 |
Added a new requirement to manage all other valid vulnerabilities (those not rated high risk or critical) found during internal vulnerability scans. |
Basis Theory |
|
N/A |
11.3.1.2 |
Added a new requirement to perform internal vulnerability scans via authenticated scan. |
Basis Theory |
|
N/A |
11.4.7 |
Added a new requirement for service providers to support their customers for external penetration testing. |
Basis Theory |
|
N/A |
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. |
Basis Theory |
|
N/A |
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. |
Basis Theory |
Requirement 12 Changes
Incident response plans should be more detailed, including communication protocols and remediation procedures.
|
PCI DSS 3.2.1 |
PCI DSS 4.0 |
Change |
Who’s Responsible |
|---|---|---|---|
|
12.2 |
N/A |
The requirement for a formal organization-wide risk assessment has been removed and replaced with specific targeted risk analyzes (12.3.1 and 12.3.2). |
No additional scope. |
|
12.4 |
12.1.3 |
Added formal acknowledgment of responsibilities by staff. |
Basis Theory |
|
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. |
No additional scope. |
|
N/A |
12.3.1 |
Added a new requirement to perform a targeted risk analysis for any PCI DSS requirement, providing flexibility in execution frequency. |
Shared |
|
N/A |
12.3.2 |
Added a new requirement to perform a targeted risk analysis for each PCI DSS requirement met with a customized approach. |
Shared |
|
N/A |
12.3.3, 12.3.4 |
Added new requirements to document and review cryptographic cipher suites and protocols, and hardware and software technologies used at least once every 12 months. |
Basis Theory |
|
N/A |
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. |
Basis Theory |
|
N/A |
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. |
Basis Theory |
|
N/A |
12.5.3 |
Added new requirement for service providers for a documented review of the impact on PCI DSS scope and controls’ enforceability over significant organizational structure changes. |
Basis Theory |
|
N/A |
12.6.2 |
Added a new requirement to review security awareness programs at least every 12 months and update if necessary. |
Shared |
|
N/A |
12.6.3.1, 12.6.3.2 |
Added a new requirement for security awareness training, which includes awareness of threats and vulnerabilities that may affect the security of the CDE, and awareness of acceptable use of end-user technologies. |
Shared |
|
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. |
Basis Theory |
What Do These Changes Mean for Merchants?
In our commitment to help customers achieve and maintain PCI compliance, we’ve ensured that our processes meet - and often exceed - the standards outlined in PCI DSS 4.0.
As partners to our customers, we strive to provide clear recommendations on the best ways for customers to meet PCI compliance requirements, if applicable.
If you have any questions about meeting PCI Compliance standards, please contact us.
