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 standard followed by the majority of these parties is currently PCI DSS v3.2.1, which 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 has been a need for the standard to be updated.
This is where the long-awaited Payment Card Industry Data Security Standard (PCI DSS) v4 comes in. Published by the PCI Security Standards Council (PCI SSC) on the 31st March 2022, it provides a significant update to v3.2.1. that will help the parties involved in payment processing to ensure their practices take these latest trends into account.
For guidance on how to transition to PCI DSS v4, download our e-guide.
What’s Changing with PCI DSS v4?
These are the 10 most notable new requirements when comparing PCI DSS v4 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 Card Data Environment (CDE) vs administrative access to CDE previously
- 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
When Does PCI DSS v4 Come Into Effect?
There will be a usual transition period of two years, meaning that PCI DSS v3.2.1 will remain active until the 31st March 2024. After this date, only v4 will be active. As always with a major version release, there will be a number of new, future-dated requirements. However, these requirements will only come into effect after the 31st March 2025 and, until then, will only be considered best practice.
Source: https://www.pcisecuritystandards.org/documents/PCI-DSS-v4-0-At-A-Glance.pdf
Customised Validation
The introduction of customised validation gives your organisation the flexibility to implement controls 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 v4’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 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.
How Does PCI DSS v4 Affect Me if I Outsource All Payment Processing or Use 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
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.
- 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.
Your Responsibilities for Compliance
Your organisation holds the ultimate responsibility for PCI DSS 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 (CHD) 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 CHD: Implement strong access controls to restrict access to CHD, 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.
Will I or My Third Parties Need to Immediately Re-assess After April 2024 to v4?
In short, no. If your organisation completes an assessment for DSS v3.2.1 prior to 31st March 2024, your AOC will continue to be valid for 12-months from this date. There will be no requirement to assess against DSS v4 until your AOC expires.
If you’re looking for support in transitioning to v4, download our PCI DSS v4 e-guide or get in touch with one of our team.
Author: Craig Moores, Principal Lead Consultant
First Published: 20th April 2022
Last Edited: 4th March 2024
Author
Craig Moores
Principal Lead Consultant
Craig joined Bridewell in 2022 as a Principal Lead Consultant, where he provides expert cyber security consultancy and leadership to clients across critical sectors. In his role, he guides organisations in information security, risk management, PCI DSS, strategic planning, and business auditing. He holds certifications from leading industry bodies including CISSP, CAA ASSURE, and is a PCI DSS Qualified Security Assessor.
Blogs