Home / Insights / QA and Software Testing
QA and Software Testing
Threat Modeling for Product Teams: A Practical Process with STRIDE
Threat modeling finds security problems while they are still design decisions. This guide gives a practical process built on the four key questions of the Threat Modeling Manifesto and the STRIDE categories, with a worked example and advice on fitting it into agile delivery.
TopicsQA and Software TestingArchitecture and ModernizationWeb and SaaS Development
Key takeaways
- Threat modeling analyses representations of a system to find security and privacy concerns before they become code.
- The Threat Modeling Manifesto frames it as four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?
- A data-flow diagram with trust boundaries is the most useful starting point; STRIDE helps structure what can go wrong at each element.
- Prioritise threats by likelihood and impact, and turn mitigations into user stories, acceptance criteria and tests.
- Model new systems, significant changes, new integrations and features handling sensitive data — briefly and regularly rather than once.
On this page
Most security flaws are cheaper to fix in design than in code, and far cheaper than after a breach. Threat modeling is the practice of finding them early. It does not require specialist tools or a security team for every session; a product team with a whiteboard and a structured method can find the majority of significant design risks.
The four questions
The Threat Modeling Manifesto, written by a group of practitioners, defines threat modeling as analysing representations of a system to highlight concerns about security and privacy characteristics. It frames the work around four questions:
- What are we working on? Model the system.
- What can go wrong? Identify threats.
- What are we going to do about it? Decide mitigations.
- Did we do a good enough job? Validate and improve.
Step 1: model the system
Draw a data-flow diagram showing:
- External entities: users, partners, third-party services.
- Processes: your services, functions and jobs.
- Data stores: databases, caches, file storage, queues.
- Data flows: what moves between them, and how.
- Trust boundaries: where data crosses between different levels of trust — the internet and your API, your service and a third party, a user’s browser and your server.
Keep it at the level of detail needed to discuss the feature; a whiteboard sketch is often enough.
Step 2: identify threats with STRIDE
STRIDE, a mnemonic developed at Microsoft, gives six categories to consider at each element and trust boundary:
| Category | Threat | Example question | Typical mitigations |
|---|---|---|---|
| — | — | — | — |
| Spoofing | Pretending to be someone or something else | Can an attacker impersonate a user or service? | Strong authentication, mutual TLS, signed tokens |
| Tampering | Modifying data or code | Can data be changed in transit or storage? | Integrity checks, signatures, access control |
| Repudiation | Denying an action | Could a user deny placing an order? | Audit logs, non-repudiation evidence |
| Information disclosure | Exposing data | Could sensitive data leak through APIs, logs or errors? | Authorisation, encryption, data minimisation |
| Denial of service | Making the system unavailable | Can a request exhaust resources? | Rate limits, quotas, timeouts, scaling |
| Elevation of privilege | Gaining unauthorised capabilities | Can a user perform admin actions? | Least privilege, server-side authorisation checks |
Walk each data flow across a trust boundary through all six categories.
Other approaches exist, such as PASTA for risk-centric analysis, LINDDUN for privacy threats and attack trees for specific goals. STRIDE is a good default for product teams.
Step 3: decide what to do
For each threat, choose to mitigate, eliminate (remove the feature or data), transfer (for example, to a provider) or accept with documented rationale. Prioritise by likelihood and impact:
| Priority | Criteria | Action |
|---|---|---|
| — | — | — |
| High | Likely and damaging — exposure of sensitive data, account takeover | Mitigate before release |
| Medium | Plausible with moderate impact | Mitigate in the current or next iteration |
| Low | Unlikely or low impact | Accept or backlog with rationale |
Record decisions so they can be revisited when the system changes.
Turn mitigations into work the team already manages: user stories, acceptance criteria and automated tests.
Step 4: validate
- Check that mitigations were implemented and tested.
- Include threat-driven test cases in QA — for example, attempting to access another tenant’s data.
- Revisit the model when the design changes.
- Hold a short retrospective: what did we miss, and what would make the next session better?
Worked example: adding file uploads
A hypothetical SaaS product adds the ability for customers to upload documents and share them with colleagues.
Model: browser → API → storage service; a background worker scans and generates previews; share links allow access by colleagues.
Threats found:
- Spoofing: share links guessable → use long random tokens with expiry.
- Tampering: files modified after scanning → store with integrity hashes; serve from scanned storage only.
- Information disclosure: a user requests another tenant’s file by ID → server-side ownership checks; tests for cross-tenant access.
- Denial of service: very large or many uploads → size limits, per-tenant quotas, rate limits.
- Elevation of privilege: malicious file exploits the preview generator → process in an isolated worker with minimal permissions; keep libraries patched.
- Repudiation: disputes over who shared what → audit log of uploads, shares and downloads.
Each becomes a story or acceptance criterion, and the QA plan includes negative tests for cross-tenant access, oversized files and expired links.
Fitting threat modeling into agile delivery
- Lightweight sessions: 30 to 60 minutes for significant features during refinement.
- Triggers: new external integrations, new data stores, authentication changes, handling sensitive data, AI features with tools or retrieval.
- Templates: a standard diagram and threat checklist in the team’s wiki.
- Shared ownership: developers, QA, product and — where available — a security champion.
- Link to standards: map findings to the OWASP Top 10 categories for consistency.
Threat modeling AI features
AI introduces specific threats: prompt injection through retrieved content, sensitive data disclosure through answers, excessive agency through tools and data poisoning of knowledge bases. Add these to your checklist whenever a feature uses language models, retrieval or agents.
Frequently asked questions
Do we need security experts to threat model?
Not for every session. Product teams can find many issues with a simple process; involve security specialists for high-risk systems and to coach the team.
How long does a threat model take?
A focused feature session can take under an hour. A new system may need several sessions.
Which tools should we use?
A whiteboard or diagramming tool is enough to start. Dedicated tools help maintain models for larger systems.
How often should models be updated?
Whenever the design changes materially, and as part of periodic security reviews.
Sources and methodology
Facts in this article were checked against the sources below on 6 November 2026. Directory data (ratings, review counts, rate bands and team sizes) changes over time and is shown as published on the date accessed. Illustrative examples are labelled as such and are not quotes.
- Threat Modeling Manifesto — accessed 6 November 2026. Definition of threat modeling and the four key questions
Related reading
Continue your research
Want security designed in, not bolted on?
Share a feature or system you are building. We will facilitate a threat modeling session and turn the results into stories and tests.