Why attributes matter
Business stakeholders do not ask for "AES-256" or "privileged access management". They say the service must always be available to customers, that regulators must be able to see who did what, and that partner data must stay private. Those statements are business attributes. Normalised, defined and measured, they become the requirements that a security architecture can be traced back to — and tested against.
Without that step, architecture decisions are justified by best practice alone, and nobody can explain to the business why a control exists.
From drivers to attributes
The work starts in the contextual layer. Collect business requirements through structured management interviews, then distil them into business drivers: short statements of what the business needs to protect or enable. A typical engagement produces a few dozen drivers.
Each driver is then mapped to one or more business attributes drawn from a consistent taxonomy — qualities such as available, confidential, auditable, legal and regulatory compliant, usable or recoverable. Using a shared taxonomy matters: it lets attributes be compared across business units and reused across projects.
Building the profile
In the conceptual layer, the selected attributes become the business attributes profile. For each attribute in scope, record:
- A definition in business terms — what the attribute means for this organisation, not a textbook definition.
- The drivers it serves — so the traceability to the business is explicit.
- A measurement approach — how you will know whether the attribute is being achieved.
- A performance target — the level the business needs, agreed with its owner.
- An owner — the person who can accept or challenge the target.
Keep the profile short. A profile with sixty attributes is a catalogue; one with twelve to twenty is a decision tool.
From the profile to control objectives
The profile then drives the rest of the conceptual architecture. Each priority attribute, read alongside the business risk model, yields control objectives: plain-language statements of what mitigation must achieve. Those objectives are realised by security mechanisms, grouped into security domains, and expressed as the logical security services that the design layers will take forward to physical and component specifications.
The result is a chain that can be walked in both directions: from a firewall rule or an identity policy up to the business attribute it supports, and from a business need down to the components that deliver it.
Common pitfalls
- Copying an attribute list from a previous client without re-validating it with the business.
- Defining attributes without measurement approaches, which makes targets meaningless.
- Skipping owners, so no one can accept a trade-off when two attributes conflict.
- Letting the profile go stale once design starts — it should be revisited when the business changes.
SABSA® is a registered trademark of The SABSA Institute. This article describes general practice and is not part of, or endorsed by, the official SABSA body of knowledge.