A framework is a consensus document. NIST, ISO 27001, PCI DSS — each gets built by committee, run through public comment, and revised on a multi-year cycle. NIST took about six years to move from CSF 1.1 to CSF 2.0. PCI DSS 4.0 landed roughly four years after the version before it. That slow cadence is deliberate. You want the baseline everyone certifies against to hold still long enough to mean something.

But the attackers don’t wait for the next revision. Mandiant’s threat intelligence team has watched the average time-to-exploit — the gap between a vulnerability going public and the first real attacks using it — fall from 63 days to five. By the time a control that addresses a new class of attack works its way into a framework update, the people exploiting it have already moved on.

What an audit measures, and what it misses

A compliance program optimizes for a passing audit. A risk-based security program optimizes for the loss you’re actually trying to avoid. Those goals overlap a lot, but they aren’t identical, and the places they pull apart are exactly where companies get hurt.

In the incidents I’ve seen in my career, the controls that separate a contained incident from a balance-sheet event are rarely the ones an auditor spends real time on. Tested, segmented, offline backups are one. So is phishing-resistant MFA on the accounts that actually matter, not MFA-in-name on a portal nobody bothers to attack. So is an incident response plan someone has run under pressure, instead of a PDF that’s never left the shared drive. A checkbox audit can mark every one of those “in place” and tell you nothing about whether they’d hold. Our our healthcare claims data shows the real split: a clean compliance posture and an actual recovery aren’t the same thing, and that gap is the whole story. 

None of this means compliance is theater. I’m not arguing you should stop certifying, because most of us can’t and shouldn’t. Regulators ask, customers ask, your insurer asks, and a framework gives everyone a shared language for the answer. Compliance is a floor. The problem starts when you treat the floor as the ceiling and run the entire program to satisfy it.

Where a risk-first program actually starts

A risk-first program starts from exposure instead of the checklist. The question it asks is what’s most likely to cause a material loss this quarter, given what’s being exploited right now and what you actually have deployed. That’s a moving target, so the program moves with it.

In practice that means watching what’s being exploited today — CISA’s Known Exploited Vulnerabilities list, EPSS scores for what’s likely to be exploited soon, your own telemetry, the threat intel that arrives with an action attached — and re-ranking priorities against that, not against a static control catalog. It means measuring exposure in dollars, so you can tell a noisy finding from an expensive one instead of flattening a $5,000 problem and a $5 million problem into the same color on a heat map. And it means accepting that some of last quarter’s top risks fell off the list, which makes some controls you stood up less urgent than they were. A framework can’t tell you it’s gone stale. Your exposure can.

So here’s the test I’d run: Take your last board deck or your last audit summary and ask one thing of every control on it. If this vanished tomorrow, what would it cost us? Answer in dollars and you’re already thinking like a risk-first program. If the only answer you’ve got is “we’d fail the audit,” that’s the work in front of you.