Security Threat Model Template (STRIDE)

Create a threat model for any feature that handles sensitive data (PII, financial data, authentication), crosses trust boundaries (public API, third-party integrations), or introduces a new attack surface (new endpoint, new protocol, new storage system). The ideal time is during the design phase, before code is written. For existing systems, prioritize threat modeling for the highest-risk components first.

A threat model is a proactive design exercise that identifies potential threats before they are exploitable. A [penetration test](/templates/penetration-test-plan-template) is a reactive assessment that tests whether known threat categories are actually exploitable in a running system. Do the threat model first (during design), then validate the mitigations with a penetration test (after implementation). They are complementary, not interchangeable.

Yes. PMs define what the feature does, who uses it, and what data it handles. These inputs are essential for scoping the threat model correctly. The PM does not need to identify every technical threat, but they should participate in the session, understand the risks, and help prioritize mitigations against the product roadmap. Use the [RICE framework](/frameworks/rice-framework) to prioritize security work alongside feature development.

A focused threat model for a single feature typically identifies 8-15 threats. If you are finding fewer than 5, you are probably not being thorough enough. If you are finding more than 25, your scope may be too broad. Break large systems into smaller components and model each one separately.

Re-review the threat model whenever the feature's architecture changes significantly: new data flows, new third-party integrations, new authentication mechanisms, or changes to trust boundaries. At minimum, review all active threat models annually. Treat the threat register as a living document, not a one-time artifact. ---