Most security architectures are a collection of controls that nobody can trace back to a business reason, which is why they are hard to defend in budget rounds and hard to change safely. SABSA is a method for building security architecture the other way round: start from what the business needs, express it as measurable attributes, and derive policies, services and controls that can each be traced back to those needs. This guide explains the SABSA matrix and its layers, business attributes profiling, two-way traceability, how SABSA sits alongside TOGAF and ISO/IEC 27001, how to apply it to identity and non-human identities, and what the certification levels involve. It is written for security architects, enterprise architects and security leaders deciding whether and how to adopt it.
Key takeaways
- SABSA is a method, not a control catalogue. The SABSA Institute describes it as a business-driven methodology for enterprise and solution security architecture focused on risk and opportunity; it tells you how to decide on controls, and leaves the controls themselves to frameworks such as ISO/IEC 27001 and NIST SP 800-53.
- Business attributes are the core artefact. A Business Attributes Profile turns vague goals into named, defined and measurable qualities, and every later design decision is justified against it.
- Traceability works both ways. Each control should trace up to an attribute and a business driver, and each driver should trace down to the controls that serve it; gaps in either direction are findings.
- It complements TOGAF and ISO 27001. The Open Group and The SABSA Institute published a TOGAF and SABSA integration white paper in 2011, and SABSA's traceability supplies the risk-based justification that ISO 27001 risk treatment and the Statement of Applicability need.
- Certification is competency based. Foundation is examined by multiple choice; Practitioner and Master require written assignments and, for Master, a thesis.
What it is and who it applies to
SABSA is published and governed by The SABSA Institute. Its executive summary describes an open-use method: copyright protected but not a commercial product, vendor neutral and free to use. SABSA is used at two scales: enterprise security architecture, setting the overall structure of security services and domains, and solution architecture, designing security for a single system or programme. The Institute lists component frameworks for business requirements engineering (attributes profiling), risk and opportunity management, policy architecture, security services oriented architecture, governance, security domains, and through-life security service and performance management.
Who benefits most: organisations with an enterprise architecture function, regulated firms that must show why each control exists, and programmes large enough that a design must be explained to auditors, boards and delivery teams. Smaller organisations rarely need the full method; they gain most from the attributes profile and a traceability table, used lightly. Unlike a regulation, nothing obliges anyone to adopt SABSA, and no SABSA certificate exists for an organisation; certification applies to individuals.
SABSA's own history notes that its layered model was aligned with the Zachman Framework's six columns around 1998, and that the SABSA Matrix and the companion SABSA Management Matrix were substantially revised in 2018. If you learnt SABSA from older material, check terms against the current version.
Structure and key requirements
The SABSA matrix
The matrix crosses layers, each representing a stakeholder view, with six columns that ask the same questions at every layer. Moving down the layers turns business intent into deployable components; moving across the columns makes sure each layer is complete.
| Layer | Stakeholder view | Question it answers | Typical outputs |
|---|---|---|---|
| Contextual | Business | What does the business do and need, and what are its drivers and constraints? | Business drivers, business risk and opportunity context, regulatory obligations |
| Conceptual | Architect | What qualities must security deliver to meet those needs? | Business Attributes Profile, control objectives, security strategy, domain model |
| Logical | Designer | Which security services and policies deliver those qualities? | Security policies, services such as authentication, authorisation, audit and key management, trust model |
| Physical | Builder | Which mechanisms implement the services? | Mechanisms, rules, protocols, data structures, infrastructure patterns |
| Component | Tradesman | Which products, tools and standards are used? | Products, configurations, technical standards |
| Service management | Service manager | How is security operated, measured and improved? | Operational processes, performance measures, assurance activities |
The six columns are assets (what), motivation (why), process (how), people (who), location (where) and time (when). At the conceptual layer, for example, "why" holds control objectives and "who" holds the trust and responsibility model; at the logical layer the same columns hold policies and the identity and privilege model. The service management layer runs across all the others, which is why SABSA calls itself a through-life method.
Business attributes profiling
A business attribute is a quality the business wants from its systems, expressed in business language: for example available, accessible, auditable, compliant, confidential, controlled, traceable or usable. The SABSA history page records that the original attribute taxonomy was built from 83 security attributes and has since grown into customisable, multi-tier Business Attribute Profiles. Building a profile has four steps:
- Select the attributes that matter for the business context, from the taxonomy or written fresh.
- Define each one in the organisation's own words, so that "available" means the same to finance and engineering.
- Measure: attach a metric and target to each attribute (for example, maximum tolerable outage for "available", or percentage of privileged sessions recorded for "auditable").
- Prioritise: rank attributes, since they conflict ("usable" against "controlled"), and the ranking drives later trade-offs.
Traceability
The Institute's executive summary highlights two-way traceability. In practice it is a table or model linking driver, attribute, control objective, service, mechanism and component. Read top down it shows completeness (every driver is served); read bottom up it shows justification (every control has a reason). Controls with no upward trace are candidates for removal; drivers with no downward trace are gaps.
| Business driver | Attribute (measure) | Logical service | Physical mechanism | Component |
|---|---|---|---|---|
| Keep customer payments flowing | Available (payment API outage under 15 minutes a month) | Resilient authentication service | Redundant token issuance, cached validation keys | Identity provider in two regions |
| Satisfy regulator on access | Auditable (100% of privileged actions attributable to a person or owned workload) | Audit and accountability service | Session recording, signed audit logs | PAM platform, SIEM |
| Protect customer data | Confidential (no standing human access to production data) | Just-in-time authorisation | Approval workflow, time-bound grants | Access request tool, cloud IAM |
Values in this table are illustrative; derive yours from the attributes profile.
Identity and NHI requirements
SABSA does not name identity products or non-human identity controls; it gives a structure in which identity requirements are derived rather than assumed. Identity appears in the "people (who)" column at every layer, and machine identities belong there too.
- Contextual: record who and what interacts with the business: staff, customers, partners, and the workloads, integrations and AI agents acting on their behalf. Treat the growth of automation as a business driver in its own right.
- Conceptual: write attributes that cover machines explicitly, such as "attributable" (every action traceable to an owned identity, human or not) and "least privileged". Define a trust model that says which workloads may act for which humans.
- Logical: specify identity services for workloads: issuance, authentication, authorisation, credential rotation and revocation, ownership and inventory. See the Identity Reference Architecture Guide.
- Physical: choose mechanisms such as workload identity federation instead of static keys, short-lived tokens and secrets vaulting. See the Secrets Management Guide.
- Service management: measure NHI hygiene: percentage of machine credentials with a named owner, rotation age, and orphaned accounts found per quarter. See the NHI lifecycle automation guide.
Tracing machine identity controls back to attributes is a practical way to win funding for NHI programmes: "rotate service account keys" becomes "deliver the auditable and confidential attributes the board approved".
Implementation steps
- Pick a bounded first scope. One business service or programme, not the whole enterprise. A new platform build is easier than retrofitting.
- Gather business drivers. Interview service owners and executives; record drivers, constraints and regulatory obligations in their words.
- Build and agree the Business Attributes Profile. Select, define, measure and prioritise attributes, and get sign-off from the business owner. This sign-off is the authority for every later decision.
- Assess risk and opportunity against attributes. For each attribute, what threatens it and what would improve it. SABSA treats opportunity, not only downside risk, as part of the analysis.
- Derive control objectives, policies and logical services. Map each attribute to objectives and services; reuse enterprise services rather than designing new ones per project.
- Design physical mechanisms and select components. Only now choose products and configurations, recording the trace for each.
- Record decisions. Use architecture decision records for trade-offs between conflicting attributes. See Security architecture decision records (ADRs).
- Define measures and operate. Set up the attribute metrics as service management KPIs, report them, and feed results back to the profile.
- Review and expand. After the pilot, publish reusable enterprise attributes and services, then extend to further domains.
Rolling back is simple because SABSA is a way of working: if the full method is too heavy, keep the attributes profile and traceability table and drop the rest of the documentation.
Evidence and assessment
The SABSA Institute stresses "inherent auditability": the ability to demonstrate compliance with several control frameworks at once. That only holds if the evidence exists.
| Artefact | What an assessor looks for | Measure of quality |
|---|---|---|
| Business Attributes Profile | Defined attributes with metrics, targets and business sign-off | Every attribute measurable; owner named |
| Traceability model | Links from drivers to components and back | Percentage of controls with an upward trace; drivers with no downward trace |
| Risk and opportunity register | Risks expressed against attributes | Risks linked to treatments in the model |
| Policy architecture | Policies derived from control objectives | No orphan policies |
| Performance reports | Attribute metrics over time | Targets met, trends reviewed by owners |
Useful programme KPIs: proportion of new projects with an agreed attributes profile; percentage of controls traceable to a driver; number of controls retired as untraceable; time to answer an auditor's "why is this control here?"; attribute targets met per quarter.
Mapping to other frameworks
| Framework | Relationship to SABSA | Where they meet |
|---|---|---|
| TOGAF Standard (The Open Group) | Enterprise architecture method; the 2011 TOGAF and SABSA integration white paper uses business attributes profiling to bring security into the architecture method | Attributes captured alongside business architecture; security services designed with information systems architecture |
| Zachman Framework | Ontology with six interrogative columns; SABSA aligned its layers and columns with it | Same what, why, how, who, where, when questions |
| ISO/IEC 27001:2022 | Management system standard with risk assessment, risk treatment and Annex A controls | Contextual layer informs clause 4 context and clause 6 risk treatment; traceability justifies inclusion or exclusion in the Statement of Applicability |
| NIST SP 800-53 Rev. 5 | Control catalogue | PL-8 Security and Privacy Architectures, PM-7 Enterprise Architecture and SA-8 Security and Privacy Engineering Principles describe what SABSA delivers |
| NIST CSF 2.0 | Outcome framework | GV.OC-01 (mission informs risk management) and GV.OC-03 (legal and contractual requirements) correspond to the contextual layer; GV.RM-01 risk objectives to the attribute targets |
| ITIL and COBIT | Service and governance frameworks listed by the Institute as integrating with SABSA | Service management layer |
For ISO 27001 work, see the ISO 27001 Certification Guide and the ISO 27001 Statement of Applicability Template.
Certification levels
From The SABSA Institute's certification page, checked 8 November 2026:
| Level | Requirement | Assessment |
|---|---|---|
| Foundation (SCF) | Official Foundation course from an Accredited Education Provider; modules F1 and F2 | Each module 48 multiple-choice questions in 60 minutes, 75% to pass; 15 extra minutes per module available for non-native English speakers |
| Practitioner (SCP) | SCF plus one Advanced course (the page lists modules A1 to A5 in the process; confirm which are offered) | Written assignment: answer 2 of 5 questions within four weeks, dual-marked by two SABSA Masters, 75% to pass |
| Master (SCM) | SCP plus a second, different Advanced course and exam | Pass on the Advanced exam and on a SABSA Master thesis |
The certification page does not state fees or renewal requirements; ask an Accredited Education Provider. For the career route, see the Security Architect Career Guide.
Common pitfalls
- Matrix filling as an end in itself: teams populate every cell of the matrix with generic text and never make a decision with it. Fill only the cells your scope needs.
- Attributes without measures: "secure" and "resilient" with no metric cannot drive trade-offs or show progress.
- Security writes the profile alone: an attributes profile the business never signed off carries no authority.
- Skipping straight to products: the component layer is chosen first and the trace is written afterwards to justify it.
- No service management layer: architecture stops at go-live, so attribute metrics are never collected and the design decays.
- Humans only in the "who" column: workloads, integrations and agents are left out, so machine identity controls have no trace and no budget.
Practitioner checklist
- Choose one business service as a SABSA pilot and name its business owner.
- Record business drivers and obligations in the owner's language.
- Build a Business Attributes Profile with definitions, metrics, targets and priorities, and get it signed off.
- Include non-human identities and AI agents in the "who" column at every layer.
- Maintain a traceability model from drivers to components and report controls with no upward trace.
- Use attribute targets as the justification in ISO 27001 risk treatment and Statement of Applicability decisions.
- Record trade-offs between conflicting attributes in architecture decision records.
- Run attribute metrics as service KPIs and review them with owners each quarter.
- Plan SCF training for architects first, and SCP for the people who will lead designs.
Standards and references
- The SABSA Institute: SABSA Executive Summary
- The SABSA Institute: SABSA Certification
- The SABSA Institute: A Brief History of SABSA, Part 2
- The Open Group: TOGAF and SABSA integration guide announcement
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Security Architect Career Guide · Security Architecture Review Guide · Identity Reference Architecture Guide · Threat Modelling Guide