Threat modeling for early-stage startups: a pragmatic framework
You don't need a security team to do threat modeling. You need one afternoon and this template.
Threat modeling has a reputation for being expensive, time-consuming, and appropriate only for enterprises with dedicated security teams. That reputation is wrong. Here's a pragmatic framework we've used with pre-seed startups and Series C scaleups alike.
- Start with what you're protecting
- STRIDE in one afternoon
- The architecture diagram is the threat model
- Prioritise by exploitability × impact, not by severity
Start with what you're protecting
The first question in any threat modeling exercise is: what are the crown jewels? For a payments startup, it's cardholder data and API credentials. For a healthcare app, it's patient records and session tokens. For a B2B SaaS, it's customer data and multi-tenant isolation.
List them. Write down what happens to the business if each one is compromised — financial impact, regulatory consequence, reputational damage. This list becomes your triage framework. Every security decision gets made relative to it.
STRIDE in one afternoon
STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is the most practical threat classification framework for application teams because the categories map directly to engineering concerns.
For each data flow in your system diagram, ask: can an attacker spoof an identity at this point? Can they tamper with this data in transit or at rest? Can they deny performing an action you need to prove they performed? Work through all six categories systematically. The output is a list of threats — not a list of controls. Solve for threats, not controls.
The architecture diagram is the threat model
A threat model that exists separately from the system architecture becomes stale immediately. The threat model should live as an annotated version of the system architecture diagram — the same diagram your engineers use to understand the system, annotated with the trust boundaries, data flows, and identified threats.
We maintain threat models in Miro with a custom component library for trust boundaries and data flow annotations. Engineers update it when they change the architecture. Security reviews the annotations quarterly. The model stays current because it's the same artifact that describes the system.
Prioritise by exploitability × impact, not by severity
CVSS scores are useful for normalising severity across different types of vulnerabilities. They're not useful for prioritising remediation order, because they don't account for the specific context of your application.
A CVSS 9.0 buffer overflow in a service that's not internet-exposed, runs on a network that requires VPN access, and handles no sensitive data is lower priority than a CVSS 6.5 authentication bypass in a public-facing API that processes payment data. Score every threat by exploitability (how easy is it to trigger?) × impact (what's the worst-case outcome?). Remediate the highest scores first.