Most security architecture conversations start in the wrong place. Teams ask which framework to adopt (SABSA or TOGAF) when the question they should be asking is how to use both.
TOGAF is a methodology for designing and governing enterprise architecture across the whole IT estate. SABSA is a methodology for designing security architecture that is directly traceable to business risk. Applying one without the other leaves a gap that tends to show up at the worst possible time.
TOGAF: The Architecture Delivery Engine
TOGAF (The Open Group Architecture Framework) is the world's most widely adopted enterprise architecture framework. Its centrepiece is the Architecture Development Method (ADM): an iterative lifecycle for building architectures across four domains:
- Business Architecture: Strategy, governance, organisation structure, and key business processes
- Data Architecture: Structure of an organisation's logical and physical data assets and management resources
- Application Architecture: A blueprint of the application landscape, its interactions, and its relationships to core business processes
- Technology Architecture: Hardware and software capabilities needed to support the deployment of business, data, and application services
The ADM is designed to be repeatable and governed. It gives large organisations a structured way to make architectural decisions, manage complexity, and keep IT aligned with business strategy.
What it does not do well is security. Security appears as a cross-cutting concern across ADM phases, but there is no deep security engineering methodology built in. That gap is deliberate.
When do I use it: When designing, governing, or rationalising enterprise IT architecture across multiple domains. TOGAF is especially valuable when you need a common language and process across business, data, application, and technology stakeholders.
Example: Consider a financial services organisation migrating three legacy systems to a cloud platform. TOGAF's ADM structures every decision across the programme:
- Business Architecture identifies that the migration must preserve existing SLAs for corporate clients and satisfy APRA CPS 231 outsourcing obligations.
- Data Architecture classifies which datasets can move to cloud, which must stay on-premises due to data sovereignty requirements, and how cross-environment data flows will be governed.
- Application Architecture maps the three legacy systems, determines which can be lifted and shifted, which need re-architecture, and which should be retired.
- Technology Architecture defines the approved cloud platform, container standards, network segmentation requirements, and integration patterns.
The ADM gives the programme a governed, repeatable process for making these decisions. What it does not tell you is which security controls to apply or how to assess the risk of the migration. That is where SABSA comes in.
SABSA: Security Architecture Driven by Business Risk
SABSA (Sherwood Applied Business Security Architecture) augments TOGAF when it comes to risk and security. It is a risk-driven methodology for building security architectures that enable business objectives rather than obstruct them.
Its core tool is a 6x6 matrix that asks six questions across six layers of architectural abstraction:
- What (assets to protect)
- Why (motivation, risk, and business drivers)
- How (security processes and services)
- Who (people, roles, and relationships)
- Where (locations and network topology)
- When (time dependencies and sequencing)
These questions are applied at each layer, from the Contextual (business) view down through Conceptual, Logical, Physical, Component, and Operational.
SABSA Master Matrix
The technique practitioners reach for first is Business Attribute Profiling (BAP): a structured method for translating abstract business goals into specific, measurable security requirements. "We need to be agile" becomes a traceable security attribute. "We need high availability" becomes a requirement tied to specific controls, with clear ownership and metrics. It forces the conversation out of tech-speak and into terms the business actually recognises.
When do I use it: When designing security architecture at any scale, when translating business risk appetite into concrete controls, or when you need security requirements that are traceable from business objective all the way down to implementation detail.
Example: Continuing the cloud migration above, the programme applies BAP to the business goal "maintain corporate client trust through the migration":
- BAP decomposes this into measurable attributes:
- Confidentiality (client data must not be exposed during migration),
- Availability (zero-downtime cutover required),
- Accountability (full audit trail of all data movements), and
- Integrity (no data corruption during transfer).
- Each attribute gets a target: Availability is defined as 99.95% uptime for the payment processing service, with a recovery time objective of four hours.
- Those targets flow down through SABSA's Conceptual, Logical, and Physical layers, driving decisions about encryption standards, backup architecture, and monitoring controls.
Without BAP, "maintain client trust" stays an aspiration. With it, the security team has a traceable requirement that can be tested, measured, and reported against.
How They Work Together
This is not a retrofit argument. In 2011, The Open Group and the SABSA Institute jointly published a whitepaper mapping exactly how the two frameworks integrate. The core idea is straightforward: TOGAF provides the delivery process and structural lifecycle; SABSA provides the security rigour and risk context.
The SABSA layers map directly to TOGAF ADM phases:
- Preliminary Phase and Phase A (Architecture Vision): Aligns with SABSA's Contextual Architecture. Business risk appetite and security attributes are defined here, before any architectural decisions are locked in.
- Phase B (Business Architecture): Aligns with SABSA's Conceptual Architecture. Business processes are mapped to security concepts and control strategies.
- Phases C and D (Information Systems and Technology Architecture): Aligns with SABSA's Logical and Physical Architectures. Security policies, access controls, and cryptographic and network security decisions are designed here.
- Phases E and F (Opportunities, Solutions, and Migration Planning): Aligns with SABSA's Component Architecture. Specific security tools and products are selected and integrated.
- Phases G and H (Implementation Governance and Architecture Change Management): Aligns with SABSA's Operational Architecture. Ongoing monitoring, incident response, and security operations are defined and maintained.
"For too long, information security has been considered a separate discipline, isolated from the enterprise architecture." (The Open Group and SABSA Institute, 2011)
Example: On the same cloud migration, running both frameworks together looks like this:
- At Phase A, SABSA's Contextual Architecture defines the business attributes: Confidentiality, Availability, Accountability, Integrity.
- At Phase B, SABSA's Conceptual Architecture maps those attributes to security services: access control, encryption, audit logging, and integrity checking.
- At Phases C and D, SABSA's Logical and Physical Architectures drive specific decisions: AES-256 for data at rest, TLS 1.3 for data in transit, a centralised SIEM for audit logging, and integrity hashing for all migration batches.
- At Phase G, SABSA's Operational Architecture defines how the security team monitors the new environment: what alerts to configure, what to log, and what the incident response playbook looks like for a data exposure event in the cloud.
Security is not reviewed at the end of the programme. It is embedded in every phase decision, from the first architecture vision through to go-live and beyond.
Which Framework Is Right for You?
Like threat modelling frameworks, these complement rather than compete.
- If you are an Enterprise Architect, TOGAF is your delivery vehicle. Use SABSA to add the security depth and rigour the ADM does not include.
- If you are a Security Architect, SABSA is your home framework. Use TOGAF to give your work the governance scaffolding to operate across the whole enterprise rather than in a security silo.
- If you are setting up a security programme from scratch, embed SABSA's Business Attribute Profiling at TOGAF Phases A and B, before architectural decisions are made. That is when course corrections are cheap. By Phase E, they are not.
The architecture mistake is not choosing TOGAF over SABSA. It is treating security as something to sort out after the build is done. Both frameworks exist to prevent exactly that, and they work best when used together.
Related
- Threat Modelling 101 for practical threat modelling frameworks
- Security vs. Compliance for why compliance is the floor and security is the priority