For a small change, yes: a short brainstorm of what can go wrong can be enough, as long as the group agrees on what the system does. For anything with several components, trust boundaries or sensitive data, sketch at least a rough diagram. OWASP says brainstorming can supplement diagrams, not always replace them.
What the guidance says
The OWASP Threat Modeling Cheat Sheet names data flow diagrams as the most common system-modeling approach, and says brainstorming can supplement them. It adds that brainstorming helps build shared terminology and lets less technical participants contribute.
The Manifesto's anti-pattern Perfect Representation warns against assuming one ideal view. So a rough sketch is fine, and several views are fine.
When brainstorming alone works
- A change to one component with one data flow
- A copy change to an existing, already modeled feature
- A quick check in sprint planning
- A first session where the goal is vocabulary and engagement
When to draw something
| Signal | Why a diagram helps |
|---|---|
| More than three components | Nobody can hold the flows in their head |
| Data crosses a trust boundary | You need to see where |
| Personal or financial data is involved | You need to see where it lands |
| New team members in the session | A picture aligns understanding fast |
| The change touches authentication | Flows and boundaries matter most here |
A middle path: the napkin sketch
Draw only boxes and arrows. Mark who is trusted and who is not with a dashed line. Label arrows with what moves. This takes five minutes and gives the group something to point at. You can tidy it later, perhaps as a Mermaid diagram.
A brainstorm format that works
- State what the change does in two sentences.
- Ask: who could misuse this, and how?
- Ask: what if this call fails, repeats, or arrives out of order? The OWASP cheat sheet suggests looking at abuse of valid workflows this way.
- Capture each answer as a short sentence on a sticky note or line.
- Rate and assign responses as usual.
Do not skip the record
Even a brainstorm needs a written outcome: the threats found, the response, the owner. Without a record, the work leaves no trace and the next change starts from zero. See a one page template.
Quick check
Is a brainstorm a real threat model?
It can be, for a small scope, if it ends with recorded threats, responses and owners. Guidance treats it as a technique to use alongside diagrams, not as a lesser form.
Who benefits most from brainstorming?
Mixed groups. OWASP notes it lets every team member, including non-technical ones, contribute.
A note on tooling
Safeguard covers checks after design, with SBOM and dependency scanning, reachability analysis and policy gates. A free scan is available.
Sources
Last reviewed: 19 October 2026.
