Set the scope, and list assets and entry points before hunting threats

A threat model that tries to cover everything finishes nothing. The Manifesto suggests iterations scoped to manageable portions of the system. Before looking for threats, write down three short lists:

1. Scope: what is in this session and what is not. "The new refund flow, from the support tool to the payment provider. Not login, not the mobile app."
2. Assets: what an attacker would want or what you must protect. Customer data, money movement, admin access, API keys, availability during peak hours, your reputation.
3. Entry points: where input arrives. Public endpoints, file uploads, webhooks, message queues, admin screens, email parsing, LLM prompts.

Assets tell you what matters most, so you can rank threats later. Entry points tell you where to start looking.

Write down assumptions too: "the payment provider verifies card ownership", "only staff on SSO can reach the support tool". Assumptions are where many incidents start, and recording them lets the next review check whether they are still true.

scope: Refund flow (support tool -> Orders API -> payment provider)
out_of_scope: [login, mobile app, invoice PDFs]
assets:
  - money movement (refund amount and destination)
  - customer PII in order records
  - support agent sessions
entry_points:
  - POST /admin/refunds (support tool, SSO)
  - payment provider webhook /hooks/refund-status
assumptions:
  - support tool is only reachable via SSO with MFA
  - provider signs webhooks with HMAC-SHA256