Part II · Chapter 4 · What a control is · lesson 6
Automating it changes what you have to prove, not how much
12 min
Builds on Designed, or running? Decide for each one
Part II · Chapter 4 · What a control is · lesson 6
12 min
Builds on Designed, or running? Decide for each one
A quarterly access review done by a person produces four artefacts a year: four dated lists, each with a reviewer's name on it and the entries they removed.
The same review done by a script produces nothing a year. It produces a script, a schedule, and the absence of complaints.
That is the trade, and almost every piece of advice about automation describes it as a reduction in work. It is not. It is a substitution: you stop proving that four people did four things and start proving that one machine did the right thing continuously, which is a harder claim with less familiar evidence behind it.
Predict
Automating a control changes three things and leaves one thing alone.
What the evidence is. Dated human records become a configuration, its change history, and the output stream.
Where the failure lives. A person forgets. A machine does not forget and does get silently disabled, misconfigured, pointed at the wrong scope, or starved of permissions.
How long failure lasts. A forgotten manual control misses one cycle. A broken automated control misses everything until somebody notices, and nothing about it is noisy.
What stays the same: somebody still has to look. The question automation always introduces is who checks the machine still does it, and what artefact would show the day it stopped.
A manual control's failure arrives attached to a person who did not do something. An automated control's failure arrives attached to nobody, in the form of nothing happening — no alerts, no removals, no findings, no output at all.
That absence reads as good news. A scanner reporting zero findings for six weeks and a scanner whose credentials expired six weeks ago produce the same dashboard. An access script that removes nothing because everything is correct and one that removes nothing because its query returns an empty set look identical from outside.
So the honest version of an automated control is always two controls. The automation, and something that checks the automation — a monthly glance at the output volume, an expected-count comparison, a deliberately seeded case that ought to be caught. That second thing is nearly always manual, usually small, and almost never in the register.
Something people say
“Automate the control and the evidence problem goes away.”
An automated control has run nightly for a year with no findings. Which single artefact does the most to establish that it was working?
None of this is an argument against automating. Two things genuinely improve and they are worth being precise about.
The forgetting failure goes away. That is the most common way controls stop, and removing it is the single biggest gain available to a small organisation — particularly for anything hung off a cadence somebody has to remember rather than off an event that happens anyway.
And the evidence stops being a thing anybody has to assemble. Where the control is a by-product of a system, the artefact already exists with a date on it that nobody chose, which is a stronger artefact than a record written up afterwards by an interested party.
What does not improve is the total effort, and the hours move rather than disappearing: from the person who performed the control to whoever maintains the mechanism, who is usually an engineer, usually more expensive, and usually unaware they have become a control owner. That is the arithmetic the next lesson runs.
Check
Some teams deliberately introduce a condition their automation ought to catch, once a quarter, so that the output stream contains a demonstrated catch rather than a year of silence.
It is the cleanest answer to the problem of a control that only produces evidence when something is wrong, and it has an obvious hazard: a seeded case is a thing somebody introduced on purpose into a system other people rely on, and the record of it has to be unambiguous about what it was.
Where it is done well, the seed is harmless by construction — an account that grants nothing, a file that matters to no one — and the record says plainly that it was a test, who ran it and when. Where it is done badly it is indistinguishable from the thing the control exists to catch, which makes every other entry in the log slightly less readable.