ALVOR
Platform
PricingCompare
Advisory
AboutBlog
Get Demo
ALVOR
Platform
PricingCompare
Advisory
AboutBlog
Get Demo

Resources · Checklist

The security architecture review checklist.

Forty-five verifiable statements across seven sections, from scope to sign-off. Print it, walk it, and let the tier decide which items apply. Free to use and share.

Read the guide

Security architecture review

v1.0 · July 2026 · alvor.io

The checklist

How to use it: assign a business impact tier first, then walk the sections. Not every item applies to every system; an item you skip should be skipped on purpose, out loud. An unchecked box is not a failure, it is a finding. The review is complete when section seven, not section one, is done.

01

Scope and system context

You cannot review what you cannot see. This section fails fast.

  • The system's purpose, users, and business criticality are stated in one paragraph
  • A business impact tier has been assigned, and the review depth matches it
  • An architecture diagram exists showing every component, datastore, and data flow
  • Trust boundaries are drawn explicitly, including between internal services
  • All external dependencies and third-party integrations are enumerated
  • The environments in scope are named (production, staging, DR), with differences noted
02

Identity and access

Most real-world compromises are identity problems wearing a technical costume.

  • Every human access path to production is enumerated and justified
  • Services authenticate to each other; nothing is trusted for being on the internal network
  • Authorization is enforced at each service, not only at the gateway
  • Secrets live in a managed store; none are static in code, images, or configuration
  • Access follows least privilege, with roles mapped to actual duties
  • Break-glass access exists, is logged, and raises an alert when used
  • Session and token handling are defined: expiry, revocation, and scope
03

Network and exposure

The attack surface is what is reachable, not what is intended.

  • Ingress points are enumerated; everything else is deny-by-default
  • Admin planes and internal dashboards are not internet-exposed
  • Network segmentation separates tiers with different trust levels
  • Egress is restricted and monitored where feasible
  • Third-party connectivity (VPNs, peering, webhooks) is inventoried, with owners
04

Data protection

Data is the thing the attacker wants and the regulator asks about.

  • Every datastore in the diagram carries a data classification
  • Sensitive and regulated data locations are known, including logs and analytics
  • Encryption in transit everywhere; at rest for anything above public
  • Key management is defined: rotation, access, and custody
  • Retention and deletion are specified and technically enforceable
  • Residency requirements are identified and satisfied by the design
  • Backups are encrypted, access-controlled, and restore-tested
05

Resilience and failure modes

Availability is a security property. Design the bad day before it happens.

  • Single points of failure are identified, then removed or accepted by name
  • The failure of each critical dependency has a designed response
  • Recovery paths do not depend on the components that just failed
  • RTO and RPO are stated and inherited from the business process the system serves
  • Degraded modes are defined: what still works, and what fails closed
  • Capacity and denial-of-service posture are specified: rate limits, quotas, surge behavior
06

Operations and detection

If the system cannot testify about its own compromise, the design is incomplete.

  • Security-relevant events are logged: authentication, authorization failures, privilege changes, sensitive data access
  • Logs reach a store the workload cannot alter, retained long enough to investigate
  • Alerts have named owners and a response path
  • A patching and dependency-update path exists, with a service-level objective
  • The system produces the evidence an intrusion investigation would need
  • Runbooks exist for the most likely failure and compromise scenarios
07

Review governance

This section is what separates a review from a conversation.

  • Threats are anchored to diagram elements and mapped to mitigating controls
  • Unmitigated threats are counted, visible, and individually accepted by a named owner
  • Architecture decisions, including rejected alternatives, are recorded
  • The verdict is recorded: proceed, proceed with conditions, or redesign
  • Conditions are tracked as work items with owners and dates
  • Sign-offs are named individuals: security, engineering, and the data or business owner
  • The approved design is baselined, so post-approval drift is detectable
  • Re-review triggers are written down: architecture change, new data category, new integration

Sign-off · named individuals, not teams

Security reviewer

Name · Date

Engineering owner

Name · Date

Data / business owner

Name · Date

Verdict: proceed · proceed with conditions · redesign. Baseline the approved design; re-review on architecture change, new data category, or new integration. Checklist by Alvor (alvor.io/resources/security-architecture-review-checklist).

The checklist, as software

Every box on this page is a workflow step in Alvor.

Diagrams on a live canvas, threats anchored to elements, named sign-offs, and a baseline that catches drift. The checklist stops being paper.

See the workflowGet a demo
ALVOR

Security architecture, management, and compliance: connected into one source of truth.

Security, Simplified.

Platform

  • Overview
  • AI Assistant
  • Security Architecture
  • Assets
  • Components
  • Dependency Mapping
  • Data Governance
  • Secure by Design
  • Security Design Review
  • Threat Modeling
  • Risk
  • Compliance
  • Policy
  • Program
  • Business Continuity
  • TPRM

Solutions

  • Startups
  • Mid-Market
  • Enterprise

Company

  • About
  • Advisory
  • Compliance
  • Blog
  • Security
  • Pricing
  • Compare

Legal

  • Privacy
  • Cookie Policy
  • Terms
  • Disclosure

© 2026 Alvor, Inc. All rights reserved.

LinkedIn