Last week I wrote about the legacy primitives running your GRC programme. The instincts left by your last GRC lead. Your CISO's priorities. Your industry's defaults. The piece was diagnostic.

This one is constructive.

If those legacy primitives are what your programme inherited, what should the operating primitives be?

The shortest answer is uncomfortable. The same ones engineering teams have used for twenty years.

Git is the most successful operating model ever built for managing complex, versioned, multi-author work where every change has to be auditable. Most modern software runs on it. Most modern compliance does too, when you look at the operations instead of the toolchain.

We just don't call it that yet.

IN PARTNERSHIP WITH

Why Sponsor The GRC Engineer?

3,200 subscribers, growing 200 every month. ~55% open rate. ~7% click-through. 80% of readers are GRC managers, directors, VPs, and CISOs with tooling budget from the world’s best companies like Anthropic, Google, Harvey, Netflix, Instacart, Block, Coinbase and hundreds more!

One sponsor pulled 64 leads from two campaigns at 20x ROI. Another mapped close to 6 figures of closed-won revenue back to a single campaign at 7x ROI. Already trusted by Vanta, Drata, Anecdotes, Tines, Mastermind, Conveyor, Kosli and many more!

You Are Already Doing Half of It

Before any framework, the vocabulary bridge.

If five of those eight rows feel familiar, you are most of the way there. You version policies. You redline drafts. You require approvals. You keep an audit trail.

What you are missing is the discipline that strings these activities together. That discipline has a name.

One thing before we go deeper. If your underlying process is broken, no mental model will save you. Engineer Your GRC Process Before You Automate It is the prerequisite. The four process principles in that piece (input quality, process definition, output consistency, feedback loops) are exactly what Git operations were designed to deliver.

It’s about fixing your thinking before using a specific tool.

Where Git Operations Belong

Not every GRC activity earns the full Git treatment. Three tiers tell you where to invest.

Git operations earn their place when the artefact is structured, the lifecycle is long, and the cost of an undetected change is high. Otherwise, leave it alone.

This is also why the policy-as-code revolution didn't happen. The movement assumed every GRC artefact deserved the full toolchain. The market disagreed. Git-based policy management was always the narrow case. The mental model scales to the rest, but only where it earns its place.

The Cognitive Shift

The harder shift is not which activities. It is how you think about them.

Every GRC artefact has a lifecycle. Drafted, reviewed, approved, released, maintained, retired. Most teams handle each stage as a separate event. A draft happens in someone's inbox. A review happens in a Word document. An approval happens in an email thread. A release happens via SharePoint.

The audit trail is reconstructed retroactively when an auditor asks.

The Git mental model collapses all of that. Every stage is a state of the same artefact.

The draft is a branch. The review is a comment thread tied to that branch. The approval is the act of merging it into the official record. The release is the tag on top. The audit trail is automatic, because every state was captured by the operating model itself.

Three practical consequences follow.

→ You stop asking "is this approved?" and start asking "is this on main?" The first question depends on memory. The second is checkable in seconds.

→ You stop saying "the policy is currently being updated" and start saying "there is a branch in review." The first is fuzzy. The second tells everyone exactly where the work lives, who is reviewing, and what would happen if it merged tomorrow.

→ You stop reconstructing audit trails and start consulting them. The audit trail is the operating record. It does not need to be assembled.

This systems-thinking move is the same one that drove From Silos to Systems and Signal vs. Noise. The way you frame the problem determines what you can build. The Git mental model is another instance of that frame, applied to the artefact layer.

Render for the Audience, Not the Tool

Most GRC-as-code advocates trip on the same step. They put the artefact in Git and assume the audience will follow them in. The audience never does.

Auditors do not pull from main. Regulators do not read diffs. CFOs do not look at PRs. The business owner who has to acknowledge a policy does not know what a branch is.

So you stop asking the audience to come to Git. You build the rendering layer.

The source of truth lives where the operations are cleanest. The audience consumes from whatever surface they already use. Google Docs for editing and review. Claude.ai or similar for conversational query. PDF for audit packs. Confluence or Notion for browse. Email digests for executives.

One source. Many build targets. Each rendering matched to who is consuming it.

The catch is the consistency tax. Every rendering must be generated, never hand-edited. Every editable surface must round-trip back to source within hours. Drift between source and renderings must be detected automatically. Changes upstream must be communicated to stakeholders through their channel.

Most programmes never pay this tax. That is why the policy library, the control catalog, the audit pack, and the exec briefing slowly say four different things about the same thing.

The technical maturity of your programme is not Git. It’s running a publishing pipeline that keeps your source and your renderings honest. The deeper take on that interface work lives in The Human API.

Three Steps to Get Started

→ Tier your artefacts. Score everything your programme produces against three questions.

• Is it structured or narrative?

• Is the lifecycle longer than a quarter?

• Does an undetected change cost the company something material?

Three yeses puts the artefact in Tier 1. Two yeses, Tier 2. One or zero, Tier 3. You will be surprised how much of your programme lives in Tier 2 or Tier 3. That is good news. The work concentrates.

→ Pick three operations per Tier 1 artefact. Not all eight. The mistake is adopting everything at once. A policy library might pick versioning, review, signed approval. A control catalog might pick versioning, branching, tagged releases. A detection content repository might pick versioning, review, automated quality gates. The companion piece for how to automate each operation, once you have picked them, is The 3 Types of Automation in GRC Engineering. This piece is about which operations. That one is about which type of automation each operation deserves.

→ Build the rendering layer. Pick one editable surface for non-technical stakeholders, usually Google Workspace. Pick one query surface for audit and exec questions, often Claude.ai. Pick one snapshot surface for formal handoff, usually PDF. Wire round-trip from at least the editable surface back to source. Set up drift detection. Pay the consistency tax.

Where It Does Not Apply

Naming what does not work earns trust on what does.

Git operations are not a substitute for risk acceptance with the CFO. Or executive alignment. Or regulator dialogue. Or vendor-CISO relationships. Or the cultural work of moving a programme from audit-driven to program-driven, which I covered in Your GRC Program Serves the Audit. The Best GRC Engineering Programs Don't.

The operating model is the artefact layer. The trust layer sits on top of it and is human work.

This is not a retreat. It is the boundary that keeps the framework honest.

A Working Example, Not a Theory

This is not theoretical. Corsair is what this mental model looks like applied to TPRM specifically. Cryptographic proof of compliance posture. Versioned, signed, queryable. Six operations baked into the protocol itself, with rendering layers for every stakeholder type.

The newsletter you are reading is the broader case. Corsair is the proof point.

Engineers did not solve security by becoming engineers. They created security engineering, a hybrid discipline. The same pattern applies here. GRC will not be solved by GRC people becoming developers. It will be advanced by GRC people who can name the operating primitives, recognise where they fit, and refuse the places they do not.

Technical depth is the enabler of that judgment. It is not the judgment itself.

You are already doing half of it. You just have not named it yet.

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!