⚙️ New to GRC Engineering? Start Here.

The ideas, the pillars, and the resources to go further. Everything you need to understand why GRC can be better than it is today through the GRC Engineering revolution.

Author

Ayoub Fandi
March 02, 2026

Legacy GRC is broken. Not in a "needs incremental improvement" way. In a fundamental, structural way.

Programs built to impress auditors rather than prevent incidents. Evidence collected through screenshots. Stakeholders treated as input providers who only hear from GRC once a year when audit season begins. Risk measured in red-amber-green heat maps that give false precision and prevent any real decision-making.

And the worst part: the current wave of "GRC automation" is making it faster, not better. We're automating compliance theatre at scale. Saving 90% of time on evidence collection sounds impressive until you realise you're spending less time chasing the same low-value outcomes.

GRC Engineering is the response to this.

It's a movement rooted in a simple belief: governance, risk, and compliance should work like engineering. With systems thinking, measurable outcomes, data architecture, and designed human interfaces. Not like bureaucracy with better tooling.

Myself and Charles Nwatu coined the term GRC Engineering two years ago because the profession needed a new identity, not just new tools. Since then, over 250,000 words across 50 newsletters, hundreds of LinkedIn posts, and the GRC Engineering manifesto.

Why this newsletter, and why now? Two reasons.

First, the community has grown fast. Many of you joined in the last few months and missed the foundational pieces. This puts everyone on the same page.

Second, the space is getting crowded. Everyone now claims to do "GRC engineering." The signal to noise ratio is getting harder to navigate. This newsletter is the baseline. The source. The original framework that everything else builds on.

If you read nothing else, read this.

IN PARTNERSHIP WITH

Automate your SDLC Governance with Kosli

Are you delivering software in a regulated industry? Know the pains of ensuring supply chain security, change management, and runtime monitoring? Kosli automates all of the governance tasks in your software delivery process, giving you speed, security, and audit-ready proof—at scale.

The Inversion Thesis

This is the foundational idea. Everything else builds on it.

Traditional GRC works top-down: pick a framework, derive controls, implement them, collect evidence, pass the audit. The framework drives the architecture.

GRC Engineering inverts this. Start from the bottom. Actual running systems, real control behaviour, system telemetry. Let reality define policy, not the other way around.

The future of GRC Engineering isn't policy-as-code. It's policy-FROM-code. Bottom-up observation of what your systems actually do, with frameworks becoming translation outputs rather than architecture drivers.

This single shift changes everything. Your evidence becomes naturally generated instead of manually manufactured. Your policies reflect reality instead of aspiration. And your compliance posture becomes a measurement of what is, not a declaration of what should be.

POV: The GRC Engineering Starter Pack.

Outcomes Over Activity

Here's a question most GRC teams can't answer: has your program actually reduced risk this year?

Not "how many controls did you implement." Not "how many evidence artefacts did you collect." Not "what certifications did you achieve." Has. Risk. Decreased.

Activity metrics like controls implemented, assessments completed, and checklists passed are compliance theatre dressed up as progress. A 100% control pass rate isn't a sign of maturity. It's often a sign that your controls aren't being tested against real threats.

GRC Engineering demands outcome metrics. Incidents prevented. Attack surface reduced. Mean time to remediation improved. If you can't connect your GRC program to actual security improvement, you're running a documentation factory.

The manifesto puts it bluntly: measurable risk outcomes over checkbox compliance. Evidence, logic, math, and reason over fear and uncertainty.

IN PARTNERSHIP WITH

If your GRC tool can show gaps but can’t close them, is the ROI really worth the cost?

Join Scrut’s live webinar to learn how modern GRC teams and security leaders reduce execution debt with agentic workflows that close the loop and route it for approval so humans stay accountable while the compliance busywork gets done.

Architecture Before Automation

The biggest mistake in GRC right now: automating broken processes.

Three teams each define "privileged access" differently. You automate evidence collection across all three. Now you have inconsistent data arriving faster than ever. Congratulations. You've turned a process problem into a distributed systems problem.

Before you automate anything, answer this: can you document your process in 10 steps? Can your teams agree on what the words mean? If not, automation will replicate your chaos at scale.

The hard part of GRC Engineering isn't the engineering. It's the coordination, consensus-building, and process design that makes automation possible. Code is the easy part. Humans are the hard part.

This is why GRC is fundamentally a data engineering problem. Your unified data model, the relationships between controls, risks, findings, and evidence, is the most strategically valuable asset your program can build. Not the dashboards. Not the automation scripts. The data architecture underneath.

GRC Is a Product

Your GRC program isn't failing because of compliance complexity. It's failing because you haven't found product-market fit.

When GRC operates as a product, control owners become users, not targets. There's a roadmap, iteration cycles, feedback loops, and measurable value delivery. When GRC operates as a project, it resets after every audit cycle and disappears until the next one.

This is also where the human interface imperative comes in. The interfaces between GRC and engineering teams need to be engineered with the same rigour as technical APIs. Clear contracts. Defined routing. Request and response formats. Feedback loops.

Never go direct to developers with compliance requests. Route through Security Engineers for technical context, Product Managers for prioritisation, or Engineering Managers for capacity.

If developers know your name, something's gone wrong. The best GRC design is invisible to them. Compliance happening as a natural by-product of existing engineering workflows.

This isn't about hiding from engineering. It's about building interfaces so clean that compliance never needs to interrupt their work.

The Frontier: AI and What Comes Next

Every GRC capability layer commoditises in turn. Evidence collection is already table stakes. Every platform can do it, every vendor promises it. Basic automation is next. If your program's value proposition is "we automated evidence collection," you're standing on a commoditising layer.

The question isn't whether AI will transform GRC. It will. The question is whether your scaffolding is ready.

Weak workflow plus advanced AI equals expensive garbage at scale. Strong workflow plus basic AI equals consistent value delivery. Three analysts make three different calls on identical scenarios. Your prompt can't capture organisational context, risk appetite nuances, or the business politics that inform human decisions.

Fix the workflow first. Then add AI.

The GRC profession is splitting in two. One group masters AI scaffolding: context documents, validation frameworks, well-designed workflows that make any model useful. The other group complains AI is dumb. The difference isn't the model. It's the infrastructure around it.

Engineering Is a Capability, Not a Role

One thing I want to be clear about: you don't need to code to be part of this.

GRC Engineering is a stack of practices: systems thinking, data-informed decisions, designed human interfaces, outcome measurement. Accessible to anyone. GRC managers, security engineers, risk analysts, auditors. The movement deliberately avoids gatekeeping.

What matters isn't your technical background. What matters is whether you believe GRC can be better than it is today, and whether you're willing to challenge the assumptions that keep it stuck.

The eight values from the GRC Engineering manifesto sum it up: automate early, measure outcomes, use evidence and logic, pursue continuous assurance, design for stakeholders, build partnerships, and build in the open.

Every Monday, a new newsletter lands that builds on these foundations. And the GRC Engineering manifesto is there whenever you need to come back to first principles.

Did you enjoy this week's entry?

Login or Subscribe to participate in polls.

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

If you enjoyed it, you might also enjoy:

See you next week!

Reply

or to participate.