Review Triggers and Scope
Review Triggers New systems and services should trigger architecture review. New systems introduce new risks. Material changes to existing systems should trigger review. Material changes include new data types, new integrations, and architectural changes. Sensitive data flows should trigger review. Sensitive data requires additional protection. Third-party integrations should trigger review. Third-party integrations introduce supply chain risk. Regulatory compliance requirements should trigger review. Compliance requirements drive security controls. Risk-Based Tiering Review depth should be proportional to risk. High-risk systems require deep review. Low-risk systems can use self-service checklists. Checklists enable self-assessment. Medium-risk systems require lightweight review. Lightweight review balances thoroughness and speed. High-risk systems require full review with multiple reviewers. Full review provides comprehensive assessment. Tiering criteria should be documented. Documentation ensures consistent application. Scope Definition Review scope should be clearly defined. Scope includes systems, components, and boundaries. In-scope and out-of-scope should be explicit. Clarity prevents misunderstanding. Review should focus on changes for existing systems. Focus on changes makes reviews efficient. Dependencies should be identified. Dependencies affect security posture.Review Inputs and Outputs
Review Inputs Architecture diagrams show system structure. Diagrams should include components, connections, and trust boundaries. Data Flow Diagrams (DFDs) show data movement. DFDs identify sensitive data flows. Data classification identifies sensitivity levels. Classification drives protection requirements. Threat model identifies threats and mitigations. Threat model should use structured methodology (STRIDE, PASTA, etc.). Dependency inventory lists third-party components. Dependencies introduce supply chain risk. Existing controls document implemented security measures. Controls show current security posture. Architecture Decision Records (ADRs) document design decisions. ADRs provide rationale. Compliance requirements identify applicable regulations. Requirements drive control selection. Review Outputs Risk findings identify security issues. Findings should include description, impact, and likelihood. Severity ratings prioritize findings. Severity should be based on risk (critical, high, medium, low). Required mitigations specify remediation actions. Mitigations should be specific and actionable. Mitigation owners assign accountability. Ownership ensures follow-through. Due dates establish timelines. Timelines should be based on severity. Residual risk statements document accepted risks. Risk acceptance requires appropriate authority. Recommendations provide security guidance. Recommendations improve security posture.Review Process
Preparation Phase Requestor prepares review inputs. Preparation ensures productive review. Reviewers study materials before workshop. Pre-reading enables informed discussion. Questions should be submitted in advance. Advance questions enable preparation. Review agenda should be distributed. Agenda sets expectations. Workshop Phase Workshop brings together requestor and reviewers. Workshop enables discussion. Requestor presents architecture and design decisions. Presentation provides context. Reviewers ask questions and probe design. Questions identify issues. Threat modeling should be performed or validated. Threat modeling identifies threats. Findings should be documented during workshop. Real-time documentation captures insights. Workshop should be collaborative, not adversarial. Collaboration builds shared understanding. Findings Phase Findings should be documented with severity, impact, and likelihood. Documentation enables prioritization. Findings should be specific and actionable. Specificity enables remediation. Findings should reference standards and best practices. References provide justification. False positives should be eliminated. False positives waste effort. Mitigation Planning Phase Mitigations should be identified for each finding. Mitigations address risks. Mitigation owners should be assigned. Ownership ensures accountability. Due dates should be established based on severity. Timelines drive action. Compensating controls should be identified for accepted risks. Compensating controls reduce residual risk. Mitigation plan should be documented. Documentation enables tracking. Sign-off Phase Sign-off indicates review completion. Sign-off requires mitigation plan. Exceptions require compensating controls and expiration dates. Exceptions should be time-bounded. Residual risk should be explicitly accepted. Acceptance requires appropriate authority. Sign-off should be documented. Documentation provides audit trail. Tracking and Verification Review artifacts should be stored in repository. Repository provides single source of truth. Findings should be linked to tickets. Linking enables tracking. Mitigation completion should be tracked. Tracking ensures follow-through. Mitigations should be verified via tests or policy checks. Verification ensures effectiveness. Re-review should occur for incomplete mitigations. Re-review ensures completion.Review Artifacts
Architecture Diagrams Architecture diagrams should show components, connections, and trust boundaries. Diagrams provide visual representation. Diagrams should be kept up-to-date. Current diagrams enable effective review. Diagrams should use standard notation. Standard notation improves clarity. Data Flow Diagrams Data Flow Diagrams show data movement through system. DFDs identify sensitive data flows. DFDs should show data sources, sinks, and transformations. Completeness enables comprehensive review. DFDs should identify trust boundaries. Trust boundaries are attack surfaces. Threat Model Threat model identifies threats, vulnerabilities, and mitigations. Threat model drives security requirements. Threat model should use structured methodology. Structure ensures completeness. Threat model should be updated as system evolves. Updates keep threat model current. Risk Register Risk register documents identified risks. Register provides risk inventory. Risk register should include severity, likelihood, impact, and mitigation status. Completeness enables risk management. Risk register should be reviewed periodically. Review ensures currency. Architecture Decision Records ADRs document significant architecture decisions. ADRs provide rationale. ADRs should include context, decision, and consequences. Completeness enables understanding. ADRs should be version controlled. Version control provides history.Review Quality and Metrics
Escaped Defects Escaped defects are security issues found in production that should have been caught in review. Escaped defects show review effectiveness. Escaped defect rate should be tracked. Tracking enables improvement. Root cause analysis should identify why defects escaped. Root cause analysis drives process improvement. Review Lead Time Review lead time measures time from request to sign-off. Lead time affects development velocity. Lead time should be tracked by review tier. Tier-specific metrics enable optimization. Long lead times indicate process bottlenecks. Bottlenecks should be addressed. Re-review Interval Re-review interval measures time between reviews for same system. Interval should be based on change rate. Frequent changes require more frequent reviews. Review frequency should match change frequency. Re-review should occur after material changes. Material changes introduce new risks. Review Coverage Review coverage measures percentage of systems reviewed. Coverage should be high for high-risk systems. Coverage gaps should be identified and addressed. Gaps represent unmanaged risk. Continuous Improvement Incident learnings should feed back into review process. Learning prevents recurrence. Review process should be periodically assessed. Assessment identifies improvement opportunities. Reviewer training should be provided. Training improves review quality. Review templates and checklists should be updated. Updates incorporate learnings.Review Best Practices
Collaborative Approach Reviews should be collaborative, not adversarial. Collaboration builds trust. Reviewers should be partners, not gatekeepers. Partnership enables better outcomes. Focus should be on improving security, not finding fault. Improvement focus is constructive. Risk-Based Prioritization Review effort should focus on highest risks. Prioritization maximizes value. Low-risk findings should not block progress. Blocking on low-risk findings creates friction. Risk acceptance should be explicit. Explicit acceptance ensures informed decisions. Actionable Findings Findings should be specific and actionable. Specificity enables remediation. Findings should include remediation guidance. Guidance accelerates remediation. Findings should reference standards and best practices. References provide justification. Lightweight Process Process should be as lightweight as possible while achieving objectives. Lightweight process scales. Automation should be used where possible. Automation reduces manual effort. Templates and checklists should streamline reviews. Standardization improves efficiency.Conclusion
Security architecture reviews create shared understanding and documented decisions through structured assessment of architecture, data flows, threats, and controls. Security engineers design lightweight processes that scale and add friction only where risk justifies it. Success requires risk-based review triggers and tiering, comprehensive inputs including diagrams and threat models, structured process from preparation through sign-off, artifact management and tracking, and metrics including escaped defects and lead time. Organizations that invest in architecture reviews shift security left and prevent costly late-stage fixes.References
- NIST SP 800-64 Security Considerations in the System Development Life Cycle
- BSIMM Architecture Analysis Practice
- OWASP SAMM Design Review
- Threat Modeling Manifesto
- Architecture Decision Records (ADR) Templates