In most development organisations, security review happens after the design is complete. The architecture is presented to a security team, who identify risks, attach requirements, and send the design back for rework. This cycle is slow, adversarial, and produces suboptimal outcomes — because the most important security decisions were already made, implicitly, before security was consulted.

Threat modelling, done in Sprint Zero alongside the initial design work, breaks this cycle. It is not a gate — it is a conversation that happens early enough to actually influence the architecture.

What Threat Modelling Actually Is

Threat modelling is a structured process for identifying what could go wrong with a system, from a security perspective, before building it. It produces three things: a model of how the system works (usually a Data Flow Diagram), an enumeration of threats against that model, and a set of mitigations for the threats that matter.

The most widely used methodology is STRIDE — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. It is a useful taxonomy for systematically examining a system design against a set of threat categories. PASTA (Process for Attack Simulation and Threat Analysis) is more comprehensive and better suited to complex systems with multiple integration points.

The methodology matters less than the discipline of doing it early and involving the right people.

Why Early Matters

Security requirements discovered during a threat model in Sprint Zero can be incorporated into the architecture. The same requirements discovered during a pre-deployment security review require rework — sometimes significant rework that breaks contracts, requires re-architecture of data flows, or changes integration patterns that other systems depend on.

The cost of a security finding scales with how late it is discovered. A threat model that reveals that sensitive data should not transit a shared message bus is cheap when the bus has not been built yet. It is expensive when the bus is in production with twelve consumers.

The question is not whether your system has threats. It does. The question is whether you know what they are before you deploy, or after something goes wrong.

Who Should Be in the Room

Threat modelling is most effective as a collaborative exercise, not as a security team activity done in isolation. The ideal participants are:

  • The solution architect or technical lead — who understands how the system is designed
  • A security architect or security engineer — who understands the threat landscape
  • A developer — who understands how the system will actually be implemented
  • A product owner or business analyst — who understands what data the system handles and why

The security team's job in this session is not to audit. It is to facilitate the threat identification process and bring expertise on threat categories and control patterns. The development team's job is not to defend their design — it is to understand it deeply enough to enumerate its threats honestly.

What Comes Out of a Good Threat Model

A useful threat model produces concrete, actionable architecture requirements — not vague recommendations. "Ensure all data is encrypted" is not a useful output. "Sensitive personal data must be encrypted at rest using AES-256, and the encryption key must be stored in a managed key service with access logging enabled" is actionable and testable.

The threat model should also produce a risk register — a prioritised list of identified threats with their likelihood, impact, and mitigation status. This register is a living document that follows the system through its lifecycle, updated as the architecture evolves and new threats emerge.

If you would like help introducing threat modelling into your development process or running a threat model for a specific system, get in touch.