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.
Map assets and sensitive actions
Begin with the things the organisation cannot afford to misunderstand. That includes data, but also actions: approving a payment, changing a permission, exporting a customer record, rotating a credential or overriding an automated decision. Rank them by confidentiality, integrity and availability consequences. The aim is not a perfect inventory. It is a shared view of what deserves stronger design treatment.
For each important asset or action, name an owner and describe the acceptable recovery path. A system that is secure only while every dependency behaves normally is not resilient. Teams should know what happens when an identity provider is unavailable, a supplier response is delayed, a message is delivered twice or an administrator makes an error.
Resolve identity and access early
Authentication is only the entrance. Architecture must also answer who may perform each sensitive action, in which context, with whose approval and for how long. Administrative access deserves its own model rather than a hidden super-user role. Service identities, scheduled jobs and support tooling need the same clarity as human users.
Prefer permissions aligned to business responsibility. Record where separation of duties matters, how access is reviewed and how it is removed. If these questions wait until interface development, the product often inherits roles that are convenient for code but unsafe or confusing for operations.
Model abuse, failure and recovery
Walk through credible misuse and failure paths with product, engineering and operational people together. Ask how an attacker, compromised account, careless operator or faulty integration could reach a harmful outcome. Then decide whether prevention, detection, containment or recovery is the right response. Not every risk needs another control, but every material risk needs an owner and an explicit decision.
Supplier boundaries matter here. Document which guarantees belong to the application and which depend on hosting, identity, payments, messaging or other services. Capture the response when a supplier guarantee is not met. This avoids an architecture that silently delegates accountability.
Design useful evidence
Logs should answer operational and security questions without becoming an uncontrolled copy of sensitive data. Define the events, actor identifiers, timestamps, correlation references and retention needs that support investigation. Protect audit data from casual alteration and make sure somebody is responsible for reviewing the signals that matter.
Create a decision record
Keep a concise security decision record alongside the architecture. It should state the context, chosen approach, rejected alternatives, assumptions, owner and review trigger. Revisit it when data sensitivity, user groups, integrations or deployment boundaries change.
A practical pre-development checkpoint
- Important assets and harmful actions are named.
- Trust boundaries and external dependencies are drawn.
- Human, service and administrative identities have clear permissions.
- Likely abuse and failure paths have owners and responses.
- Logging supports investigation without unnecessary collection.
- Material decisions, assumptions and review triggers are recorded.
This checkpoint does not replace detailed testing. It makes later testing more valuable because the system has a deliberate security model to test.