IT Security ArchitectDESIGN REVIEW · THREAT MODEL · TRACE

Architecture review builder

Choose what the system does. The builder keeps the 26 questions every review needs and adds the ones your system's traits call for (55 in all). Every question names the evidence to ask for and traces to NIST controls.

Sheet TL-101Rev AUpdated Data 800-53 5.2.0
01 Scope
26 questions in scope

Answers stay in this browser (local storage) and are never sent anywhere.

01Scope and context

CTX-1

Is there a current diagram of the system that shows components, data stores, external dependencies and trust boundaries?

Every later question is answered against this picture; a missing or stale diagram hides whole classes of risk.

Evidence: Dated data-flow diagram with an owner and trust boundaries marked.

Trace (official NIST data)
CTX-2

Has the data been categorized (types, sensitivity, owner), and does the design reflect that categorization?

Protection levels, baselines and retention all follow from what the data is.

Evidence: Categorization record or data inventory referenced by the design.

Trace (official NIST data)
CTX-3

Is there a threat model for this design, updated for the change under review?

A review without a threat model checks controls against no particular attacker.

Evidence: Threat model (e.g. STRIDE worksheet) with date and the change it covers.

Trace (official NIST data)
CTX-4

Which security engineering principles does the design apply (least privilege, defense in depth, fail secure), and where are exceptions recorded?

Named principles make trade-offs explicit and reviewable instead of implicit.

Evidence: Design document section listing principles and accepted exceptions.

Trace (official NIST data)

02Identity and access

IAM-1

Are all human users uniquely identified and authenticated before access, with no shared accounts outside documented exceptions?

Shared or anonymous access breaks accountability and makes revocation impossible.

Evidence: Authentication flow and account types list.

Trace (official NIST data)
IAM-2

Is multi-factor authentication required for privileged accounts and for non-privileged accounts where the data warrants it?

Password-only access is the most common entry point into otherwise well-designed systems.

Evidence: IdP or application policy showing MFA enforcement by account type.

Trace (official NIST data)
IAM-3

Is authorization enforced on the server for every request to every protected resource, not only in the user interface?

Client-side checks are bypassed by calling the API directly.

Evidence: Description of the enforcement point and a sample of endpoint authorization rules.

Trace (official NIST data)
IAM-4

Do roles follow least privilege, with privileged functions limited to a small, named set of accounts and conflicting duties separated?

Broad roles turn any single compromised account into a full compromise.

Evidence: Role-permission matrix; list of privileged accounts.

Trace (official NIST data)
IAM-5

How are service-to-service calls authenticated (workload identity, mutual TLS, signed tokens) rather than trusted by network location?

Implicit trust inside the network is what lets an attacker move laterally.

Evidence: Service identity mechanism per internal connection.

Trace (official NIST data)
IAM-6

Who reviews accounts and entitlements, how often, and how quickly are accounts of leavers and unused accounts disabled?

Stale accounts are valid credentials nobody is watching.

Evidence: Access review procedure and last review record.

Trace (official NIST data)
  • AC-2 Account ManagementLMH
    CSF 2.0: PR.AA-01, PR.AA-05, PR.DS-10, DE.CM-01, DE.CM-03 · 800-171 r3: 03.01.01
  • AC-2(3) Disable AccountsMH
    CSF 2.0: none direct; base AC-2: PR.AA-01, PR.AA-05, PR.DS-10, DE.CM-01, DE.CM-03 · 800-171 r3: 03.01.01

03Data protection

DATA-1

Is data protected in transit on every hop, including internal ones, with current protocols and approved cryptography?

Internal networks are not private once any host on them is compromised.

Evidence: Connection inventory with protocol and TLS configuration per hop.

Trace (official NIST data)
DATA-2

Is sensitive data encrypted at rest, and who (people and services) can use the keys?

Encryption at rest only helps if key access is narrower than data access.

Evidence: Storage encryption settings and key access policy.

Trace (official NIST data)
DATA-3

Are retention periods defined, and is data deleted or sanitized when it is no longer needed, including copies and backups?

Data that should not exist cannot be protected or breached.

Evidence: Retention schedule and deletion mechanism.

Trace (official NIST data)

04Boundaries and data flows

BND-1

Is every trust boundary crossing identified, with an enforcement point (gateway, proxy, firewall policy) at each?

Boundaries without enforcement points are lines on a diagram, not controls.

Evidence: Diagram with enforcement points annotated; rule sets.

Trace (official NIST data)
BND-2

Are only the required ports, protocols, services and features enabled, and is the inventory of them current?

Every unused service is attack surface with no business value.

Evidence: Component inventory with enabled services.

Trace (official NIST data)
BND-3

Is input that crosses a trust boundary validated for type, length, range and format before it is used?

Injection flaws start where untrusted input reaches an interpreter unchecked.

Evidence: Validation approach per interface (schema, allow-lists).

Trace (official NIST data)
BND-4

Do errors returned to external callers avoid revealing stack traces, versions, paths or other internal detail?

