Chapter 08 · Response

Recurring patterns

Written for programme designers who want to test their controls against the shapes cases actually take.

Patterns, not incidents

The shapes below are generalisations drawn from how the categories in chapter 2 behave. They name no organisation, product, person or event. Their purpose is to give a programme something concrete to test its controls against.

Table 8.1 — Recurring pattern, usual trigger and the control that addresses it
Pattern	Usual trigger	Control
The departing collector	Resignation accepted, notice period running	Egress baseline review at notice, not at exit
The accumulated mover	Third or fourth internal role change	Access removal bound to the grant transaction
The unmanaged supplier account	Contract end handled by the supplier	Supplier accounts in the organisation's own leaver inventory
The convenience workaround	A control that blocks legitimate work	Fixing the blocked path rather than policing the workaround
The single administrator	Small team, long tenure, no cover	Two-person rule over destructive operations
The unreported mistake	A previous reporter treated as a suspect	A reporting route with a stated non-punitive outcome

Reading the table

Two observations are worth drawing out. First, four of the six patterns are addressed by access design rather than by detection, which is consistent with chapter 5. Second, two of them — the convenience workaround and the unreported mistake — are created by the programme's own choices, and neither can be fixed by adding a control on top. They are fixed by removing or changing the control that produced the behaviour.

Using the patterns

Take each pattern in turn and name the control in your own environment that addresses it.
Where no control exists, record it as an accepted exposure with a named owner.
Where a control exists, establish when it was last shown to work rather than last reviewed.
Re-run the exercise after any organisational change that moves people between roles in volume.