Match review depth to risk. Routine changes need one reviewer, changes to sensitive paths need two, and changes that create a new trust boundary or touch authentication or cryptography need the security team. A written tier table makes this predictable and stops every change getting the heaviest process.
Why one rule for everything fails
If every pull request needs the same review, one of two things happens. Either the process is light enough to move fast and risky changes get too little attention, or it is heavy enough for the risky ones and everything else crawls. Google's public guidance warns that slow reviews reduce team velocity and push people to submit lower quality changes. A tiered approach avoids that trade.
The OWASP Secure Code Review Cheat Sheet points in the same direction with a hybrid approach: risk-based scheduling that combines baseline reviews for high-risk components with diff-based reviews for routine changes, and trigger-based reviews that escalate when a significant concern appears.
A three tier model
| Tier | Typical change | Review |
|---|---|---|
| 1, routine | Copy, styling, internal refactor, tests, small bug fix | One reviewer from the team |
| 2, sensitive | Anything touching permissions, personal data, payments, file handling, parsing, or a new dependency | Two reviewers, one with security context such as a champion |
| 3, high risk | Authentication, sessions, cryptography, new trust boundary, new external integration, removal of a control | Security team reviews, plus a second developer |
The exact lists are yours to write. The point is that they exist, are short, and are visible.
How a change gets its tier
Make assignment mechanical where you can.
- By path. A code owners file maps sensitive directories to the right reviewers. A change under the auth directory automatically requests the security team.
- By label. Authors add a label when the change adds an endpoint, a permission or a dependency.
- By checklist. The pull request template asks three yes or no questions: does this touch input from outside, permissions, or secrets? Any yes moves it up a tier.
- By reviewer judgment. Any reviewer can move a change up a tier. Nobody can move it down.
That last rule is a simple safety valve.
Keep tier 1 fast
Most pull requests belong here. Keep the bar clear and the turnaround short. Google's guidance says one business day is the maximum time to respond to a review request, and that individual responses should be quick even when the whole process takes longer. If tier 1 is slow, people will try to label risky changes as routine to escape it.
Guard against tier gaming
Authors under pressure may split a risky change into harmless looking pieces. Watch for it. Google's guidance supports small, self-contained changes, so splitting is good, but the tier should follow the combined effect. Ask in the description: "Is this part of a larger change that touches X?"
Escalation triggers
The OWASP cheat sheet's trigger based idea is useful. Examples of triggers that move a change up:
- A reviewer cannot tell whether a check exists.
- The change touches code with no tests.
- A scanner finding is suppressed on a sensitive path.
- The author is new to the area.
Record the tier
Put the tier in the pull request as a label. It gives you data: how many changes land in each tier, how long each takes, and whether tier 3 reviews find more than tier 1. That answers the question "is the process worth the cost?" with numbers instead of opinion.
Try it yourself
Open the demo to see how policy gates can route or block pull requests based on rules. Think about which of your tier rules could be enforced automatically.
Click through it at your own pace, or open it full screen.
Safeguard's policies, gates and guardrails can enforce rules such as requiring review on sensitive paths or flagging new dependencies at pull request time.
Quick check
Should small teams use tiers?
Yes, in a lighter form. Even a two person team benefits from agreeing which changes need both of them.
Who writes the tier table?
Engineering leads with the security team. Review it each quarter against the incidents and near misses you saw.
Sources
- OWASP Secure Code Review Cheat Sheet
- Google Engineering Practices: Speed of code reviews
- Google Engineering Practices: Small CLs
Last reviewed: 19 October 2026.
