Threat modeling is not just imagining what an attacker could do. It is examining together which assets exist in the system, who crosses which boundaries, and what a wrong decision costs.
The first drawing is the data flow
Show users, browsers, APIs, databases, third-party services and the admin dashboard in one diagram. When where data comes from, where it transforms and where it is stored becomes visible, risk becomes discussable.
Ask these questions
- Which asset is critical for us?
- Which identity could an attacker assume?
- Where does the trust boundary change?
- What happens if an endpoint is called directly?
- How are errors or permission changes recorded?
Scoring risks is not enough
Match every risk with a control: validation, least privilege, encryption, rate limits, monitoring or human approval. If a control’s owner, test method and re-evaluation time are unclear, the threat model is not a living document.
When should it be done?
It should be revisited whenever a new data type, integration, permission model or automation is added. The best time is a short design session before code is written, because a fix in architecture is cheaper than closing a hole in production.