Guides

Threat Modeling Checklist: 40 Questions for Every Design Review

Published October 10, 2026 ยท 11 min read

Most threat models don't fail because the team picked the wrong methodology. They fail because someone forgot to ask the question that mattered: who can call this endpoint without logging in, what happens when the queue fills up, or who signed off on accepting that risk last year. A checklist won't make anyone an expert, but it reliably stops the obvious things from being missed.

This one has 40 questions in three parts: before the session, during it and after it. The questions in the middle follow STRIDE, because that's how most teams sweep a design, plus trust boundaries, third parties and privacy, which STRIDE alone tends to underweight.

How to use it: don't read all 40 questions against the whole system. Draw a data flow diagram first, then take one element at a time and run through the STRIDE questions that apply to it, starting with anything that touches a trust boundary. "Not applicable, next" is a perfectly good answer. Every "yes, that could happen" becomes a threat with a score, a decision and an owner.

Before the session: scope

Ten minutes on these saves an hour of arguing about what's in scope halfway through.

  1. What exactly are we modeling? A feature, a service, or the whole product? Write it down in one sentence.
  2. What is out of scope, and why? Saying "the payment provider's internals are out of scope" is fine. Silently ignoring the admin console is not.
  3. What are we protecting? List the assets: customer data, credentials, money movement, availability, the integrity of a decision the system makes.
  4. Who would want to attack it, and what would they want? Name the realistic threat actors, including a malicious insider and a curious customer, not just "hackers".
  5. Is there a current diagram everyone agrees is accurate? If the people in the room disagree about the architecture, fix that before looking for threats.
  6. Who needs to be in the room? At least one person who built it, one who runs it, and someone who can make a decision about risk.

During the session: the STRIDE sweep

Ask these per element of the diagram, not of the system as a whole.

Spoofing: can something pretend to be something it isn't?

  1. How does this component know who is calling it? And is that check made on the server, not only in the client?
  2. Can credentials or tokens be stolen, guessed or replayed? Think about credential stuffing, phishing, tokens in logs or URLs, and tokens that never expire.
  3. Do services authenticate to each other, or does anything inside the network get trusted automatically?
  4. Can an incoming webhook, callback or message be forged? Is its signature verified, and are replays rejected?

Tampering: can data or code be changed without permission?

  1. Can a user change an ID, price, role or quantity in a request and have the server accept it?
  2. Is untrusted input ever interpreted as code or a query? SQL, templates, shell commands, file paths, deserialisation, and for AI features, prompts.
  3. Can data be modified in transit or at rest by someone who shouldn't be able to? Think about unencrypted links and shared buckets.
  4. Could someone change what gets deployed? Build pipelines, dependencies and release artefacts are part of the system; see threat modeling your CI/CD pipeline.

Repudiation: could someone act and later deny it?

  1. Are security-relevant actions logged with who, what and when? Logins, permission changes, exports, payouts, deletions.
  2. Can the people being logged alter or delete the logs? An admin who can wipe the audit trail has no audit trail.
  3. Would we be able to reconstruct what happened after an incident, from the logs we actually keep and for as long as we keep them?

Information disclosure: what could leak, and to whom?

  1. Can one customer ever see another customer's data? Check every query, cache, search index, export and background job; see multi-tenant threat modeling.
  2. What do error messages, logs and debug output reveal? Stack traces, tokens, personal data and internal hostnames have a habit of ending up there.
  3. Where are secrets stored, and who can read them? Keys in code, environment variables visible to too many people, shared credentials.
  4. What leaves the system to third parties? Analytics, error tracking, support tools and AI services all receive data, sometimes far more than they need.

Denial of service: what happens when it's overwhelmed?

  1. What can an unauthenticated caller make expensive? Login, password reset, search, file processing, report generation.
  2. Are there rate limits, timeouts and size limits on every entry point, including the ones meant only for partners?
  3. If one dependency goes down, what else fails with it? And is there any single component whose loss stops everything?

