Mental models for security & IT leaders

Thinking tools · 11 min read · Reviewed June 2026

Most security failures at small organizations aren't knowledge failures — the person in charge usually knew what MFA was. They're decision failures: the wrong thing prioritized, the likelihood misjudged, the uncomfortable number left unmeasured. This site already runs on a handful of thinking tools without naming them — the 80/20 series is the Pareto principle worked to the bone, and "a bad system beats a good person" is systems thinking in work boots. This page names the rest.

Ten models, organized by the three kinds of decisions this role actually faces. Each one comes with the specific way it bites security and IT leaders, the counter-move, and a reference at The Decision Lab — an independent behavioral-science resource with no affiliation to this site — for the research behind it. One warning before the list: collecting mental models is its own trap. The goal isn't to know ten; it's to catch the two or three that are currently costing you money.

Deciding what to do first

The Pareto principle

A small minority of causes produces a large majority of effects — the vital few and the trivial many. In security the distribution is brutal: a handful of weaknesses account for almost all real-world breaches, which means a handful of controls buy almost all the risk reduction. The bite: treating the field as infinite and spreading one person's attention across fifty controls at 30% coverage each. The counter-move is the entire foundations series: identify the vital few, deploy them completely, defend your attention against the rest. Go deeper: the Pareto principle at The Decision Lab.

The law of the instrument

"Give a boy a hammer and everything he meets is to be pounded." Every vendor selling you an answer holds a hammer, and to the SIEM vendor your problem is always a logging problem. But the law applies to you too: if your background is networking, every risk looks like a network risk; if it's compliance, everything looks like a documentation gap. The bite is a tool-shaped or expertise-shaped security program instead of a threat-shaped one. The counter-move: start from the breach data and your two inventories, not from what you (or your vendors) are best at — and enforce the spend rule from the license audit. Go deeper: law of the instrument at The Decision Lab.

The sunk cost fallacy

We keep investing in things because of what we've already invested, even when stopping is clearly better. The bite in this role is everywhere: the security appliance nobody configured, renewed annually because "we paid so much for it"; the half-deployed project that's two years old; the framework implementation that fits a customer you no longer have. Money spent is gone — the only question that matters is what the next dollar and hour buy. The counter-move: the license audit, run annually, with the explicit permission to kill things — and a decision log so abandoning a sunk cost is a recorded decision, not a quiet embarrassment. Go deeper: the sunk cost fallacy at The Decision Lab.

Judging risk honestly

Base rate neglect

Given vivid specific information and boring statistical information, we ignore the statistics. Security marketing is a base-rate-neglect machine: the demo shows a nation-state implant, while the base rate says small organizations get breached through stolen credentials, unpatched edge devices, and email fraud. The bite: a register full of exotic scenarios while RL-01 through RL-05 sit unmitigated. The counter-move: score risks against frequency data, not vividness — it's why the risk library ships with suggested scores and why likelihood belongs in calendar language ("about once every three years"), which forces base rates into the conversation. Go deeper: base rate fallacy at The Decision Lab.

The availability heuristic

We judge likelihood by how easily examples come to mind — which means by whatever was in the news this week. The bite has a familiar shape: the CEO reads about a headline breach and asks "are we protected against that?", and a week of your scarcest resource goes to the threat that's most available rather than most likely. The counter-move: keep one written, data-anchored priority list (the register), and answer headline questions by placing the new threat on it — "here's where that ranks against what we're already working, and here's why" — which respects the question without letting the news cycle run your program. Go deeper: availability heuristic at The Decision Lab.

Optimism bias and the planning fallacy

Two biases that travel together: we underestimate our own probability of bad events, and we underestimate how long work will take even when our own history says otherwise. The first bite is "we're too small to be a target" — the 2026 DBIR's answer is that small organizations were 96% of ransomware victims, because attacks are opportunistic, not curated. The second bite is every security project planned at 100% capacity. The counter-moves: let base rates overrule self-assessment, answer insurance applications literally rather than aspirationally (RL-10 in the library exists because optimism on a form becomes a denied claim), and build the buffer in — the 90-day plan's week thirteen is the planning fallacy, pre-paid. Go deeper: optimism bias and the planning fallacy at The Decision Lab.

Normalcy bias

We underestimate the possibility of disaster because life has, so far, continued as normal. It's the quiet voice saying the backups don't need testing because they've never been needed, and the incident plan can wait because there's never been an incident. The bite: years of "normal" treated as evidence of safety, when it's mostly evidence of luck plus survivorship. The counter-move is rehearsal — the restore test, the tabletop walkthrough, the break-glass drill — because rehearsal converts "that never happens" into "here's what we do when it does." Go deeper: normalcy bias at The Decision Lab.

Keeping the program honest

The ostrich effect

We avoid information we expect to be unpleasant. In this role it looks like not measuring MFA coverage because the number might embarrass the rollout, archiving vendor advisories unread, or skipping the restore test in a quarter when failure would be inconvenient to report. The bite: erosion compounds precisely where you've stopped looking. The counter-move: make the looking automatic and cheap — five numbers, one hour, every quarter — and reframe red numbers as the system working ("a red metric with a named fix builds more trust than a wall of green"). Go deeper: the ostrich effect at The Decision Lab.

Status quo bias

We prefer the current state of affairs and treat any change as a loss. It's why legacy authentication stays enabled years after everyone agrees it's dangerous, why the end-of-life firewall survives budget cycle after budget cycle, and why "we've always done it this way" functions as an argument. The bite: at small organizations the status quo usually predates any security thinking at all, so defending it means defending decisions nobody actually made. The counter-move: flip the burden of proof once a year — each exception, legacy protocol, and aging device must re-justify its existence, with the quarterly review's expiry-dated exception list doing this automatically for access. Go deeper: status quo bias at The Decision Lab.

Goodhart's law

When a measure becomes a target, it stops being a good measure. Make "tickets closed" the goal and tickets get closed badly; make "training completion" the goal and people click through videos; make "audit findings" the goal and findings get argued away instead of fixed. The bite: a security program that optimizes its scoreboard instead of its security. The counter-move: measure coverage against an inventory rather than activity — the design principle behind the five numbers — and when a metric goes green and stays green for a year, ask whether it's still measuring anything or merely being managed.

Hindsight bias

After something happens, it feels like it was predictable all along — so post-incident reviews quietly become trials of whoever was closest to the failure. The bite is twofold: people stop reporting near-misses (rational, if reporting means blame), and reviews produce "be more careful" instead of system changes. The counter-move: blameless reviews that ask what the system made easy or hard — a bad system beats a good person, every time — plus a decision log, which is also your defense when hindsight bias is aimed at you: "why did you deprioritize that?" has a good answer when the reasoning was written down at the time, with the information you actually had. Go deeper: hindsight bias at The Decision Lab.

How to actually use this page

Don't laminate the list. Pick the two or three models that made you wince — that's the tell — and add one question to your quarterly review: "which of these bit us this quarter?" A sunk-cost renewal that slipped through, an availability-driven fire drill, a skipped test that was really the ostrich effect. Naming the pattern is most of the cure, because these biases survive on not being noticed.