Review Checklist
A concise checklist for reviewers. Print it, copy it into your review template, or hand it to newer reviewers as a primer.
Pre-review (2 minutes)
Section titled “Pre-review (2 minutes)”Confirm the document is worth reviewing before you start:
- The document is at a declared Documentation Depth (Minimum / Recommended / Comprehensive)
- The declared depth matches the Business Criticality tier (Tier 1/2 → Comprehensive; Tier 3/4 → Recommended; Tier 5 → Minimum)
- The author, owner, version, and status are populated
- There is a named business owner in Section 2 Stakeholders
- No sections are left as placeholder text (
[...],TBD)
If any of these fail: send back to the author before spending more time on review.
Section 0 — Document Control
Section titled “Section 0 — Document Control”- Version and change history show active maintenance
- Authors and contributors are named
- Classification is set and appropriate to the content
Section 1 — Executive Summary
Section titled “Section 1 — Executive Summary”- The Solution Overview is understandable to a non-technical reader
- Business drivers are specific (what, when, consequence of inaction)
- Strategic alignment is credible — not boilerplate
- Shared services reuse has been considered
- Scope boundaries are clear (in / out / related)
- Criticality tier is justified, not defaulted
Section 2 — Stakeholders & Concerns
Section titled “Section 2 — Stakeholders & Concerns”- Business owner is named
- Security Architect / CISO office is listed for Tier 1-3 solutions
- Data owner / DPO is listed if personal data is in scope
- Operations / SRE lead is listed for production-bound solutions
- Regulatory context is declared (UK GDPR, PCI-DSS, DSPT, etc.)
Section 3 — Architectural Views
Section titled “Section 3 — Architectural Views”3.1 Logical
Section titled “3.1 Logical”- Components are decomposed meaningfully (not “backend” and “frontend”)
- Each component has a named owner
- Technology choices are specific (name + version where relevant)
- Design patterns, where used, have rationale
3.2 Integration & Data Flow
Section titled “3.2 Integration & Data Flow”- Every internal interface is documented (protocol, auth, direction, encryption)
- Every external integration is documented
- Synchronous vs asynchronous is explicit
- Error handling and retry behaviour is covered for critical paths
3.3 Physical
Section titled “3.3 Physical”- Hosting venue, region, and service models are stated
- Environments are listed (dev / test / staging / prod / DR)
- Network connectivity is documented (internet-facing? VPN? peering?)
- Perimeter protection is addressed (WAF, DDoS) where relevant
3.4 Data
Section titled “3.4 Data”- Every data store is classified (Public / Internal / Confidential / Restricted)
- PII and sensitive personal data are explicitly identified
- Retention periods are stated
- Encryption at rest is documented with key management choice
- Data sovereignty is addressed where relevant
3.5 Security
Section titled “3.5 Security”- Business impact assessment (CIA) is populated
- Authentication model is documented for each access type
- Authorisation model is documented (RBAC / ABAC etc.)
- Encryption at rest AND in transit are addressed
- Secret management is documented (never hardcoded)
- Security monitoring and SIEM integration are addressed
- Threat model is present for Comprehensive-depth documents
3.6 Scenarios
Section titled “3.6 Scenarios”- Key use cases are documented
- Architecture Decision Records are captured with alternatives
- Decisions reflect the design in the other views
Section 4 — Quality Attributes
Section titled “Section 4 — Quality Attributes”- Operational Excellence: logging, monitoring, alerting, runbooks
- Reliability: RTO/RPO targets with justification; DR strategy; backup
- Performance: targets with measurement method; growth projections for Tier 1-2
- Cost: analysis performed; capex/opex; monitoring enabled
- Sustainability: at least acknowledged; carbon metrics for Comprehensive depth
Section 5 — Lifecycle
Section titled “Section 5 — Lifecycle”- CI/CD pipeline is documented (SAST, DAST, SCA, container scanning as appropriate)
- Migration plan is documented (if applicable)
- Test strategy covers unit, integration, performance, security
- Release management: cadence, approval, rollback
- Operations and support: hours, model, escalation
- Resourcing: skills assessed, gaps addressed
- Exit planning: for cloud and third-party dependencies
Section 6 — Decision Making & Governance
Section titled “Section 6 — Decision Making & Governance”- Constraints are documented with category (regulatory, technical, commercial, time, organisational)
- Assumptions have named owners and closure evidence
- Risks have severity, likelihood, owner, mitigation, residual risk
- Dependencies are tracked with status
- Issues (if any) have resolution plans
- Guardrail exceptions are declared and justified
- Architecture Decision Log is maintained
- Compliance traceability is populated for Comprehensive depth
Section 7 — Appendices
Section titled “Section 7 — Appendices”- Glossary covers all acronyms used in the document
- Reference documents are listed with URLs
- Approval sign-off has named approvers with dates
Cross-cutting checks
Section titled “Cross-cutting checks”Consistency
Section titled “Consistency”- Logical View components appear in Integration, Physical, Data, and Security
- Technology choices are consistent across views
- ADRs reflect the design shown in the views
- Business criticality tier matches quality attribute targets
- Compliance traceability references regulations mentioned in Section 2
Clarity
Section titled “Clarity”- Can a reviewer read this without asking the author questions?
- Are acronyms defined in the glossary?
- Are tables meaningful (not boilerplate)?
- Are diagrams present where the standard expects them?
Credibility
Section titled “Credibility”- Risk mitigations actually mitigate the risks
- Assumptions have owners and target closure dates
- Non-functional targets are grounded in business needs
- Cost estimates show their workings
- Self-assessed compliance scores look plausible given the content
Decision
Section titled “Decision”After completing the checklist, record your decision:
- Approved — ready to proceed
- Approved with conditions — conditions listed in the governance record
- Deferred — more information required (specify what)
- Rejected — fundamental issues to resolve
Record your decision in Section 7.4 Approval Sign-Off with date and any conditions.
Tips for reviewers
Section titled “Tips for reviewers”- Start with Section 1. If the Solution Overview doesn’t make sense, stop — send back to the author.
- Check the tier first. If it’s mismatched with the depth, much of your review time is wasted.
- Spot-check three random tables. If they’re boilerplate, the rest likely is too.
- Look for the named owner. Accountability follows names. Unnamed = unaccountable.
- Demand evidence for scores of 4-5. Aspirational self-scoring is common; evidence is rare.
- Don’t re-do other reviewers’ work. Security, privacy, finance all have specialist reviewers — note their involvement rather than replicating their review.