Part IV · Chapter 8 · The Second Year · lesson 2
Which of yours stops happening first?
13 min
Builds on Who notices when this stops happening?
Part IV · Chapter 8 · The Second Year · lesson 2
13 min
Builds on Who notices when this stops happening?
Eleven controls went into the first report. Twelve months later, ten of them are still happening and one is not. The interesting question is whether you could have named it in advance.
You can, and the ranking has almost nothing to do with importance. The restore test is arguably the most important control in the register and it is also the one most likely to have stopped. Three questions sort the list, and none of them is about security.
Whose week absorbs it? A control that happens inside a rhythm a team already has — the sprint ritual, the month-end close, the on-call handover — inherits that rhythm's reliability. A control that exists only as its own calendar invite inherits nothing, and competes for a Tuesday afternoon against whatever else is on fire.
Would anybody outside the register notice? If the control stops and the first thing to change is a row in a spreadsheet, then nothing is watching it. If the control stops and a queue backs up, a report comes out blank, or somebody cannot get into a system, then the organisation itself is the detector and the register is only the paperwork.
How long is the interval? A monthly control that slips is a week late. An annual control that slips is noticed next year. Long intervals are not safer because they are less work in total; they are riskier because nothing in the year reminds anyone they exist.
Predict
Now take the one the ranking puts at the bottom. Below is the restore test, and the block asks you the four things that matter in the second year rather than the first: whether it applies to you at all, why, where it has actually got to, and who finds out when it stops.
The third and fourth questions are the ones to be slow about. Where it has got to is a question about the last twelve months, not about intent. Who notices has only one honest answer for most organisations, and it is nobody.
Decide · backup-restore-test
A backup is a hypothesis and a restore is the experiment. Nearly every organisation has backups; a much smaller number have evidence that data came back out of one, into a working system, within a time anybody had agreed to. This control is about the second thing, and the first thing only matters because it is a precondition.
The decision
What you restore, how far you take it, and how often. A restore into a scratch environment proves the archive is readable; a restore that an application then successfully serves proves considerably more and costs considerably more. Deciding which of those you are claiming, and saying so, is the control. So is deciding what happens when the test fails, because a failed restore test during business hours is good news arriving at an inconvenient time.
Where this goes wrong
The backup job reports success and the success is monitored, which makes the whole area feel covered. Nothing in that signal speaks to whether the archive can be read, whether the schema still matches, or whether anybody holds the key, and each of those failures is silent right up until the restore that was not a test.
Does this apply to you?
Three of the engine's observations turn up here more than anywhere else in the subject, and all three are arithmetic rather than judgement.
If you marked it running and attached nothing, you were asked what you would hand over. That is not a criticism of the control; it is the gap between a control existing and a control having left a trace.
If you marked it running or in place and left the owner blank, you were asked who notices when it stops. This track exists because of that question. An owner is not an administrative field — it is the whole difference between a control and a document, and the next lesson is about what happens when the name in it stops being true.
And if the artefact you named is older than its own cadence allows, the engine will say how many days before the end of your window the last one landed, and ask the only question available: did it run and go unrecorded, or did it not run? Those two have the same evidence and completely different fixes.
Most controls in a first register were designed to satisfy a requirement, and the requirement was satisfied by the control existing and producing an artefact. Nothing in that design process asks what the organisation would feel if the control stopped.
So the detection story, when there is one, is almost always the next audit. That is a twelve-month detection window on a quarterly control, which means the failure mode is three missing instances rather than one.
Where a control genuinely does have a detector, it is nearly always because the control sits on a path somebody needs. Access reviews that remove access get noticed, because somebody loses access and complains. Access reviews that only produce a list get noticed by nobody, and both of those are the same control with a different conclusion allowed.
Check