What Is a Security Design Review? Process, Roles, and What Good Looks Like

Every security team eventually learns the same expensive lesson: the vulnerabilities that hurt most were never in the code. They were in the design, visible on a whiteboard months before the first commit, and nobody looked.

A security design review is the structured examination of a system's architecture, before or while it is built, to find and fix security problems that scanners and code review cannot see. It examines trust boundaries, data flows, authentication and authorization decisions, and failure modes, and it ends with an explicit, recorded decision: proceed, proceed with conditions, or redesign.

That last clause separates a real review from a meeting. A review produces a decision with names attached. Everything else in this guide serves that outcome.

What a design review catches that nothing else will

Static analysis reads code. Penetration tests probe running systems. Both arrive after the design is committed, which means both are structurally blind to a whole class of problems:

• Missing trust boundaries. Two services chat freely because nobody decided they shouldn't. No scanner flags the absence of a boundary.
• Authentication that stops at the front door. The gateway checks tokens; the services behind it trust anything on the internal network.
• Data in the wrong place. Regulated data flowing into a log pipeline, an analytics store, or a third-party service that was never assessed for it.
• Blast radius nobody chose. A single compromised credential that reaches every tenant, because isolation was an aspiration rather than a design decision.
• Recovery as an afterthought. A failover plan that depends on the same identity provider that just went down.

Each of these can pass every code review and every scan, because the code correctly implements a flawed design. The review is the only control positioned early enough to catch them while the fix is a diagram edit instead of a migration.

When to run one

Not every change deserves a review, and a process that pretends otherwise gets routed around within a quarter. The triggers that earn the effort:

• A new system, service, or product surface
• A new integration with an external party
• A change to authentication, authorization, or session handling
• A new category of data, or existing data crossing a new boundary
• Anything entering scope for a compliance framework or a customer commitment

Tier the depth by business impact. A marketing microsite and a payment ledger should not get the same review, and pretending they will is how backlogs are born.

The process, step by step

Two of these steps carry most of the value and most of the friction.

Step 4, the design explanation, is where the review actually happens. The diagram shows the shape; the interview reveals the decisions. Why does this service hold its own user table? What happens to the queue when the consumer dies? Who can read that bucket? Most findings surface as the team answers a question they had not been asked before. Write the answers down: the explanation document is what the next reviewer, the auditor, and the team's own new hires will read.

Step 6, the decision, is where most processes quietly fail. A review that ends with "some good points were raised" has produced nothing. Good reviews end with a recorded verdict, conditions tracked to closure, and the approved design frozen as a baseline, so that when the architecture changes in six months, the change is visible and triggers a re-review instead of silently invalidating the old one.

Who needs to be in the room

The composition matters more than the headcount. A review run by security alone produces findings nobody owns. A review run by engineering alone produces a self-assessment. The data owner's seat is the one most often left empty, and it is the one that turns "we found a risk" into "someone with authority accepted or rejected it."

What a finished review actually contains

"We did a design review" can mean anything from a Slack thread to a signed record. Here is the checklist for the second kind:

If your current process produces all of this, you have a working review practice regardless of what tools you use. If it produces a meeting invite and a page of notes, you have review theater.

The anti-patterns

The failure modes are so consistent across companies that they deserve names:

The root cause of review theater is almost never laziness. It is friction. When capturing the architecture means redrawing it in a diagramming tool, when the design explanation means a week of document formatting, and when threat modeling means a half-day workshop nobody can schedule, the process degrades to whatever fits in one meeting. The discipline follows the friction curve, always.

How long it should take

For a typical service at moderate tier: one to two days of actual security effort, spread over about a week of calendar time so the team can answer questions asynchronously. High-tier systems justify more; low-tier systems should compress to hours or a self-service questionnaire.

If your reviews take longer, measure where the time goes. In our experience it is almost never the analysis. It is the artefact production: chasing an accurate diagram, writing the explanation document, formatting the final record. That work is real, but it is not judgment, which means it can be drafted by tooling and reviewed by humans instead of produced by hand. This is precisely the split described in Microsoft's Security Development Lifecycle and the OWASP SAMM architecture assessment practice: the discipline is stable, and the cost of practicing it is what tooling should attack.

Where tooling fits

You can run genuine design reviews with a wiki, a diagramming tool, and discipline. Plenty of good teams do, and the checklist above works the same way.

What a purpose-built platform changes is the friction economics: the diagram lives on a real canvas instead of in screenshots, the design explanation is drafted from the team interview instead of written from scratch, threats anchor to diagram elements instead of floating in a spreadsheet, and the sign-off matrix and baseline come with the workflow instead of depending on someone remembering. That is the difference between a practice that survives one motivated architect and one that survives a reorg. If you want to see the workflow end to end, this is how Alvor runs security design reviews.

Whichever way you run it: draw the boundaries, write the answers down, count the unmitigated threats, and end with names on a decision. That is the whole discipline. Everything else is tooling.