Security work is most effective while architecture is still movable. Once identity, data and trust assumptions are embedded, improvement becomes slower and more expensive.
Start with consequence
Identify the information and actions that would create material harm if exposed, altered or unavailable. This creates a sharper basis for design than a generic control list.
Draw the trust boundaries
Show where users, services, suppliers and administrative functions cross from one level of trust to another. Each boundary should have an explicit identity and authorisation decision.
A threat model is useful when it changes an engineering choice—not when it merely records one.
Make evidence part of the system
Important actions need proportionate logging and ownership. Evidence should help operators answer what happened without collecting unnecessary sensitive data.
Keep the decisions visible
Record material assumptions and trade-offs so future teams understand why the system behaves as it does. Security architecture is a living part of engineering ownership.