Table of Contents
TL;DR
Mitigating controls let you pass a PCI audit on the spirit of the standard instead of the letter. Our auditor taught us that lesson when he looked at a legacy database connection we could not afford to rebuild and said: wrap it in a VPN. The vulnerability was neutralized, the audit passed, and a six-figure project became a configuration change. Eight years of audits later, that one concept saved more money than any tool we ever bought.
The first time our company faced a PCI audit, we expected a checklist cop. We got something better and, in some ways, harder: an auditor who graded us on the spirit of the standard instead of the letter. His name is Steve Levinson, and years later he wrote the foreword to my book Family Cybersecurity. At the time, he was the outside expert who decided whether a major national retailer got to keep accepting credit cards.
Auditing on the spirit did not make our lives easier. A letter-of-the-law auditor accepts paperwork. A spirit-of-the-law auditor wants to know whether the risk the requirement exists to prevent has actually been prevented. You cannot hide behind a document with that kind of auditor. But you can have a real conversation with him, and that conversation is where I learned the most useful concept in compliance work.
The problem we could not fix
We had SQL connections between servers running on old code. The software on top of those connections could not be upgraded, which meant the connectors could not be upgraded either. They were leaky. They exposed information they should not have exposed, and they carried known vulnerabilities. Fixing the underlying problem meant replacing the software stack above it, a project I estimated in the hundreds of thousands of dollars, with months of work and real operational risk.
Under a checklist reading, that finding fails the audit. Failing the audit meant losing the ability to process certain card brands, and most of our revenue came through cards. The stakes were not abstract.
“Wrap it in a VPN”
The auditor looked at the finding and said: wrap it in a VPN. Put the leaky connection inside an encrypted tunnel. The connectors would still be old, still technically vulnerable, but nothing could reach them and nothing they leaked could be read. The breach potential was gone even though the flaw remained.
That is a mitigating control. You are not fixing the underlying problem. You are making it unreachable, unreadable, or unexploitable, which is what the requirement wanted all along. The standard does not exist to make you upgrade software. It exists to keep cardholder data safe. A VPN wrapper kept it safe.
The concept was new to us, and I will admit it took a while to get through our thick heads that it was legitimate. It felt like cheating. It is not cheating. It is risk management, and it is written into the standard for exactly this situation: legacy systems that cannot be economically replaced but can be economically contained.
A mitigating control does not fix the problem. It makes the problem unreachable, which is what the requirement wanted all along.Share on X
What changed after we understood it
Once the concept landed, we found uses for it on our own. Not many, maybe one finding per audit cycle, but there was always something: a system that could not be patched on schedule, a protocol that could not be retired yet. Instead of waiting for the auditor to flag it, we would come to the audit with the problem identified and a mitigating control already designed.
He never rejected one. Sometimes he suggested ways to tighten a control or offered an alternative, and those discussions made the controls better. What he liked was the initiative. An IT organization that proposes its own mitigating controls is an organization that understands what the standard is for, and that understanding is worth more to an auditor than a binder of perfect paperwork.
What a mitigating control is not
Two misunderstandings show up whenever I explain this concept to executives, and both are expensive. The first is treating a mitigating control as a waiver. It is not a hall pass; it is a live piece of your security architecture that gets re-examined every audit cycle. Our VPN wrapper was inspected each year like everything else: is the tunnel configured correctly, is the encryption current, has anything changed around it. A control that decays is a finding waiting to be written.
The second is reaching for a mitigating control when the real fix is affordable. The concept exists for the genuinely stuck cases, and auditors can smell the difference between “we cannot economically fix this” and “we would rather not.” Propose a compensating control for a problem you could patch in an afternoon and you have told the auditor something about your organization that no control will compensate for. We earned the latitude we got by using it honestly, roughly one control a year across eight years of audits, each one a real constraint with a real containment.
There is also a budget dimension executives should appreciate. A mitigating control converts capital projects into operational configuration. The six-figure rebuild we avoided was not deferred, it was made unnecessary, because the risk the rebuild would have addressed no longer existed. Multiply that across the handful of controls we fielded over the years and the audit program paid for itself in avoided projects alone, which is a sentence you will rarely hear about compliance.
What this means if you are writing about security
I tell this story to executives who want to publish on cybersecurity because it shows the difference between knowing the standard and having lived it. Anyone can define a mitigating control by quoting the PCI DSS glossary. The lived version has a leaky SQL connector in it, a six-figure estimate, an auditor with a name, and the moment a configuration change made an impossible problem disappear. Readers trust the second version, and so do the AI systems that now decide which sources get cited.
For more from this series, see the The Cybersecurity Hub: breaches, audits, and hard-won security lessons from four decades in the trenches.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.