SABSA as the foundation: security architecture that starts with the business

Sooner or later every security programme gets asked the same question: why this control? Why this much logging, this approval step, this encryption, this cost? Most frameworks answer with a reference number. SABSA answers with a business reason — and it was built to do that from the start.

What SABSA is

The SABSA Institute describes SABSA (Sherwood Applied Business Security Architecture) as "a proven methodology for developing business-driven, risk and opportunity focused Security Architectures at both enterprise and solutions level that traceably support business objectives". Three phrases in that sentence carry the whole idea: business-driven, risk and opportunity, and traceably.

It isn't a single checklist. It's a set of integrated frameworks you can use together or on their own — among them Attributes Profiling for business requirements, a Risk and Opportunity Management Framework, a Policy Architecture Framework, a Governance Framework and a framework for through-life service and performance management. And although it's copyright protected, the Institute describes it as "an open-use methodology, not a commercial product".

The matrix, in one paragraph

SABSA organises architecture into layers, each a different stakeholder's view: the contextual (business) view at the top, then conceptual, logical, physical and component, with an operational layer running alongside them for the service's working life. Across every layer it asks the same six questions — what (assets), why (motivation), how (process), who (people), where (location) and when (time). Decisions flow down the layers; justification flows back up.

Business attributes: the heart of it

The step that makes SABSA different is Attributes Profiling — what the Institute calls its Business Requirements Engineering Framework. Instead of starting with threats or controls, you agree with the business the qualities a system must have, in the business's own words, and how each one will be measured.

In practice an attribute has four parts:

• A name the business recognises — available, confidential, auditable, compliant.
• A definition for this system — "available" means something very different for a payments platform and an internal wiki.
• A measure — how you'd know it's being met.
• A target the business has signed off.

Once the profile exists, every later conversation has an anchor. A control isn't justified because a standard lists it; it's justified because it protects an attribute the business asked for.

Risk and opportunity

SABSA treats risk as two-sided. The Institute's own summary pairs being "risk & opportunity balanced" with "prioritised and proportional responses". That matters more than it sounds. Security that only ever says no loses the argument eventually. Framing strong identity as the thing that makes remote working or a new partner integration possible is still security — it's just security the business wants to pay for.

Two-way traceability

SABSA's signature property is traceability in both directions:

• Top down: from a business attribute to the risks that threaten it, the controls that treat those risks, and the evidence that the controls work.
• Bottom up: from any control, log source or policy back to the attribute it exists to protect.

The Institute describes the result as "auditable" — it "demonstrates compliance to relevant authorities". In my experience it also does something quieter: it finds controls nobody can justify, which is money you can stop spending.

Where every other framework plugs in

SABSA doesn't compete with other standards. The Institute positions it as aligning with frameworks such as TOGAF, ITIL and Zachman, and as a business-driven, traceable way to deploy standards such as the ISO 27000 series, NIST and COBIT. That's exactly how I use it:

1. Obligations enter at the contextual layer. A law, regulation or government policy — UK Secure by Design, the NCSC CAF or NIS2 — is a business driver. It belongs next to the business goals, not in a separate compliance spreadsheet.
2. They become attributes. "Compliant", "auditable", "reportable within 24 hours", "governed at board level" — each with a definition and a measure, like any other attribute.
3. Risk decides what matters. Threats to those attributes are assessed alongside every other risk.
4. Frameworks supply the controls. NIST SP 800-53, the CIS Controls or a cloud well-architected framework provide the catalogue to choose from.
5. One set of evidence serves every regime. Because each control traces back to an attribute, the same evidence can answer an auditor, a regulator and the board.

I go through the controls side of that chain in Mapping controls to frameworks without drowning in them.

Where SABSA goes wrong

• Attribute sprawl. Forty attributes nobody can remember. I aim for the dozen or so the business will actually sign off and review.
• Architecture as paperwork. A beautiful matrix that no engineer ever opens. Layers only earn their keep if design decisions are actually made in them.
• A one-off exercise. SABSA includes through-life service management for a reason. Attributes, risks and evidence change as the service does — the traceability has to be maintained, not produced once for a review.

---

Frameworks tell you what controls exist. Regulations tell you what you must prove. SABSA is what connects both to the reason the business is paying for security at all. Start there, and every other framework becomes a tool you choose rather than a list you survive.

Sources

• SABSA executive summary — The SABSA Institute
• Sherwood Applied Business Security Architecture — overview of the layers and matrix (secondary source, based on Sherwood, Clark & Lynas, Enterprise Security Architecture)