The Payment Card Industry Data Security Standard (PCI DSS) exists to secure payment card data and encourage global adoption of consistent data security measures. For anybody involved in payment processing – merchants, processors, acquirers, issuers, and other service providers – the standard ensures they store, process, and transmit payment card data securely.
The previous standard, PCI DSS v3.2.1, was published back in May 2018. Since then, however, the complexity around securing payment card data has increased due to the adoption of new technologies such as cloud and serverless computing. Considering this, there wasa need for the standard to be updated, which is where the long-awaited Payment Card Industry Data Security Standard (PCI DSS) 4.0 comes in.
Published by the PCI Security Standards Council (PCI SSC) on the 31st March 2022, it provided a significant update to v3.2.1. and introduced a number of new PCI DSS requirements that help the parties involved in payment processing ensure their practices take these latest trends into account.
See our related content for guidance on how to transition to PCI DSS 4.0 and why you should comply with PCI DSS.
PCI DSS 4.0 Changes
These are the 10 most notable new requirements when comparing PCI DSS 4.0 to v3.2.1 (all future-dated and effective from the 31st March 2025).
Detect and protect staff against phishing attacks
Bi-annual review of all user accounts and related access privileges
More stringent password requirements (length increasing from 7 to 12 characters, no hard-coding in files or scripts)
Multi factor authentication required for all access to Cardholder Data Environment (CDE) vs administrative access to CDE previously, and a revamp of multi factor authentication requirements for secure implementation.
Daily log reviews by use of automated mechanisms vs the option of manual reviews previously
Authenticated scanning for internal vulnerability scans
Address covert malware communication channels by use of intrusion detection/prevention techniques
More thorough, specific, and targeted risk assessment
Regular PCI DSS scope confirmation including card data discovery techniques
Detect, alert, and promptly address failures of critical security control systems to ensure continuous functionality and security of systems like firewalls and intrusion detection systems
When Did PCI DSS v4 Come Into Effect?
PCI DSS 4.0 was first published on the 31st of March 2022. As with previous versions of the standard, there was a usual transition period of two years, meaning that PCI DSS v3.2.1 remained active until the 31st of March 2024. On this date v3.2.1 was retired and only v4 was active. As always with a major version release, there were also a number of new, future-dated requirements that came into effect on the 31st of March 2025.
The PCI DSS 4.0 implementation timeline is best shown in the figure below (provided by the PCI Security Standards Council).
Source: https://www.pcisecuritystandards.org/documents/PCI-DSS-v4-0-At-A-Glance.pdf
PCI DSS Requirements
Below is more information on some of the main requirements under PCI DSS 4.0.
Customised Validation
The introduction of customised validation gives your organisation the flexibility to implement controls and validation methods that meet the customised approach objective. If your security programme can achieve security objectives with methods not specifically defined by PCI DSS, it may still be possible to achieve compliance.
This customised approach requires you (the assessed company) to work closely together with a PCI DSS Qualified Security Assessor (QSA) to agree upon and properly document chosen controls, methods, the results of a targeted risk analysis, and testing procedures to demonstrate the control’s effectiveness.
Customised validation is more suitable for companies with a mature information security programme, although the new standard is intentionally set up so those with less sophisticated approaches are developed into a position where customised validation could be appropriate.
Targeted Risk Analysis
Another significant change is PCI DSS 4.0's emphasis on targeted risk analysis (TRA). The primary reasons that TRAs were introduced within the latest version of the DSS are to enable organisations to determine the frequency that certain routine compliance activities are completed using a risk-based approach, and to demonstrate that any controls met using a customised approach have addressed the risk associated with the customised approach objective.
TRAs are mandatory under the following circumstances:
Deviation from Standard Controls: If an organisation chooses to deviate from a standardised PCI DSS control, they must create and document a TRA to justify the deviation and demonstrate that the alternative control offers an equivalent or higher level of security.
Unique Security Environment: If an organisation has a unique security environment that cannot be adequately addressed by the standardised PCI DSS controls, they must create and document a TRA to describe the unique environment and the security controls implemented to mitigate risks.
TRAs offer numerous other advantages for organisations striving to achieve and maintain PCI DSS compliance. These benefits include:
Improved Risk Management: TRAs enable organisations to identify and prioritise their most critical risks, allowing them to concentrate their compliance efforts on the areas that are most important.
Enhanced Security Posture: By addressing their most critical risks, organisations can greatly enhance their overall security posture and safeguard their payment card data from unauthorised access.
Reduced Costs: TRAs can assist organisations in streamlining their compliance efforts, resulting in a reduction in the time and resources required to maintain compliance.
Enhanced Customer Trust: By demonstrating a commitment to data security, organisations can establish trust with their customers and safeguard their reputation.
Whether this means decommissioning outdated systems, upgrading to newer technology, or adopting better policies, following v4 will have a transformative impact on your overall security systems and security posture, and contribute to a more secure landscape for the payment data industry.
Outsourced Payment Processing and Cloud Services
The utilisation of cloud services or outsourcing payment processing can significantly change your obligations for PCI DSS v4 compliance. While a cloud provider may assume responsibility for certain compliance aspects (typically for infrastructure and devices), it is still crucial for you to understand your responsibilities as your organisation will continue to play a vital role in ensuring the overall security of your cardholder data and reporting your compliance position.
Cloud Service Provider's Attestation of Compliance
The utilisation of cloud services or outsourcing payment processing can significantly change your obligations for PCI DSS 4.0 compliance. While a cloud provider may assume responsibility for certain compliance aspects (typically for infrastructure and devices), it is still crucial for you to understand your responsibilities as your organisation will continue to play a vital role in ensuring the overall security of your cardholder data and reporting your compliance position.
Third Party Service Providers and Attestations of Compliance (AOC)
When it comes to PCI DSS compliance, Cloud Service Providers (CSPs) are required to provide an Attestation of Compliance (AOC) that outlines the specific requirements they have been independently assessed to. This AOC typically covers areas such as access control, vulnerability management, incident response, and physical security.
If they don't provide an AOC, then your annual assessment of your PCI DSS compliance position must include those controls operated and managed by your CSP – not an easy task.
As part of the changes associated with PCI DSS 4.0 , third-party service providers (TPSPs) are required to provide the following upon receipt of a customer request:
PCI DSS compliance status information for any service the TPSP performs on behalf of customers; and
Information about which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the customer, including any shared responsibilities.
PCI DSS v4.01: Changes to SAQ A Reporting Requirements for e-Commerce
In June 2024, the standard was updated to v4.01 following a limited revision, though there were no new or deleted requirements in this version compared with PCI DSS v4.0. These latest versions of the standard included several requirements that came into effect immediately from April 2024, such as ASV vulnerability scanning, and new future dated requirements that would come into effect at their implementation date of 31st March 2025. After this point, it would become mandatory to include them as part of an assessment.
For e-commerce environments and entities that are eligible to report compliance to the requirements of SAQ A, the future-dated requirements for SAQ A included:
- 6.4.3 – Payment page scripts that are loaded and executed in the consumer’s browser are authorised and managed.
- 8.3.6 - Passwords used as authentication factors to meet Requirement 8.3.1 should be a minimum of 12 characters, containing both numbers and letters.
- 11.6.1 – A change- and tamper-detection mechanism is deployed onto payment pages.
- 12.3.1 – A targeted risk analysis is completed to support with requirement 11.6.1.
On January 30th, in response to stakeholder feedback, the PCI Security Standards Council (PCI SSC) announced an update that requirements 6.4.3, 11.6.1, and 12.3.1 will be removed from the SAQ A reporting template with effect from March 31st 2025 (the date the new future dated requirements are due to become mandatory).
New Eligibility Criterion in the SAQ A Reporting Template
Also, from March 31st 2025, and in place of the removed requirements, an additional eligibility criterion has been added to the SAQ A reporting template, whereby merchants will need to “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-Commerce system(s).”
This means that although the specific requirements have been removed, you will still need to evidence that your e-Commerce sites (and in particular, the payment pages) operate in essence to the intent of these requirements and are secure in the same way the removed requirements had intended. As such, if you or your organisation have already commenced the process of implementing these requirements, we recommend you continue to do so in order to demonstrate compliance with the updated SAQ A eligibility criteria.
You can find more information in the full announcement released by the PCI SSC.
Your Responsibilities for PCI Compliance
Your organisation holds the ultimate responsibility for PCI compliance while processing customer cardholder data, even if certain activities are outsourced. It is important that you:
Understand Your Data Flow: Clearly identify where cardholder data is processed and stored, both within your organisation and within the cloud environment.
Choose a Compliant CSP: Select a CSP that is certified as PCI DSS Level 1 TPSP and has an AOC that includes the PCI DSS requirements you want them to be responsible for.
Manage Access to Cardholder Data: Implement strong access controls to restrict access to cardholder data, including access management, least privilege, and access auditing.
Maintain Visibility: Continuously monitor your cloud environment to proactively identify potential security risks and vulnerabilities.
IaaS, PaaS, and SaaS each have different levels of responsibility for PCI DSS compliance. In the case of IaaS, you have more control over the infrastructure, which means you have a greater burden of compliance obligations.
PaaS, on the other hand, provides a more controlled environment where CSP typically manages many of the PCI DSS requirements. However, you still have some responsibility for managing data access and security controls within the PaaS environment.
With SaaS, the application is hosted and managed by the CSP, leaving you with minimal control over the infrastructure. In this case, the CSP's AOC should cover all PCI DSS requirements for the SaaS application.
It is important to remember that outsourcing does not eliminate your PCI DSS compliance obligations. By carefully selecting a compliant CSP, establishing clear governance, and actively managing your outsourced services, you can effectively protect your cardholder data and maintain PCI DSS compliance.
Craig Moores
Principal Lead Consultant
