Are you Ready for the Requirements of PCI DSS v4 Next Year?
The PCI DSS version 4 update, released in 2022, introduced a series of enhancements to ensure that organisations handling cardholder data maintain robust security practices. While many of the changes were clarifications or reordering of existing requirements, several “future-dated” requirements were added that will become mandatory after 31st March 2025. These future-dated requirements will be included in PCI DSS assessments after this date, and organisations must understand how this affects them well before their annual assessment.
Blackfoot has extensive experience as a PCI DSS QSA company. We provide our customers with consultancy and auditing services to help them achieve and maintain compliance with the PCI DSS. We have completed many assessments using version 4 of the standard and are assisting organisations in preparing for the changes coming in 2025. This post will explain these additional requirements, why they matter, and how you can start preparing today.
Why Future-Dated Requirements Matter
The new requirements matter because, as with all PCI DSS requirements, they help protect against common threats that result in cardholder data breaches. PCI DSS version 4 addresses threats that were less common when the previous version, 3.2.1, was released in 2018.
Version 4 was released in 2022 and contained two sets of future-dated requirements. The first batch of new requirements applied from April 2024, with more coming in 2025. The 31st March 2025 deadline marks a shift in PCI DSS compliance, with all changes introduced in the release of version 4 finally coming into effect after that date.
The PCI SSC clearly understood that the changes in version 4 would take time to adopt, which is consistent with previous updates to the standard, where the SSC also provided generous transition timelines. Businesses that have been proactive and implemented these practices already will have a smoother journey beyond March 2025; however, many organisations have been slow to act and may face compliance issues if new requirements aren’t addressed soon.
Broadly speaking, the 2024 requirements were straightforward and should already be in place for any compliant organisation. An additional year was provided to address the more complex requirements, which may involve infrastructure changes and financial investments and necessitate a more phased approach to ensure compliance.
Summary of Future-Dated Requirements
It may be generous to describe this as a “quick summary” because there are so many changes to work through. The details below are summaries of these changes, and as always, a QSA and the PCI DSS itself should be referred to for comprehensive information.
For organisations that complete a reduced assessment based on SAQ criteria, here is a breakdown of the future dated requirement changes per SAQ. This will enable you to focus on the changes that will impact your audits:
- SAQ A MOTO – 3.2.1
- SAQ A MOTO and eCommerce – 3.2.1, 6.4.3, 8.3.6, 11.6.1
- SAQ A Commerce only – 6.4.3 and 11.6.1
- SAQ A-EP – 3.2.1, 4.2.1, 5.2.3.1, 5.3.2.1, 5.3.3, 5.4.1, 6.3.2, 6.4.2, 6.4.3, 7.2.4, 7.2.5, 8.3.6, 8.4.2, 8.5.1, 8.6.1, 8.6.2, 8.6.3, 10.4.1.1, 10.4.2.1, 11.6.1, 12.3.1, 12.6.3.1
- SAQ B – None
- SAQ B-IP – 4.2.1 only
- SAQ C-VT – 5.3.3, 5.4.1, 8.3.6, 12.6.3.1
- SAQ P2PE –3.2.1 only
- SAQ D – all bar the service provider requirements noted below
- SAQ D SP – all requirements listed below
Here are the requirements that will become active after 31 March 2025:
Data Storage and Encryption (Requirements 3.2, 3.3, 3.4, 3.5, 3.6, 4.2)
3.2.1 – Minimise account data storage
Organisations must implement updated data retention and disposal policies required by version 3.2.1 and extend to cover limiting sensitive authentication data (SAD) storage before authorisation completion.
3.3.2 – Encrypting sensitive authentication data (SAD)
SAD stored electronically before authorisation completion must be encrypted using strong cryptography.
3.3.3 – Issuer requirements for SAD storage
For issuers and companies supporting issuing services, any SAD storage must:
- Be limited to legitimate business needs.
- Be encrypted using strong cryptography.
3.4.2 – Prevent copying of PAN with remote access technologies
Technical controls must be implemented to prevent personnel from copying or relocating PAN using remote-access technologies unless explicitly authorised with a legitimate business need.
3.5.1.1 – Keyed hashes for PAN
PAN must be rendered unreadable using keyed cryptographic hashes of the entire PAN, and key management must adhere to PCI DSS Requirements 3.6 and 3.7.
3.5.1.2 – Encryption for disk/partition-level data
If disk or partition-level encryption is used for PAN storage, it must only be on:
- Removable media, or
- Non-removable media if another mechanism meeting Requirement 3.5.1 is also used to render PAN unreadable.
3.6.1.1 – Cryptographic architecture (service providers)
Service providers must maintain documentation of their cryptographic architecture, covering:
- Algorithms, protocols, and keys used, including key strength and expiry.
- Preventing the use of cryptographic keys in both production and test environments.
- Key usage for each cryptographic key.
- An inventory of hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices.
4.2.1 – Safeguard PAN during transmission
Organisations must ensure:
- Only trusted keys and certificates are used.
- Certificates are valid, not expired or revoked.
- Secure versions of protocols are used without fallback to insecure versions.
- Appropriate encryption strength is used based on the encryption methodology.
4.2.1.1 – Inventory of trusted keys and certificates
An inventory of all trusted keys and certificates used to protect PAN during transmission over open, public networks must be maintained.
System and website protection (Requirements 5.2, 5.3, 5.4, 6.3, 6.4)
5.2.3.1 – Evaluating system components not at risk for malware
The frequency of evaluations for system components identified as not at risk for malware must be defined by the entity’s targeted risk analysis.
5.3.2.1 – Conduct a risk assessment for periodic malware scans
A risk assessment must be conducted for organisations relying on periodic malware scans to meet requirement 5.3.2. This doesn’t apply if continuous behavioural analysis is used.
5.3.3 – Anti-Malware for removable media
The anti-malware solution for removable media must:
- Perform automatic scans when media is inserted or connected, or
- Use continuous behavioural analysis when media is inserted.
5.4.1 – Detecting and protecting against phishing attacks
Processes and automated mechanisms must be in place to detect and protect personnel from phishing attacks.
6.3.2 – Inventory of software components
Organisations must maintain a bespoke and custom software inventory, including third-party components, to facilitate vulnerability and patch management.
6.4.2 – Web application attack detection
An automated technical solution must be deployed in front of public-facing web applications to detect and prevent web-based attacks. This solution must be actively running, up to date, and configured to block attacks or generate alerts that are immediately investigated.
6.4.3 – Management of payment page scripts
Payment page scripts that load in consumers’ browsers must be managed with methods to:
- Authorise each script.
- Ensure script integrity.
- Maintain an inventory with a written justification for each script’s necessity.
Authentication and authorisation (Requirements 7.2, 8.3, 8.4, 8.5, 8.6)
7.2.4 – Review of user accounts and access privileges
User accounts, including those of third parties, must be reviewed every six months to ensure appropriate access privileges based on job function. Inappropriate access must be addressed, and management must acknowledge the appropriateness of access.
7.2.5 – Implement least privilege access for application or system accounts
Any accounts used by applications or systems, rather than assigned to individual users, must be configured with the least privileges necessary for the application or system and prevented from being used for anything else.
7.2.5.1 – Review of application and system accounts
Access for application and system accounts must be reviewed periodically based on a targeted risk analysis to ensure access remains appropriate, with any inappropriate access addressed. Management must acknowledge the appropriateness of access.
8.3.6 – Password complexity
If passwords are used for authentication, they must:
- Have a minimum of 12 characters (or eight if the system doesn’t support 12).
- Include both numeric and alphabetic characters.
8.3.10.1 – Service provider password requirements (service providers)
For service providers, if passwords are the sole authentication factor:
- Passwords must be changed at least every 90 days, or
- Security posture must be dynamically analysed to determine access in real-time.
8.4.2 – MFA for non-console access
Multi-factor authentication (MFA) must be implemented for all non-console access into the cardholder data environment (CDE).
8.5.1 – MFA implementation
MFA systems must:
- Be protected from replay attacks.
- Only be bypassed by users, including administrative users, if specifically authorised for a limited time.
- Use two different types of authentication factors.
- Require all factors to be successful before granting access.
8.6.1 – Interactive login for application/system accounts
If application or system accounts can be used for interactive login, access must be controlled, justified, and monitored, and every action must be attributable to an individual user.
8.6.2 – No hard-coded passwords in scripts
Passwords for application and system accounts used for interactive login must not be hard-coded into scripts, configuration files, or custom source code.
8.6.3 – Password management for application/system accounts
Application and system account passwords must be managed by:
- Periodically changing passwords based on a targeted risk analysis or when compromise is suspected.
- Constructing passwords with sufficient complexity.
POI devices (Requirement 9.5)
9.5.1.2.1 – Frequency of POI device inspections
The entity’s targeted risk analysis must define the frequency and type of point-of-interaction (POI) device inspections.
Logging, monitoring, and security testing (Requirements 10.4, 10.7, 11.3, 11.4, 11.5, 11.6)
10.4.1.1 – Automated audit log reviews
Automated mechanisms must be used to perform audit log reviews.
10.4.2.1 – Frequency of log reviews
The entity’s targeted risk analysis must define the frequency of log reviews for other system components.
10.7.2 – Prompt detection and response to security control failures
Failures of critical security control systems, such as network security controls, IDS/IPS, anti-malware solutions, or audit logging mechanisms, must be promptly detected and addressed.
10.7.3 – Responding to security control failures
Organisations must have procedures in place to promptly restore security functions, document failure durations, investigate causes, and prevent recurrence.
11.3.1.1 – Management of vulnerabilities
All applicable vulnerabilities (not ranked as high-risk or critical) must be addressed based on a targeted risk analysis, with rescans conducted as necessary.
11.3.1.2 – Authenticated internal vulnerability scans
Internal vulnerability scans must be performed via authenticated scanning, with sufficient privileges granted for systems that accept credentials. Systems unable to accept credentials for authenticated scans must be documented.
11.4.7 – External penetration testing for multi-tenant providers
Multi-tenant service providers must support external penetration testing for their customers.
11.5.1.1 – Covert malware communication detection (service providers)
Service providers must detect and prevent covert malware communication channels through intrusion detection or prevention techniques.
11.6.1 – Tamper-detection for payment pages
A tamper-detection mechanism must be deployed to alert personnel to unauthorised modifications to payment page HTTP headers or scripts. This mechanism must function weekly or at a frequency defined by a targeted risk analysis.
Risk, documentation, and reviews (Requirements 12.3, 12.5, 12.6, 12.10)
12.3.1 – Targeted risk analysis documentation
For each requirement specifying a targeted risk analysis, organisations must document the protected assets, the threats being mitigated, and the analysis results. These analyses must be reviewed annually or when a significant change occurs.
12.3.3 – Cryptographic protocol review
All cryptographic cipher suites and protocols must be documented, monitored, and reviewed at least annually to address anticipated cryptographic vulnerabilities.
12.3.4 – Hardware/software review
Organisations must review hardware and software annually to ensure they receive timely security fixes, support compliance, and have a plan to address any end-of-life technologies.
12.5.2.1 – PCI DSS scope validation (service providers)
Service providers must document and confirm the PCI DSS scope at least every six months or after significant changes in the in-scope environment.
12.5.3 – Documenting organisational structure changes
Significant changes to the organisational structure must result in a documented review of the impact on PCI DSS scope, with results communicated to executive management.
12.6.2 – Security awareness program review
The security awareness program must be reviewed and updated at least annually to address new threats and vulnerabilities.
12.6.3.1 – Security awareness training
Security awareness training must cover threats such as phishing and social engineering.
12.6.3.2 – Acceptable use training
Security awareness training must include the acceptable use of end-user technologies.
12.10.4.1 – Incident response training frequency
The frequency of incident response training must be defined in the entity’s targeted risk analysis.
12.10.5 – Incident response plan for security alerts
The incident response plan must include monitoring and responding to alerts from systems such as IDS/IPS, network security controls, and anti-malware solutions.
12.10.7 – Incident response for stored PAN
Organisations must establish procedures to respond when PAN is detected outside the CDE, including secure deletion, investigation of the source, and remediation of any data leaks.
Preparing for PCI DSS Version 4 Changes in 2025
If any changes explained above apply to your PCI DSS scope, you should prepare for them now. Here are a few practical steps to ensure compliance:
- Conduct a gap analysis: Identify which of the future-dated requirements your organisation is not yet compliant with. This will give you a clear picture of the changes you must make before April 2025. Blackfoot can help organisations with structured PCI DSS gap analysis services or ad-hoc support.
- Engage with a QSA early: Work with a Qualified Security Assessor (QSA) to get expert guidance on implementing these new requirements effectively. Your QSA can also help determine the applicability of any new requirements and discuss scope-reduction options if the requirements are challenging to implement.
- Allocate resources: Whether it’s budget, personnel, or technology, ensure that you have the resources in place to implement the required changes. This could include investing in new security tools, such as anti-phishing software, upgrading your encryption systems, and website changes.
- Update policies and procedures: Many new requirements involve implementing or refining policies, such as data retention or incident response. Review your current documentation and make the necessary updates.
- Start now: With the deadline approaching, there’s no time to waste. Organisations that wait too long could struggle to meet the requirements at the last minute. If your next assessment is before April 2025, it’s worth considering implementing the new requirements early. Otherwise, it may be 2026 before your QSA first assesses them. By including some or all of these requirements in your next assessment, your QSA can provide assurance that you’ll be prepared in 2026.
Conclusion
The future-dated requirements in PCI DSS version 4 may seem daunting, but they are crucial for maintaining the highest security standards required to protect cardholder data. By implementing these practices now, your organisation will ensure compliance going into 2025 and beyond and strengthen its overall security posture.
Do you need help preparing for PCI DSS v4 changes? Contact us today to discuss how we can help your organisation stay ahead of the curve and ensure a smooth transition to PCI DSS version 4 compliance.
