Frameworks, guidance, publications, and models for practical security architecture.
Assured ControlEnterprise Security Architecture

Security Services Domain Model / Conceptual Layer

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.)

At A Glance

ConceptDefinition
Domain PolicyThe authoritative set of security principles, rules and governance directives for a defined domain, translating business objectives and risk appetite into rules that apply uniformly across the domain.
Control ObjectiveWhat security must achieve — the outcome a policy demands, stated before deciding how to deliver it.

This Layer, Live

The interactive model, pre-filtered to the conceptual layer.

Open full screen

Select "All" to see how domain policy is shaped by compliance obligations, and how control objectives connect down to security services.

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:

  1. 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.
  2. 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.
  3. State mandatory requirements explicitly — data classification levels, authentication standards — rather than leaving them implicit in downstream designs.
  4. 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.
  5. 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:

  1. State each control objective as a required outcome — "unauthorised access is prevented" — not as a named control or technology.
  2. 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.
  3. Map each control objective to the risk it treats and the business attributes it protects, so its purpose is traceable in both directions.
  4. 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.
  5. 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.

Who, What, When, Where, Why

Who

Domain owners and governance forums ratify domain policy; security architects and risk owners jointly derive control objectives from it. Compliance and legal functions supply the obligations that shape policy in the first place.

What

The conceptual layer decides what must be true before any logical or physical design starts: domain policy as the authoritative rule set, and control objectives as the outcomes services will be measured against.

When

Set once domains are scoped and before logical services are designed, then reviewed whenever compliance obligations, business drivers or risk appetite change — not left static once a programme's initial policy pack is signed off.

Where

Domain policy sits with the governance forum accountable for the domain; control objectives sit just beneath it, close enough to logical design to stay implementable but decided independently of it.

Why

Deciding what must be enforced before deciding how it will be delivered is what keeps services accountable to policy rather than policy retrofitted to justify whatever services already exist.

Cross-Framework Mapping

ConceptAlso Known As
Domain PolicyControl Objective (COBIT), Domain Standard (NIST/CIS), Architecture Principle (TOGAF).

Note the naming collision: what COBIT calls a "Control Objective" maps to what this model calls Domain Policy, not to this model's own Control Objective concept — worth flagging explicitly when working across frameworks in the same conversation.

← Contextual Layer Next: Logical Layer →