Verbose errors give attackers a map of the system.

Evidence: Error-handling standard and a sample external error response.

Trace (official NIST data)

05Logging and detection

LOG-1

Which security-relevant events are logged (authentication, authorization failures, administrative actions, data exports), and with what content?

You can only investigate what you recorded, in the detail you recorded it.

Evidence: Agreed event list and a sample record.

Trace (official NIST data)
LOG-2

Are logs sent off the host to a store that the system's own administrators cannot alter or delete?

An intruder with admin rights erases local logs first.

Evidence: Log pipeline and write/delete permissions on the log store.

Trace (official NIST data)
LOG-3

Are clocks synchronized to an authoritative source so events from different components can be correlated?

Timelines across components fall apart without a common clock.

Evidence: Time synchronization configuration.

Trace (official NIST data)
LOG-4

Who reviews or alerts on these events, and is the system connected to central monitoring?

Logs nobody reads detect nothing.

Evidence: Alert rules or monitoring integration for this system.

Trace (official NIST data)

06Resilience

RES-1

Are backups taken, protected from compromise of the production environment, and restore-tested?

Ransomware targets backups reachable with production credentials.

Evidence: Backup scope, isolation, and last restore test result.

Trace (official NIST data)

07Build and supply chain

08Operations and change

OPS-1

Is there a hardened configuration baseline for each component, and is drift from it detected?

Secure designs degrade through unmanaged configuration changes.

Evidence: Baseline documents or policy-as-code; drift reports.

Trace (official NIST data)
OPS-2

How are vulnerabilities found and fixed in each layer (OS, runtime, libraries, container images), and within what time frame?

Each layer has its own update path; one missed layer is enough.

Evidence: Scanning coverage per layer and remediation time frames.

Trace (official NIST data)
OPS-3

Do changes to this design go through change control with a security impact analysis?

Most architectural risk enters through later changes, not the first release.

Evidence: Change process and a sample impact analysis.

Trace (official NIST data)
OPS-4

Is there an incident response path for this system: who is alerted, what can be isolated, and what evidence is preserved?

Containment options are design decisions; they are hard to add mid-incident.

Evidence: Runbook or incident plan section for this system.

Trace (official NIST data)
  • IR-4 Incident HandlingLMHP
    CSF 2.0: ID.IM-01, ID.IM-02, ID.IM-03, DE.AE-02, DE.AE-03, DE.AE-06, DE.AE-08, RS.AN-03, RS.AN-06, RS.AN-07, RS.AN-08, RS.CO-02, RS.CO-03, RS.MA-02, RS.MA-03, RS.MA-04, RS.MA-05, RS.MI-01, RS.MI-02, RC.CO-03, RC.CO-04, RC.RP-01, RC.RP-02, RC.RP-06 · 800-171 r3: 03.06.01
  • IR-8 Incident Response PlanLMHP
    CSF 2.0: ID.IM-01, ID.IM-02, ID.IM-03, ID.IM-04, DE.AE-03, DE.AE-08, RS.AN-08, RS.MA-01, RS.MA-05, RC.RP-01, RC.RP-02, RC.RP-04, RC.RP-06 · 800-171 r3: 03.06.05

How the builder works

Security architecture review workflowSix boxes left to right: scope the system, draw the data-flow diagram, threat model, ask scoped review questions, record findings, trace findings to controls. An arrow returns from findings to the diagram for the next change.Scope01Diagram02Threat model03Questions04Findings05Trace06next change: revise the diagram first
Review workflow used by the architecture review builder. Drawing: IT Security Architect, original.

The workflow is described in the guide How to run a security architecture review. In short:

  1. Scope. Baseline questions always apply. Each trait adds questions specific to that risk.
  2. Answer. Mark each question Meets, Gap or Not applicable, with notes. Answers are saved in your browser only.
  3. Trace. Each question lists SP 800-53 controls with their official baselines (L, M, H, P). For each control the builder shows the CSF 2.0 subcategories that NIST's informative references link to it, and the SP 800-171 Rev. 3 requirements that list it as a source.
  4. Export. Markdown for the design record; CSV for a tracker. CSV cells that begin with =, +, - or @ are prefixed with an apostrophe so spreadsheets do not run them as formulas.

Assumptions and limits

  • The questions and their control associations are our editorial judgment. They are a starting set, not a complete or official checklist.
  • Control titles, baselines and crosswalks are NIST data: SP 800-53 Rev. 5 OSCAL 5.2.0, the CSF 2.0 Reference Tool export generated 11/03/2026, and SP 800-171 Rev. 3 OSCAL 1.1.0.
  • "None direct" means NIST maps no CSF subcategory to that enhancement; the subcategories of its base control are shown instead.
  • A mapping is a relationship, not proof that a control satisfies an outcome or requirement.
  • Nothing you type leaves your browser. There are no accounts and no uploads.

Found an error or a missing question? Email info@itsecurityarchitect.com.