# SABSA Framework
SABSA (Sherwood Applied Business Security Architecture) is a methodology for developing risk-based, business-driven security and enterprise architecture frameworks. It exists because most security programs fail not from technical deficiency but from a fundamental disconnect between what the business requires and what security teams actually build. SABSA solves this by starting at the business requirement level and tracing every security control, mechanism, and configuration back to a documented business need. The result is a security architecture that can be explained, justified, and measured in terms executives and regulators understand, while still producing precise technical specifications that engineers can implement.
First published in 1995 by John Sherwood, Andrew Clark, and David Lynas, SABSA has become a widely adopted framework in enterprise security architecture and is supported by a formal certification program through The SABSA Institute. Unlike control frameworks such as NIST SP 800-53 or ISO 27001, which provide catalogs of security controls, SABSA is the architectural methodology that determines which controls an organization actually needs and why those specific controls create business value rather than mere compliance theater.
SABSA is not a technology standard. It does not prescribe specific products, vendors, or implementations. It is the systematic process for ensuring that every dollar spent on security can be traced to a specific business requirement and measured against business outcomes. This traceability is what separates mature security programs from collections of tools purchased in response to vendor presentations and compliance checklists.
SABSA operates through a structured six-layer model adapted from the Zachman Framework for Enterprise Architecture. Each layer represents a different level of abstraction, from business context down to operational implementation. Each layer is examined through six interrogatives: What (assets and entities), Why (motivation and risk), How (processes and functions), Who (people and roles), Where (locations and domains), When (events and timing). This produces a 36-cell matrix where every cell defines a specific architectural question that must be answered with traceable requirements.
The Six Layers in Practice
The Contextual layer captures business requirements in business language. The "What" cell identifies the business information and assets that require protection: customer data, intellectual property, financial records, operational systems. The "Why" cell documents business risk: regulatory penalties, competitive disadvantage, operational disruption, reputation damage. The "How" cell maps business processes: transaction flows, decision workflows, communication patterns. The "Who" cell identifies organizational roles: customers, employees, partners, regulators. The "Where" cell defines business locations: headquarters, branch offices, remote workers, cloud regions. The "When" cell captures business time dependencies: market hours, regulatory deadlines, seasonal peaks, incident response windows.
The Conceptual layer translates business requirements into security services defined in architectural terms. A business requirement for "customer data confidentiality" becomes a "data protection service." A requirement for "complete audit trails" becomes an "accountability service." A requirement for "service availability during market hours" becomes a "resilience service." These services are described functionally, not technically. No specific technologies are selected at this layer.
The Logical layer defines security mechanisms that implement the conceptual services. The data protection service becomes encryption-at-rest policies, data classification schemas, and access control rules. The accountability service becomes audit logging requirements, event correlation specifications, and evidence retention policies. The resilience service becomes recovery time objectives, backup strategies, and failover procedures. These mechanisms are precise enough that different technical teams could implement them consistently.
The Physical layer selects specific technologies, products, and infrastructure that implement the logical mechanisms. Encryption-at-rest policies become Azure Key Vault configurations and AES-256 specifications. Audit logging requirements become Splunk deployments and syslog forwarding rules. Recovery time objectives become active-active database clusters and automated failover scripts. This is where vendor selection, capacity planning, and integration architecture occur.
The Component layer defines precise implementation details: software versions, configuration parameters, integration specifications, deployment procedures. This layer produces the technical artifacts that system administrators and engineers need for actual implementation: hardened configuration baselines, installation scripts, integration guides, operational procedures.
The Operational layer defines how the security architecture is managed over time. This layer is often neglected in practice, but it is foundational to SABSA's business-driven approach. Service level agreements define the expected performance of each security service. Measurement frameworks track whether services are meeting business requirements. Governance processes ensure the architecture evolves as business requirements change. Operational procedures define how the architecture is maintained, updated, and validated on an ongoing basis.
Business Attribute Profiling: The Critical Foundation
Every SABSA engagement begins with Business Attribute Profiling, and this activity determines whether the entire engagement succeeds or becomes an expensive documentation exercise. A business attribute is a quality that the organization requires from its information environment: confidentiality, integrity, availability, accountability, assurance, privacy, authenticity, non-repudiation. These attributes must be defined in business terms, with specific contexts and measurable criteria.
Consider a healthcare organization implementing electronic health records. Generic security requirements might specify "patient data encryption" and "access controls." A SABSA practitioner conducting Business Attribute Profiling would work with clinical, administrative, and legal stakeholders to understand that the organization actually requires five distinct attributes: patient privacy (clinical data accessible only to treating providers), data integrity (medical records cannot be altered without audit trails), clinical availability (patient data accessible within 30 seconds during emergencies), regulatory accountability (all access logged for HIPAA compliance), and clinical assurance (providers can trust that data is complete and current). Each attribute has different business consequences, different technical requirements, and different measurement criteria.
Lifecycle Integration and Continuous Validation
SABSA defines four lifecycle phases that integrate architecture development with business operations. The Strategy and Planning phase establishes business context and high-level requirements. The Design phase develops the architecture through the six-layer model. The Implementation phase executes the technical deployment while maintaining traceability to business requirements. The Management and Measurement phase ensures the architecture continues to meet business needs over time.
The Management and Measurement phase is where most organizations fail to realize SABSA's full value. They complete the architectural design, implement the technical controls, and then treat the SABSA artifacts as static documentation. In practice, business requirements evolve continuously. New business processes are introduced. Regulatory requirements change. Technology platforms are upgraded or replaced. An effective SABSA implementation treats the architecture as a living system that is regularly validated against current business conditions.
Common Implementation Patterns and Failure Modes
Organizations implementing SABSA for the first time typically underestimate the time and stakeholder involvement required for genuine Business Attribute Profiling. Technical teams want to skip to technology selection. Business stakeholders assume that "security" is a generic requirement that does not require detailed business input. The result is often a SABSA matrix populated with generic attributes copied from other organizations rather than attributes that reflect actual business requirements and risk tolerance.
A second common failure is treating the SABSA matrix as a documentation requirement rather than a decision-making tool. Teams focus on completing all 36 cells rather than using the matrix to identify gaps, conflicts, and missing requirements. The matrix is valuable because it forces explicit traceability: if a cell cannot be completed with confidence, it signals that requirements are incomplete or that design decisions are being made without adequate business justification.
Successful SABSA implementations are typically conducted iteratively rather than as comprehensive waterfall projects. An organization might begin by applying SABSA to a single critical business process, complete the full six-layer analysis for that process, implement the resulting architecture, and validate the operational outcomes before expanding to additional processes. This approach delivers immediate value while building organizational competence with the methodology.
Security programs that develop without explicit architectural methodology accumulate controls reactively. Tools are purchased in response to vendor demonstrations, compliance audits, and security incidents rather than in response to documented business requirements. The result is a security estate that is expensive, difficult to operate, and impossible to explain to stakeholders who need to understand what they are buying and whether it is working.
This reactive approach creates multiple business consequences. First, security spending becomes arbitrary. When executives ask why the organization needs a specific security tool or why security budgets are increasing, the security team cannot provide business justifications that executives can evaluate against other business investments. Second, compliance becomes a periodic scramble rather than a continuous state. When auditors or regulators ask why specific controls exist and how they address specific business risks, the organization cannot demonstrate clear traceability from requirements to implementation.
Third, security teams cannot communicate effectively with business stakeholders because they cannot connect technical security measures to business outcomes. When a business unit requests an exception to a security policy, the security team cannot explain which business requirements would be affected or what the trade-offs are. When security incidents occur, the organization cannot quickly determine which business processes are affected and what the business impact is.
The Hidden Cost of Architecture Debt
Organizations without explicit security architecture accumulate what can be understood as "architecture debt" that eventually requires expensive remediation. Multiple security tools are deployed without integration, creating operational silos where security analysts cannot correlate events across systems. Security policies are developed reactively for specific situations without consideration of how they affect other business processes or technical systems. Security controls are configured differently across different systems because there is no architectural specification that defines consistent implementation standards.
When these organizations face regulatory scrutiny, merger and acquisition due diligence, or major security incidents, they discover that their security posture cannot be quickly assessed or explained because there is no architectural framework that connects technical controls to business requirements. The remediation process often requires significant re-architecture work that could have been avoided with initial SABSA application.
SABSA vs. Compliance Theater
A common misconception is that formal compliance with security standards such as ISO 27001 or SOC 2 provides adequate security architecture. These standards define control objectives and implementation guidance, but they do not provide the methodology for determining which specific controls an organization needs or how those controls should be prioritized and integrated based on business requirements.
Organizations can achieve formal compliance while implementing controls that are poorly suited to their actual business requirements and risk profile. They can pass audits while operating security programs that provide minimal business value because the controls were selected from catalogs rather than derived from business-driven architectural analysis. SABSA provides the architectural discipline that ensures compliance efforts are directed toward controls that address genuine business requirements rather than generic security objectives.
The Cyber Defense Assurance (CDA) approach to SABSA is grounded in the Risk Governance and Assurance (RGA) domain of the Planetary Defense Model and operationalized through the Perpetual Compliance Assurance (PCA) methodology. Where traditional SABSA implementations treat the framework as an architectural design methodology, CDA treats SABSA as an operational discipline that integrates directly with continuous control validation and business risk management.
The PCA methodology holds that compliance is not an event but a state. This principle aligns directly with SABSA's Operational layer, which defines ongoing measurement and governance rather than point-in-time architectural assessment. CDA maintains SABSA artifacts as living architecture records that are continuously validated against operational telemetry and business requirements. Business Attribute Profiles are mapped to specific control assertions in the CDA control library, with each assertion assigned monitoring cadence, evidence sources, and performance thresholds.
When a business attribute specified at the Contextual layer requires 99.9% availability for a critical business process, CDA's PCA monitoring continuously validates that the Physical and Component layer controls supporting that attribute are functioning within specification. When controls drift out of configuration or performance degrades below business requirements, automated workflows initiate review against the SABSA traceability chain to determine which business attributes are affected and what risk exposure the organization faces.
CDA's operational approach extends SABSA's lifecycle model beyond traditional architecture practice. Each SABSA phase becomes a distinct deliverable with defined acceptance criteria and continuous validation requirements. The Strategy and Planning phase establishes business context that is regularly reviewed against changing business conditions. The Design phase produces architectural specifications that are maintained as the organization's technical environment evolves. The Implementation phase includes validation procedures that ensure deployed controls match architectural specifications. The Management and Measurement phase provides the operational framework for continuous business-driven security assurance.
Within the Security Program Hygiene (SPH) domain, CDA applies SABSA's Component layer discipline to ensure that configuration specifications derived from architectural analysis are enforced through hardened baselines and continuous configuration management. This integration means that SABSA's business-driven architecture is not merely documented but operationally enforced on a continuous basis.