Security Architecture: Integrating SABSA with TOGAF

How Does SABSA Integrate with TOGAF?

SABSA (Sherwood Applied Business Security Architecture) integrates with TOGAF by embedding security requirements into every ADM phase as Business Attribute Profiles rather than adding security as a separate workstream at the end. During Phase A, security stakeholders and high-level business attributes are identified. Through Phases B, C, and D, security services are mapped to each architecture component. In Phases G and H, security governance ensures the implemented architecture maintains the security properties the business defined.

In many organizations, security is treated as a "bolt-on" at the end of a project. This leads to friction, higher costs, and often, critical vulnerabilities. True Enterprise Architecture requires a Secure by Design approach.

The industry-standard way to achieve this is by integrating the SABSA (Sherwood Applied Business Security Architecture) framework with the TOGAF ADM.

What is SABSA?

SABSA is a business-driven security architecture framework. While TOGAF focuses on the "what" and the "how" of the enterprise, SABSA focuses on the "Why" (the business drivers) and the "With Whom" (the trust relationships).

The secret sauce of SABSA is the Business Attribute Profile (BAP). Instead of starting with technical controls like "Firewalls" or "Encryption," SABSA starts with business attributes like "Trustworthy," "Compliant," or "Available."

Integrating SABSA into the ADM

You don't need a separate security project. You simply "infuse" security into every phase of the TOGAF cycle.

1. Preliminary & Phase A (Contextual)

During the Architecture Vision, you identify the security stakeholders and define the "High-Level Business Attributes." If the business goal is "Global Expansion," the security attribute might be "Regulatory Compliance."

2. Phases B, C, and D (Conceptual & Logical)

As you design your Business, Data, and App architectures, you map security services to the components.

Phase B (Business): Who is authorized to perform this process?
Phase C (Data): How is this information classified? (e.g., Public, Internal, Confidential).
Phase D (Technology): What physical controls enforce the logical rules?

3. Phase G & H (Operational)

Security governance ensures that the developers aren't cutting corners. The Architecture Board uses the SABSA attributes to measure if the final product is actually "secure" according to the business's original definition.

The Power of Business Attribute Profiling (BAP)

A BAP is a list of attributes that the architecture MUST satisfy.

Attribute: Traceable
Definition: All transactions must be recorded for audit purposes.
Metric: 100% of ledger entries must have a corresponding audit log.

By defining security in these terms, you speak the language of the business, making it much easier to get budget and buy-in for security initiatives.

Why Security Must Be an Architecture Concern, Not a Technology Concern

The SABSA integration with TOGAF works because both frameworks share the same foundational principle: start with the business. TOGAF's four domains — Business, Data, Application, Technology — map directly to SABSA's six layers:

Contextual (Business context → Phase A): Why does security matter to this business?
Conceptual (Business Architecture → Phase B): What security services does the business need?
Logical (Information Systems → Phase C): How are those services logically structured?
Physical (Technology → Phase D): What technical controls implement the logical services?
Component (Solutions → Phases E/F): Which specific products deliver those controls?
Operational (Governance → Phase G/H): How are the controls managed day-to-day?

This alignment means security architects using SABSA can work directly within the TOGAF ADM structure without maintaining a parallel framework. Security deliverables become ADM deliverables, security governance becomes architecture governance, and security requirements live in the same Requirements Repository as all other architecture requirements.

Practical Example: Financial Services Cloud Migration

A bank migrating to cloud uses SABSA attributes to guide TOGAF Phase D Technology Architecture decisions:

Attribute: Confidential — customer financial data must never leave the approved cloud region. Phase D Decision: All production workloads in AWS eu-west-1; data residency enforced via AWS SCPs.
Attribute: Traceable — all data access must be logged for regulatory audit. Phase D Decision: AWS CloudTrail enabled across all accounts; logs stored in a separate, immutable S3 bucket with 7-year retention.
Attribute: Available — core banking must achieve 99.99% uptime. Phase D Decision: Multi-AZ RDS with automated failover; 15-minute RTO with cross-region backup.

By expressing these as business attributes first, the bank's executive team can review and sign off the security architecture without understanding the technical implementation. The attribute statement is business language. The Phase D design decision is technical language. SABSA bridges the two.

Where to Learn More About SABSA

The SABSA Institute provides the official SABSA methodology documentation, certification programme, and community resources. The integration of SABSA with TOGAF is also discussed in detail within the TOGAF Security Architecture guidance published by The Open Group.

Common Questions About SABSA and TOGAF Integration

Q: Do I need a separate security architecture team to apply SABSA with TOGAF?

Not necessarily. The most effective integrations happen when the enterprise architect has sufficient security architecture knowledge to embed SABSA concepts directly into ADM deliverables, rather than running a parallel security project. However, for complex programmes with significant compliance requirements (financial services, healthcare, critical infrastructure), a dedicated security architect working alongside the EA team produces better outcomes. In either case, the integration point is the Business Attribute Profile — security architects define the attributes, and the EA team ensures they are reflected across all four architecture domains.

