Security Architecture and Technology Program Oversight
Security Architecture and Technology Program Oversight
This domain tests whether you can govern architecture decisions rather than personally design systems. Expect questions on reference architectures, review boards, zero trust, cloud responsibility boundaries, secure development, framework mapping, and technical debt.
Architecture governance
- An architecture review board (ARB) with security representation approves exceptions and records decisions as architecture decision records, including the compensating controls and expiry date.
- A reference architecture defines approved patterns - identity, network segmentation, logging, encryption, key management - so projects reuse rather than reinvent.
- Oversight means challenging design at design time, not discovering gaps at go-live.
Key concepts
- Defence in depth layers preventive, detective, and corrective controls; zero trust (NIST SP 800-207) removes implicit network trust, using a policy decision point and policy enforcement points, per-request authentication and least privilege.
- Cloud shared responsibility: the provider secures the cloud; the customer secures what is in it - identity, configuration, data classification, and access.
- Secure SDLC embeds threat modelling, code review, dependency scanning, and release gates. Control frameworks such as NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) map controls to outcomes and to each other.
Worked example
A CRM moves to a SaaS provider. The ARB requires a written responsibility matrix: provider covers physical security, hypervisor, and platform patching; the organisation retains identity federation, role design, data classification, field-level encryption choices, integration secrets, and configuration drift monitoring. Exit and data-portability terms are added before signature. Reasoning: signing without the matrix is how organisations discover post-incident that nobody owned configuration security.
Traps that cost marks
- Assuming the cloud provider secures customer data and configuration.
- Buying tools before defining the architecture and the risk they address.
- Approving exceptions without compensating controls, owner, and expiry.
- Ignoring operational technology and industrial protocols, where patching windows and availability constraints differ sharply from IT.
- Letting technical debt accumulate invisibly; unsupported platforms are an architecture risk that belongs on the risk register.