Our human risk management platform helps turn human risk within your security architecture into targeted, measurable action.

SABSA framework: aligning security architecture with business strategy
The SABSA framework helps connect security architecture with business goals, covering the matrix, lifecycle and certification in one structured approach.
Contents
- What is the SABSA framework?
- Matrix: layers & questions
- Concepts: Lifecycle, Business Attributes, Risks
- Why SABSA?
- SABSA vs. other frameworks
- Certification
Key takeaways: SABSA framework
- Security architecture is most effective when driven by business objectives, not technology choices
- The SABSA matrix structures security decisions across six layers, providing a clear rationale for each
- Business Attributes serve as a shared language between security teams, IT and senior leadership
- Human risk is a core business risk that can be made more visible and measurable with the SoSafe human risk management platform
- The SABSA lifecycle helps organisations continuously adapt their security architecture as business requirements evolve
Explore security architecture further
No single framework fits every organisation. Explore concise guides to established approaches for business-driven security architecture.
What is the SABSA framework?
Most security frameworks start with technology. SABSA starts with the business. The SABSA framework, short for Sherwood Applied Business Security Architecture, is a methodology for designing, implementing and managing security architectures that are grounded in business requirements from day one. It positions security as part of how an organisation protects and enables its goals, not as a control layer added at the end.
History and the SABSA Institute
The SABSA framework was first published in 1995 by John Sherwood, Andrew Clark and David Lynas. Today, the SABSA Institute maintains the framework as an open standard, drives its further development and provides guidance on SABSA certification and training for security professionals worldwide.
The business-first approach
The SABSA framework follows a top-down principle: goals define the need for security. The framework translates those goals layer by layer into architectural and technical decisions, giving security teams a structured way to connect what they build with why it matters. For organisations that want security to be a strategic asset rather than a compliance exercise, this traceability from business requirement to security measure is one of the main strengths of the SABSA framework.
The SABSA matrix: layers and guiding questions
The SABSA matrix is the structural core of the framework. It combines six architecture layers with six guiding questions, creating 36 defined fields. Each field addresses a specific question at a specific level of enterprise architecture. This gives teams a clear way to trace every security decision back to a business requirement.
The 6 SABSA layers
The six horizontal SABSA layers show the level at which a security decision is made:
- Contextual: The business perspective – what the organisation needs to protect and why it matters
- Conceptual: Strategic direction for the architecture. Which principles and policies should shape security decisions?
- Logical: Which security services and functions are actually required to meet those principles?
- Physical: The implementation layer, covering the technologies and products that put the logical design into practice
- Component: Systems, tools and configurations, and how they need to work together to deliver the physical design
- Operational: Day-to-day operations. How does the organisation keep the architecture working in practice, and who monitors it?
The 6 guiding questions
The SABSA framework matrix applies the same six questions across every layer:
- What: Which assets, data or processes are in scope
- Why: Which business goal or risk is driving the requirement
- How: Which process or method will be used to achieve the goal
- Who: Which roles and responsibilities are involved
- Where: Which environment or infrastructure is relevant
- When: Which timing, dependencies and workflows need to be considered
The SABSA framework in practice: a worked example
This SABSA example shows how a familiar security challenge, phishing attacks targeting employees, can be structured using a simplified version of the SABSA matrix:
| Layer | What | Why | Who |
| Contextual | Employees and email communication | Protecting against financial loss and data exposure | Executive leadership, CISO |
| Conceptual | Security principle: awareness before technology alone | People are a frequent target in phishing attacks | CISO, HR |
| Logical | Security awareness programme, phishing simulation | Helping employees recognise and respond to phishing attempts | Security team |
| Physical | E-learning platform, simulated phishing emails | Scalable deployment across the organisation | IT, security |
The SABSA framework helps ensure that security measures can be linked back to a business objective. Frameworks such as the Zachman framework use a similar matrix structure for enterprise architecture. SABSA applies that same principle specifically to security.
SABSA identifies the risk. SoSafe helps address it.

