Template — Security architecture review document

Preface: why use a template?

A template is a living document: it collects feedback over time and keeps security reviews consistent within a given security domain—such as application security, network security, or cloud security.

It carries a shared mindset for how to run the work: a common way of thinking, a dedicated process, and practices that can evolve as threats, stacks, and ownership change.

Treat this document as an initial base. Customize it for each domain and organization (scope, controls, evidence, and vocabulary) so the review matches how risk is actually owned and decided where you operate.

Use this as a checklist when preparing or recording a security architecture review: it ties business intent to technical design, explicit risks, and control coverage so reviewers and owners share the same picture.

Section 1 — Application background

Team (business owner, risk owner, tech lead, development) — Names who can decide scope, accept residual risk, and answer technical questions so the review does not stall on ownership gaps.
Application business objectives and impact — States what success looks like and what breaks if the app fails, so security priorities align with real business harm, not generic threats.
Use cases — Describes how actors use the system end-to-end so threat modeling and controls map to actual flows instead of abstract components.
Supported use cases — Lists what is in production scope today so reviewers know where assurance must be strongest.
Out-of-scope use cases — Documents what is explicitly excluded so nobody assumes protection where none was designed or funded.
Technical requirements mapped to business requirements — Shows how each major technical choice backs a business need, making trade-offs and gaps visible under scrutiny.
Design principles — Captures non-negotiable engineering rules (e.g. least privilege, zero trust boundaries) so later design changes can be checked against intent.

Section 2 — Risk analysis (business objectives and ecosystem impact)

CIA analysis — States which of confidentiality, integrity, and availability matter most for this system and lists them in explicit priority order; that ranking drives trade-offs when controls collide and forms a baseline for severity adjustment so risk and incident handling stay aligned with what you protect first.

Section 3 — Architecture review

Architecture diagram — Gives a single visual of trust boundaries and data paths so reviewers can reason about blast radius and chokepoints consistently.
In-scope components — Enumerates what this review covers (services, stores, integrations) so scope creep and orphan systems are avoided.
Assumptions (technical and business) — Records beliefs the design relies on (latency, identity source, data residency) so wrong assumptions surface before they become incidents.
Dependencies — Overview of what the application relies on externally so dependency failure or compromise is treated as first-class risk.
In-house solution dependencies — Internal platforms, shared libraries, and teams the app depends on for security-relevant behavior (auth, logging, deployment).
Cloud service dependencies — Managed services (IaaS/PaaS/SaaS) and their shared responsibility boundaries so control ownership is clear.
External dependencies (supply chain) — Third-party software, APIs, and vendors whose compromise or change could affect your system’s integrity or availability.
Asset list and data classification — Inventory of sensitive data and critical assets so protection and retention match sensitivity and regulatory expectations.
Control list mapped to CIA — Lists controls and maps each to confidentiality, integrity, and/or availability so coverage gaps (e.g. strong integrity but weak availability) are obvious.

Section 4 — Security controls

Cryptography — How data is protected in transit and at rest (algorithms, protocols, TLS versions) so reviewers can judge strength and operational feasibility.
Key management — Where keys live, who can use them, rotation, and break-glass so cryptographic controls remain trustworthy over the key lifecycle.
Database security — Access model, encryption, backups, and segregation so datastore compromise is constrained and recoverable.
Log security — What is logged, who can read logs, integrity/tamper protection, and retention so detection and forensics are trustworthy and compliant.
Security configuration — Hardening baselines, feature flags, and secure-by-default settings so drift from a safe posture is visible and reversible.

Section 5 — Resources and references

Project wiki — Canonical link to product/engineering docs so reviewers pull one current source of truth for scope and behavior.
Team wiki — Runbooks, on-call, and team-specific conventions so operational reality matches what the architecture claims.
Document revision history, reviewer, and date — Audit trail of who approved which version and when so accountability and “what we knew then” are recoverable after changes.