Review Checklist - Secure Architecture
This checklist applies to all applications assessed according to the criteria defined in this chapter. It serves as a binary, auditable verification instrument of the practical adoption of the secure architecture prescriptions, enabling:
- Continuous control of the application of requirements
ARC-001toARC-015 - Verification per project at key moments of the lifecycle
- Generation of operational indicators that can be aggregated by team or organisation
🗓️ It must be reviewed at every release or significant architectural change, as indicated in
aplicacao-lifecycle.
📋 Verification Items
| Item | Verified? |
|---|---|
Are the trust zones delimited, justified and documented in a versioned diagram? (ARC-001) | ☐ |
Are the externally exposed components inventoried, each with a technical justification and a boundary control (gateway, WAF, ACL)? (ARC-002) | ☐ |
Is there a formal record of the security-focused architecture review (date, participants, decisions)? (ARC-003) | ☐ |
Are the significant structural decisions documented in an ADR (context, alternatives, trade-offs, owner)? (ARC-004) | ☐ |
Was threat modelling of the critical flows carried out, archived and linked to the diagram? (ARC-005) | ☐ |
Are there technical isolation controls between sensitive domains, testable and auditable? (ARC-006) | ☐ |
Were only approved architectural patterns used, or was non-adherence formally justified? (ARC-007) | ☐ |
Are the data flows between zones represented in a DFD with an explicit control at each boundary, versioned? (ARC-008) | ☐ |
Is there a documented threshold for "significant change" and evidence of review after the last one that reached it? (ARC-009) | ☐ |
Are the diagrams versioned, accessible and reviewed within the last ≤12 months or at the last significant release? (ARC-010) | ☐ |
For L3 applications, is there segregation of network, permissions and identity between dev, staging and production? (ARC-011) | ☐ |
For L3 applications, is there a formal approval checklist signed by a security owner before the deploy? (ARC-012) | ☐ |
For L3 applications, is the topology validated automatically in CI/CD, with promotion blocked on failure? (ARC-013) | ☐ |
Do systems with AI/ML components have explicit trust boundaries (training/inference/agentic), anti-prompt-injection controls (input/output) and provenance of models/datasets, with the AI figuring as a distinct participant? (ARC-014) | ☐ |
Does each AI agent with tool use operate with a dedicated ephemeral identity and minimum scope per tool and environment, without reusing human credentials? (ARC-015) | ☐ |
At autonomy A2+, is there an intent declaration in the audit before a destructive tool-call, out-of-band human approval, an exercised kill-switch and an audit per tool invocation integrated with Ch. 12? (ARC-015) | ☐ |
| Is there ARC requirement → threat → decision/ADR → control → evidence traceability, with approved exceptions (compensation, owner, sunset)? | ☐ |
📌 Practical Application Notes
- This checklist must be integrated into sprint tasks, release gates or regular technical reviews.
- It must be used as an instrument of control and operational reporting by architecture, security and audit teams.
- All fields must be validated with objective evidence (e.g. versioned files, PR comments, internal links).
⚠️ In the event of a negative answer, an approved formal exception must exist (see
ARC-011).
📊 Compliance and KPI
- Validation of this checklist makes it possible to declare compliance with Chapter 04 - Secure Architecture.
- The results per project can be aggregated for the purposes of measuring organisational maturity and traceability.
- This mechanism can be integrated into dashboards, team metrics and continuous audit processes.
✅ This instrument is aligned with the continuous-control logic defined in the SbD-ToE model.