Core concepts: lifecycle, Business Attributes and risk
The SABSA matrix defines the structure. Three further concepts explain how the SABSA framework operates in practice: the lifecycle, Business Attributes and the principle of traceability.
The SABSA lifecycle
SABSA treats security architecture as a continuous process, not a one-off project. The SABSA lifecycle is structured around four phases:
- Strategy and concept: Derive the security strategy from business objectives and identify relevant risks
- Design: Develop the security architecture based on the SABSA matrix
- Implement: Translate architectural decisions into concrete solutions
- Manage and measure: Maintain operations, monitor performance and support continuous improvement
The lifecycle model deliberately separates strategy and planning from the design phase. This helps keep the transition from business requirements to technical implementation transparent and manageable.
SABSA Business Attributes
SABSA Business Attributes are defined qualities that an organisation expects from its security architecture, for example, confidentiality, availability, compliance or reliability. They connect abstract business goals with concrete security measures.
The guiding question shifts from “Do we have a firewall?” to “What availability requirements does the organisation have, and how does the architecture address them?”. Business Attributes are documented in the Business Attribute Profile (BAP), giving all stakeholders a shared basis for understanding and evaluating security decisions.
Risk and traceability
Traceability is one of the defining principles of the SABSA framework. It describes the ability to connect every security measure back to a business requirement or identified risk. SABSA approaches this in two directions:
- Completeness: Every business requirement relating to security is designed to have a corresponding element in the architecture, with any residual risk assessed and accepted by the organisation
- Justification: Every operational or technical security element can be grounded in a risk-assessed business requirement
This supports transparency where it matters most: when developing the security architecture strategically and determining which measures are genuinely needed.
Why SABSA? Strengths and use cases
The SABSA framework connects security architecture with business strategy. This section outlines the concrete strengths of the approach and the types of organisations for which it may be a strong fit.
Key strengths at a glance
The main advantages of the SABSA framework:
- Security decisions are grounded in objectives from the start
- Security investments can be transparently linked back to business risks
- Traceability helps ensure that every measure has a clear business justification
- The lifecycle supports the continuous development of security architecture over time
- Attributes create a shared language between IT, security and senior leadership
SABSA in practice: who benefits?
The SABSA framework addresses different perspectives within an organisation. The table below shows the practical value it can offer to key roles:
| Role | Value |
| CISO / security architect | A structured methodology for business-driven SABSA architecture and traceable reporting based on defined business requirements |
| CEO / board | A clearer connection between security investments and business risk |
| Security team | A defined framework for architectural decisions with stronger alignment between security measures and business justification |
Which organisations is SABSA suited for?
SABSA is not tied to a specific industry or business model. It tends to be most useful where security decisions are complex, involve many stakeholders and need to stand up to close scrutiny. That makes the SABSA framework a strong fit for organisations in sectors such as financial services, energy, healthcare, the public sector, defence and critical infrastructure.
It can also help when teams are already working with several frameworks at once. In those environments, SABSA enterprise security architecture gives organisations a way to connect business requirements, risk, governance and technical implementation more consistently. Used alongside frameworks such as ISO 27001, COBIT or TOGAF, SABSA can help create a clearer line between what the business needs and how security teams deliver it.
SABSA compared to other frameworks
In practice, the SABSA framework is often discussed alongside other security and enterprise architecture frameworks. The sections below position SABSA objectively and highlight where the approaches differ and where they can complement each other.
SABSA and TOGAF
TOGAF covers enterprise architecture in breadth. Security is part of that picture, but it is not its primary focus. This is where the SABSA framework can add depth: it brings a dedicated security perspective into the TOGAF structure and can be integrated as a specialised layer. The shared foundation is a comparable layered approach. Integration can draw on risk management, requirements management and the TOGAF Architecture Development Method (ADM).
SABSA and Zachman
The Zachman framework thinks in matrices. So does SABSA. The difference lies in scope: Zachman describes enterprise architecture in its full breadth. The SABSA framework applies the same matrix thinking consistently to the security domain and goes into more detail in terms of methodology.
SABSA and NIST CSF
The NIST Cybersecurity Framework and SABSA share a focus on risk. Their approaches differ. NIST CSF organises security into categories and maturity tiers. SABSA addresses how the architecture behind those categories should be built. For organisations looking to implement NIST CSF operationally, the SABSA framework can provide a useful architectural method.
SABSA and ISO 27001
ISO 27001 defines what organisations need to achieve in an information security management system. It does not provide a detailed method for structuring the underlying security architecture. SABSA can complement ISO 27001 at the architecture level, helping organisations connect the architecture they build with relevant ISMS requirements.
SABSA at a glance
| Framework | Focus | Architecture methodology | Security-specific | Certification |
| SABSA | Security architecture | Yes, matrix and lifecycle | Yes | Yes, SCF, SCP, SCM |
| TOGAF | Enterprise architecture | Yes, ADM | No | Yes |
| Zachman | Enterprise architecture | Yes, matrix | No | No |
| NIST CSF | Risk and controls | Structured guidance | Yes | No |
| ISO 27001 | ISMS standard | No | Yes | Yes, audit |
SABSA certification: levels, benefits and getting started
The SABSA certification programme is designed for security architects who want to apply the SABSA framework in practice, not just follow it in theory. Offered by the SABSA Institute, the programme is competency-based: practical application takes priority over the recall of concepts.
SABSA certification levels
SABSA Certification has three levels, each building on the one before:
- SABSA Chartered Foundation (SCF): The Foundation level covers the essentials of the SABSA framework through two modules: F1, Security Strategy & Planning, and F2, Security Service Management. Both modules are tested in a 60-minute multiple-choice exam with 48 questions and a pass mark of 75 percent. SCF certification remains valid indefinitely and does not require CPE credits.
- SABSA Chartered Practitioner (SCP): At Practitioner level, candidates build on the Foundation and choose one of five career paths. They then complete the relevant Advanced module, from A1 to A5. The assessment is assignment-based: candidates answer two out of five questions and submit their work within four weeks. Each submission is assessed independently by two SABSA Masters. The pass mark is 75 percent.
- SABSA Chartered Master (SCM): The Master level is the highest SABSA credential. It requires SCP certification, a second Advanced module and a Master Thesis that shows how the SABSA framework has been applied in practice.
How does certification help security teams?
SABSA Certification helps security teams turn technical knowledge into business-focused architecture. Certified professionals learn to design security architectures that reflect organisational goals, risk priorities and management expectations. This gives companies a clearer basis for security investment and makes architecture decisions easier to explain at leadership level.
Costs vary by training provider, format and location. The SABSA Institute provides the latest details.
Human risk. Made measurable.

From SABSA architecture to operational implementation with the SoSafe Human Risk Management Platform.















