A security team of six supports two hundred engineers. Design reviews are a bottleneck. What do you do?
Show the full answer Hide the answer
Why the queue exists
Reviewing everything means capacity is the constraint, and the queue grows with engineering headcount. Teams respond by skipping the review or by scheduling it after the design is finished, when changing it is expensive — so the bottleneck degrades both throughput and the quality of the reviews that do happen.
The interventions, in order of leverage
- A paved road that is secure by default. Standard patterns for authentication, secret handling, data access and network configuration mean most services need no bespoke review — the review already happened, once, when the pattern was built.
- Triage by risk. Most changes do not need a review. A short self-assessment routes the minority that do, with clear triggers: new external exposure, new data classification, a change to authentication or authorisation, a new third party.
- Automated checks for the mechanical, so review time is spent on design judgement rather than on finding a hardcoded credential.
- Security champions embedded in teams, trained and supported, handling the routine and escalating the genuinely novel.
- Published patterns and anti-patterns, so teams can self-serve the common answers.
What must remain centralised
Novel architectures, changes to the security controls themselves, high-consequence data flows, and anything crossing a trust boundary in a new way. The goal is not fewer reviews but reviews concentrated where judgement is genuinely required.
The measure to track
Not reviews completed, but the proportion of services on the paved road — the number that never needed a review. Reviews completed rewards throughput on the bottleneck; paved-road adoption rewards removing it, and they lead to opposite investments.