What is GRC engineering? Compliance as code comes of age

What is GRC engineering? It is governance, risk and compliance run as an engineered system: controls defined as code, evidence produced where the work happens, and drift caught as it occurs rather than found at the next audit. Many of the pages that rank for the term call it the future of GRC. I think they are a few years late. Compliance as code is a now concept. If you run a 25 to 250-person tech firm and an enterprise buyer's security review is holding up a deal, the question isn't whether this arrives. It's whether you build it before that review comes round again, or after.

That's a claim people push back on, so here's why I hold it, the strongest objection, and what I'd do this quarter.

Why is "the future of GRC" the wrong frame?

Calling GRC engineering the future treats it as a trend to watch. The usual view is that it belongs to large firms with engineering budgets, or that it's a job title you hire for later. Both readings let a smaller firm keep running compliance the old way for one more cycle, and then another.

The old way deserves a fair hearing. Traditional GRC means policy documents, a risk register in a spreadsheet, evidence gathered by hand by whoever is free that week, and a consultant who knows where everything lives. For most of the last two decades, that was rational. Systems were few, auditors wanted documents, and most software couldn't be queried for its own configuration.

The trouble is what happens next. The consultant leaves, and the know-how leaves with them. The evidence was built for one audit, so it gets rebuilt for the next. And the same finding comes back. A finding that keeps coming back is a system problem, not a people problem. Working harder doesn't fix it, and nor does a better spreadsheet.

Where did compliance as code come from?

Compliance as code grew out of DevOps. Engineering teams stopped configuring servers by hand and started defining infrastructure in version-controlled files that could be reviewed, tested and rebuilt. Policy as code followed: security rules written as machine-checkable tests that run before a change ships. Compliance as code applies the same idea to control requirements and the evidence behind them.

Each of those steps has its own guide in the vault. Policy as code covers which rules to encode first, and compliance as code covers automated checks that an audit firm will accept. I won't repeat them here.

GRC engineering is the name the practice has taken as it has grown past tooling into a discipline. A group of practitioners has published a GRC Engineering manifesto that calls it "a fundamental shift in how GRC is done, one that fully embraces an engineering mindset". You don't need to sign up to every line of it. Its existence is the point: the practice now has a name, principles and a community arguing about them.

Why is compliance as code a now concept, not a future one?

Compliance as code is already built into how standards bodies and large buyers work. There are open machine-readable formats for controls, a US government programme that has proposed evidence as data, and a UK regulator that expects firms to satisfy themselves their suppliers are resilient. The tooling categories are mature. What's missing at most smaller firms is the decision to use them.

Three markers make the case:

• Open standards exist. NIST's Open Security Controls Assessment Language (OSCAL) provides "open, machine-readable formats available in XML, JSON, and YAML" for control catalogues, security plans and assessments. Controls and their evidence can now be data, not Word documents.
• Large buyers are asking for data. In April 2025, FedRAMP, the US government's cloud authorisation programme, proposed in RFC-0006 that authorisation packages for its new 20x route "must be machine-readable, supported by evidence, and should include automated technical validation whenever possible". In early 2026 it proposed machine-readable packages for its established Rev5 route too (RFC-0024).
• UK regulated buyers push the duty down. Under the FCA's PS21/3 on operational resilience, firms had to be able to stay within impact tolerances by 31 March 2025. The FCA expects them "to satisfy themselves of that third party's resilience", and where they can't get enough information, to "review and where necessary change their arrangements".

That last point is the one UK tech firms underrate. If you sell into a bank or an insurer, their operational resilience duty becomes your evidence request. The UK conversation about GRC engineering is behind the US one. That's an opportunity for a UK firm that moves first, because its buyers will soon expect what US buyers are starting to.

What changes when compliance becomes a system the firm owns?

Compliance becomes a system when controls, evidence and exceptions live in the same workflow as the rest of engineering. My position is simple: renting people brings know-how, not a system, and the annual scramble returns the year after they leave. An engineered system keeps working after the consultant has gone.

In practice, five things change:

• Controls are tested, version-controlled definitions, not paragraphs in a policy. A control either passes its test or it doesn't.
• Evidence is a by-product of normal work. It is defined at source, so nobody hunts for screenshots. Automated evidence collection covers how to build the catalogue.
• Drift becomes a ticket this week, not a finding next audit. Continuous control monitoring is the mechanism.
• One control set serves several standards. ISO 27001, SOC 2 and your buyers' questionnaires draw on the same unified control library, so each new framework is a mapping exercise, not a new programme.
• Ownership sits in the firm. The system belongs to you, not to whoever built the last spreadsheet.

We run GRCMANA's own estate and our public Trust Centre on the same engineered approach. I'm not arguing for something we don't do ourselves.

The strongest objection: a 40-person firm can't afford this

The best argument against GRC engineering for a small firm is cost. A 40-person firm has a handful of engineers, and every hour spent on compliance plumbing is an hour not spent on the product. On this view, spreadsheets and a consultant are the cheaper option, and engineering can wait until the firm is bigger.

It's a fair objection, and I think it gets the cost comparison backwards. The people-run model isn't cheap. You pay for it again every cycle, because the evidence is rebuilt from nothing each time. The engineering effort is front-loaded and then mostly maintains itself. A cloud-native firm also starts with most of what it needs. It already uses version control, deployment pipelines and cloud services that report their own configuration. The work is connecting what exists, not building a new platform.

There's one part of the objection I'd concede. Heavy on-premise or legacy estates with no API access are where the engineered approach can't land. There, the work becomes manual hours, and it's better to say so up front. For most B2B tech firms selling into regulated buyers, though, that isn't the estate they run.

What should you do about it?

Start where it hurts: the finding that keeps coming back. The aim this quarter isn't a platform or a new team. It's one control that tests itself, one decision about where evidence lives, and one mapping you can reuse for the next standard. Four moves, in order:

1. Find your repeat finding. Look at your last audit or customer security review and pick the finding or question that has come up before. That's where a system pays back first.
2. Write one control as a test. Take a control you already claim, such as multi-factor authentication on production access, and define the check that proves it. ISO/IEC 27001:2022 already expects you to decide what to monitor and measure (clause 9.1). This turns that decision into something that runs.
3. Decide where the evidence lives. Choose the source system for each piece of evidence before the next audit, not during it.
4. Map once, reuse everywhere. Before you take on a second framework, map your controls to both, so the second standard costs a mapping rather than a programme.

None of this needs a big team. It needs one decision: that compliance is something the firm owns and runs, not something it rents.

The question to ask before your next security review

What is GRC engineering, for a firm your size? It's the point where the same finding stops coming back. If your last audit and the one before it raised the same issue, you don't have a system yet, and the future-of-GRC framing is costing you time. For the detail, start at our GRC engineering hub, beginning with the guide to compliance as code.