Software Architects
Overview
Architects design solutions that withstand time and threats.
They ensure that security principles are embedded in structural decisions from the outset. They apply secure patterns from the foundation up.
Key Responsibilities
- Design solutions with secure patterns (Ch. 04)
- Anticipate risk implications in integrations and data flows
- Ensure architectural consistency across pipelines, IaC and deploys
- Take documented architectural decisions (ADR)
- Own the design rules: they accept the policies that check them automatically and approve the exceptions to those rules
Organisational Context
The architects' work supports the security by design principles set out in GDPR and the AI Act, as well as NIS2 obligations related to planning appropriate technical measures. Without secure architecture, later fixes are costly and ineffective.
Regulatory Framework
They give effect to:
- GDPR (data protection by design, Article 25) and AI Act (high-risk AI systems «designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity», Article 15(1))
- NIS2: Appropriate structural technical measures
Activities by Chapter
Ch. 02 - Security Requirements
Review classification and requirements whenever a critical integration or relevant structural change occurs.
User Stories:
- US-02: Review on critical changes - Update controls and traceability
Ch. 03 - Threat Modelling
Create the initial threat model with DFDs and STRIDE/LINDDUN, validate the architecture by identifying critical threats before design, update the model on significant changes, apply LINDDUN when personal data is processed.
User Stories:
- US-01: Initial threat model - Risks visible from the outset
- US-02: Architecture validation via threat modelling - Identify threats before design
- US-03: Update on significant changes - Keep the model valid
- US-06: Applying LINDDUN for privacy - Coverage of GDPR threats
Ch. 04 - Secure Architecture
Define secure architecture principles, produce the architecture sheet with controls, record decisions (ADR) with their security rationale, review trust boundaries and integrations, synchronise the threat model with decisions, maintain review triggers and the catalogue of secure patterns, specify isolation controls, run threat modelling in the initial design for L2-L3.
User Stories:
- US-01: Secure architecture principles - Guide technical decisions
- US-02: Architecture sheet with controls - Secure and scalable solution
- US-07: Decision records (ADR) - Traceability and consistency
- US-08: Review of trust boundaries - Validate authentication, authorisation, isolation
- US-09: Threat model ↔ architecture synchronisation - Controls cover threats
- US-10: Architecture review triggers - Up-to-date documentation
- US-11: Catalogue of secure patterns - Reuse of validated designs
- US-12: Technical isolation controls - Resilience to overload and failures
- US-15: Identification and governance of non-deterministic components - Specify proportionate controls
Ch. 08 - IaC and Infrastructure
Collaborate on environment segregation with tagging and least-privilege permissions, govern IaC modules from trusted origins.
User Stories:
- US-02: Environment segregation with tagging - Isolation and traceability
- US-04: Governance of IaC modules - Prevent the spread of bad practices
Ch. 11-12 - Deployment and Operations
Support the resilient design of production environments with availability and recovery patterns.
Chapter References
For full context and framing: