Security Architecture
Domain 3 - Security Architecture
This domain tests whether you can design and govern architectures that enforce security requirements while supporting business change. Expect questions on principles, reference models, segmentation, and design review.
Core rules and concepts
- Architecture translates risk and policy into structure: trust boundaries, data flows, identity, segmentation, and control placement. Use frameworks such as SABSA for business-driven security architecture, TOGAF for enterprise alignment, and NIST guidance for control selection.
- Apply principles deliberately: least privilege, defense in depth, secure defaults, fail-safe, separation of duties, and zero trust where identity and continuous verification fit the use case.
- Maintain current and target-state architectures, standards, and patterns. A design review checks threat models, data classification, dependency risk, and exception handling before build.
- Threat modeling (for example, STRIDE) identifies threats and controls early; architecture decision records capture rationale and residual risk.
Worked example
A manufacturer connects IT billing systems to operational technology (OT) for production reporting. The architect rejects direct connectivity. The design inserts a DMZ with a brokered data diode/one-way transfer, allow-lists, protocol inspection, and separate identity domains. The threat model shows that ransomware on IT could otherwise reach controllers. The exception for a legacy historian is documented with a compensating control and expiry. Reasoning: segmentation and mediated flows reduce blast radius; the decision record makes residual risk visible.
Traps that cost marks
- Treating architecture as a diagram rather than enforceable decisions and standards.
- Designing controls after systems are built.
- Assuming zero trust means no network controls.
- Ignoring availability and safety constraints in OT or critical services.