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.
Applicability (9 profiles)
Framework Mappings (13)
| AIS-04 | Secure Application Development Lifecycle | informative |
| AIS-04 | Secure Application Development Lifecycle | informative |
| 8.27 | Secure system architecture and engineering principles | full |
| NIS2-CIR-6.2 | Secure Development Life Cycle | informative |
| CP-12 | Safe Mode | partial |
| PL-8 | Security and Privacy Architectures | full |
| PM-7 | Enterprise Architecture | informative |
| SA-24 | Design For Cyber Resiliency | informative |
| SA-8 | Security and Privacy Engineering Principles | full |
| SC-24 | Fail in Known State | partial |
| SC-7(18) | Boundary Protection | Fail Secure | full |
| SI-17 | Fail-safe Procedures | partial |
| ASI08 | Cascading Failures | informative |
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, confirmed 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 formally adopted?
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.