Threat Modelling

Threat modelling is thinking like an attacker on a schedule: systematically enumerating what could attack a system, what they would target, and how — then fixing the design before the attacker gets a vote. It is security's cheapest hour, and the practice that separates systems designed to resist attack from systems merely audited after it.

What It Is

Threat modelling is a structured analysis of a system's security: identifying assets worth attacking, mapping entry points and trust boundaries (where data crosses from untrusted to trusted ground), enumerating plausible threats (frameworks like STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — exist to force completeness), rating them by likelihood and impact, and designing mitigations into the architecture. It is performed at design time, on diagrams, and refreshed when the architecture changes — the point being that security shaped into structure costs a fraction of security bolted on after deployment.

Why It Matters to You

The executive framing: threat modelling is where security becomes design input rather than compliance output. Its absence explains the familiar pattern — systems that pass their checklists and are architecturally indefensible, because nobody asked 'what does an attacker see here?' while the diagram was still on the wall. It is also the natural integration point for AI governance: AI systems introduce new attack surfaces (data poisoning, prompt injection, model extraction) that legacy security processes do not cover, and threat modelling is the discipline that surfaces them before deployment rather than after the first novel incident.

When You'll Meet It

In security reviews, architecture sign-off, and any AI system governance. The standing question: 'when was this system last threat-modelled, and what changed since?' — security designed once and never revisited ages like everything else.