Elevation of privilege: can someone get more access than they should?

  1. Is authorisation checked on every request, or only when the page loads? Try every endpoint as a lower-privileged user.
  2. Can a user change their own role, team or tenant through a profile update, invitation or self-service flow?
  3. Do services and jobs run with more permissions than they need? Over-broad cloud roles turn one bug into full access.
  4. What can support staff and admins do, and is any of it protected by more than a single password?

During the session: boundaries, third parties and privacy

Trust boundaries and third parties

  1. Where does data cross a trust boundary? Internet to app, app to database, your system to a vendor's. Each crossing is where most real threats live.
  2. What happens if a vendor or integration is compromised? What could it read, change or trigger in your system? See threat modeling vendor integrations.
  3. Which dependencies could execute code in your environment, and how would you know if one changed? Supply chain threats rarely appear on a diagram unless someone asks.
  4. Is anything trusted just because it's "internal"? Internal networks, admin tools and message queues are frequently the softest targets; see zero trust.

Privacy

  1. What personal data does this collect, and is all of it needed? Data you don't hold can't leak.
  2. Could separate datasets be combined to identify someone, even when each one looks anonymous on its own?
  3. Can people find out what you hold about them, and have it deleted, including from backups, logs and third parties? LINDDUN covers these privacy threats systematically.

After the session: decide and record

This is the part most teams skip, and it's the part an auditor, or the next incident review, will ask about.

  1. Is every threat written as a risk, in the form "[actor] can [action] because [weakness], resulting in [impact]", rather than as a vague worry?
  2. Has each one been scored on likelihood and impact, in the context of this system rather than by copying a generic severity? Our post on the CVSS trap explains why that matters.
  3. Does each threat have a treatment decision: mitigate, avoid, transfer or accept? An accepted risk with no name next to it isn't a decision; see prioritising a backlog of threats.
  4. Does each threat have an owner, and do the mitigations exist as tickets someone will actually work on? Our guide to writing mitigations auditors accept covers the wording.
  5. Do we know what will trigger the next review? A new integration, a new data type, a change to authentication, or a date in the calendar; see when to re-threat-model.

Making the checklist stick

  • Timebox it. Ninety minutes for one feature is enough. If you run out of time, the elements you didn't reach should be the ones furthest from a trust boundary.
  • Record answers where the design lives. Threats in one person's notebook get lost. Put them next to the diagram, and in a risk register that leadership reads.
  • Prune it for your stack. A team building mobile apps will add questions about local storage and deep links; see threat modeling a mobile app. Teams building AI features should add prompt injection and tool misuse; see threat modeling AI agents.
  • Revisit it after incidents. If something went wrong that the checklist didn't catch, add the question that would have.

Frequently asked questions

What is a threat modeling checklist?

A list of questions a team works through when reviewing a design, so that common threats aren't missed. It complements a method such as STRIDE: the method structures the review, and the checklist makes sure each area gets asked about.

Should we ask every question for every element?

No. Apply the STRIDE questions element by element and skip the ones that don't apply. The scoping questions are asked once per session, and the decision questions once per threat.

How long should a threat modeling session take?

About ninety minutes for a single feature or service is a good default. Larger systems are better split into several sessions, each with its own diagram and scope.

Is a checklist enough on its own?

It's a strong start, but it's best paired with a diagram of the system, so questions are asked about real components, and with a register where every threat gets a score, a decision and an owner. For the bigger picture, see threat modeling methodologies compared.

Need a starting point for the diagram and the register? The free threat modeling templates include a data flow diagram, an attack tree and a STRIDE risk register. Running this with a group for the first time? Read how to run your first threat modeling workshop.

Related articles

Guides How to Run Your First Threat Modeling Workshop Glossary What Is STRIDE? Guides Threat Modeling Methodologies Compared

Turn the answers into a living threat model

In ThreatTree you draw the diagram, record each threat as an attack tree step tagged with its STRIDE category, and score it on likelihood and impact. Every scored threat lands in a risk register with a treatment plan and an owner, so questions 36 to 40 are answered as you go.

Get started free

Not ready to sign up? Get new threat-modeling guides by email instead.