What it means
Reviews use requirements, models, threat scenarios, peer analysis, testing, simulations, and implementation evidence to challenge assumptions and verify that the architecture behaves as intended.
Why it matters
A visually polished design can still contain missing trust boundaries, conflicting requirements, untested dependencies, or controls that fail under realistic operating conditions.
Practical focus
- Review requirements, threats, interfaces, data flows, and failure modes
- Use independent peers and subject-matter experts where risk justifies it
- Validate high-risk assumptions through tests or prototypes
- Track findings to verified closure
Common mistakes
- Treating a meeting as proof of validation
- Reviewing only the happy path
- Accepting control presence without effectiveness evidence
- Closing findings when documentation changes but the design does not
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: