⚙️ The Compliance Leverage Ladder: Your GRC Roadmap Is Pulling the Weakest Levers

Pull up your GRC roadmap for this quarter. I'll guess what's on it.

Tighten the password policy. Reduce the patch SLA from 45 days to 30. Recalibrate the risk matrix thresholds. Add two controls to close last year's findings. Maybe a tooling migration if you're ambitious.

Every single one of those is a number being tuned.

Last week I argued that "get technical" is useless advice until someone says at what. This week I want to answer a harder version of that question: technical where in the system? Because there's a piece of systems literature from 1999 that ranks interventions exactly like the ones on your roadmap. They come dead last.

The ladder

In 1999, Donella Meadows published Leverage Points: Places to Intervene in a System. She was one of the great systems thinkers and lead author of The Limits to Growth. Her essay makes one claim that should bother every GRC leader. There are twelve places you can intervene in any system. They differ enormously in impact, and people reliably crowd the weakest ones.

Rung 12, the weakest intervention, is parameters. Constants and numbers. Meadows' observation was that parameters soak up nearly all the attention precisely because they're visible, adjustable, and safe.

Password length, SLA days, your risk matrix thresholds: all parameters. The annual exercise of re-approving threshold values in policy documents is rung 12 work, which is one reason the policy-as-code revolution never arrived: we encoded the parameters and left the structure alone.

I collapsed Meadows' twelve rungs into five bands. Purists will notice I'm folding her stocks, buffers, and delays together; the ranking logic survives the compression, and the top of her ladder gets philosophical in ways you don't need to see the problem:

Now map your roadmap against this table and count. Most GRC programs I've seen put 80 to 90 percent of their energy into band 5. Some of that is mandated; PCI does not care about your leverage analysis. The problem starts when parameter work is the whole roadmap, because everything GRC Engineering is for lives in bands 4 through 1.

Engineering already climbed this ladder. The trail markers are worth reading.

Band 4: the 15-minute loop

Scarf was a company built by Haskell devotees. Its founder and CEO, Avi Press, sat on the Haskell Foundation board.

This month they moved new development to Python anyway, and his reasoning had nothing to do with Haskell's qualities: "If an LLM can produce a working implementation in a few minutes, but your compile step takes dramatically longer, then your language and build system have become a bottleneck in the development loop." Even 15 minutes of cold-start build time, he argued, turns the compiler from a papercut into the dominant cost of a piece of work.

Haskell stayed exactly as good as it had always been. The loop made that irrelevant.

Your annual audit is a 12-month feedback loop.

Hold those two numbers next to each other. Engineering is walking away from beloved technology over minutes of latency. GRC defends a 12-month gap between a control failing and its owner finding out through any guaranteed path, and calls it an assurance model. Your program leaks in exactly the shape of that gap.

The band 4 move: measure your program's cold build time. For each control, how long between a failure and the control owner knowing? It's a table you can build this week:

Yes, your SOC or a CCM tool may catch some of these sooner. The table tracks each control's guaranteed detection path, not the lucky one. Rank your controls by feedback latency, weighted by criticality, and expect the ranking to embarrass you. It should.

Band 3: the status field you don't have

Kelsey Hightower describes Kubernetes' core shift in one line: "we went from infrastructure is code to infrastructure is data." You declare the state you want, the system holds a status field describing the state you have, and a controller loop closes the gap continuously.

That is a compliance architecture. It shipped years before "continuous compliance" became a phrase every GRC vendor puts on its homepage.

Your control catalog is already the declared desired state. What's missing is the status field. Almost no GRC program can answer "is this control operating right now?" with data. They can answer "was this control operating during the audit window?" with a screenshot, and your auditor sampled 0.07% of it anyway.

Meadows tells a story about this band: a subdivision of identical Dutch houses where some electric meters were installed in the basement and some in the front hall, in plain view. Same houses, same prices. Consumption in the front-hall houses ran 30 percent lower. The only change was who saw the information, and when.

Policy-FROM-code is the electric meter move: control telemetry visible to the person who owns the control, at the moment it drifts, instead of filed for an auditor who arrives in Q3. It's the engineering answer to compliance as a query on data you already collect.

The band 3 move: pick one control and give it a status field. Engineers would call the pattern drift detection against a known-good baseline, and it's the cheapest feedback loop you can steal:

// drift.ts: the cheapest continuous control you can build
const baseline = await Bun.file("baseline/iam-admins.json").json();
const live     = await iam.getGroupMembers("admins");

const drift = diff(baseline, live);
if (drift.length > 0) {
  await notifyOwner("iam-admins", drift);  // the meter, in the front hall
}
// re-baselining is a governance decision, on purpose

Yes, the baseline file is declared state. The leverage is in who gets the diff, not in the file. Twenty lines, and drift becomes a decision instead of an accident.

Band 2: the ticket queue

Kelsey Hightower again, because he keeps handing us the playbook. Early in his career at Google, his team was measured on activity: calls answered, machines repaired. His line about it is one of the best goal statements I've read: "activity is you being an all-star answering a bunch of calls, but the ticket queue for the team is still high."

So he stopped optimising calls answered and started draining the queue. The goal changed, and everything downstream reorganised around it.

GRC's version of calls answered: evidence items collected, controls tested, findings raised, questionnaires returned. All activity. The queue is still high.

The band 2 move: rewrite one goal from activity to outcome, and make it falsifiable. A control attestation is activity. A prediction is a feedback loop: "fewer than 3 of the 40 accounts we deprovision this quarter will still hold access at day 7." Predict rates you can measure, not rare events whose absence proves nothing.

Score your program on prediction accuracy and you've changed what every band below it optimizes for. This is also why control triage works: it's a goal-level decision about where assurance effort goes, wearing an operational costume.

Why your best proposals die

Meadows warned that systems resist changes to their own structure. The operational version: resistance scales with leverage.

Microsoft just demonstrated it in public. Xbox CEO Asha Sharma's July restructuring memo admitted work "passes through as many as 14 layers of management," while platform teams had grown "40% larger than they were at the start of this generation, even as our player base and playtime have declined." Everyone in the building knew. Nothing moved for years, because the people who would have to approve collapsing 14 layers down to five are the layers in between.

Nobody fights you over patch SLA days. Everyone fights you over demoting the annual audit from primary detection path to backstop, because roles are load-bearing. Your stalled continuous-compliance initiative was a band 3 intervention meeting band 3 resistance. The idea was fine; the altitude wasn't.

Treat that as a forecasting tool. Before you propose a structural change, map whose job is the buffer you're removing: walk the approval chain from your last stalled proposal, and mark every name as either a sponsor or a load-bearing role. That list is your resistance forecast, and you can plan around it.

That’s all for this week’s issue, folks!