Q: What is the difference between TOGAF security architecture and ISO 27001?

TOGAF (via SABSA) focuses on designing security into the enterprise architecture from the outset. ISO 27001 focuses on managing information security as an ongoing operational discipline through an Information Security Management System (ISMS). The two are complementary: TOGAF/SABSA creates the security architecture that ISO 27001 then operationalises. Many regulated organisations use TOGAF Phase D Technology Architecture to specify the controls that their ISO 27001 ISMS then manages in production.

Q: How does SABSA map to the ArchiMate Motivation Extension?

The ArchiMate Motivation Extension — which models goals, drivers, outcomes, and requirements — is the natural notation for representing SABSA Business Attribute Profiles in architectural diagrams. A Business Attribute such as "Traceable" can be modelled as a Goal in ArchiMate, with Requirements flowing from it down through the Business, Application, and Technology layers. This makes the security rationale explicitly visible and traceable in the architecture model, satisfying both TOGAF governance requirements and SABSA documentation standards. For the full ArchiMate specification, including Motivation Extension elements, see The Open Group's official documentation.

Summary

Security is not a technical problem; it is a business risk problem. By integrating SABSA with TOGAF, you move from "stopping threats" to "enabling the business" to take calculated risks safely. An architect who understands security is an architect who provides true strategic value.

The key actions for integrating SABSA into your TOGAF practice:

Identify security stakeholders and their business attributes in Phase A alongside other stakeholder concerns
Map security services to each Phase B business capability and service
Define data classification and access control rules in Phase C as first-class architecture outputs
Specify physical security controls in Phase D driven by the logical security architecture
Include security compliance in Phase G Architecture Compliance Reviews

In our next post, we look at another modern architectural challenge: Green IT & Sustainability: Architecture for the Planet.

This post is part of the TOGAF 9.2 Masterclass series. Don't forget to check out our previous post on Interactive Mock Exam: TOGAF 9.2 Certified. For the Technology Architecture context in which security controls are specified, see Phase D Technology Architecture.

Common Challenges Integrating TOGAF and SABSA

Security requirements are captured too late in the ADM The most common failure is treating security as a Phase D concern — bolted onto infrastructure design after business, application, and data architectures have been finalised. By Phase D, many architectural choices that create security risk have already been locked in. Security architecture requirements should be identified in Phase A (Architecture Vision) alongside other business requirements, and SABSA's Contextual and Conceptual layers should run in parallel with TOGAF Phases A and B.

SABSA's Contextual layer is skipped entirely Organisations familiar with ISO 27001 or NIST frameworks tend to start SABSA at the Logical layer (controls and mechanisms) because it maps most directly to familiar security controls. However, the Contextual layer — which translates business risks into security drivers, defines security attributes, and establishes the security governance model — is where SABSA most strongly augments TOGAF. Skipping it means security architecture is disconnected from business risk.

Security architecture deliverables are not stored in the Architecture Repository SABSA produces its own set of architecture artefacts (Security Architecture Definition, Trust Framework, Security Services Catalogue). These belong in the TOGAF Architecture Repository alongside business and technology artefacts. Separating security architecture into a separate document store breaks the traceability between security requirements and the technical controls that implement them.

External references:

Frequently Asked Questions

What is SABSA and how does it differ from TOGAF? SABSA (Sherwood Applied Business Security Architecture) is an enterprise security architecture framework that provides a structured approach to designing security architectures aligned with business risk. Where TOGAF provides a method for developing all enterprise architecture domains, SABSA specialises in the security domain using a six-layer model analogous to the Zachman Framework. The two frameworks are complementary: TOGAF defines the architecture process and governance; SABSA ensures security is embedded in the architecture at every layer from business risk through to technical controls. The SABSA Institute website provides access to the framework.

How do SABSA's layers map to TOGAF phases? SABSA's Contextual layer (business risk and security attributes) aligns with TOGAF Phase A (Architecture Vision) and Phase B (Business Architecture). The Conceptual layer (security policies and trust models) aligns with Phase B and Phase C (Information Systems Architecture). The Logical layer (security services and information flows) aligns with Phase C. The Physical layer (security mechanisms and technologies) aligns with Phase D (Technology Architecture). Component and Operational layers map to Phase E/F implementation planning. Running the SABSA layers in parallel with the ADM phases ensures security architecture is integrated rather than appended.

Do I need SABSA certification to integrate security into TOGAF? No. SABSA certification is valuable for dedicated security architects, but most enterprise architects can apply SABSA principles without formal certification. The key is understanding SABSA's security attribute model (Confidentiality, Integrity, Availability, Accountability, Assurance, Agility) and ensuring these are evaluated against each TOGAF architecture domain. The SABSA Institute publishes white papers on TOGAF/SABSA integration that do not require certification to access.