APP-013 Secure System Architecture and Design Principles
Description
Documented secure architecture and engineering principles are applied when designing and building systems. Principles include defence in depth, fail-secure defaults, minimal attack surface, least privilege in design, and segregation of sensitive functions. Architecture decisions involving security trade-offs are documented and reviewed.
Rationale
Security weaknesses that are architectural in nature cannot be fixed by patches or configuration. Embedding secure-by-design principles prevents entire classes of vulnerability at the design stage.
Framework Mappings (3)
| AIS-04 | Secure Application Development Lifecycle | partial |
| 8.27 | Secure system architecture and engineering principles | full |
| SA-8 | Security and Privacy Engineering Principles | full |
Evidence (2)
Documented secure architecture and engineering principles document adopted by the organisation, covering defence in depth, fail-secure defaults, minimal attack surface, and least privilege in design.
Example: Security Architecture Principles document or equivalent section within the engineering handbook (Confluence, Notion, or internal wiki) explicitly listing principles such as defence in depth, fail-secure defaults, minimal attack surface, and least privilege in design, with a last-reviewed date within the last 12 months.
Test: Request the security architecture principles document. Verify: (1) the document explicitly names and describes at least four of the following: defence in depth, fail-secure defaults, minimal attack surface, least privilege in design, segregation of sensitive functions, (2) the document is accessible to and used by the engineering team — confirm via onboarding materials or design review template reference, (3) last-reviewed date is within the last 12 months.
Architecture decision records (ADRs) or design review records for significant systems, demonstrating that security trade-offs were documented and reviewed during the design phase.
Example: Architecture Decision Records (ADRs) or design review documents for systems built or significantly changed in the last 12 months, showing: the decision context, options considered, security implications of each option, the selected option, and a named approver.
Test: Request ADRs or design review records for 2–3 systems built or significantly changed in the past 12 months. For each, verify: (1) the document was created before or during the design phase, (2) security implications of the architectural choices are explicitly addressed, (3) a named approver (security lead, architect, or equivalent) has reviewed and signed off, (4) any accepted security trade-offs are documented with a compensating control or risk acceptance.
Questions (2)
Are documented secure architecture and engineering principles — such as defence in depth, fail-secure defaults, and minimal attack surface — formally adopted and applied when designing systems?
The principles must be documented, accessible to engineers, and demonstrably applied in design decisions — not merely stated in a policy document. Architecture decision records (ADRs) are a typical artefact.
How are security architecture principles applied during the design of new systems or significant changes?
A formal design review with a security stakeholder, producing documented architecture decision records (ADRs), is the expected practice for significant systems.