Version 4.0 of the PCI DSS (Payment Card Industry Data Security Standard) went into effect on 1 April 2024, surpassing v3.2.1.
As a QSA (Qualified Security Assessor), I’ve completed a few PCI DSS v4 analyses and assessments.
In this blog, I’ll share the good, the bad and the improvable aspects of this new standard.
I’ll also highlight a potentially problematic change introduced by PCI DSS v4.0.1, a recently published ‘limited revision’. PCI DSS v4.0.1 included no new requirements, but may nonetheless present a new challenge for certain organisations.
In this blog
New sub-requirements X.1.1 and X.1.2
New sub-requirements to prevent tampering with payment web pages
TPSP contracts (potential v4.0.1 challenge)
The good
New sub-requirements X.1.1 and X.1.2
I like the new sub-requirements that appear as the first two in each high-level requirement:
That the requirement is fully covered in policies and procedures.
The roles and responsibilities are clearly assigned.
It always surprises me that organisations can get to the point of undergoing their assessment but still have no clear idea of who has overall responsibility for PCI DSS compliance, or who has responsibility at the more detailed requirement level.
Responsibilities should be clear in every policy and in an overall RACI matrix (standing for ‘responsible’, ‘accountable’, ‘consulted’ and ‘informed’).
It can only be a good thing that PCI DSS version 4 is promoting this.
New sub-requirements to prevent tampering with payment web pages
I’m also pleased to see the new sub-requirements 6.4.3 and 11.6.1, dealing with prevention of tampering with payment web pages:
6.4.3 sets out requirements around managing payment page scripts loaded and executed in consumer browsers.
11.6.1 sets out requirements for deploying a change- and tamper-detection mechanism.
However, from what I’ve seen, not everyone has these in place.
Requirement 6.4.3 isn’t mandated until after 31 March 2025, but that’ll arrive quickly, and e-commerce organisations must prepare now. Most will need third-party tools for 11.6.1.
The bad: targeted risk analyses
I’m not convinced about the value of the targeted risk analyses PCI DSS v4 requires for determining the frequency of some controls.
Even if an entity adopts the PCI SSC’s (Payment Card Industry Security Standard Council) suggested frequencies, the organisation must still justify this with a targeted risk analysis.
Few organisations have meaningful data on which to base such analyses. As such, to many, this will feel like an empty exercise.
The improvable: ‘hidden’ requirements
However, the biggest unforeseen impact I’ve seen from PCI DSS v4 is the effect of ‘hidden’ requirements. These have always existed, but seem to be having more effect in v4.
In working towards PCI DSS compliance, organisations will naturally focus on the requirements in the Standard itself.
Consequently, they may be unaware of a second set of requirements: the testing requirements in the Standard, which are further set out for assessors in the RoC (Report on Compliance). These specify what the assessor must do to mark a requirement as ‘in place’.
One requirement that often catches organisations out is the need to have a documented procedure for any action it takes.
The organisation tells the QSA what it does (interview evidence). The assessor then watches (observation evidence) or, for configurations, checks this (system evidence).
But the entity hasn’t documented these actions in a procedure document, so the assessor can’t mark the requirement as ‘in place’.
Example
This is different to the more generic sub-requirements (X.1.1) I was discussing earlier.
For example, sub-requirement 9.4.1.2 says:
The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months.
I then find organisations only focusing on this requirement: literally just reviewing the security of these locations annually, and perhaps also documenting these reviews.
However, the testing procedure in the Standard adds in 9.4.1.2.a:
Examine documentation to verify that procedures are defined for reviewing the security of the offline media backup location(s) with cardholder data at least once every 12 months.
And in the RoC, the assessor must cross-reference to the specific procedure document(s).
The organisation simply saying that it’s doing these reviews, and has records of them, isn’t enough. It must also have a documented procedure that explains how it conducts these reviews.
Suggestion for improvement
Documented procedures should exist, and the Standard is right to require them.
We’ve all seen instances where there are well-established practices, but after someone leaves or an organisational change, the process simply stops happening.
That said, perhaps the PCI SSC could’ve done more to bring these ‘hidden’ requirements to the forefront by including them in the main requirements rather than in the evidence requirements. Organisations are then less likely to overlook them.
A potential challenge from PCI DSS v4.0.1: TPSP contracts
Though the recently released PCI DSS v4.0.1 introduces no new requirements, the updated applicability notes for sub-requirement 12.8.2 may present a challenge for certain organisations.
The requirement itself hasn’t changed: organisations must have and maintain a written agreement with their TPSPs (third-party service providers). That agreement must include an acknowledgement from the TPSP that it’s responsible for the security of the card account data it stores, processes or transmits on behalf of the organisation.
Previously, many entities and their assessors have accepted the TPSP’s AoC (Attestation of Compliance) or responsibility matrix as evidence of such an agreement. However, the updated applicability notes now explicitly rule this out, stating:
Evidence that a TPSP is meeting PCI DSS requirements is not the same as a written acknowledgment specified in this requirement.
For example, a PCI DSS Attestation of Compliance (AOC), a declaration on a company’s website, a policy statement, a responsibility matrix, or other evidence not included in a written agreement is not a written acknowledgment.
A ‘written agreement’ means what it says. Any future contracts that entities have with TPSPs will need to include this.
What about existing contracts?
Organisations will need to seek such agreements with every supplier providing a service that could affect the security of account data.
Where such TPSPs are PCI DSS-compliant, sub-requirement 12.9.1 (applicable to service providers only) demands that they make such an agreement.
However, many TPSPs aren’t compliant – think of the many relatively small companies that host e-commerce sites for their clients. So, we can expect them to be highly resistant to making any agreement that, in effect, changes their contract and potentially exposes them to unknown liabilities.
Organisations can’t delay on this: they must check existing contracts and, where such an agreement isn’t already in place, start talking to their TPSPs now.
Concluding thoughts
Threats to payment data continue to develop, so the PCI DSS must change and evolve to keep up with them.
But it isn’t enough to look at the general subject of a requirement and conclude that you have it covered. One of the strengths of the PCI DSS as a standard is that it’s specific, but that also means it requires careful reading of each (sub-)requirement to achieve compliance.
The devil, as they say, is in the detail.
Looking for more PCI DSS v4 support?
IT Governance can help. Our range of consultancy, technical security, software and training services helps organisations meet the requirements of the PCI DSS.
Whether you’re looking to reduce your assessment scope, you need support with an SAQ (self-assessment questionnaire) or you require a gap analysis, we have the right solution.
Here’s what Damien Everard, COO of Appletree, had to say about us:
IT Governance were very professional and pragmatic in their approach, and displayed a level of understanding of our business that we found unique and refreshing.
Ready to find out more?
The post The Good, the Bad and the Improvable of PCI DSS v4 appeared first on IT Governance UK Blog.
