Set turnaround by risk tier and publish it. Low risk changes need a checklist, not a meeting. Medium risk gets a review within a few working days. High risk, such as new authentication or sensitive data flows, gets a design review early. Speed comes from deciding what does not need review.
Why reviews become a bottleneck
When every feature waits for the same small team, queues form and launches slip. Engineering then starts skipping the review or springing it on security at the last minute. Both outcomes are worse than a clear, fast tiered process.
Tier by risk, not by size
| Tier | Examples | Process | Turnaround to publish |
|---|---|---|---|
| Low | Copy changes, internal UI, no new data or access | Self serve checklist in the pull request | Same day, no human wait |
| Medium | New endpoint, new integration, new dependency | Async review of a short design note | A few working days |
| High | Authentication, payments, personal data, new external exposure | Early design review plus pre release check | Booked at design time |
Pick numbers that your team can meet, and report how often you meet them. A target you miss every month teaches people to ignore it.
The self serve checklist
Keep it to ten items or fewer. Cover the things that cause most issues: input validation, authorization checks on every new endpoint, secrets handling, new dependencies and logging of sensitive data. If every box can be ticked honestly, the change proceeds without waiting.
NIST's Secure Software Development Framework describes practices such as reviewing the design for security requirements and reviewing code. It is a useful reference for what a review should cover, and it leaves the process to you.
Pull review earlier
The cheapest time for a review is before the code exists. Ask authors to add a short security note to the design document for medium and high tier work. A reviewer can read it in ten minutes and flag the issue before a sprint is spent on it.
Automate the first pass
Automated checks on the pull request handle known classes of issues, which frees reviewers for design questions. Reviewers should spend time on authorization logic, data flows and abuse cases that tools do not judge well.
Measure the queue
Track time from request to first response and to decision, by tier. If medium tier waits grow, add a second reviewer or move more items into the checklist tier.
Quick check
Who decides the tier?
The author proposes, using a short rubric, and the reviewer can raise it. Make raising a tier easy and lowering it rare.
What if a review finds a serious issue late?
Treat it as a signal that the design review step was skipped or too thin, and fix the process as well as the feature.
Sources
Last reviewed: 19 October 2026.
