How to run a security architecture review

A security architecture review asks one question in many forms: does this design protect what it must, against the threats it will face, in a way someone can verify? The reviews that work share a shape. They are scoped to the system in front of them, run against a current diagram, end in findings with owners, and trace each finding to the controls the organization already reports against.

This guide describes that workflow. The architecture review builder implements it: you choose the system’s traits and it produces the scoped question set, with each question traced to NIST SP 800-53 controls and, through NIST’s own mappings, to CSF 2.0 and SP 800-171 Rev. 3.

What is a security architecture review?

It is a structured examination of a system’s design, before or during build, to find security weaknesses while they are still cheap to fix. CISA’s description of the Security Architect work role includes this task almost word for word: perform security reviews, identify gaps in security architecture, and develop a security risk management plan (task T0177).[6]

A review is not a penetration test, and it is not an audit. A test exercises a built system. An audit checks that controls operate as documented. A design review checks whether the design, if built as drawn, would need fewer of either to go well.

When should you run one?

Run a review at three points:

1. Before build, on the proposed design. This is where findings are cheapest.
2. On significant change: a new trust boundary, a new external dependency, new data types, new administrative paths. SP 800-53 expects changes to be analyzed for security impact before they are made (CM-4 Impact Analyses).
3. Before authorization or a major release, as an input to the risk decision.

Step 1: Scope the system

Write down what the system does in terms that change the risk. The builder uses twelve traits; each adds questions:

Trait	Why it adds questions
Internet-facing endpoints	Denial of service, exposed admin paths, external testing
Processes PII	Authority and purpose for collection, privacy impact, notice
Handles CUI	Boundary completeness, external service obligations
External identity provider	Token validation, behavior when the provider fails
Remote administration	Dedicated admin paths, oversight of privileged users
Third-party services or components	Provenance, supplier failure, dependency register
Secrets or keys	Storage, rotation, revocation
Multi-tenant	Isolation at every layer, tenant context from identity
CI/CD pipeline	Who controls the pipeline, artifact integrity, blocking tests
Public cloud	Shared responsibility, cloud permissions, management-plane logging
Partner or customer APIs	Client authentication and limits, interconnection agreements
Recovery objectives	RTO and RPO, single points of failure

Scoping also means fixing the impact level. If the organization uses SP 800-53, the security categorization (RA-2 Security Categorization) decides which baseline applies. The builder shows each control’s baseline membership (Low, Moderate, High, Privacy) as published in NIST’s baseline profiles.[2]

Step 2: Review against a diagram

Ask for a data-flow diagram that shows components, data stores, external entities and trust boundaries. SP 800-53 calls for documented security architectures (PL-8 Security and Privacy Architectures); in practice, the diagram is that document’s working core.

Two checks catch most diagram problems:

• Every store has a reader and a writer. Data does not appear from nowhere or vanish. The STRIDE authors at Microsoft made the same point: watch for magic data sources and sinks.[5]
• Every flow that crosses a trust boundary has an enforcement point. A boundary on a diagram without a gateway, proxy or policy at the crossing is a drawing, not a control.

Step 3: Threat-model the design

A review without a threat model checks controls against no particular attacker. Use STRIDE per element on the diagram (the STRIDE worksheet generates the questions) and bring the result into the review. SP 800-53 has an enhancement for exactly this expectation of developers: SA-11(2) Threat Modeling and Vulnerability Analyses.

Step 4: Ask scoped questions and request evidence

Each question in the builder names the evidence that would answer it. The difference matters. “Do you encrypt data at rest?” invites “yes”. “Show the storage encryption settings and the key access policy” shows whether key access is narrower than data access, which is the point of SC-28 Protection of Information at Rest and SC-12 Cryptographic Key Establishment and Management together.

Step 5: Record findings that trace

Mark each question Meets, Gap or Not applicable, and write a note. A useful gap note has four parts: what is missing, the risk in one sentence, the owner, and the control it maps to. The control reference matters because it is the language the security plan, the assessor and the risk register already use.

Tracing in the builder works like this. Each question lists SP 800-53 controls. For each control, the builder shows:

• the CSF 2.0 subcategories that NIST’s informative references link to that control;[3]
• the SP 800-171 Rev. 3 requirements that list the control as a source.[4]

A gap noted against AC-2 Account Management, for example, therefore also points to the SP 800-171 requirement 03.01.01 (Account Management) for a contractor system handling CUI.

Step 6: Close the loop

Export the review (Markdown for the design record, CSV for a tracker). Gaps become work items with owners and dates. When the design changes, update the diagram first, then re-run the review for the affected traits. The revision table on every guide here follows the same discipline.

What a review cannot tell you

A design review assumes the system will be built as drawn. It does not prove the implementation is correct, that controls operate over time, or that the threat model was complete. Pair it with testing (CA-8 Penetration Testing for penetration testing), configuration monitoring and periodic re-review.

References

1. SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (OSCAL release 5.2.0). National Institute of Standards and Technology (Joint Task Force), 10/22/2026.Official standard (machine-readable) · checked 11/04/2026 (dataset)
2. SP 800-53B control baselines (LOW, MODERATE, HIGH, PRIVACY profiles, OSCAL). National Institute of Standards and Technology, 10/22/2026.Official standard (machine-readable) · checked 11/04/2026 (dataset)
3. CSF 2.0 Reference Tool: Informative References export. National Institute of Standards and Technology (CPRT), 11/03/2026.Official dataset · checked 11/04/2026 (dataset)
4. SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (OSCAL). National Institute of Standards and Technology, 10/22/2026.Official standard (machine-readable) · checked 11/04/2026 (dataset)
5. Uncover Security Design Flaws Using The STRIDE Approach. Shawn Hernan, Scott Lambert, Tomasz Ostwald, Adam Shostack, MSDN Magazine (Microsoft), 2006-11.Practitioner article (vendor, archived) · checked 11/04/2026 (full text)
6. Security Architect (Work Role Code 652). Cybersecurity and Infrastructure Security Agency.Official documentation · checked 11/04/2026 (page)

Revisions

Rev	Date	Description
0	11/04/2026	First issue.