SABSA Security Architecture Framework

Overview

The SABSA (Sherwood Applied Business Security Architecture) Security Architecture Framework is a comprehensive methodology for developing risk-driven enterprise security architectures. It helps organizations align security strategies with business objectives by providing a structured approach to designing, implementing, and managing security architectures that address business risks and requirements.

Primary Objectives

• Enable consistent and repeatable security architecture development aligned with business goals
• Provide assurance that security measures address identified risks effectively
• Support risk reduction through a holistic view of security requirements and controls
• Benefit executives by linking security to business value and risk management
• Assist auditors by providing traceability between business requirements and implemented controls
• Guide security architects and engineers in designing and validating security solutions
• Facilitate decision-making and accountability through clear mappings from business needs to technical implementations

Scope & Applicability

• Applicable across industries and organizational sizes, particularly in complex enterprises requiring alignment between business and security
• Covers all security domains including governance, risk management, compliance, identity and access management, data protection, and infrastructure security
• Excludes detailed operational security procedures which are addressed in complementary frameworks
• Requires foundational governance structures, asset inventories, and data classification schemes to effectively define security requirements

Core Structure

• Structured around six layers: Contextual, Conceptual, Logical, Physical, Component, and Operational
• Each layer addresses specific questions from business requirements to technical implementation
• Organized through a matrix of six architectural questions (What, How, Where, Who, When, Why) across the layers
• Terminology includes business attributes, security services, controls, and assurance levels
• Mapping anchors include business requirements linked to security capabilities and controls, enabling traceability

How It Is Used

• Typically adopted through phased rollouts beginning with business risk assessments and contextual architecture definition
• Used in gap analysis to identify missing security capabilities and control weaknesses
• Supports audit and attestation processes by providing structured documentation of security architecture decisions
• Guides engineering workflows by integrating security requirements into design reviews and software development lifecycle (SDLC) gates
• Enables backlog mapping to prioritize security enhancements based on risk and business impact

Implementation Artifacts

• Security policies, standards, and procedures derived from the architecture layers and business requirements
• Control libraries mapped to industry standards such as ISO/IEC 27001, NIST SP 800-53, and others
• Evidence packages including architecture diagrams, risk assessments, configuration baselines, and audit logs

Measurement & Maturity

• Key performance indicators (KPIs) include control coverage, risk reduction metrics, and compliance status
• Maturity models assess capabilities across architecture layers and organizational adoption levels
• Common baselines define minimum viable controls aligned with business risk appetite, progressing to advanced, integrated security architectures

Common Pitfalls

• Focusing on checklist compliance without aligning controls to actual business risks
• Over-scoping the architecture leading to complexity and difficulty in maintenance (“framework sprawl”)
• Unassigned ownership of controls, resulting in weak evidence collection and outdated documentation

Integration & Mapping

• Provides crosswalks to frameworks such as COBIT, TOGAF, ISO/IEC 27001, and NIST
• Integrates with Governance, Risk, and Compliance (GRC) platforms, Security Operations Centers (SOC), Incident Response (IR), and SDLC processes
• Supports tooling for control testing automation and continuous compliance monitoring

When Not to Use It

• May be too complex or resource-intensive for small organizations or those requiring lightweight security approaches
• Less suitable when regulatory requirements demand prescriptive controls rather than risk-driven architecture
• In such cases, simpler frameworks or staged adoption of SABSA components may be preferable

Standards & References

• Primary references include the SABSA Institute’s official publications and the SABSA Framework documentation
• Companion materials include implementation guides, case studies, and mappings to ISO/IEC 27001 and NIST standards