Conceptual Layer
What must be enforced, decided before any design: domain policy translates business objectives and risk appetite into authoritative rules, which set the control objectives that services must satisfy. (SABSA conceptual layer.)
Breaking Down Each Concept
Each concept below sets out what it is, exactly what an architect needs to do to establish it well, the inputs it depends on, the outputs it must produce, and the mistake most likely to undermine it.
1. Domain Policy
What it is: the authoritative set of security principles, rules and governance directives for a defined domain — translating business objectives and risk appetite into a cohesive policy that applies uniformly across all the domain's sub-domains, controls and mechanisms.
What you need to do:
- Write domain policy as a self-contained governance artefact — the authoritative statement of what must be enforced across the domain, before any logical or physical design begins.
- Derive every rule in the policy from a compliance obligation, a business driver, or a risk the domain must treat. A rule with no traceable source is scope creep, not policy.
- State mandatory requirements explicitly — data classification levels, authentication standards — rather than leaving them implicit in downstream designs.
- Apply the policy uniformly across all the domain's sub-domains, controls and mechanisms. Inconsistent application is the commonest way a domain policy loses its authority.
- Review domain policy whenever compliance obligations or business drivers change, and whenever the control objectives it sets stop matching what services can actually deliver.
Inputs: compliance obligations, business drivers, the domain's risk appetite, existing enterprise security policy where it exists.
Outputs: an authoritative domain policy that sets the control objectives every service, mechanism and product in the domain must satisfy.
Watch for: policy written at the physical layer by accident. "Use AES-256" is an implementation detail masquerading as policy; policy states what must be true, not how.
2. Control Objective
What it is: what security must achieve — the outcome a policy demands, stated before deciding how to deliver it.
What you need to do:
- State each control objective as a required outcome — "unauthorised access is prevented" — not as a named control or technology.
- Derive every control objective directly from domain policy. A control objective invented at the logical layer without a policy behind it has no governance backing.
- Map each control objective to the risk it treats and the business attributes it protects, so its purpose is traceable in both directions.
- Keep control objectives implementation-free. The moment an objective names a specific service or product, it has become a design decision wearing a policy label.
- Test control objectives against real services during design. An objective no service can realistically satisfy is a policy that needs revising, not a service that needs stretching.
Inputs: domain policy, the risks it must treat, the business attributes it protects.
Outputs: a set of control objectives that security services can be designed and assessed against.
Watch for: control objectives copied wholesale from a compliance checklist without being reframed as outcomes specific to the domain's actual risk.