Thoughts on PCI DSS v4.0

Has it already been 7 months since the eagerly awaited updated to PCI DSS, v4.0 was published? Now that people have had time to digest v4.0 of the new PCI DSS standard, what are people’s thoughts on it?

The main change of course is the pragmatic move as to how an entity can choose to report on its PCI DSS compliance. The traditional route of attesting compliance via evidencing controls is retained as the ‘defined validation’ route; but a new risk-based approach based on evidencing control objectives is new: ‘customised validation’. It is clearly aimed at the larger, more mature entities who have the resources for a well-defined risk function. It should not be seen as an easier route to compliance however – as the notes in the new standard clearly articulate- there is more paperwork involved in this route. To my mind this is a pragmatic approach already employed by many of the largest merchants, as well as acquirers and issuers but, as with all compliance, it does leave the door open for interpretation.

Q. How many QSAs does it take to change a lightbulb? A. It depends on the position of the lightbulb, the ambient light and whether the bulb’s hue is acceptable to the QSA or not. Perhaps slightly flippant, but we have all been there in the past where 2 QSAs have a completely different view on a complex compliance question. I think version 4.0 of the standard has the potential to exacerbate this issue…

Whether an entity has a mature and well-defined risk management function in theory should be easily auditable: evidencing an adopted and recognised risk management framework; a defined business impact risk table and risk appetite; and whether there is an audit trail demonstrating well-managed risks managed to within appetite for the business to support that control objective. What is open to interpretation perhaps is how far the QSA goes into whether or not the objective has been met. Is the entity’s own risk appetite itself called into question?

Having worked for multiple organisations in all levels of the payment chain, whilst risk appetites are similar, they are never the same across two organisations, even from within the same vertical. So it does perhaps raise the question as to how far auditors will go with the interpretation. In theory it hands the role of judge, jury and executioner to the QSA to deem whether or not an entity’s risk appetite is too “risky” when meeting control objectives, which will have the potential for major consequences for an organisation’s compliance and associated costs.

I was genuinely surprised at the encryption of PANs in transit on internal networks being recommended only as ‘good practice’ in v4.0; since in the last two years, nearly every conference I have attended , inside or outside of the PCI DSS space, focuses heavily of the damage of ransomware and how they begin as the exfiltration of data on internal networks, before any malicious data encryption on the internal network begins. It seems bizarre therefore to me then that you would choose to leave this area unprotected and hence have this as an optional requirement, especially since the data perimeter is not what it once was with the added complexity of the adoption of cloud across the payment ecosystem . ‘Good practice’, unlike ‘best practice’ will remain so post 2025 in terms of PCI DSS compliance, so it seems an odd decision to me personally.

The changes to third party assessment seems to me more pragmatism from the standards council, and I welcome this approach. Many entities recognise that their supplier has to be fit for purpose for the service they consume and that controls must be assessed relative to that service. Yes there are some control deficiencies which constitute security 101 and are non-negotiable, but equally there are others which may struggle to be met by multiple vendors and therefore a pragmatic supplier assessment is required.

What do you think? Do you welcome the risk based alternative approach in v4.0 of PCI DSS?