Security Architecture Review Template one signed gate record for identity, network, data, authorisation, secrets, supply chain, observability, resilience, and decommissioning
A free, copy-ready security architecture review template that turns a design-time conversation into a defensible engineering and audit artefact. Ten structured sections covering review scope and panel, identity and access boundaries, network and segmentation, data classification and protection, authorisation patterns, secrets and key handling, supply-chain and build integrity, observability and detection coverage, resilience and recovery posture, and decommissioning and disposition. Each section pairs the design decision with a named control owner, a verification mechanism, and a residual-risk record. Aligned with ISO/IEC 27001:2022 Annex A 5.8, 8.25, 8.27, and 8.28, SOC 2 CC1.4, CC3.2, CC5.1, and CC7.2, PCI DSS 4.0 Requirement 6.2.1 and 6.2.4, NIST SSDF (SP 800-218) practices PO.1, PS.1, PW.1, PW.4, and PW.5, OWASP ASVS v4 V1 through V14, NIST SP 800-207 Zero Trust Architecture, NIST SP 800-160 Volume 1 systems security engineering, ISO/IEC 27034 application security, CSA Cloud Controls Matrix Application and Interface Security domain, and NIST CSF 2.0 Protect function. Built for internal AppSec, product security, security architects, platform security, security engineering, GRC, and CISO-sponsored programmes that need a design-time gate record the engineering owner, the security partner, the GRC partner, and the executive view all read on the same artefact.
Carry the architecture review on the live engagement record, not in a static document folder
SecPortal pairs the signed architecture review with each control decision as a finding, the verification evidence per mitigation, the framework mapping for the audit, and the activity log for the per-revision trail. Free plan available.
No credit card required. Free plan available forever.
Ten sections that turn a design conversation into a defensible engineering and audit artefact
A security architecture review is the gated activity that examines a system against the principles, the durable controls, and the operating constraints the organisation expects every shipping design to satisfy. The ten sections below walk identity, network, data, authorisation, secrets, supply chain, observability, resilience, and decommissioning. Each section captures the design decision, names the control owner, points at the verification mechanism, and records the residual risk. Aligned with ISO/IEC 27001 Annex A 5.8, 8.25, 8.27, and 8.28, SOC 2 CC1.4, CC3.2, CC5.1, and CC7.2, PCI DSS 4.0 Requirement 6.2.1 and 6.2.4, NIST SSDF practices PO.1, PS.1, PW.1, PW.4, and PW.5, OWASP ASVS v4 V1 through V14, NIST SP 800-207 Zero Trust Architecture, NIST SP 800-160 Volume 1 systems security engineering, CSA Cloud Controls Matrix Application and Interface Security, and NIST CSF 2.0 Protect function.
Copy the full security architecture review template (all ten sections) as one block.
1. Review scope, panel, and document control
Open the architecture review with the durable identity of the system, the engineering owner, the security partner, the residual-risk approver, and the dates that anchor the next review. ISO/IEC 27001 Annex A 8.27 expects documented secure system architecture activity tied to a named system; NIST SSDF PO.1 expects defined security requirements per project. This section makes the artefact traceable rather than orphaned.
System name: {{SYSTEM_NAME}}
System version covered: {{SYSTEM_VERSION_OR_RELEASE_TRAIN}}
Review type: {{NEW_DESIGN_OR_MATERIAL_CHANGE_OR_PERIODIC}}
Document version: {{REVIEW_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next review date: {{NEXT_REVIEW_DATE}}
Document classification: Internal (review contains design context; share with auditors under engagement scope)
Review trigger (one or more):
- New design entering the architecture review gate.
- Material change to the existing design (new auth pattern, new external integration, new data class, new tenancy model, new region, new compliance scope, supply-chain compromise, regulatory change).
- Periodic review on calendar cadence (annual for high-risk systems, biennial for lower-criticality systems).
- Incident with design-level root cause.
- Off-cycle review on framework or threat-landscape change.
In-scope of this review:
- Components: {{IN_SCOPE_COMPONENTS}}
- Data classes: {{IN_SCOPE_DATA_CLASSES}}
- Trust boundaries: {{IN_SCOPE_TRUST_BOUNDARIES}}
- External integrations: {{IN_SCOPE_INTEGRATIONS}}
- Compliance perimeter: {{IN_SCOPE_COMPLIANCE_PERIMETER}} (for example PCI scope, ISO scope, HIPAA scope, GDPR processor or controller scope, sector-specific scope)
Out of scope (and the reason):
- {{OUT_OF_SCOPE_COMPONENTS_AND_RATIONALE}}
- {{OUT_OF_SCOPE_INTEGRATIONS_AND_RATIONALE}}
Linked artefacts:
- Architecture diagram location: {{ARCHITECTURE_DIAGRAM_LOCATION}}
- Data-flow diagram location: {{DATA_FLOW_DIAGRAM_LOCATION}}
- Threat model location: {{THREAT_MODEL_LOCATION}}
- Architecture decision records: {{ADR_FOLDER_OR_LIST}}
- Related runbooks and policies: {{RELATED_RUNBOOKS_AND_POLICIES}}
Review panel and sign-off:
- Engineering owner (system owner; signs off on the design): {{ENGINEERING_OWNER_NAME_AND_ROLE}}
- Security partner (AppSec engineer, product security engineer, or security architect): {{SECURITY_PARTNER_NAME_AND_ROLE}}
- Residual-risk approver (senior security architect, head of AppSec, or CISO delegate): {{RESIDUAL_RISK_APPROVER_NAME_AND_ROLE}}
- Platform engineer or SRE (validates platform buildability): {{PLATFORM_ENGINEER_NAME_AND_ROLE}}
- GRC partner (where regulatory scope applies): {{GRC_PARTNER_NAME_AND_ROLE}}
- External challenger (optional, recommended for high-risk systems): {{EXTERNAL_CHALLENGER_NAME_AND_ROLE}}
Frameworks the review evidences:
- ISO/IEC 27001 Annex A 5.8 (Information security in project management)
- ISO/IEC 27001 Annex A 8.25 (Secure development lifecycle)
- ISO/IEC 27001 Annex A 8.27 (Secure system architecture and engineering principles)
- ISO/IEC 27001 Annex A 8.28 (Secure coding)
- ISO/IEC 27034 (Application security)
- SOC 2 CC1.4 (Commitment to competence)
- SOC 2 CC3.2 (Risk identification)
- SOC 2 CC5.1 (Control activities)
- SOC 2 CC7.2 (Monitors system components)
- PCI DSS 4.0 Requirement 6.2.1 (Bespoke and custom software)
- PCI DSS 4.0 Requirement 6.2.4 (Software design addressing common attack types)
- NIST SSDF (SP 800-218) PO.1, PS.1, PW.1, PW.4, PW.5
- OWASP ASVS v4 V1 (Architecture, Design and Threat Modelling)
- NIST SP 800-207 Zero Trust Architecture
- NIST SP 800-160 Volume 1 Systems Security Engineering
- CSA Cloud Controls Matrix (Application and Interface Security)
- NIST CSF 2.0 Protect function
2. Identity, authentication, and access boundaries
Identity is the first cross-cutting concern in every architecture. Capture which identities the system authenticates, how the authentication happens, what factor strength applies per identity class, where authority is delegated, and how revocation is exercised. NIST SP 800-207 Zero Trust principles read this section as the per-request authentication and verification posture. OWASP ASVS V2 (Authentication) and V3 (Session) read it as the authentication design.
3. Network exposure, segmentation, and lateral movement
Network architecture is where assumed boundaries either hold or quietly collapse. Capture which traffic crosses which boundary, what blocks an unintended path, and what proves the segmentation works. Zero Trust Architecture (NIST SP 800-207) reads this as the per-flow verification posture rather than as a perimeter declaration; PCI DSS 1.x reads it as the segmentation evidence.
Data is what the architecture exists to handle. Capture which data classes enter the system, where they live, who can read them, how they are protected at rest and in transit, and how they leave the system. ISO 27001 A.5.12 (Classification of information), A.5.14 (Information transfer), A.8.10 through A.8.12 (Information access restriction, deletion, masking) and the equivalent SOC 2 CC6.1 and CC6.7 read this section as the data-protection evidence.
Authorisation answers a separate question from authentication. Authentication establishes who; authorisation establishes what they may do, against which resource, under which conditions, evaluated where, with what evidence. OWASP ASVS V4 (Access Control), V13 (API and Web Service), and OWASP API Security Top 10 read this section as the authorisation design evidence. Multi-tenant systems read it as the tenant-isolation design.
Authorisation model:
- Primary model: {{PRIMARY_AUTHZ_MODEL}} (RBAC, ABAC, ReBAC, capability, ACL)
- Permission set (or link to permission registry): {{PERMISSION_REGISTRY_LOCATION}}
- Role inheritance: {{ROLE_INHERITANCE_MODEL}}
- Decision point: {{POLICY_DECISION_POINT}} (application code, sidecar, central policy engine, gateway)
- Enforcement point: {{POLICY_ENFORCEMENT_POINT}} (handler, middleware, sidecar, gateway)
- Policy administration point: {{POLICY_ADMIN_POINT}} (UI, infrastructure as code, file-as-code, central admin)
- Policy information point: {{POLICY_INFO_POINT}} (identity provider claims, attribute store, runtime context)
Tenant isolation (multi-tenant systems only):
- Isolation level: {{ISOLATION_LEVEL}} (shared database with row-level security, schema-per-tenant, database-per-tenant, cluster-per-tenant)
- Tenant identifier propagation: {{TENANT_ID_PROPAGATION_PATTERN}}
- Cross-tenant access surface: {{CROSS_TENANT_ACCESS_SURFACE}} (support impersonation, billing aggregation, analytics)
- Cross-tenant audit trail: {{CROSS_TENANT_AUDIT_TRAIL_LOCATION}}
API authorisation surface:
| Endpoint or resource | HTTP method or operation | Required permission | Object-level check | Function-level check | Audit emission |
| -------------------- | ------------------------ | ------------------- | ------------------ | -------------------- | -------------- |
| {{ENDPOINT_1_PATH}} | {{ENDPOINT_1_METHOD}} | {{ENDPOINT_1_PERM}} | {{ENDPOINT_1_OBJECT_CHECK}} | {{ENDPOINT_1_FUNCTION_CHECK}} | {{ENDPOINT_1_AUDIT}} |
| {{ENDPOINT_2_PATH}} | {{ENDPOINT_2_METHOD}} | {{ENDPOINT_2_PERM}} | {{ENDPOINT_2_OBJECT_CHECK}} | {{ENDPOINT_2_FUNCTION_CHECK}} | {{ENDPOINT_2_AUDIT}} |
Failure modes to test against:
- BOLA (Broken Object Level Authorisation; OWASP API1): every endpoint that takes an object identifier must validate the actor against the object before the operation.
- BOPLA (Broken Object Property Level Authorisation; OWASP API3): every endpoint that returns or accepts object fields must filter by the actor permissions.
- Broken Function Level Authorisation (OWASP API5): every administrative or privileged operation must enforce a function-level check that does not rely on UI restriction alone.
- Mass assignment: every input that binds to a domain object must whitelist writable fields rather than rely on the model layer.
Decisions:
| Decision ID | Decision | Rationale | Decision class | Owner | Residual severity |
| ----------- | -------- | --------- | -------------- | ----- | ----------------- |
| {{AUTHZ_DEC_01_ID}} | {{AUTHZ_DEC_01_DESCRIPTION}} | {{AUTHZ_DEC_01_RATIONALE}} | {{AUTHZ_DEC_01_CLASS}} | {{AUTHZ_DEC_01_OWNER}} | {{AUTHZ_DEC_01_RESIDUAL}} |
| {{AUTHZ_DEC_02_ID}} | {{AUTHZ_DEC_02_DESCRIPTION}} | {{AUTHZ_DEC_02_RATIONALE}} | {{AUTHZ_DEC_02_CLASS}} | {{AUTHZ_DEC_02_OWNER}} | {{AUTHZ_DEC_02_RESIDUAL}} |
6. Secrets, keys, and cryptographic posture
Secrets and cryptographic keys are perishable artefacts. Capture where they live, how they rotate, how they are issued to the workload, and how revocation behaves under compromise. ISO 27001 A.8.24 (Cryptography), NIST SP 800-57 (Key management), and PCI DSS 3.x (Cardholder data protection) read this section as the cryptographic posture evidence.
7. Supply chain, build integrity, and dependency posture
The supply chain is the surface adversaries reach without touching production. Capture which dependencies the system trusts, how dependency updates flow, what blocks an unsigned artefact, and how the provenance chain is recorded. NIST SSDF PS.1, PS.2, and PW.4 read this section as the supply-chain integrity evidence; SLSA levels read it as the build-attestation posture; EU Cyber Resilience Act and CISA Secure by Design read it as the SBOM and provenance evidence.
8. Observability, audit logging, and detection coverage
A system that cannot be observed in production is a system the incident response team cannot defend. Capture which security-relevant events the system emits, where the logs go, which detections fire on which events, and how alerts route. ISO 27001 A.8.15 (Logging), A.8.16 (Monitoring activities), SOC 2 CC7.1 (Identifies and analyzes the operation of controls), PCI DSS 10.x (Logging and monitoring), and NIST 800-53 AU and SI controls read this section as the audit and detection evidence.
Security-relevant event inventory:
| Event class | Emission point | Log destination | Retention | Detection rule | Alert routing |
| ----------- | -------------- | --------------- | --------- | -------------- | ------------- |
| {{EVENT_1_CLASS}} | {{EVENT_1_EMISSION}} | {{EVENT_1_DESTINATION}} | {{EVENT_1_RETENTION}} | {{EVENT_1_DETECTION}} | {{EVENT_1_ALERT_ROUTE}} |
| {{EVENT_2_CLASS}} | {{EVENT_2_EMISSION}} | {{EVENT_2_DESTINATION}} | {{EVENT_2_RETENTION}} | {{EVENT_2_DETECTION}} | {{EVENT_2_ALERT_ROUTE}} |
Event-class examples to consider: authentication success and failure, MFA challenge and outcome, password and credential change, role assignment and revocation, administrative action, cross-tenant access, privileged session, sensitive data read and export, configuration change, deployment, secret read, key issuance, anomalous request volume, rate-limit trigger, WAF block, malware-scanner detection.
Log integrity:
- Append-only or write-once posture: {{LOG_APPEND_ONLY_POSTURE}}
- Log signing or hash-chaining: {{LOG_SIGNING_OR_HASH_CHAIN}}
- Log access control (who can read which logs): {{LOG_ACCESS_CONTROL}}
- Log retention by class (operational, audit, regulatory): {{LOG_RETENTION_BY_CLASS}}
- Log access audit trail: {{LOG_ACCESS_AUDIT_TRAIL}}
Detection coverage by stage of the cyber kill chain or MITRE ATT&CK:
- Reconnaissance: {{RECON_DETECTIONS_OR_GAP}}
- Initial access: {{INITIAL_ACCESS_DETECTIONS_OR_GAP}}
- Execution and persistence: {{EXECUTION_PERSISTENCE_DETECTIONS_OR_GAP}}
- Credential access: {{CREDENTIAL_ACCESS_DETECTIONS_OR_GAP}}
- Lateral movement: {{LATERAL_MOVEMENT_DETECTIONS_OR_GAP}}
- Collection and exfiltration: {{COLLECTION_EXFIL_DETECTIONS_OR_GAP}}
- Impact: {{IMPACT_DETECTIONS_OR_GAP}}
Monitoring of the security architecture itself:
- Drift detection on segmentation rules: {{SEGMENTATION_DRIFT_DETECTION}}
- Drift detection on identity-provider posture: {{IDENTITY_DRIFT_DETECTION}}
- Drift detection on encryption posture: {{ENCRYPTION_DRIFT_DETECTION}}
- Drift detection on dependency posture: {{DEPENDENCY_DRIFT_DETECTION}}
Decisions:
| Decision ID | Decision | Rationale | Decision class | Owner | Residual severity |
| ----------- | -------- | --------- | -------------- | ----- | ----------------- |
| {{OBS_DEC_01_ID}} | {{OBS_DEC_01_DESCRIPTION}} | {{OBS_DEC_01_RATIONALE}} | {{OBS_DEC_01_CLASS}} | {{OBS_DEC_01_OWNER}} | {{OBS_DEC_01_RESIDUAL}} |
| {{OBS_DEC_02_ID}} | {{OBS_DEC_02_DESCRIPTION}} | {{OBS_DEC_02_RATIONALE}} | {{OBS_DEC_02_CLASS}} | {{OBS_DEC_02_OWNER}} | {{OBS_DEC_02_RESIDUAL}} |
9. Resilience, recovery posture, and abuse resistance
Resilience is the security concern that decides whether the system survives load, hostile traffic, dependency failure, and operator error. Capture the failure modes the architecture accommodates, the recovery objectives by data class, and the abuse-resistance posture against denial of service, account takeover, and resource exhaustion. NIST CSF 2.0 Recover, ISO 22301 alignment, ISO 27001 A.5.30 (ICT readiness for business continuity), and DORA Articles 9 and 11 read this section as the resilience evidence.
10. Decommissioning, verification mapping, and document control
Every architecture has an end. Capture the conditions under which the system retires, the disposition rule for data and credentials, the integrations that unwind, and the residual records that stay on hold. Then close the review with the verification table that pairs each decision in Sections 2 through 9 with the mechanism that demonstrates it operates, the framework cross-reference, the residual-risk register, and the sign-off panel that makes the document the engineering artefact.
Decommissioning plan:
- Trigger conditions: {{DECOMMISSIONING_TRIGGER_CONDITIONS}} (product end-of-life, customer migration, contract termination, regulatory withdrawal)
- Notice period and stakeholder communications: {{DECOMMISSIONING_NOTICE_PERIOD}}
- Data disposition rule by class: {{DATA_DISPOSITION_RULE_BY_CLASS}}
- Credential and key destruction: {{CREDENTIAL_KEY_DESTRUCTION_RULE}}
- Integration unwind sequence: {{INTEGRATION_UNWIND_SEQUENCE}}
- Residual-record retention (audit hold, regulatory hold, litigation hold): {{RESIDUAL_RECORD_RETENTION}}
- Decommissioning evidence pack location: {{DECOMMISSIONING_EVIDENCE_PACK_LOCATION}}
Verification mapping (one row per decision in Sections 2 through 9):
| Decision ID | Verification mechanism | Evidence location | Last verified date | Verification owner | Cadence | Outcome |
| ----------- | ---------------------- | ----------------- | ------------------ | ------------------ | ------- | ------- |
| {{V_01_DECISION_ID}} | {{V_01_MECHANISM}} | {{V_01_EVIDENCE_LOCATION}} | {{V_01_DATE}} | {{V_01_OWNER}} | {{V_01_CADENCE}} | {{V_01_OUTCOME}} |
| {{V_02_DECISION_ID}} | {{V_02_MECHANISM}} | {{V_02_EVIDENCE_LOCATION}} | {{V_02_DATE}} | {{V_02_OWNER}} | {{V_02_CADENCE}} | {{V_02_OUTCOME}} |
| {{V_03_DECISION_ID}} | {{V_03_MECHANISM}} | {{V_03_EVIDENCE_LOCATION}} | {{V_03_DATE}} | {{V_03_OWNER}} | {{V_03_CADENCE}} | {{V_03_OUTCOME}} |
Verification mechanism categories:
- Static analysis rule (Semgrep, CodeQL, language-specific linter)
- Software composition analysis policy on the manifest
- Unit or integration test
- End-to-end test against a deployed environment
- Authenticated dynamic application security test
- External vulnerability scan against the verified perimeter
- Penetration test scenario from a named engagement
- Code review check enforced through the pull-request template
- Policy-as-code rule (OPA, Cedar, Sentinel) at the gateway or admission controller
- Runtime detection rule (SIEM, EDR, application security observability)
- Configuration drift detection (cloud security posture, infrastructure as code)
- Manual architectural re-review on cadence
Framework cross-reference (the same review evidences each framework on the named control):
| Framework | Control reference | What this review evidences |
| --------- | ----------------- | -------------------------- |
| ISO/IEC 27001:2022 | A 5.8 Information security in project management | Section 1 |
| ISO/IEC 27001:2022 | A 8.25 Secure development lifecycle | Section 1 and Section 10 |
| ISO/IEC 27001:2022 | A 8.27 Secure system architecture and engineering principles | Sections 2 through 9 |
| ISO/IEC 27001:2022 | A 8.28 Secure coding | Section 7 |
| ISO/IEC 27034 | Application security controls | Sections 2 through 9 |
| SOC 2 CC1.4 | Commitment to competence | Section 1 |
| SOC 2 CC3.2 | Risk identification | Sections 2 through 9 |
| SOC 2 CC5.1 | Control activities | Verification mapping |
| SOC 2 CC7.2 | Monitors system components | Section 8 |
| PCI DSS 4.0 | Requirement 6.2.1 (Bespoke and custom software) | Sections 1, 5, 6 |
| PCI DSS 4.0 | Requirement 6.2.4 (Software design addressing common attack types) | Sections 2 through 9 |
| NIST SSDF (SP 800-218) | PO.1 Define Security Requirements | Section 1 |
| NIST SSDF (SP 800-218) | PS.1 Protect Code | Section 7 |
| NIST SSDF (SP 800-218) | PW.1 Identify Vulnerabilities During Design | Sections 2 through 9 |
| NIST SSDF (SP 800-218) | PW.4 Reuse Existing Well-Secured Software | Section 7 |
| NIST SSDF (SP 800-218) | PW.5 Create Source Code by Adhering to Secure Coding Practices | Section 7 |
| OWASP ASVS v4 | V1 Architecture, Design and Threat Modelling | Section 1 |
| OWASP ASVS v4 | V2 Authentication | Section 2 |
| OWASP ASVS v4 | V4 Access Control | Section 5 |
| OWASP ASVS v4 | V6 Stored Cryptography | Section 6 |
| OWASP ASVS v4 | V8 Data Protection | Section 4 |
| OWASP ASVS v4 | V10 Malicious Code | Section 7 |
| OWASP ASVS v4 | V14 Configuration | Sections 3, 6, 7 |
| NIST SP 800-207 | Zero Trust Architecture | Sections 2, 3, 5 |
| NIST SP 800-160 Vol 1 | Systems Security Engineering | Whole document |
| CSA Cloud Controls Matrix | AIS Application and Interface Security | Whole document |
| NIST CSF 2.0 | Protect function | Whole document |
| {{ADDITIONAL_FRAMEWORK_1}} | {{ADDITIONAL_FRAMEWORK_1_CONTROL}} | {{ADDITIONAL_FRAMEWORK_1_EVIDENCE}} |
Residual-risk register (one row per Accept decision across Sections 2 through 9):
| Residual ID | Decision ID | Residual description | Compensating control | Named approver | Acceptance date | Review date |
| ----------- | ----------- | -------------------- | -------------------- | -------------- | --------------- | ----------- |
| {{R_01_ID}} | {{R_01_DECISION_ID}} | {{R_01_DESCRIPTION}} | {{R_01_COMPENSATING}} | {{R_01_APPROVER}} | {{R_01_ACCEPT_DATE}} | {{R_01_REVIEW_DATE}} |
| {{R_02_ID}} | {{R_02_DECISION_ID}} | {{R_02_DESCRIPTION}} | {{R_02_COMPENSATING}} | {{R_02_APPROVER}} | {{R_02_ACCEPT_DATE}} | {{R_02_REVIEW_DATE}} |
Programme metrics that the audit reads:
- Coverage rate: in-scope systems with a current architecture review divided by total in-scope systems.
- Currency rate: reviews within the agreed cadence divided by total reviews.
- Verification coverage: decisions with linked verification evidence divided by total Mitigate decisions.
- Open commitment backlog: controls in planned-but-not-implemented status with median age and ninety-fifth percentile age.
- Residual-risk register currency: residual-risk rows reviewed within cadence divided by total residual-risk rows.
Document control and sign-off:
- Document identifier: {{DOCUMENT_IDENTIFIER}}
- Document repository: {{DOCUMENT_REPOSITORY_LOCATION}}
- Linked finding records (per Mitigate decision): {{LINKED_FINDING_RECORDS}}
- Linked risk-acceptance records (per Accept decision): {{LINKED_RISK_ACCEPTANCE_RECORDS}}
Version history:
| Version | Effective date | Approver | Summary of change |
| ------- | -------------- | -------- | ----------------- |
| {{V1_NUMBER}} | {{V1_DATE}} | {{V1_APPROVER}} | {{V1_SUMMARY}} |
| {{V2_NUMBER}} | {{V2_DATE}} | {{V2_APPROVER}} | {{V2_SUMMARY}} |
Sign-off panel:
- Engineering owner: {{ENGINEERING_OWNER_SIGNATURE_BLOCK}}
- Security partner: {{SECURITY_PARTNER_SIGNATURE_BLOCK}}
- Residual-risk approver: {{RESIDUAL_RISK_APPROVER_SIGNATURE_BLOCK}}
- Platform engineer or SRE: {{PLATFORM_ENGINEER_SIGNATURE_BLOCK}}
- GRC partner (where applicable): {{GRC_PARTNER_SIGNATURE_BLOCK}}
Triggered review list (a review is triggered outside the calendar cadence on any of the following):
- New authentication or authorisation mechanism added to the system.
- New external integration that crosses a trust boundary or carries a new data class.
- New data class entering the system or a data class moving from internal to regulated.
- New tenancy model, new region, or new compliance scope.
- Incident with a design-level root cause.
- Major refactor of in-scope code or material change to the data-flow diagram.
- Supply-chain compromise affecting in-scope dependencies.
- Regulatory or framework change that expands the audit perimeter.
Periodic review:
- Annual review at minimum for systems with regulated data or public-internet exposure.
- Biennial review for internal systems with lower asset criticality.
- Reviews that do not result in a change still record the date and the named reviewer.
Six failure modes the architecture review has to design against
Architecture-review artefacts fail engineering and audit reviews in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the review defensible.
The review runs as a verbal sign-off and produces no durable artefact
A meeting occurs, decisions get made, the security partner says the design is fine, and nothing lands in a document. The next audit reads no architecture-review evidence; the next refactor unknowingly undoes decisions nobody captured. The fix is the structured template above with a named owner, an approver, and a signed document trail. Without the artefact the review is a memory.
Cross-cutting concerns are skipped because the focus stays on the new feature
The team brings the new endpoint or the new flow to the review and the conversation stays inside the feature scope. Identity, segmentation, supply chain, observability, resilience, and decommissioning never get examined because they are not the feature. The fix is the ten-section template that walks every cross-cutting concern by default; sections that are unchanged from the prior review carry a reference to the prior review rather than getting silently dropped.
Residual risks are described without a named approver or a review date
The review records that the system accepts a residual but the audit cannot read who decided to accept it, with what authority, against which rationale, and when the residual is next reviewed. The fix is the residual-risk register in Section 10 with one row per Accept decision, a named approver, an acceptance date, a review date, and a linked formal risk-acceptance record.
Controls are named but never paired with verification evidence
The review claims the system enforces tenant isolation, validates inputs, signs artefacts, and rotates secrets, but no row in the verification mapping points at the test, the policy, the runtime detection, or the scan that demonstrates each claim is operating. The fix is the verification table in Section 10 with one row per Mitigate decision and an evidence pointer; without the pointer the architecture record is aspirational rather than operational.
The review is produced once and never refreshed against the running system
The team ran an architecture review three years ago; the system has changed substantially since; no triggered review fired on any of the material changes. The audit reads stale evidence as current evidence. The fix is the triggered-review list in Section 10 plus the next-review date in Section 1; material changes force an update outside the calendar cadence, and the calendar cadence catches the rest.
The review is the security team artefact and engineering never reads it
The security partner ran the session and stored the document in the security folder. Engineering ships against the design they remember, not against the durable record. The fix is the sign-off panel in Section 10 with the engineering owner, the platform engineer, and the GRC partner each signing the document, plus the document repository in the engineering tree alongside the architecture decision records so the team that ships the system carries the artefact.
Twelve questions the architecture re-review has to answer
Periodic review keeps the architecture record current against the running system. Triggered review keeps it current against material design change. Both reviews answer the same twelve questions; capture the answers in the version history so the review trail is reproducible at any moment between audit cycles.
1.Is the system scope in Section 1 still accurate against the current release train, and have any in-scope components, data classes, integrations, or compliance perimeters changed since the last review.
2.Has the identity model in Section 2 changed in any way, including new identity classes, new identity providers, new MFA enforcement requirements, or new step-up authentication for high-impact operations.
3.Have the network segments in Section 3 changed in topology, in enforcement plane, or in the egress-control posture, and is the segmentation drift detection still operating.
4.Has the data inventory in Section 4 changed, including new data classes entering the system, new retention or disposal commitments, new cross-region replication, or new sub-processors handling any data class.
5.Has the authorisation model in Section 5 changed in any way, including new tenancy patterns, new permission classes, new policy-decision points, or new high-risk endpoints requiring per-object authorisation review.
6.Has the secret and key inventory in Section 6 changed, including new secret classes, new rotation cadence commitments, new cryptographic algorithms or key sizes, or new post-quantum readiness milestones.
7.Has the dependency and supply-chain posture in Section 7 changed, including new package managers, new SBOM commitments, new artefact-signing requirements, new vendor integrations, or new branch protection rules.
8.Has the observability and detection coverage in Section 8 changed, including new event classes emitted, new detection rules, new alert routing, or new drift-detection commitments on the security architecture itself.
9.Has the resilience and abuse-resistance posture in Section 9 changed, including new recovery objectives, new failure-mode commitments, new rate-limiting design, or new game-day cadence.
10.For every Mitigate decision in Sections 2 through 9, is the named control still in place, is the verification evidence in Section 10 still being produced on cadence, and is the residual severity still accurate.
11.For every Accept decision in Sections 2 through 9, has the linked risk-acceptance record been reviewed within the cadence, and is the named approver still the right approver for the residual.
12.Has any framework, regulation, or sector-specific expectation in the period changed in a way that requires an additional row in the compliance cross-reference in Section 10.
How the architecture review pairs with SecPortal
The template above is copy-ready as a standalone artefact. The architecture-review session itself runs on diagrams, whiteboards, decision-record editors, and the engineering judgement of the reviewer panel. SecPortal does not run the methodology and does not replace the architects who decide. What SecPortal carries is the operational layer the team builds around the artefact so the document the team produced becomes auditable rather than reproducible from email threads.
The engagement management surface opens one engagement per architecture review so the scope, the panel, the linked diagrams, and the decision set live on one record across the lifecycle of the design. The document management feature carries the signed review artefact, the version history, the linked diagrams, the architecture decision records, and the disposition record for retired versions. The findings management feature carries each Mitigate decision across Sections 2 through 9 as a finding on the engagement record with an auto-calculated CVSS 3.1 vector, an owner, evidence, and a per-finding status, so the design-time control set becomes the same backlog the rest of the security programme reads against. The activity log captures the timestamped chain of state changes by user, so the dates the review was last performed, who signed off, and which controls moved from planned to implemented are reproducible at any moment between audit cycles.
The compliance tracking feature maps the artefact across the framework cross-reference in Section 10 with CSV export, so one architecture review can be sliced by ISO 27001 Annex A, SOC 2 Trust Services Criteria, PCI DSS, NIST SSDF, OWASP ASVS, NIST SP 800-207, and CSA Cloud Controls Matrix when an auditor asks. The team management feature carries role-based access control that decides who can edit the review, who approves the residual risk, and who reads the verification evidence per decision, with owner, admin, member, viewer, and billing roles enforceable across the workspace. The AI report generation workflow drafts the architecture-committee summary, the audit-package narrative, or the executive briefing from the same engagement data so the engineering view, the GRC view, and the executive view are the same record.
The verification mapping in Section 10 pairs each decision with a verification mechanism; several of those mechanisms run on the same SecPortal engagement record as the review. Code scanning via Semgrep against GitHub, GitLab, and Bitbucket repositories connected through OAuth surfaces findings against the same source the design assumes. The authenticated scanning feature runs dynamic application security tests against the deployed service with the encrypted credential store carrying the credentials behind the test. The external scanning feature runs the 16-module attack-surface assessment across the verified perimeter so the public-facing surface decisions in Section 3 have runtime evidence on the same record. The continuous monitoring feature schedules the scans on a daily, weekly, biweekly, or monthly cadence so the verification commitments in Section 10 are honoured by the platform rather than by manual re-runs. The retesting workflows feature ties retest evidence to the original finding so the closure trail per control is single-record traceable. The finding overrides feature carries the accepted-risk and false-positive overrides with named actor, rationale, and timestamp so the residual-risk register in Section 10 has a durable backing record.
The platform does not draw the architecture diagram, classify residual risks automatically, compute compensating-control effectiveness, or replace dedicated diagramming and threat-modelling tools (Excalidraw, Lucidchart, draw.io, OWASP Threat Dragon, Microsoft Threat Modeling Tool, IriusRisk, ThreatModeler). The methodology and the engineering judgement remain with the team. SecPortal carries the document, the decisions as findings, the verification evidence, the framework mapping, the residual-risk register, and the audit trail so the artefact becomes the operational record rather than a static deliverable.