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.
This story runs against everything most executives believe about compliance. They picture auditors as box-checkers and treat the audit as a tax, and plenty of auditors deserve that reputation. The good ones care whether the cardholder data is safe, and working with one changed how I thought about every stuck system we owned. The attitude I’d want toward the Report on Compliance and the Attestation of Compliance is to ask how they help your customers. We were trying to help our customers, and we wanted to do the best thing for them. That was our reason to do the work.
Auditing on the spirit didn’t 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 been prevented. You can’t 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’d SQL connections between servers running on old code. We couldn’t upgrade the software on top of those connections. That meant we couldn’t upgrade the connectors either. They were leaky.
They exposed information they shouldn’t 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.
A control that decays is a finding waiting to be written.
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 weren’t abstract. Whenever we failed something, my first move was to ask the auditor how he came to that conclusion and to show me his test. I had to explain the failure to people, and I couldn’t design a mitigation until I understood the problem.
Can a VPN be a PCI mitigating control?
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’s a mitigating control. You’re not fixing the underlying problem. You’re making it unreachable, unreadable, or unexploitable, and that’s what the requirement wanted all along. The standard doesn’t 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 it took a while to get through our thick heads that it was legitimate. At first it felt like cheating to me. The standard provides for exactly this situation, legacy systems that you can’t economically replace but can economically contain, and people who call compensating controls a loophole have never read the part of the standard that asks for them.
A mitigating control doesn’t fix the problem. It makes the problem unreachable, and that’s what the requirement wanted all along.Share on X
What changed after we understood it
Once we understood the concept, we found uses for it on our own. Not many, maybe one finding per audit cycle, but there was always something: a system we couldn’t patch on schedule, a protocol we couldn’t retire yet. Instead of waiting for the auditor to flag it, we’d 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 is a mitigating control 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’s a live piece of your security architecture that auditors re-examine every audit cycle. The auditors inspected our VPN wrapper 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 stuck cases, and auditors can smell the difference between “we cannot economically fix this” and “we’d rather not.” Propose a compensating control for a problem you could patch in an afternoon and you’ve told the auditor something about your organization that no control will compensate for.
I have no sympathy for companies that game this. Every phony compensating control makes the next auditor more suspicious, and the teams with really stuck systems pay for it in tougher reviews they did nothing to deserve. We kept getting latitude because we used it honestly, roughly one control a year across eight years of audits, each one a real constraint with a real containment.
There’s also a budget dimension executives should appreciate.
A mitigating control converts capital projects into operational configuration. The rebuild we avoided never had to happen at all, because the risk it 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. It drives me up the wall that so many executives still treat compliance as pure cost when the numbers run the other way.
My take
Learn the mitigating control before you approve a six-figure rebuild. When a stuck system can’t be fixed economically, contain it and show the auditor how. Our VPN wrapper turned a capital project into a configuration change. Treat the control as live architecture, because auditors re-examine it every cycle. Don’t use it to dodge a fix you could patch in an afternoon. A phony control makes the next auditor tougher on the teams with honest problems.
What should security writers learn from mitigating controls?
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.
Executives who have lived through audits like these and then write security books full of glossary definitions are throwing away the best material they have. I’d much prefer to see the leaky connector, the estimate and the auditor’s suggestion on the page, because that’s what a reader remembers, and it’s what makes the book worth citing.
For more from this series, see The Cybersecurity Hub: breaches, audits, and hard-won security lessons from four decades in the trenches.
