The failure mode of traditional GRC, what changes when you treat compliance as a software problem, and the skills that define a GRC engineer.
25 min 100 XPSkills: GRC fundamentals, Systems thinking
Brief
Governance, risk and compliance has been practised the same way for two decades: a control owner is asked a question once a year, screenshots something, pastes it into a folder, and an auditor ticks a box. It works at ten controls. It collapses at four hundred.
GRC engineering is the response. It treats a compliance program as a software system: controls are code, evidence is generated by pipelines, and assurance is continuous rather than annual. The job title is new; the discipline borrows almost everything from SRE and platform engineering.
If you can describe a control precisely enough to test it, you can describe it precisely enough to automate it.
The failure mode you are replacing
Traditional GRC fails in three predictable ways. First, evidence is point-in-time: a control can be broken for eleven months and still pass an audit sampled in month twelve. Second, effort scales linearly with scope: every new framework multiplies the same manual work. Third, the data is trapped in documents, so nobody can answer 'which controls are failing right now?' without a two-week fire drill.
Each failure has an engineering answer: continuous monitoring instead of sampling, shared control definitions instead of per-framework duplication, and structured data instead of prose.
Sampling hides an eleven-month failure. Continuous checks surface it the day it starts.
What a GRC engineer actually does
A GRC engineer sits between the compliance function and the platform teams. On a normal week they might model a control catalog in YAML, write a Rego policy that blocks a non-compliant cloud resource, build a job that collects access-review evidence from an identity provider, and put a dashboard in front of the CISO showing control health per business unit.
The skill stack is roughly: framework literacy, control design, data modeling, scripting, API integration, and enough pipeline engineering to run all of it on a schedule with alerts when it breaks.
Compliance as a control plane
The mental shift that matters: stop thinking of compliance as reporting, and start thinking of it as a control plane. Controls declare a desired state. Monitoring detects deviation from that state. Automation either prevents the deviation or generates the record that it was corrected. Audit becomes a read operation against a system that was already telling you the truth.
Everything in the rest of this path, policy as code, evidence pipelines, continuous control monitoring, AI-assisted analysis, is an implementation detail of that one idea.
The compliance control plane. Audit stops being an event and becomes a read.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The eleven-month gap
Answer challenge+30 XP
Name the property of the evidence, not the property of the control.
Incident brief
INCIDENT 04-11: Your SOC 2 report was issued clean in December. In February the platform team discovers that the nightly backup-integrity job silently stopped restoring test data on 14 January of the previous year: eleven months before the auditor looked at it.
The control owner is adamant nothing was missed: "We had full logging the whole time, and the auditor pulled three restores from November and they all passed. The control was tested. This is a monitoring gap on the platform side, not a compliance issue."
The auditor pulled three of roughly three hundred restore events and formed an opinion about the whole period from those three.
Term bank, not all of these are right
point in timecontinuoussamplingloggingmonitoringpopulation
1.1The owner blames monitoring. Name the actual property of the audit evidence that let the break survive to December. (two words)
1.2Three restores out of three hundred. Name the testing technique that produced the clean opinion.
Task 2: Who owns which chair
Answer challenge+40 XP
One of these duties poisons the well if the engineer takes it.
Incident brief
A req lands on your desk titled "GRC Engineer (Assurance)". The listed duties: model the control catalog in YAML, build the access-review evidence job, run the CISO control-health dashboard, and, added by someone in a hurry, issue the opinion on whether the controls operated effectively for the period.
The hiring manager's note: "Since they built the automation, they know the controls best, so they should be the one signing off that the controls work. It saves us a hand-off."
Term bank, not all of these are right
modeling the control catalogbuilding the evidence jobissuing the opinionauditorcontrol ownerengineer
2.1Which of the four listed duties must be struck from the req? (three words, as written)
2.2Which role does that struck duty belong to, and must stay independent of the build?
Task 3: Dashboard is not a control plane
Answer challenge+30 XP
The loop is missing a stage. Name it, then name what audit should have become.
Incident brief
A team ships a dashboard that reads every cloud account hourly and turns a tile red whenever a resource drifts from the declared control state. Tiles have been red for six weeks. Nothing has changed in the accounts.
The team lead announces it in the all-hands: "Compliance is fully automated now: we detect every deviation in under an hour." The auditor still arrives in March and still asks for screenshots of each red tile's resolution.
Your new head of GRC wants to "start the automation journey" and has already decided where: the annual policy refresh, "because the board sees it".
Visibility is not impact. Four compliance activities are on the table with their run frequency, effort and where their data actually lives. Write the scoping record for the one intervention that removes the most recurring manual work and can be built against a real source of truth today.
Compliance activity inventory (last 12 months)
id activity runs/yr mins/run source of truth evidence today
EV-DRIFT cloud config drift review 365 45 aws-config-api screenshots in confluence
AC-QTR production access recertification 4 480 okta-api excel export, emailed
VN-WK vendor questionnaire chase 52 90 email inbox email threads
PL-ANN policy annual refresh 1 960 word documents signed pdf
intervention kinds: automate_evidence | automate_test | rewrite_policy | hire_analyst
Your new head of GRC has drafted an "automation roadmap" for next quarter and wants your sign-off by Friday. She has already told the board that six controls will be "fully engineered".
Two of the six are real engineering. The rest move human work around, rename it, or repeat something the platform already does. Accept the ones that produce machine-checkable evidence on their own; reject the rest and say why.
Verdicts are accept or reject. Every rejection needs one reason code from: still-manual | renames-only | no-evidence | duplicate.
Draft roadmap (as circulated)
W-1 Nightly job compares Okta admins against the approved list in the HR system and opens a ticket on any drift.
W-2 Monthly calendar invite reminding the platform team to export the admin list into a spreadsheet.
W-3 Rename "quarterly user access review" to "continuous access assurance" in the control library.
W-4 Pipeline check that fails a deploy when a Terraform plan creates a storage bucket with public read.
W-5 New Confluence page describing how the team intends to monitor privileged access.
W-6 Weekly script that re-exports the same Okta admin list W-1 already collects, into a second bucket.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Automation & Code
The Spreadsheet Failure Mode
Diagnose a real compliance program drowning in manual work and identify the three automations that save the most work.
