If you have spent any time studying TOGAF®, you have probably come across the term “SABSA” in discussions about security architecture. Yet the TOGAF® standard itself says surprisingly little about how to actually apply it. The missing piece is a joint white paper published by The Open Group and The SABSA Institute, titled “TOGAF® and SABSA® Integration” (Document No. W117, October 2011). It lays out, in detail, exactly how the two frameworks fit together.
This guide walks through that primary source — along with the Wikipedia overview of SABSA for structural reference — to explain the background of SABSA, its purpose, what it actually consists of, and how it plugs into the TOGAF® Architecture Development Method (ADM).
What Is SABSA? Background and Origins
SABSA (Sherwood Applied Business Security Architecture) is a risk-driven methodology for building enterprise information security architectures, created by John Sherwood and colleagues. The white paper defines it as follows:
“SABSA is a methodology for developing risk-driven enterprise information security and information assurance architectures and for delivering security infrastructure solutions that support critical business initiatives. It is an open standard, comprising a number of frameworks, models, methods, and processes, free for use by all, with no licensing required for end-user organizations.”
(TOGAF and SABSA Integration, W117)
The key word here is “open standard.” Organizations can use SABSA to build their own architectures without paying licensing fees. The methodology is documented in detail in the so-called “Blue Book,” Enterprise Security Architecture: A Business-Driven Approach (John Sherwood, Andy Clark, and David Lynas, 2005) (TOGAF and SABSA Integration, W117).
Structurally, the SABSA Model draws on the Zachman Framework, adapted for a security perspective:
“The SABSA Model comprises six layers. It is based on the well-known Zachman framework for developing a model for enterprise architecture, although it has been adapted somewhat to a security view of the world.”
(TOGAF and SABSA Integration, W117)
TOGAF® and SABSA share a common philosophy — both are business-focused and both envision architecture as an enterprise-wide blueprint — but they were built along entirely separate paths:
“SABSA and TOGAF® are culturally and philosophically very similar, both being business-focused and both having a vision of architecture as an enterprise-wide blueprint. They have different roots and different histories, however, and therefore the actual frameworks are not identical.”
(TOGAF and SABSA Integration, W117)
The formal effort to bridge the two began in May 2010, as a joint initiative between The Open Group’s Architecture Forum, its Security Forum, and The SABSA Institute:
“The TOGAF-SABSA integration project started in May 2010 as a joint initiative of both the Architecture Forum and the Security Forum of The Open Group, and the SABSA Institute.”
(TOGAF and SABSA Integration, W117)
This was not the first attempt. Back in December 2005, The Open Group Security Forum had already submitted an earlier white paper (W055: Guide to Security Architecture in TOGAF) with similar intent. Parts of it made it into TOGAF® 9, but not in the fully integrated form the Security Forum had envisioned (TOGAF and SABSA Integration, W117). The 2011 white paper picks up where that earlier effort left off.
The Purpose of SABSA: Turning Security into a Business Enabler
At its core, SABSA reframes security not as a constraint, but as something that actively enables the business:
“The fundamental idea behind SABSA is that the security architecture is there to facilitate the business.”
(TOGAF and SABSA Integration, W117)
This mindset shapes how SABSA treats risk. Rather than focusing solely on threats, it takes a balanced view that also accounts for the upside of opportunity:
“It is this balanced view of risk that is embedded in SABSA, including the enabling of benefits arising from opportunities as well as the control of the effects of threats.”
(TOGAF and SABSA Integration, W117)
It also redefines what counts as an “asset.” Where traditional IT security frameworks focus on protecting databases and network infrastructure, SABSA treats those as secondary assets. The primary assets are the business capabilities themselves — production capacity, customer satisfaction, brand and reputation:
“These are regarded in SABSA as secondary assets, supporting the primary assets of business capability.”
(TOGAF and SABSA Integration, W117)
As for the TOGAF-SABSA integration project itself, its stated purpose is to merge the two into a single, holistic methodology:
“This White Paper documents an approach to enhance the TOGAF® enterprise architecture methodology with the SABSA security architecture approach and thus create one holistic architecture methodology.”
(TOGAF and SABSA Integration, W117)
The end goal is explicit:
“The ultimate goal is that the security architecture is fully integrated in the enterprise architecture.”
“The TOGAF® Architecture Development Method (ADM) is the heart of TOGAF® and is therefore the designated place to integrate the security architecture.”
(TOGAF and SABSA Integration, W117)
The integration rests on three cornerstones:
- Risk management drives the selection of security measures. “The SABSA approach to operational risk management is business-driven instead of threat-driven.”
- Requirements management is central to successful architecture development. “TOGAF follows a requirements-driven approach and SABSA Business Attribute Profiling provides a powerful technique to capture architectural requirements.”
- The ADM is mapped phase by phase. “This paper shows which security architecture artifacts are relevant to each phase of the ADM… This way, SABSA is expressed in TOGAF words, providing a common language between TOGAF® and SABSA.”
(All quotes: TOGAF and SABSA Integration, W117)
What SABSA Actually Consists Of
The SABSA Model and the SABSA Matrix
The SABSA Model is a layered hierarchy that moves from high-level business requirements down to the selection of specific technologies and products. The classic six-layer matrix, as documented on Wikipedia, looks like this:
| Layer | Focus |
| Contextual | The business itself, business risk model |
| Conceptual | Business Attributes Profile, control objectives |
| Logical | Business information model, security policies |
| Physical | Business data model, security mechanisms |
| Component | Detailed data structures, security products and tools |
| Operational | Operational continuity assurance, operational risk management |
At each of these layers, SABSA asks the same six questions — What, Why, How, Who, Where, and When — creating what is known as the SABSA Matrix:
“At each of the horizontal layers of abstraction of the architecture model a series of vertical cuts through each of these horizontal layers is made, answering the questions: what, why, how, who, where, and when. This is called the SABSA Matrix.”
(TOGAF and SABSA Integration, W117)
Note that the original white paper describes Security Service Management as a vertical layer that cuts across the other five horizontal layers, rather than as a sixth horizontal row. Newer versions of the SABSA Matrix (like the one on Wikipedia) present “Operational” as a sixth horizontal layer instead. This is a terminology update over time, not a contradiction in the underlying model.
The SABSA Lifecycle
SABSA has its own lifecycle, analogous to the TOGAF ADM:
“At the heart of the SABSA methodology is the SABSA Model, a top-down approach that drives the SABSA Development Process. This process analyzes the business requirements at the outset, and creates a chain of traceability through the SABSA Lifecycle phases of Strategy & Planning, Design, Implement, and ongoing Manage & Measure to ensure that the business mandate is preserved.”
(TOGAF and SABSA Integration, W117)
The essential distinction between the two lifecycles is what each one is actually managing:
“Just as the ADM is the core process model of TOGAF®, so is the SABSA Lifecycle the core process model of SABSA.”
“TOGAF is all about managing the change and migration of an enterprise architecture from one state to another. SABSA is about creating a new state for the security architecture as well as maintaining that new state during business operations.”
(TOGAF and SABSA Integration, W117)
Business Attribute Profiling
If SABSA has one signature technique, it is Business Attribute Profiling. It breaks a business capability down into individual “attributes” — such as Confidential, Available, or Accurate — and assigns each one a measurement approach, a specific metric, and a performance target.
“Business Attribute Profiling is at the heart of the SABSA framework. It is a requirements engineering technique that translates business goals and drivers into requirements using a risk-based approach.”
(TOGAF and SABSA Integration, W117)
“Each business capability can be regarded as a complex ‘molecular’ structure comprising many ‘atomic’ parts. Business Attribute Profiling decomposes the complex molecule into its atomic parts. Each atomic part is a single business attribute.”
(TOGAF and SABSA Integration, W117)
The technique delivers three practical benefits: it lets architects communicate with executives in non-technical terms, it structures requirements in a way that’s easy for stakeholders to review, and it provides traceability between business drivers and technical requirements. Its usefulness extends well beyond security — it can serve as a general-purpose requirements engineering technique for any quality requirement.
How SABSA Plugs into the TOGAF® ADM
The white paper’s most practical contribution is a detailed mapping of SABSA artifacts onto specific ADM phases:
“The ADM contains the concept of artifacts that are consumed or produced by each phase. To match this, SABSA is also split up into artifacts and divided over the TOGAF® phases. This way, SABSA is expressed in TOGAF® words which will ensure correct embedding of the relevant SABSA components at the appropriate ADM phases.”
(TOGAF and SABSA Integration, W117)
Here is how that mapping breaks down phase by phase:
| ADM Phase | SABSA-Derived Artifacts and Activities |
| Preliminary Phase | Establishes the security context — security organization, security principles, risk appetite — needed to guide the security architecture design (“establishes the security context required to guide the security architecture design”) |
| Phase A: Architecture Vision | Identifies security stakeholders and secures approval via a high-level security blueprint (“identify the complete list of all (including security-related) stakeholders and to determine their requirements for approval”) |
| Phase B: Business Architecture | Defines business-level trust, risk, and controls — Business Risk Model, Security Domain Model, Trust Framework — independent of specific IT systems (“business-level trust, risk, and controls, independent from specific IT or other systems”) |
| Phase C: Information Systems Architecture | Integrates the Security Services Catalog into TOGAF’s Information System Services Catalog (“the security services become part of the TOGAF Information System Services Catalog”) |
| Phase D: Technology Architecture | Verifies that security standards and rules are correctly reflected in the technology architecture; a dedicated artifact is usually unnecessary |
| Phase E: Opportunities and Solutions | No dedicated security artifact, but risk evaluation is essential when prioritizing the roadmap |
| Phase F: Migration Planning | Ensures appropriate risks and controls are identified for each migration stage; Business Attribute Profiling can also drive a real-time project risk dashboard |
| Phase G: Implementation Governance | Confirms implementation adheres to the security architecture via security management, audit, and awareness activities (“provides assurance that the detailed design and implemented processes and systems adhere to the overall security architecture”) |
| Phase H: Architecture Change Management | Maintains continuous alignment through risk management and security architecture governance (“defines two processes essential for continued alignment between the business requirements and the architecture: risk management and security architecture governance”) |
(All quotes: TOGAF and SABSA Integration, W117)
One particularly notable detail: SABSA’s Manage & Measure phase — the ongoing monitoring of operational performance — sits formally outside the scope of the TOGAF® ADM.
“However, as indicated by the ghosted SABSA Manage & Measure phase in Figure 25, this phase of SABSA is out of scope for the TOGAF® ADM.”
(TOGAF and SABSA Integration, W117)
Instead, that ongoing monitoring connects to Phase H’s continuous requirements management process, and to a separate Open Group standard, O-ISM3 (the Information Security Management Maturity Model).
The Biggest Contribution: Fixing TOGAF’s Requirements Management Gap
Arguably the white paper’s most valuable proposal for TOGAF® practitioners is applying Business Attribute Profiling to requirements management as a whole:
“Requirements management plays a central role in architecture work. This is recognized in both TOGAF® and SABSA.”
“However, TOGAF® does not provide a concrete technique for describing or documenting requirements.”
“In contrast, SABSA presents its unique Business Attribute Profiling technique as a means to effectively describe requirements.”
(TOGAF and SABSA Integration, W117)
The white paper even specifies where the Business Attribute Profile fits into the TOGAF® Content Metamodel — inside the Motivation Extension, at the location of the “Goal” object:
“The most suitable location in the current metamodel for the Business Attribute Profile is in the Motivation Extension, at the location of the object ‘Goal.’”
(TOGAF and SABSA Integration, W117)
This opens the door to using Business Attribute Profiling for far more than security — it can standardize the way any quality requirement is captured across an architecture engagement:
“The Business Attribute Profile can form the basis for all quality requirements (including security requirements) and therefore has significant potential to fully transform the current TOGAF® requirements management approach.”
(TOGAF and SABSA Integration, W117)
Summary
SABSA and TOGAF® grew out of separate traditions, yet they share the same underlying belief — that architecture exists to serve the business, not the other way around. That shared philosophy is exactly why the two frameworks integrate so naturally. The key takeaways from the official TOGAF-SABSA Integration white paper are:
- Security is a business enabler, not a constraint — this principle is woven directly into how the ADM should be applied.
- Every ADM phase gets a corresponding set of security artifacts, because the ADM is “the designated place to integrate the security architecture.”
- Business Attribute Profiling closes a real gap in TOGAF, giving architects a concrete requirements engineering technique where the standard itself offers none.
For any enterprise architect running TOGAF® engagements, the practical implication is clear: SABSA should not be treated as a separate discipline handed off to a security team. It is a standard component that belongs inside the ADM itself.
References
- The Open Group / SABSA Institute, TOGAF® and SABSA® Integration (W117), October 2011
- Wikipedia, Sherwood Applied Business Security Architecture
Disclaimer
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
Leave a Reply