The charge is fair. Here is how you own your way off the gate.

Last week I posted a fake dictionary entry. The top definition of GRC: a performative function, valued for the performing and not the outcome.

GRC people agreed with it. That is the part worth sitting with.

The charge is fair. But it describes a stage, not a verdict, and you can move off it faster than you think.

IN PARTNERSHIP WITH

Your vendors are lying to you.

Not intentionally. But questionnaires let them.

Every attestation your vendor submits is a best-effort snapshot of what they think you want to hear. By the time it reaches you, something has already changed. A new integration went live. An admin account was never deprovisioned. MFA got quietly disabled.

Coverbase Inspect uses AI agents to log into your vendors' apps and validate controls directly. MFA enforcement, guest accounts, unintended exposures, unsanctioned features. Any SaaS app, not just ones on a supported list. Continuously.

No questionnaires. No attestations. No blind faith in SOC 2s.

Why the charge lands

GRC is meta-work. It is work about work that already happened somewhere else.

Engineering builds the access controls. IT runs the backups. A control owner signs off on the risk. GRC writes it down, maps it to a framework, and presents it to someone outside the building.

That last step is the tell. The real audience for most GRC output was never internal. It is the auditor, the customer's security team, the regulator on the far side of a questionnaire. GRC exists, in large part, to perform trust to outsiders on behalf of work that insiders actually did.

That is a real job. Signalling trust at scale is how deals close. The problem starts when performing is the only thing the function does, which is how a program ends up serving the audit instead of the business.

Security stood exactly here

Here is the hopeful part, because it is not hypothetical: security used to be GRC.

In the waterfall era, security was a review gate. It inspected work other people built, near the end, and signed off or sent it back. It owned a checklist and an opinion, nothing you could point to in production.

Then it changed posture. Security teams started owning real surfaces: authentication, access, the hardening baseline. The moment security owned a mechanism, it stopped judging the work at the end and started running part of it the whole way through. Today a strong security engineering team runs alongside delivery as a counterpart.

GRC is on the same curve, one step behind:

The dotted box is the whole game. Fill it in and the posture changes.

Why GRC is a step behind

Not because GRC people are less capable. For a structural reason: GRC sits one layer further abstracted, and its counterpart is not one engineering org but many.

Harder to embed. Easier to stay at the gate. But difficulty is not the main thing holding the function back. The misconception is.

The fear that keeps GRC at the gate

When I say own more, many GRC people hear something I am not saying: break the lines, take the control from the engineer, make the risk call that belongs to the business, stop being independent.

That is not it, and the confusion is the single biggest thing keeping GRC performative.

More ownership does not mean owning other people's decisions. The control owner still owns the control. The risk owner still owns the risk. You are not reaching across the line to grab their accountability.

What you own is your own outcome. Today most GRC teams own an activity: the questionnaire went out, the evidence got collected, the report shipped. That is output. Whether the business actually decided better because you were in the room is the outcome, and in most programs it belongs to no one. You can own that without touching anyone else's job.

And proactive is not the opposite of independent. Waiting for the artifact to review does not make you more neutral, it makes you slower and easier to ignore.

What rots if you stay passive

Two things break, and you have seen both.

Accountability leaks. The moment GRC "owns" a control on paper, the real owner stops owning the outcome. The risk sits in a register and nobody drives it down, because on paper somebody already has it.

The representation drifts from reality. The evidence says the bucket is encrypted; the screenshot is nine months old; nobody re-checks, because checking was never the job, presenting was. The gap between what the evidence claims and what is running is exactly where your risk lives.

How you scale your impact

The move is the one security made: own a mechanism. For GRC, that mechanism is the decision layer.

You take the raw material that already exists and make sense of it programmatically, turning it into a current, queryable answer to "is this control doing its job right now," delivered to the person accountable while the decision still matters.

Concretely, that is the difference between a screenshot and a query:

-- Change management control: every production deploy needs an approved change.
-- Ask the deploy telemetry directly, instead of sampling tickets once a year.
SELECT d.service, d.deployed_by, d.deployed_at, d.commit_sha
FROM        deploy_events  d
LEFT JOIN   change_requests c
       ON   c.commit_sha = d.commit_sha
      AND   c.status      = 'approved'
WHERE  d.env = 'production'
  AND  d.deployed_at > now() - interval '7 days'
  AND  c.id IS NULL;
-- Each row is a production change that skipped the control. A live finding,
-- not a ticket you sampled at 0.07% during audit week.

This is why "be more proactive" is not a personality note. A human assembling evidence helps one owner per afternoon. A decision layer you build once serves every owner, continuously. That is the difference between effort that ends when you stop typing and impact that compounds while you sleep.

Think of it as platform engineering's paved road. The platform team does not write every service; it runs the road every service moves on safely. The owners still drive. You make sure they can see. And it does not care whether the driver is a human or an agent.

The one shift to make Monday

You do not climb the maturity curve with a five-point plan. There is one move, and it is a mindset before it is a task.

Stop measuring your week by what you produced. Measure it by what someone else decided.

Pick one control or one risk you touch. This week, do not wait for the questionnaire or the audit cycle to pull you in. Go to the person who actually owns the decision, the engineer, the system owner, the head of the function, before they ask you for anything. Bring them the live picture of where that control truly stands right now, and help them make a call they would not have made without you in the room.

That is the entire shift. You did not take their decision. You did not break a line. You made sure a real decision got made, with current information, because you were there.

Then ask yourself the only question that separates performing from owning:

If the honest answer is no, you owned an activity. If it is yes, you owned an outcome. Do it once, then the next control, then the next. That is how a function makes itself essential, one owned decision at a time.

Security earned its way off the gate by owning the mechanisms that mattered. The work is the same for us, one layer up and across more teams.

Performative is not what GRC is. It is what GRC looks like before it owns the system, and before its people decide to own their outcomes.

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!