Part II · Chapter 4 · What a control is · lesson 3
Who notices when this stops happening?
12 min
Builds on The document is the intention; the control is the thing that happens
Part II · Chapter 4 · What a control is · lesson 3
12 min
Builds on The document is the intention; the control is the thing that happens
A control stopped happening in April. It is now October.
Who found out, and on what day? That question has only three possible kinds of answer, and the differences between them are the whole of this lesson.
Somebody found out within a cycle, because the thing that was supposed to happen did not and that absence landed in their week. Somebody found out months later, because they went looking for an unrelated reason. Or nobody has found out, and the first person to know will be whoever asks for the records.
Predict
The owner field in a register is usually filled in with the person who wrote the control, approved it, or has the job title nearest to it. None of those people find out when it stops.
Three different roles get collapsed into one word:
The performer does the thing. Their failing is what the control's failure consists of, so they cannot be the detector without a conflict.
The detector finds out that it did not happen, and the useful question about them is how long it takes and what brought it to their attention.
The responder has the standing to make it happen again, which sometimes means arguing with somebody else's priorities.
In a small organisation all three are the same person, which is survivable and has to be said out loud rather than hidden behind a name in a field.
The control below is the one where ownership is genuinely contestable, not as a teaching device but in practice. Three events get filed under one heading. The joiner is owned by whoever cannot work without access. The leaver is owned by whoever is chasing the laptop or the final payroll run. The transfer is owned by the gap between those two, and the person who moved is still here, still working, still perfectly able to do their job with last year's permissions.
Decide · joiner-mover-leaver
Three different events get filed under one heading and only one of them is reliably handled. Joining is handled because nobody can work without access. Leaving is handled because somebody notices the empty desk or the final payroll run. Moving is handled by nobody, because the person is still here, still working, and their old access is still convenient.
The decision
What triggers the access change, and whether the trigger is something that happens anyway. A checklist that depends on somebody remembering to open it is a different control from one hung off the event that already has to happen — the payroll change, the contract, the directory record. Choosing the trigger is choosing whether this control has a failure mode at all.
Where this goes wrong
The mover case has no moment of truth. A joiner cannot start without access and a leaver's manager is usually chasing something, but a transfer produces no blocked work and no empty chair, so the old permissions are simply never raised. The result looks like seniority rather than like an error, which is why it survives several reviews.
Does this apply to you?
Read the name you put in and ask three things of it.
Would they find out, or would they be told? A detector who learns about the failure from the person who performs the control is not a detector. That is the performer self-reporting, which is worth having and is a different control with a different failure mode.
How long would it take? For this one the honest answer is usually measured in months, because the transfer case produces no blocked work and no empty desk. The signal that would have caught it is a periodic comparison of who has access against what people currently do — which is a second control, owned by somebody else, and the reason these two keep turning up in the same conversation.
Is it a person or a role? A role survives somebody changing teams and is only as real as its staffing. A named person is unambiguous today and becomes wrong silently. Neither is the right answer; writing down which one you chose is.
If the name you wrote is the same as the person who performs it, the control has one point of failure covering both doing and noticing. That is the condition under which everything above stops being a useful frame — and it describes most organisations under about ten people, where the honest register entry says so rather than naming a second person who does not exist.
Check
Because the field is doing a different job from the one its name suggests, and it is still worth having.
What it buys is a person to go to. When the gap is found — by a sample request, an incident, or somebody else's curiosity — the owner is who gets asked, and an empty field at that moment costs a week of working out whose it was. In an organisation where people change teams, that week is the common case rather than the exception.
What it does not buy is a shorter time to detection, and registers routinely spend the field as though it did. Keeping two fields in your head — who is accountable, and what would actually surface the failure — is the whole upgrade, and it costs one extra sentence per control.