A change needs a security design review when it adds a new trust boundary, handles new sensitive data, changes how users authenticate or are authorized, introduces a new external dependency or service, or changes how secrets or keys are handled. If none apply, a normal code review is usually enough.
Why a rule beats a feeling
Without a rule, design reviews either happen for everything, which burns time, or only when someone remembers. A short list of triggers makes the decision quick and consistent.
NIST's Secure Software Development Framework describes design review in practice PW.2.1: a qualified person not involved in the design, or automated processes in the toolchain, review the design to confirm it meets security requirements and addresses identified risks. Findings are recorded as artifacts. The framework leaves the choice of when to review to the organization, which is where triggers come in.
The five triggers
| Trigger | Example |
|---|---|
| New trust boundary | A new public API, a partner integration, a webhook |
| New sensitive data | Storing identity documents, health or payment data |
| Authentication or authorization change | New login method, new role, changed permissions |
| New dependency or service | A new SDK, hosted service or data store |
| Secrets and keys | New way of storing, rotating or sharing credentials |
New trust boundary
Anywhere data crosses from one level of trust to another is a place to look. OWASP's threat modeling cheat sheet describes data flow diagrams as a common way to see these crossings.
Authentication and authorization
Mistakes here have the widest impact. A change in who can do what deserves a second pair of eyes before code is written.
A fast decision path
- Ask the five trigger questions at refinement.
- If any answer is yes, request a design review before the story enters the sprint.
- If none are yes, note "no trigger" in the story and continue.
- If unsure, ask the tech lead or security champion for a five minute opinion.
What a review looks like
Keep it proportionate. For a small change, a 20 minute conversation around a sketch is enough. For a major new system, a fuller threat model is better. Answer the four questions from the Threat Modeling Manifesto: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job.
Record the result in the story or the architecture decision record: the risks found, the decisions made, and the follow-up work.
Adjust the triggers over time
Review the list after each security issue. If a bug slipped through that no trigger would have caught, add one. If a trigger fires constantly with nothing found, narrow it. A good list is short and earns its keep.
What if the team disagrees
If the author thinks no review is needed and the reviewer disagrees, default to doing the review for a first pass, and capture why it was or was not useful. Over time, the notes show which triggers need tuning.
Not a replacement for code review
A design review looks at the plan. Code review looks at the implementation. Both are needed, and neither replaces testing. A design that was fine can still be implemented with a flaw.
Safeguard can help by inventorying the dependencies and services in use, so the "new dependency" trigger is easy to check. A free scan is at gold.safeguard.sh/scan.
Quick check
Who should do the design review?
Someone who was not involved in the design, such as another tech lead or a security champion, as NIST SSDF practice PW.2.1 describes.
How long should a design review take?
Proportionate to the change. A small change can take 20 minutes. A major new system needs a fuller threat model.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1
- Threat Modeling Manifesto
- OWASP Threat Modeling Cheat Sheet
Last reviewed: 19 October 2026.
