Security Architecture Foundations and Governance
This domain tests whether you can connect business drivers to a security architecture and then prove the connection through governance. Expect questions on architecture frameworks (SABSA, TOGAF, Zachman), the policy hierarchy, design principles, and the review and exception machinery that keeps an architecture defensible over time.
Frameworks and where they fit
- SABSA is business-attribute driven: derive security attributes from business goals, then walk the layers (contextual, conceptual, logical, physical, component, operational) producing traceable requirements at each step.
- TOGAF ADM provides phases A–H plus requirements management; security is cross-cutting and applied in every phase, not one phase.
- Zachman is an ontology (what/how/where/who/when/why × planner through subcontractor), useful to confirm every cell has an owner.
- Control catalogues (ISO/IEC 27001 Annex A, NIST SP 800-53) supply the what; architecture frameworks supply the why and where.
Governance machinery
Policy states intent and is approved at executive or board level; standards are mandatory and specific ("TLS 1.2 or higher only"); procedures are step-by-step; guidelines are advisory. Exceptions need an owner, a compensating control, an expiry date, and a risk acceptance recorded at the correct authority level. An architecture review board (ARB) gates designs against principles and standards and records its decisions.
Design principles
Saltzer and Schroeder: least privilege, complete mediation, economy of mechanism, open design, separation of duties, least common mechanism, fail-safe defaults, psychological acceptability. Add defense in depth, attack-surface minimisation, and zero trust - never trust a network location; authenticate and authorize each request.
Worked example
A retailer's new customer portal reaches the ARB with the argument "it is encrypted and behind a firewall." Reasoning: first establish business attributes (regulatory scope for payment data, availability target), then derive requirements - if card data touches the portal, PCI DSS applies, so tokenize at the payment page and never store PANs. Then select patterns: WAF, an OIDC identity provider, a segmented application tier, logging shipped to a separate account. Each requirement traces to a business attribute; each exception gets an owner and expiry; residual risk is accepted in writing by the business owner, not by the architect.
Traps
- Confusing policy with configuration standards.
- Treating ARB approval as risk acceptance.
- Citing frameworks with no traceability to requirements.
- Enforcing advisory guidelines as mandates.