Engineers should ask for a security review when a change adds a new way in, a new place sensitive data lives, or a new trust relationship. Everything else can be handled with the team's normal checks. A three tier rule makes that clear, so reviews are rare enough to be taken seriously and early enough to be useful.
Why a rule beats a policy
If every change needs approval, reviewers drown and engineers learn to route around them. If nothing does, serious design mistakes land in production. The goal is a rule short enough to remember and specific enough to apply without asking.
Tier 1: self serve
Most changes. Bug fixes, interface tweaks, copy changes, refactors that do not move boundaries. The team's definition of done and automated checks are enough. No security contact is needed.
Tier 2: quick look
Ask for a short asynchronous review, roughly a conversation or a comment thread, when the change does any of these.
- Adds a new endpoint that returns user specific data.
- Introduces a new third party service or library with network access.
- Changes how a file, message or webhook from outside is processed.
- Alters roles or permissions in a small way.
The ask should take the author five minutes: a link to the pull request and two sentences on what could go wrong. Agree an expected response time, such as one working day.
Tier 3: full review
Book design time before building when the change does any of these.
- Introduces a new authentication method or identity provider.
- Stores a new category of regulated or highly sensitive data.
- Opens a service to the public internet for the first time.
- Lets customers run code or upload content that is executed.
- Gives one system broad access to others, such as a new integration with admin scope.
A full review is a design conversation with a short threat model, ideally before significant code exists. See when to threat model a feature for a trigger list.
Make it easy to start
Put the tier questions in the design document template and the pull request template. Provide one place to ask, whether a channel, a form or a label. If asking takes more than a minute, people will not.
Close the loop
Record the outcome of each Tier 2 and 3 review on the ticket: what was raised, what changed, what was accepted. Over time, review the pattern. If the same advice repeats, turn it into a checklist item or a shared library so it stops needing a human.
Calibrate with experience
Look back each quarter at changes that caused trouble. Were they in the right tier? If a Tier 1 change caused an incident, widen the Tier 2 triggers. If reviewers spent time on trivial requests, narrow them. Tiers are a living document.
Quick check
Who decides which tier a change belongs in?
The author, using the written triggers. When unsure, they go one tier up and ask. Reviewers should welcome that rather than complain about it.
How fast should a Tier 2 review come back?
Agree a target, such as one working day, and publish it. A review that arrives after the merge protects nobody.
Last reviewed: 19 October 2026.
