GRC engineering: treating compliance as software

There's a generation of GRC practitioners who came up in spreadsheets and grew into a job that increasingly looks like software development. They version-control their policies. They write code to pull evidence from their cloud accounts. They argue about API design when their auditor's tool spits back a malformed schema. They use git for the same reason an engineer does: because compliance work is now done in artifacts that change over time and need to be reviewed.

We call this practice GRC engineering. It's not a job title — most people doing it have "Compliance Manager" or "Senior GRC Analyst" or "Security Engineer" on their LinkedIn. It's a way of working: treating the compliance program as a software product, with the same discipline around interfaces, automation, testing, and change management that engineering uses for application code.

This post is about what GRC engineering looks like in practice, why it produces dramatically better programs, and what tools and patterns make it possible.

The shift in what compliance "is"

For most of GRC's history, compliance was a document discipline. You had policies in Word, evidence in a SharePoint folder, controls in a spreadsheet, a risk register in another spreadsheet, and a binder of vendor SOC 2 reports somewhere. Once a year, an auditor would arrive, ask for everything, and you'd spend two months reassembling it into a presentable form.

Three things broke that model.

Audit cadence changed. Buyers stopped accepting annual snapshots. They want a Trust Center that's current today. They want continuous monitoring evidence. They want to see your last 30 days of access reviews, not the one you did in October.

Volume changed. Most programs went from one framework to three, four, or six. The number of controls under management went from low hundreds to a thousand-plus. The number of vendors under review went from a dozen to two hundred. No spreadsheet survives that volume.

Auditors changed. A new generation of auditors expects evidence pulled from APIs, not screenshots from a console. They expect runbooks they can read. They expect traceability between a control claim, the evidence supporting it, and the human who approved it.

These three shifts together moved compliance from a document discipline to an operational one. Operations needs software. Software needs engineers — or at least, it needs the engineering mindset.

What GRC engineers actually do

The day-to-day of a GRC engineer is recognizable to anyone who's done DevOps or platform engineering, with a different problem domain.

They treat policies as code. Policies live in version control. Changes go through pull request review. The "approved" version is the one with a merge commit signed by the right approvers. Diffs are visible. History is queryable. When the auditor asks why a control statement changed, the answer is in the commit log.

They write evidence collection as code. Instead of taking a screenshot of IAM settings every quarter, they write a script that queries IAM, computes the relevant posture, and writes it to the evidence store. The script is reviewed, versioned, and scheduled. When AWS changes the API, the script breaks, someone fixes it, and the fix goes through the same review process.

They design controls with traceability in mind. Every control statement points to the evidence that supports it, the people who own it, and the changes over time. When a finding lands, they can trace it to the control, the evidence, the policy, and the conversation that decided how the risk was treated.

They use APIs first, UIs as a fallback. When evaluating a tool, the first question is "what's the API surface?" If the only way to get data out is a CSV export from a web UI, that tool is going to be a bottleneck. Real GRC programs need API access to everything they touch.

They automate the boring parts so they can focus on the hard parts. Risk treatment decisions, framework selection, audit strategy — these need human judgment. Pulling cloud config evidence, sending vendor renewal emails, filing tickets when a control owner misses a deadline — these don't. Automating the latter creates capacity for the former.

The role of agents in GRC engineering

GRC engineering used to require actual engineers. You needed someone who could write Python, manage cron jobs, debug a flaky API integration, and maintain the resulting glue code. Most GRC teams don't have that headcount, which is why most programs are still spreadsheet-bound.

Agents are changing the math.

A modern AI agent can write a deterministic evidence pull from a plain-English description. A GRC operator describes what they need ("I want a weekly snapshot of all admin users with their MFA status"), the agent writes a recipe that calls the right APIs, and a human reviews and approves the recipe before it runs. After that, the recipe runs on a schedule — no model in the loop, fully deterministic — until something breaks. When it breaks, the agent investigates, proposes a fix, and waits for approval again.

