Start with what must remain true
List the assets and outcomes the product must protect: account ownership, confidential records, money movement, service availability, or the integrity of a release. Then sketch how data crosses browsers, services, queues, vendors, and administrative tools.
Trust boundaries deserve attention because assumptions change across them. A value validated in one service may arrive through a different path later, while a queue consumer may treat internal traffic as automatically trusted.
Tell attacker stories
For every sensitive flow, ask how an attacker could impersonate a participant, alter data, repeat an action, exhaust a resource, or hide evidence. Connect each plausible story to a design control, a test, or an explicit accepted risk.
Keep the session close to the architecture decision. A short model before choosing identity boundaries or storage ownership can change the design; a large report after implementation mostly produces backlog.
- Name assets, entry points, trust boundaries, and privileged operations.
- Include support tools and recovery paths, not only customer-facing screens.
- Assign every mitigation to an owner and verification method.
- Record assumptions that would invalidate the model if they change.
Keep the model alive
Update the model when a new data flow, identity provider, integration, or privilege boundary appears. It does not need perfect notation; it needs enough structure for the next engineer to challenge an old assumption.
A useful model changes a decision, creates a test, or documents a conscious risk. Count those outcomes instead of the number of diagrams produced.