I've watched a lot of well-intentioned GRC people do the same thing. They sit down with the control list, all of it, and go control by control asking how to make each one better. Automate the evidence here. Get the test closer to the source there. Wire up a collector for that one.

It looks like diligence. It feels like engineering. Most of it is wasted.

Three jobs look almost identical from the outside, and we constantly mistake one for another:

Most "control hardening" is quietly the first row wearing the costume of the second, sold internally as the third. You automate a control's evidence collection and you feel like you've strengthened it. You haven't. The control is exactly as strong as it was yesterday. You've just made annual ceremonies cheaper.

This is the same trap I called Compliance-as-Cope, one level down. We keep automating the part that was already easy to automate.

IN PARTNERSHIP WITH

The security leader's playbook to GRC orchestration

Teams lose weeks to audits, pulling logs, taking screenshots, and reconciling spreadsheets. Engineers are pulled off critical work to collect evidence that’s outdated almost immediately. It’s exhausting, and it happens multiple times a year.

This playbook from Drata and Tines shows a better way. Inside, you’ll find detailed workflows for evidence collection, monitoring, audit prep, and more.

The audit is anchoring you to the wrong objective

The reason this happens is structural. Spend most of your year in audit-prep mode and the work you reach for bends toward the audit by default. The audit becomes the anchor. It pegs your objectives, your understanding of your own program, even your sense of what "good" looks like.

So you build a beautifully automated process whose entire purpose is to impress one person, once a year. It might save 30min a quarter but was it worth it?

And here's the bit nobody says out loud: past a baseline of competence, you'd have passed anyway. A fraction of the automation, a bit more manual effort during audit week, same outcome. Above that baseline, the audit barely registers how much of its prep you automated. (The sampling math makes this brutally clear.) That's the tell: the effort was never really about assurance.

I've made this argument before and I'll keep making it.

It's the whole case for a program that serves risk instead of the auditor.

Automation is a liability you own forever

There's a tempting move here. "Fine, I'll automate the boring controls so I can stop caring about them." I understand the instinct. It's wrong.

Automate a performative control and you don't stop caring about it. You convert a once-a-year annoyance into a system you babysit forever. Every evidence pipeline is a thing that breaks, drifts, and needs maintenance. You've traded a small, bounded, annual cost for a permanent, unbounded one.

And it's paid for in a currency you're probably not counting:

Getting a collector close to the source means pulling strings: the right API access, a service account, admin in a tool owned by a team that doesn't report to you and doesn't care about your audit. That capital is finite. Every favour you burn automating evidence for a control nobody cares about is a favour you won't have when you need deep access to a control that actually matters.

There's one exception. Automation that costs nothing to get and nothing to keep, a throwaway script with no special access and no upkeep, is genuinely cheap. Take it. The trap is capital-intensive automation of things that don't matter. (This is really just picking the right type of automation for the job.)

"Set it and forget it" is a myth anyway. Controls decay. They drift out of their intended state through config changes, staff turnover, and a threat landscape that won't sit still. And the automation you build to watch them decays right alongside them. It's a control with a lifecycle of its own.

Spend your scarcest currency on depth

Here's the rule.

For a performative control, the security-awareness training, the risk committee that reads a slide deck, the policy nobody opens, do the honest minimum. Meet the requirement cleanly, accept that it exists for the audit, and walk away. Collect its evidence with a cheap script if you can. If automating it would cost real capital or real maintenance debt, do it by hand once a year and protect your bandwidth.

Then take the time, the tokens, and the political capital you just saved, and aim all of it at the controls where depth changes the picture. Get close to the source. Give a risk owner visibility they genuinely didn't have before. That's the gap between auditing existence and managing actual risk.Your Platform Won't Save You

Ask what AI your GRC tool actually ships. Outside coding, a genuinely agentic experience is rare. What you have is a deterministic workflow with an inference step or two, built on the same models, with the same blindness and no feedback loop of its own. You cannot catch plausible-but-wrong output with a tool that produces it. (That's the real AI dilemma.)

A map for deciding

Two questions decide where a control belongs. How much does it matter for the audit? And how much does it actually reduce risk? Plot every control against both and you get the four wards from the triage room up top:

• 🟥 Harden (high audit, high risk): the ICU. Your highest-ROI work. Go deep.

• 🟩 Keep honest (high audit, low risk): minor care. Meet the requirement, discharge, unironically.

• 🟪 Champion (low audit, high risk): the bed nobody referred. No auditor will ask for it, so you fight for it.

• ⬛ Kill / question (low audit, low risk): why is this even admitted?

Keep the overlap. There's a huge, healthy intersection between framework controls and risk-reducing ones, and audits earn real money through sales, trust, and regulatory access. The same control even lands in different wards at different companies. Awareness training is theatre at one org and genuine protection at another. The ward is a property of your context, not a universal label. Map your own controls before you touch anyone else's list.

What GRC engineering is actually for

Strip away the audit theatrics and the job underneath is simple: help the people who own controls and risks make better decisions. Give them accurate, pertinent, close-to-the-source data, enriched with the GRC and security signal only you can add, handed back in a form they can act on. It's the compliance-as-a-query idea pointed at people instead of auditors.

There's a name for this, and it isn't mine. In FAIR-CAM, the same model Jack and Laura just simulated, it's the third domain of controls: Decision Support. Controls whose entire job is to improve the quality of human decisions.

That's the layer GRC engineering should be building. Not a faster way to feed the auditor. A better way to feed the decision-maker.

The maturity move

Maturity is knowing where not to engineer, and having the discipline to leave the performative stuff boring so you've got something left for the work that counts.

Automate the easy things until there's no capacity for the hard ones and you haven't built a revolution. You've built Compliance-as-Cope with better tooling.

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

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you next week!