PCI DSS 4.0 Requirements: A Deep Dive into the Latest Changes and How They Affect Your Organization
Released on March 31, 2022, the latest version of the Payment Card Industry Data Security Standard — PCI DSS 4.0 — is currently in effect today. It will become the only active version on March 31, 2024.
By March 31, 2025, organizations will also have to adopt requirements that have been identified as future dated in v4.0.
To meet these compliance deadlines, organizations that store, process, transmit, or impact the security of cardholder data must:
- 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
- start implementing future-dated requirements to be assessed by March 31, 2025 at the latest
This can be difficult to do on your own. That’s why Marc Rubbinaccio, a former QSA and currently the subject matter expert for PCI DSS at Secureframe, and Jonathan Smith, a QSA at Moss Adams, hosted a Secureframe Expert Insights webinar on May 11.
They provided a deep dive into the most significant changes for PCI DSS 4.0 and guidance for how you can comply. Keep reading or watch the video replay on demand to get their insights.
PCI DSS 4.0 vs 3.2.1 requirements
As the technology and threat landscapes rapidly evolve, the security frameworks designed to protect organizations from security incidents and breaches must keep pace. That’s why frameworks like PCI DSS are regularly updated.
While keeping up with the latest changes to PCI DSS compliance requirements can be difficult, organizations that adapt will be most able to protect payment data.
Below are the major differences between PCI DSS v4.0 and v3.2.1 and why you should comply with the latest iteration.
1. Continuing to evolve
One of the main goals 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. That’s why PCI DSS 4.0 contains updates to multi-factor authentication, password, and security awareness requirements as well as new ecommerce requirements.
Multi-factor authentication and password requirements
A major topic of discussion in the security community is how to best secure authentication without hampering the ability of users to log into systems and perform actual work.
A good example of this is NIST revising their password requirements a couple of years ago to specifically address how passwords were getting hacked in the real world. PCI DSS 4.0 has improved upon authentication requirements, forcing multi-factor authentication for all users accessing the cardholder data environment, not just administrators. Password length requirements have also been increased from 8 to 12 characters. Finally, instead of having to rotate all passwords after 90 days, PCI DSS now gives organizations the option to use dynamic analysis to determine access to resources automatically.
Security awareness requirements
Social engineering, and phishing in particular, is still one of the most prevalent ways attackers gain access to systems and steal cardholder data. No matter how strong your cloud and application security configurations are, if one employee with access to sensitive data falls for a spear phishing attack, hackers could gain that same access and start leaking cardholder data.
As a result, PCI DSS is bolstering its stance on security awareness training by requiring specific threats and vulnerabilities be included in organizations’ training programs. For example, if you are an e-commerce merchant and offer support over chat, your support personnel should be aware of specific types of phishing attacks that could occur over live chat.
Security awareness training must also be reviewed and updated annually based on changes to the environment or potential risks.
Another addition to security awareness requirements is delineating acceptable use of all end-user technology, including accessing and using workstations and understanding the consequences for not adhering to these acceptable use policies.
Ecommerce requirements
One of the biggest and most impactful changes in PCI DSS 4.0 revolves around the managing and handling of scripts within payment pages and payment-adjacent pages.
Prior to PCI DSS 4.0, there were no specific requirements relating to the handling of scripts that are executed and loaded in a consumer’s browsers. This led to the prevalence of Magecart attacks, which primarily focused on e-commerce merchants. Hackers injected their own code into payment pages to hijack the cardholder forms or redirect consumers to malicious websites.
2. Promote continuous security
Another goal of PCI DSS v4.0 is to support long-term, continuous processes to protect payment data.
A common issue among organizations pursuing PCI compliance is that they heavily invest in implementing processes, procedures, and configurations immediately prior to their assessment — then they receive their certification and PCI DSS becomes an afterthought for the next 11 months. As a result, many organizations pursuing recertification miss regular reviews throughout the year due to mis-organized controls. This can lead to either non-compliance against PCI or the auditor having to draft up a compensating control based on how the organization would go above and beyond to meet this control for the following year.
A major gap that PCI DSS 4.0 is looking to fill is bolstering responsibility assignment for security controls. Now, instead of just stating quarterly vulnerability scanning will be performed, the organization must state who in the organization is responsible for meeting this control and driving all other PCI DSS security controls.
Another aspect that was previously overlooked is PCI DSS scoping. Scoping your cardholder data environment is critical for ensuring all applicable resources and personnel are included in the scope of the audit as well as the scope of all required security controls, configurations, and reviews. Previously, if changes are made throughout the audit period that could affect your scope, the auditor would discover this only when the next year’s audit is about to start. With PCI DSS 4.0, an organization is now required to review and document their PCI DSS scope throughout the year. This ensures that the organization is maintaining PCI DSS compliance accurately.
3. Allow for flexibility
To help organizations prioritize security as a continuous process, PCI DSS 4.0 also provides additional flexibility. This flexibility is meant to allow organizations to choose security controls most suited to their business and security needs. This is reflected in two major ways in PCI DSS 4.0.
One significant change in PCI DSS 4.0 includes changing organizations’ mindset on risk management. Previously, organizations were required to perform a full annual risk assessment as well as interval testing defined by the PCI DSS, with some tasks being daily, biannual, or quarterly. With PCI DSS 4.0, not only should a full annual risk assessment be performed, but interval testing can now be specifically defined by the organization based on risk. For example, access reviews can now be performed at a regular interval that makes the most sense to the organization based on the risk defined.
PCI DSS 4.0 also introduced the customized approach, a second method for entities to meet strict PCI DSS requirements. Customized approach provides organizations with the flexibility to meet the security objectives of PCI DSS requirements using new technology and innovative controls. The assessor will validate that the customized controls meet the PCI DSS requirements by reviewing the entity's customized approach documentation and developing a procedure for validating the controls are being met by the customized approach.
To be clear, this will take additional work and documentation from the organization. It will ultimately be easier to meet the requirement as defined by PCI DSS, but some mature organizations may opt for a customized approach.
4. Enhanced validation
Another major change made by PCI DSS is to now allow organizations to complete partial assessments.
Previously, if any requirement was not tested by the auditor, the organization was automatically considered not compliant. Now with PCI DSS 4.0, organizations have the flexibility to only test a certain aspect of their service as requested by a customer and a QSA will sign off that the controls tested were compliant to PCI DSS.
Recommended reading
PCI History: How the Standard Came To Be
What do these changes mean for your organization and how to respond?
Whether you’re already PCI certified or pursuing PCI certification for the first time, you should take the following steps to start transitioning to PCI DSS v4.0.
1. Understand the new requirements and changes to existing ones
To start your journey to PCI DSS v4.0, review the PCI DSS 4.0 documentation for an in-depth comparison for every control that is changing and is brand new.
If you are a Secureframe customer, reach out to your compliance manager to have an in-depth discussion about your current environment and scope to determine which controls are applicable to you.
You can also leverage the expertise of your QSA and their experience with your environment. If you do not have a QSA currently, Secureframe has a network of audit partners we can introduce you to.
2. Review the timeline for implementation
Since not all requirements will need to be in place by 2024, it is important to prioritize the controls based on the implementation timelines. You need to understand which controls are effective immediately for PCI DSS 4.0 assessments and prioritize those so you are prepared for 2024. Then, understand and prioritize the controls for the future dated requirements in 2025.
3. Put a plan in place
To ensure a smooth transition to PCI DSS 4.0, put together a solid plan, including an implementation timeline with assigned owners for all policies, processes, and configuration changes required for PCI DSS 4.0. Prioritize the most impactful requirements and the requirements with the earliest implementation date.
Recommended Reading
Fast-Track PCI DSS Compliance with Secureframe
PCI DSS 4.0 requirements and how to meet them
With the changes in PCI DSS 4.0, organizations are challenged with complying with hundreds of updated or new requirements by March 2024 and future-dated requirements by March 2025. To help, we’ve provided an overview of the most significant PCI DSS 4.0 requirements and guidance for how to comply in the tables below.
| Must be performed immediately for all 4.0 assessments | What changed? | How to meet this requirement |
|---|---|---|
| All Requirement Sections | Roles and responsibilities for performing activities in each requirement must be documented, assigned, and understood. | Use a responsibility assignment matrix to assign owners. Can be done within a platform like Secureframe. |
| Requirement 8 | Increased the number of invalid authentication attempts before locking out a user ID to ten attempts. | Set threshold for invalid authentication attempts before locking out to ten attempts. |
| 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. | Use dynamic analysis, a solution that takes multiple data points and determines in real time if an account should gain access. | |
| Requirement 9 | Restrict access to consoles in sensitive areas via locking when not in use. | Lock the login screens of consoles when not in use. |
| Requirement 12 | Added requirement for personnel to formally acknowledge their responsibilities. | Include the security responsibilities of all roles within the organization in your information security policy. |
| Perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach. | Implement a controls matrix and risk analysis for controls being met via customized approach (see appendix D/E of PCI 4.0 for more information). | |
| Document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. | Develop a document that contains info related to the storage of CHD (purpose, retention, elements, access, encryption), internal systems and apps consisting of the CDE, and connections to vendors or third parties. | |
| Service providers must support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5. | Document a process for obtaining PCI AOC’s from third-party service providers as well as a plan for receiving evidence in case the TPSP is not PCI compliant. |
| Future-dated requirements effective in 2025 | What changed? | How to meet this requirement |
|---|---|---|
| Requirement 3 | Include locations of stored SAD prior to authorization in data retention / disposal policies, procedures and processes. | Inventory SAD data flows to understand where it goes (will involve product/development). |
| Issuers must define business justification for the storage of sensitive authentication data. | In a policy or similar document, state the instances of stored sensitive authentication data, and the justification for the storage of that data. | |
| Encrypt SAD that is stored electronically prior to authorization. | Utilize the same processes to encrypt SAD that is used for PAN (but consider utilizing different keys for SAD vs PAN). | |
| Establish technical controls to prevent copying of PAN when using remote-access technologies. Document a list of personnel allowed to copy or relocate PAN data. | Identify a solution that will help stop the copying of PAN. Can be DLP, PCoIP, blocking of copy/paste functions over RDP, etc. | |
| When hashing is used to render PAN unreadable, ensure all aspects of the hash is documented and the hashing method results in keyed cryptographic hashes of the entire PAN. | When hashing, use cryptographic keys. | |
| If disk level/partition level or transparent encryption is used to render PAN unreadable, it must only be used on removable media devices. | If your cloud solution uses transparent encryption (i.e. the decryption process is tied with user access such that data is automatically encrypted), implement an additional layer of encryption. | |
| Service providers must document the prevention of shared cryptographic keys between production and test environments. | Document how keys are different between production and test environments. | |
| Requirement 4 | Any certificates used to protect PAN data over open / public networks must be confirmed to be valid and not expired. All certificates and trusted keys must be maintained in a documented inventory. | Inventory all card flows over the Internet. Document where you control the encryption (i.e. your website) and where another organization controls encryption (i.e. their website/API). Make sure that your certificates are signed and that you don’t transmit PAN to an organization with an expired certificate. |
| Requirement 5 | Any systems not commonly affected by malware must have a defined periodic risk review. Malware scans must be defined by the organization based on risk. | Perform a risk assessment that can be based upon documented risks - not a knee jerk reaction. |
| Removable media must be reviewed for malware either automatically when attached to systems, or through analysis of those systems when removable media is attached. | Ensure your AV product can support scanning of removable media. | |
| Implement an automated mechanism for detecting and protecting personnel against phishing attacks. | Implement anti-spoofing controls through an email provider and link-scrubbers or anti-malware technology. | |
| Requirement 6 | Maintain an inventory of bespoke and custom software including third-party integrated components. | Utilize tools and/or manual processes to enumerate libraries. (something like Snyk should be able to help). |
| Implement an automated technical solution to detect and prevent web application attacks such as a web application firewall (WAF). Implement methods to determine all payment page scripts are authorized, maintaining integrity, and documented in a script inventory. | The integrity of scripts can be enforced by several different mechanisms including, but not limited to: sub-resource integrity (SRI), a CSP, and proprietary script or tag-management systems, which can prevent malicious script execution. A tool like SourceDefence can help with this. | |
| Requirement 7 | All user accounts and privileges need to be reviewed at least every six months to ensure access is granted based on job function. | Make sure to account for job transfers. Folks who are transferred who don’t need as much access commonly fall through these processes. |
| Application and system accounts must be managed based on least privilege and reviewed periodically based on risk. | Inventory non-user accounts, then ascertain guardrails in how these accounts should be used (limit admin permissions, restricting hours of use, ability to be used for remote access, etc.). | |
| Requirement 8 | Increased minimum password length from seven to 12 characters. | Use passwords with at least 12 characters. |
| 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 utilize zero trust (Service Providers only). | Analyze if you would like to rotate passwords or implement zero trust (i.e only allowing logon for various parameters, like geolocation, time of day, etc.). | |
| Implement MFA for all access into the cardholder data environment, not just non-console remote access. | The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function. | |
| Secure the implementation of the MFA system. | Make sure MFA can’t be bypassed and isn’t susceptible to replay attacks. | |
| Manage the use of system / application accounts with interactive login. | Try to disable interactive use of application accounts. If not, there will be five actions that need to be taken: time limited, business justification, approval, user identity is confirmed, and user attribution is tracked. | |
| Do not hard-code passwords/passphrases into files or scripts for any application / system accounts that can be used for interactive login. | Utilize code repository functions to detect accounts/passwords. | |
| Implement practices for protecting passwords for application and system accounts against misuse. | Prepare to rotate system passwords, and make sure their password/rotation mix makes sense. | |
| Requirement 9 | Perform periodic POI device inspections based on risk. | Define how often this review is to be performed. |
| Requirement 10 | Utilize automated mechanisms to perform audit log reviews. | Make sure any systems you were doing manual logs in can ship logs to your SIEM. |
| Implement controls to detect, alert, and address / respond to failures of critical security control systems (new for merchants). | Service providers have been doing this requirement — now merchants will need to. Figure out how you can detect when a security control fails (ie. who watches the watcher). | |
| Requirement 11 | Manage all non-critical and non-high-risk ranked vulnerabilities found during internal vulnerability scans. | Make sure you start focusing on medium/lower risk vulnerability churn. |
| Perform authenticated internal vulnerability scanning. | Make sure your vulnerability scanning tool can do authenticated scans. Inventory all targets to see if they can accept authenticated scans. Set up credentials, and manage credentials in accordance with requirements in section 8. | |
| Multi-tenant service providers must support their customers' need for external penetration testing. | Set up a contracts process to enable this requirement. | |
| Service providers need to implement intrusion-detection and or intrusion-prevention techniques to detect, alert on / prevent, and address covert malware communication channels. | See if your current IDS/IPS can detect covert malware communication channels. Select an IDS/IPS that can do this. | |
| Implement a change-and-tamper detection mechanism on payment pages to monitor and alert for unauthorized modifications. | Mechanisms include but are not limited to: the report-to or report-uri CSP directives can report violations of the Content Security Policy (CSP), Synthetic user monitoring can detect changes to JavaScript in payment pages and alert personnel, Embedded tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected, Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel. A tool like SourceDefence can help with this. | |
| Requirement 12 | Perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently the control is performed. | Each of these are documentation/process-related. Simply review the requirements and begin the documentation processes. Contact your Secureframe compliance manager or QSA to help answer questions. |
| Document and review cryptographic cipher suites and protocols in use at least once every 12 months. | ||
| Review hardware and software technologies in use annually. | ||
| Service providers must document and confirm PCI DSS scope at least every 6 months and upon significant change to the in-scope environment. | ||
| Review and update the security awareness program at least once every 12 months. Include threats, vulnerabilities, and acceptable use of end-user technologies in security awareness training. | ||
| Perform periodic incident response training based on risk. Implement an incident response process for detection of stored PAN anywhere it’s not expected. |
How Secureframe can help you comply with the most current version of PCI DSS
PCI DSS can be a difficult framework to organize, manage, and stay compliant to year after year. This is where Secureframe comes in.
You will be assigned a compliance manager who will help you scope your PCI DSS environment annually, making sure you understand what your cardholder data environment is, what connected-to systems are, and which networks are isolated and out-of-scope. The compliance manager will adjust the PCI DSS report to reflect your PCI DSS scope so you only see the requirements that are applicable to you.
Throughout the year, Secureframe compliance managers will be available to help assist you with readiness work and perform a gap assessment with you prior to your audit so you can be confident in your PCI DSS compliance before your auditor performs the actual assessment.
Owners and responsibilities for controls are a major sticking point in PCI DSS 4.0. Secureframe will allow you to assign owners to tasks, controls, and reviews all within the platform so you can meet these requirements.
Secureframe also provides security awareness training and secure code training and we review the training annually to ensure they are up to date. You can manage the completion of security awareness training and policy acceptance including acceptable use all within the Secureframe platform.
Since iterations of controls are now risk-based, Secureframe will allow you to manage the intervals for tests based on your assessed risks, so if you want to perform vulnerability scans monthly, you will have the ability to set this test to trigger monthly.
We also have pre-evaluated partners for any third party service that Secureframe cannot complete. We have a network of penetration testers, ASV scanning partners, as well as audit partners who would be happy to assist you in becoming PCI DSS compliant.
To learn more about how Secureframe can help you achieve and maintain PCI compliance, schedule a demo.