Take one access-review control from Word document to a scheduled check that produces its own evidence.
50 min 220 XPSkills: Automation, Evidence
Brief
Everything so far has been vocabulary and judgement. This room is the hinge: you take one ordinary control out of a Word document and turn it into something that runs on a schedule, checks a real source, and leaves behind evidence nobody had to assemble.
The control we will convert is the most common one in every program: administrative access must be approved, and access no longer needed must be removed. It is reviewed quarterly, by hand, by a person with better things to do.
Automating a control is not writing a script. It is deciding what counts as truth, what counts as a violation, and what the run leaves behind.
The five parts
Every automated control has the same anatomy. A trigger decides when it runs, replacing the calendar reminder. A source of truth supplies the data, replacing the emailed CSV. A rule expresses the assertion that must hold, replacing the reviewer's judgement call. A result records pass or fail with row-level detail, replacing the tick in a cell. And an evidence artifact, a signed output plus the run log, replaces the screenshot.
Miss any one and you have something less than a control. A rule with no artifact proves nothing later. An artifact with no trigger is a one-off. A result nobody routes anywhere is a dashboard, not a control.
Five parts, each replacing one manual step. The dashed arrow is what makes it a control rather than a report.
Translating the control statement
Start with the prose: "Access is reviewed quarterly by the system owner." Extract the four testable elements, who, what, when, and what proof remains. Each one becomes a field. The owner becomes an identity, the subject becomes a specific query, the cadence becomes a schedule, and the proof becomes a retained artifact with a retention period.
Once written that way the code is almost mechanical: schedule weekly, list admins from the identity provider, assert that every admin has an approval ticket, emit the result as JSON. The hard thinking happened in the translation, not the syntax.
The same control, three times. The middle column is where the work actually is.
Failing loudly
A manual control fails visibly: someone does not do it and the tracker cell stays empty. An automated control can fail invisibly: the API returns an error, the exception is swallowed, the job exits successfully and the dashboard turns green on zero rows.
So write the failure paths first. Zero rows returned is a failure, not a pass. An authentication error is a failure. A run that did not happen at all is a failure, which means you need a check on the check: an alert when no result was recorded for a scheduled window.
Closing the loop
The last step is the one teams skip. A detection that goes into a dashboard is not a control, because nothing forces anyone to act. Route every failure into a ticket with an owner and a due date, and the control now has a consequence, and, incidentally, generates its own remediation evidence.
Retention matters too. If the auditor is testing a twelve-month period, run artifacts must survive twelve months. Container logs that rotate after seven days are not evidence.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: Green dashboard, empty logs
Answer challenge+70 XP
Two answers: what the run failed to leave behind, and what that record must carry.
Incident brief
The access check has run every Monday for eleven months. It prints a summary to stdout and turns a tile green. The tile is green now.
The auditor asks for the results of the run on 12 February. The container logs rotate after seven days. The tile stores only the current state. The engineer offers to re-run the check today and send the output, saying: "It'll show the same thing, the control's been passing all year."
Nothing in the system can distinguish 'passed every week for eleven months' from 'crashed silently in February and has passed since'.
1.1Name the pipeline output missing here, which must survive log rotation. (one word)
1.2Name the field each run record needs so a specific past run can be located. (one word)
Task 2: Checking the copy
Scenario sim+70 XP
Name what the script is missing, then the system it should be querying.
Incident brief
The new automated access control reads admins.csv from a shared bucket and asserts each row has an approval ticket. It runs nightly and has passed for six weeks.
admins.csv is produced when someone in IT remembers to export it: most recently forty-one days ago. Three admin accounts have been granted since, none of them in the file. The nightly job cannot see them and cannot know it cannot see them.
The engineer's defence: "The check is automated and runs every night. If IT exports more often, it gets more accurate."
Term bank, not all of these are right
source of truthidppopulationtriggerscheduleassertion
2.1Name the pipeline stage that is wrong here. (three words)
2.2Name the system the check should query directly instead. (three letters)
Task 3: Detection is not a control
Scenario sim+80 XP
Name the missing consequence, then the line that encodes the rule.
Incident brief
The check now queries the identity provider live, retains signed JSON for twelve months, and correctly reports nine admins without approval tickets. It has reported the same nine for four months.
In the quarterly review the head of platform says: "This is our strongest control: fully automated, evidence retained, zero manual effort." The nine accounts are still there. Nobody was ever assigned to remove them; the output goes to a dashboard nobody has a reason to open.
In the check's config, one line reads `assert: a.approval_ticket != null` and it is doing its job perfectly.
Term bank, not all of these are right
ticketasserttriggerartifactescalationdashboard
3.1Name what must be raised automatically on failure to make this a control. (one word)
3.2Name the config keyword that encodes the control's rule. (one word)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
You are automating the cloud drift control. The platform lead sketches it out: "run it some time overnight, email the team, and if it fails just retry until it goes green so we don't get noise".
Retrying until green is how a control learns to lie. Write the job specification: when it runs, what it reads, what it asserts, what happens when the assertion is false, and how long the result is kept.
Available systems and conventions
source systems: aws-config-api | okta-api | github-api
schedule format: standard five-field cron, UTC
(minute hour day-of-month month day-of-week)
failure actions in use elsewhere:
open_ticket | page_oncall | email_team | retry | suppress
Evidence retention agreed with the audit firm: 7 years.
The control asserts that no production resource is publicly
exposed at the moment of the run.
Your first automated control has been live for a week. The run log shows eight days of results and the dashboard is green.
Raise the runs that mean the control did not actually do its job. Leave the ones that are noisy but sound.
List only the lines that qualify, worst first. Severity is one of: critical | high | medium | low. Add or delete rows as needed.
Control run log
C-1 Mon: run completed, 0 records evaluated: source returned an empty list, result recorded as PASS.
C-2 Tue: run completed, 214 records, 3 violations, ticketed.
C-3 Wed: run errored on API timeout; job caught the exception and recorded PASS.
C-4 Thu: run completed, 214 records, 0 violations.
C-5 Fri: run skipped: scheduler holiday calendar suppressed it; no record written at all.
C-6 Sat: run completed, 214 records, 1 violation, ticketed, closed same day.
C-7 Sun: run completed against a cached snapshot from Thursday because the live call failed.
C-8 Mon: run completed, 215 records, 0 violations.
1
2
3
4
5
6
7
8
9
10
11
12
Checks
The right findings are raised
Benign lines are left out
Severity matches the actual exposure
Ranked worst first
Next on your path · Automation & Code
Git for GRC Artifacts
Version control, review and approval workflows applied to policies and control definitions.
