The Security Architecture Review Checklist (One You Will Actually Use)

Search for "security architecture review checklist" and you will find two kinds of results: government PDFs with two hundred items nobody has ever completed, and blog posts with eight items that fit in a tweet. Both fail the same way. The long ones die of friction; the short ones die of false confidence.

A working checklist has a different job. It is not the review; it is the coverage floor of the review: the guarantee that, whatever else your judgment finds, the standard questions were at least asked. Ours has 45 items across seven sections, and the whole thing is free to print and use. This post explains the reasoning behind it, because a checklist you understand beats a checklist you obey.

Where a checklist sits in the review

The checklist is one instrument inside a larger process. If you have not defined that process yet, start with our guide to security design reviews and come back; the short version is that a review runs from intake to a recorded, signed decision, and the checklist keeps the middle honest.

The seven sections, and why they are these seven

1. Scope and system context. The section that fails fast. If there is no diagram with explicit trust boundaries, no assigned tier, and no list of external dependencies, stop; you are not reviewing, you are guessing. Every later section assumes this one.

2. Identity and access. Most real-world compromises are identity problems wearing a technical costume, so this is the longest section. The items that do the heavy lifting: services authenticate to each other (nothing is trusted for being on the internal network), and every human path to production is enumerated and justified. Teams pass firewalls and fail these two constantly.

3. Network and exposure. Short on purpose. The attack surface is what is reachable, not what is intended, so the section reduces to enumerating ingress, denying by default, and keeping admin planes off the internet. If those are true, the rest of the network conversation is optimization.

4. Data protection. The section regulators read. Classification on every datastore in the diagram, encryption everywhere it matters, and the two items teams miss most: sensitive data hiding in logs and analytics pipelines, and retention that is stated but not technically enforceable.

5. Resilience and failure modes. Availability is a security property, and this is where the checklist overlaps deliberately with business continuity. Here is the excerpt in full, because it is the section most checklists omit entirely:

The third item is the one that catches architectures designed on a sunny day: a failover plan that authenticates through the identity provider that just went down, or a restore procedure documented in the wiki that lives on the cluster being restored.

6. Operations and detection. If the system cannot testify about its own compromise, the design is incomplete. Security-relevant events logged, logs the workload cannot alter, alerts with named owners, and a patching path with a real service-level objective. Detection designed after launch costs ten times what it costs on the whiteboard.

7. Review governance. The section that separates a review from a conversation, and the reason this checklist exists at all:

Complete sections one through six and skip seven, and you have produced an impressively thorough document that changes nothing. Governance is what gives the other 39 items consequences.

Checklist versus judgment

A fair objection: checklists produce compliance behavior, and design flaws are creative. Both true. The checklist does not find the novel attack path; the threat modeling it mandates in section seven does. What the checklist prevents is the embarrassing failure mode: the brilliant review that found a subtle race condition in the authorization flow while nobody noticed the database backups were unencrypted and world-readable.

This is also why the checklist deliberately stops at the design level. Control-by-control verification of what was actually built belongs to standards like OWASP ASVS, and the engineering discipline underneath both is laid out in NIST SP 800-160. The layers stack; they do not substitute for each other.

Get the artefact

The full checklist, all 45 items with a sign-off strip at the end, is at alvor.io/resources/security-architecture-review-checklist. Print it, fork it into your wiki, staple it to your review template; it is free and no email is demanded.

And when the paper version starts to hurt, that pain has a shape: chasing current diagrams, retyping threats into spreadsheets, chasing sign-offs over Slack, and discovering that the approved design changed two quarters ago. That shape is what Alvor's security architecture platform exists to remove; every box on the printout is a workflow step there, with the baseline and the named sign-offs built in.

Either way, run the review. The checklist just makes sure that when you say a system was reviewed, the sentence means the same thing every time.