This post is the written companion to Episode 1 podcast (with sources).
Most organisations stop investigating at the exact moment the explanation becomes useful.
Someone clicked. Someone approved something they shouldn’t have. A slide deck gets built, a timeline gets written, and the story collapses into a sentence that feels satisfying. The organisation stops there—because the sentence is useful. It supports closure. It supports reporting. It supports a neat lesson.
Here’s the problem: usefulness is not the same as explanatory power.
The click obviously matters. It is part of what happened. But in recurring incident classes, behaviour is rarely a useful explanation for recurrence. It is often the moment the system made its hidden constraints obvious.
This is the stance I’ll keep coming back to:
architecture before blame.
Not because individuals don’t matter. Because blaming the endpoint doesn’t explain the pattern. And if you can’t explain the pattern, you can’t control recurrence.
Here is the definition I’m working with:
Behavioural security studies how the setup around an asset shapes behaviour that changes security risk.
This isn’t “advanced awareness training.” It isn’t personality scoring. It isn’t blaming users. It’s a discipline about explanation: whether your causal account gives you leverage, or merely gives you closure.
A visibility event is what you can put on a timeline: the click, the share, the approval, the missed check.
A cause that gives you leverage sits upstream: repeatable conditions in the setup around the asset that shape what people do under pressure.
Systems and safety research has been saying this for a long time: outcomes in complex systems are often better explained by interacting conditions and control constraints than by the last visible human act (Reason, 2000; Leveson, 2011). If your analysis ends with behaviour, you may have a tidy description. You don’t yet have a strong explanation of recurrence.
So the target variable in this post is not “reduce clicks.” It is reduce recurrence.
Two competent people. Same role. Same deadlines. Same tools.
The secure path takes five minutes and requires a ticket.
The insecure path takes ten seconds and nobody complains.
Under pressure, people choose the path that keeps the work moving. That isn’t a character flaw. It is a predictable response to constraints.
Now ask what the system selects for. Not what it claims to value in policy. What it rewards in reality.
This is what it means to treat behaviour as a surface symptom of a deeper structure: the environment is producing the behaviour.
A one-off can be noise. A repeating incident class is signal.
If the same failure class keeps recurring, you should treat that as evidence of a stable configuration, not as evidence that you need another round of “be more careful.”
Dynamic risk environments drift. People adapt. Practices stabilise. Over time, the gap between “work as imagined” and “work as done” can widen without anyone making a dramatic decision to be unsafe (Rasmussen, 1997). When a visibility event finally happens, organisations often behave as if the story started there. It didn’t.
This is not an operational procedure. It’s three tests that keep your causal thinking honest.
1) Swap the person
If you replace the individual and the same failure class still plausibly recurs, then behaviour is not your deep explanation.
This is why the “two competent people” thought experiment matters: it forces you to notice when your explanation is really just an attribution to whoever was in the chair when the system became visible.
2) Perfect humans
Ask whether your explanation gives you leverage without requiring perfect humans. If your fix only works with flawless behaviour, it isn’t a control. It’s a wish.
This aligns with a basic resilience point: performance varies, and systems must be governed so normal variability does not routinely become failure (Hollnagel, 2014). Controls that only hold in calm conditions are not robust controls.
3) Local rationality
Ask whether you can explain why the action made sense at the time—not why it was wrong in hindsight, but why it was locally rational under those constraints.
If you can’t explain local rationality, you can’t design against recurrence.
This is the difference between moral storytelling and causal explanation. It is also why “fix the person” so often fails: it never explains what the setup made easy, costly, normal, or unavoidable (Dekker, 2014).
What changes when you stop ending the story at behaviour
You stop spending most of your energy on sermons.
You stop polishing the message and start interrogating the conditions.
You stop treating recurrence like a personal failure and start treating it like a control reliability problem.
You start asking questions that touch the upstream layer:
- What in the setup made the insecure action the easy default?
- What pressure made the secure action expensive?
- What would have to be true for this failure class to stop recurring?
If your incident narrative can’t answer those, you don’t have an explanation. You have a stopping point.
That’s the core claim of this intro: causes that give you leverage beat causes that give you closure.
References (Harvard)
Dekker, S. (2014) The Field Guide to Understanding “Human Error”. 3rd edn. Boca Raton: CRC Press.
Hollnagel, E. (2014) Safety-I and Safety-II: The Past and Future of Safety Management. Farnham: Ashgate.
Leveson, N. (2011) Engineering a Safer World: Systems Thinking Applied to Safety. Cambridge, MA: MIT Press.
Rasmussen, J. (1997) ‘Risk management in a dynamic society: a modelling problem’, Safety Science, 27(2–3), pp. 183–213.
Reason, J. (2000) ‘Human error: models and management’, BMJ, 320(7237), pp. 768–770.
