Making sure your security controls are in place and functioning is the intent behind every Requirement and testing procedure in the PCI DSS. Yet every day, breaches occur at organizations where those controls were, indeed, in place and functioning. Attackers had simply found another way in.
Did you also need these 4.0 controls? Some background may be helpful.
The annual snapshot never told the whole story
Many compliance programs are based on annual cycles. You collect the evidence and engage your QSA or complete your SAQ, get the checkmark that you’re compliant, and then you don’t think about it anymore. This process guarantees one thing: your environment looked pretty good the day someone checked it. It guarantees nothing about the other days of the year.
Verizon’s 2023 Payment Security Report confirmed what many of us suspected. Just 28.6% of organizations assessed against PCI DSS requirements at the mid-year mark in 2022 were fully compliant – a decrease from 38.9% in 2019.
That’s not a rounding error. It’s proof that your carefully implemented, well-documented, expensive security controls degrade astonishingly quickly the moment the auditor turns their back.
Devices and applications are improperly configured or left unpatched. New suppliers are connected to your cardholder data environment, but nobody tells your compliance people to update your scope documentation.
Two paths, both harder to fake
PCI 4.0 is not only about additional rules, but it transforms the way compliance is demonstrated. Now, organizations can either go for the Defined Approach, which involves the classic set of prescriptive controls, or the Customized Approach, in which teams can develop their own controls – as long as they can prove, using concrete evidence, that they achieve the security objectives.
This doesn’t only remove generic compensating controls; it removes the comfort blanket of not having to produce real evidence that your systems are secure. No evidence, no compliance.
For a full breakdown of the structural changes, pci 4.0 is worth reading in detail, because the shift from static checklists to evidence-based validation touches nearly every requirement in the standard.
Scoping mistakes get expensive fast
The most important decision regarding how painful your compliance program is going to be is how you scope the cardholder data environment.
Start with too loose a scope, and you’ll spend the next few years in a battle with an assessment that keeps discovering systems you were trying to forget about.
PCI 4.0’s reimagined SAQs align more closely to the actual attack paths of most breaches than previous versions have. This is great news for your security posture, and a rough time for those teams who let themselves scope out under the old rules and get away with it.
Segmenting networks and tokenization both reduce the size of the environment you need to defend and show to be compliant, but only if you do it with the true intention of minimizing scope rather than just checking a box that says you don’t store credit cards in drive C.
Teams that push segmentation out as a real discussion on project after project draw fewer and fewer systems into scope every cycle.
MFA and vulnerability timelines catch the unprepared
Two changes are more likely than any other to suddenly tip your checkbox-minded, assessor-weary security teams onto their backs. Vast swaths of the industry had multi-factor authentication (MFA) in place for their VPN and only their VPN.
If you had a physical bastion or a jump host that didn’t qualify because it was inside the network and thus not “remote,” tough luck. You can be sure your QSA will catch that oversight this time.
Next, vulnerability management timeframes. Nothing kills an organization’s “we only have to be secure one day out of the year” groove more than focusing a compliance framework around the assumption that static, long-lived assets combined with policies and procedures alone can keep attackers out.
Then Requirement 11 goes and codifies what many of us were already struggling to achieve: finding and fixing security bugs faster than the bad guys can exploit them.
Outcomes, not paperwork
Tick-box compliance only verifies if you have adhered to a set of rules. It does not verify if those rules would have actually stopped a cybercriminal. This used to be less of a problem since the two overlapped sufficiently that no one was too concerned. However, this is no longer the case.
A risk assessment that is directly applicable to your business – not some generic tick-the-box template obtained from a QSA’s manual – is the bridge between your security priorities and the real-world business you’re in. Your environment’s third-party service providers add another loop to this.
Their SAQ response is only as good as your assessment of it. Just because a vendor ticked all the boxes on their self-assessment doesn’t mean their access to your environment would tick all the boxes of a determined auditor.
Continuous compliance doesn’t offer a shortcut, and won’t protect you against doing the real work to secure your systems. But the model does make you more resistant to modern attacks as a side-effect of forcing you to adapt quickly. It also speaks more directly to the truth that attackers don’t give you twelve months to forget about them.
The standard caught up with reality
PCI 4.0 isn’t about making life harder for organizations. It’s about holding up a mirror to how networks are protected against the evolving behaviors of bad actors and their ever-improving resources, and recognizing the growing disparity.
It’s inevitable that the controls to close these gaps are much easier to deploy if networks are well-architected. Networks that are not segmented, not monitored properly, and still largely flat are just going to be an amplifying sprawl for any improvement in the generational malware that routinely bypasses the best prevention tools that we currently have, i.e. antivirus and firewalls.