Framework · SABSA
The Sherwood Applied Business Security Architecture has been the working method for enterprise security architects since 1995. This is the framework itself: the six-by-six matrix, the layers, the business attributes technique, and how the work it describes gets carried from a design decision through to a control someone has actually finished.
What it is
SABSA stands for Sherwood Applied Business Security Architecture. The SABSA Institute describes it as a methodology for developing business-driven, risk and opportunity focused security architectures, at both enterprise and solutions level, that traceably support business objectives.
The word doing the work in that sentence is traceably. SABSA's central discipline is that every control, every mechanism and every product choice must be traceable upward to a business requirement that justifies it. A control nobody can trace to a requirement is a control nobody can defend in a budget meeting or an audit.
It is not a control catalogue and not a certification you put your company through. There is no such thing as being "SABSA compliant". It is a way of working that produces an architecture, and it is deliberately vendor-neutral: SABSA is copyright protected but open to use, and is not a commercial product.
At a glance
Source: The SABSA Institute, SABSA Executive Summary, read September 2026.
The SABSA Matrix
Each row is a viewpoint, from the business owner down to the person running the thing day to day. Each column is a question every layer has to answer. Where a row meets a column, SABSA expects an artefact.
What
Assets
Why
Motivation
How
Process
Who
People
Where
Location
When
Time
Contextual
Business View
Business decisions
Business risk
Business processes
Business governance
Business geography
Business time dependence
Conceptual
Architect's View
Business attributes profile
Control objectives
Security strategies
Roles and responsibilities
Domain framework
Time management framework
Logical
Designer's View
Information assets
Security policies
Security services
Entity and trust framework
Domain maps
Calendar and timetable
Physical
Builder's View
Data assets
Security rules and procedures
Security mechanisms
Human interface
ICT infrastructure
Processing schedule
Component
Tradesman's View
Component assets
Security standards
Security tools and products
Identities and job descriptions
Nodes, addresses and protocols
Step timing and sequencing
Operational
Service Manager's View
Operational continuity
Operational risk management
Process delivery management
Personnel management
Environment management
Time and performance management
Contextual
Business View
Conceptual
Architect's View
Logical
Designer's View
Physical
Builder's View
Component
Tradesman's View
Operational
Service Manager's View
The SABSA Matrix is the work of The SABSA Institute. Cell labels here are short summaries of each artefact, not the full cell contents.
The six layers
Contextual
Business View
What the business is, what it values, and what it is trying to achieve. Nothing below this layer is allowed to exist without tracing back to it.
Conceptual
Architect's View
The security objectives, expressed as measurable business attributes rather than technology choices.
Logical
Designer's View
The security services required to meet those objectives, still independent of any product.
Physical
Builder's View
The mechanisms that deliver those services: data structures, applications, infrastructure, interfaces.
Component
Tradesman's View
The specific products, tools and standards selected to build the mechanisms.
Operational
Service Manager's View
Running, monitoring and measuring the architecture through its life. In the matrix this layer sits across all six questions at once.
Business attributes
Business Attributes Profiling is the piece of SABSA practitioners talk about most. It takes vague business requirements and converts them into a taxonomy of named attributes: available, confidential, traceable, recoverable, compliant, and so on for whatever the organisation actually cares about.
Each attribute then gets a metric and a target. That is the move that makes the rest of the method work. Once "recoverable" means a stated recovery time rather than a feeling, every control below it can be justified, measured and argued about with evidence.
It is also why SABSA sits comfortably next to enterprise architecture methods like TOGAF rather than competing with them. TOGAF describes how to run architecture as a practice; SABSA supplies the security and risk view, with the traceability attached.
What SABSA actually contains
The Institute publishes SABSA as a set of integrated frameworks, usable together or on their own.
From design to done
The bottom two layers of the matrix, Component and Operational, are about things being built and then run. That is the half architects usually lose: the design is approved, and then it disperses into tickets nobody traces back. Alvor carries the same descent as work, so an architecture decision stays connected to the task that implements it and the evidence that proves it.
Draw it and threat model it
Architecture diagrams with data flows and trust boundaries, a threat model over the live design, and the business impact analysis behind it.
End the review with a signature
A design review closes on named sign-offs and an architecture decision record, so the decision has an owner and a date rather than living in a comment thread.
Threats become the control set
The threats identified in design produce the controls that answer them, mapped across every framework in scope at once rather than re-derived per audit.
Controls become work with owners
Each control becomes projects and tasks with an owner and a due date, and progress rolls up transactionally, so the gap between designed and done is a number rather than a feeling.
Evidence, freshness and the board view
Implementation status per control, evidence carrying freshness states so stale proof is visible, and KPIs with thresholds that roll into a board pack.
Five modules, one record: Secure by Design · Security Management · Compliance · Risk · Asset Management
SABSA and tooling
Being straight about this: Alvor is not a SABSA product, is not certified or endorsed by The SABSA Institute, and does not implement the matrix. The Institute certifies architects, not software. What a platform can do is hold the record the method depends on.
Traceability needs somewhere to live
SABSA's demand is that every control traces to a business requirement. That trace is only real if it is recorded and kept current. Alvor links assets to risks, risks to controls, controls to evidence, and evidence to named sign-offs, so the chain survives after the workshop ends.
Attributes need metrics attached
A business attribute without a measurement is a wish. Alvor carries maturity assessments, KPIs with thresholds, and control implementation status, which is where attribute targets can be given numbers and watched over time.
The layers produce artefacts
Diagrams, threat models, domain definitions, policies and decision records are all SABSA outputs at different layers. Alvor's Secure by Design module is where those artefacts are drafted, reviewed and approved rather than scattered across drives.
Questions
SABSA stands for Sherwood Applied Business Security Architecture. The SABSA Institute describes it as a methodology for developing business-driven, risk and opportunity focused security architectures, at enterprise and solutions level, that traceably support business objectives. It has been in use since 1995 and is applied in around 50 countries. Its defining discipline is traceability: every control and product choice should trace upward to a business requirement that justifies it.
Broadly, yes. The SABSA Institute states that SABSA is copyright protected but is an open-use methodology rather than a commercial product, and publishes it under a limited open source licence. You do not buy SABSA or license it per seat. Training and professional certification are separate paid offerings through the Institute and its accredited education partners.
The SABSA Matrix is a six-by-six grid. The rows are six layers, each representing a different viewpoint of the same system: Contextual (the business view), Conceptual (the architect's view), Logical (the designer's view), Physical (the builder's view), Component (the tradesman's view) and Operational (the service manager's view). The columns are six questions every layer must answer: What, Why, How, Who, Where and When. Each of the thirty-six intersections calls for an architectural artefact.
Business Attributes Profiling is SABSA's technique for turning vague business requirements into something measurable. Requirements are translated into a taxonomy of named attributes, such as available, confidential, traceable or recoverable, and each attribute is given a metric and a target. That step is what allows controls beneath it to be justified and measured rather than asserted.
They are complementary rather than competing. TOGAF describes how to run enterprise architecture as a practice, with its own development method and governance. SABSA supplies the security and risk view, and the traceability from business requirement down to control. Organisations commonly run SABSA alongside an enterprise architecture method rather than choosing between them.
Yes, for people. The SABSA Institute certifies and accredits security architects through its own certification scheme, delivered with accredited education partners. There is no certification for organisations and no such thing as being SABSA compliant, because SABSA is a methodology rather than a control standard or an auditable scheme.
No, and any vendor claiming otherwise is describing something that does not exist. SABSA is a way of working, not a standard you are audited against, and the Institute certifies architects rather than tools. What software can do is hold the record the method depends on: the links from assets to risks to controls to evidence to named sign-offs, kept current so the traceability SABSA asks for survives beyond the workshop that produced it.
Get started
Whether you lead security, run IT, manage compliance, or sit in the C-suite - we'll show you your view.