Design Review Trigger
The stated conditions under which a change requires security review, so that review capacity goes to what warrants it and everything else proceeds.
Two arrangements fail predictably. Reviewing everything exhausts the security team and turns the review into a queue that delivery teams route around. Reviewing nothing means the significant changes are missed alongside the trivial ones.
Explicit triggers resolve it. Review is required when a change introduces a new trust boundary, handles a new class of sensitive data, adds an internet-facing surface, changes authentication or authorisation, introduces a new third-party dependency with data access, or alters the network boundary. Everything else proceeds on automated checks alone.
The list must be short, unambiguous and self-assessable — a team should be able to determine in a minute whether they need a review, without asking. If determining it requires a conversation with security, the trigger has failed and the queue has returned.
The other half is that a triggered review must be fast enough to be worth respecting. A review that takes three weeks will be avoided, and the avoidance will be rational. Committing to a turnaround, and staffing to meet it, is what makes the trigger list credible rather than aspirational.