This is GRC engineering without the GRC engineer. The agent provides the engineering velocity. The human provides the judgment and the approval. The program looks engineered — code-shaped policies, scripted evidence, traceable changes, version-controlled artifacts — without requiring a full-time engineering hire on the compliance team.

Why determinism matters

The single most important property of GRC engineering is that the things you depend on day-to-day are deterministic. Not "the agent reliably summarizes the evidence." Deterministic. Same input, same output, every time, no model involvement.

This matters for three reasons.

Auditors need to read and understand what's running. An auditor reviewing your evidence pulls needs to be able to read the recipe and reason about what it does. They can't audit a model's behavior. They can audit code.

Operations need to be stable. A program where evidence quality varies based on which model version is currently deployed is a program in constant low-grade chaos. Operations need to drift only when you intend them to, not when an upstream provider changes a default.

Failure modes need to be debuggable. When something breaks, you need to be able to trace what happened. "The agent didn't want to run this morning" is not a debuggable failure. "The IAM API returned a 429 at 03:14 UTC and the recipe correctly retried but the second attempt got rate-limited on a different endpoint" is.

The engineering principle here is the same one that produced reliable distributed systems: keep the model where it adds value (planning, drafting, debugging) and out of the path where reliability matters (execution, evidence collection, control enforcement). Agent-first GRC works because it respects that boundary.

The MCP question

A recurring engineering question in GRC right now is what to do about MCP — the Model Context Protocol that lets agents call external tools safely. We're hearing this from practitioners every week, and the question usually takes one of three forms:

1. "Should our agents be calling MCP servers we don't control?"
2. "Should we expose our internal tools to vendor agents via MCP?"
3. "How do we govern this for ISO 42001 or NIST AI RMF?"

The short answer is: MCP is the right primitive, and the governance is the same as governance for any other tool the agent uses. Allowlisting per workspace, per agent, per skill. Logging every call. Reviewing the tool surface periodically. Treating MCP server access the same way you'd treat SSH access or API keys — least privilege, audited, revocable.

The longer answer is that MCP is a wedge issue separating GRC engineering from spreadsheet GRC. A program that can't articulate which MCP servers its agents call, when, and why, can't be run as software. A program that can, can be.

What's missing

GRC engineering is still early. A few real gaps:

Tooling is uneven. Some platforms expose great APIs and let you manage everything as code. Others expose nothing and trap your data behind a UI. Procurement should weigh API surface heavily.

Skills are uneven. Most GRC teams have one or two people comfortable in code and a long tail who aren't. Agents bridge that gap somewhat — operators can describe what they want and the agent writes the code — but the long tail still needs to learn to read code well enough to approve it.

Auditor familiarity is uneven. Some auditors love evidence delivered as code and recipes. Others get nervous when they don't recognize the artifact. The auditor side of the relationship is catching up, but it's not done.

Frameworks are uneven. Some frameworks (SOC 2, ISO 27001) translate cleanly to code-shaped artifacts. Others (HIPAA, PCI ROC) still expect narrative responses an engineer would find archaic. The work of translating between these worlds is real.

The practitioner profile

If you read this post and recognize yourself, you're probably a GRC engineer already, even if your title says something else. The profile we see most often:

• Came up in compliance, learned just enough engineering to be dangerous, increasingly indistinguishable from a platform engineer who happens to specialize in security.
• Or: came up in engineering, ended up running security and compliance for their team, learned the audit side fast, now operates on both sides.
• Comfortable reading code. Doesn't necessarily ship production code, but reviews enough to approve it confidently.
• Allergic to vendor lock-in. Asks about APIs and export formats first. Skeptical of platforms that don't expose their internals.
• Runs the compliance program with the same discipline they'd run a service: SLOs, error budgets, dashboards, on-call.

These practitioners are the ones building the next generation of GRC programs. They're not waiting for vendors to add features. They're combining tools, writing automation, and treating the program as a product they own. We've built episki for them.

If this sounds like the way you want to work, the platform overview explains the substrate, and the AI page covers how agents and recipes fit together. Or just start a trial and try it.