Security architecture has a credibility problem. Organizations invest significant effort in building security frameworks, hiring architects, and producing documentation — and then find that the resulting architecture sits on a shelf, poorly understood by leadership, and inconsistently implemented by the teams meant to follow it.
The root cause is almost always the same: the architecture was designed around technology, not around the business. Controls were selected because they appeared in a framework checklist. Architecture decisions were made by security engineers without a clear line back to business objectives, risk appetite, or regulatory requirements.
SABSA was developed specifically to solve this problem. After 10+ years of applying it across financial services, insurance, public transit, and government, it remains the most rigorous and business-aligned approach to security architecture available.
What SABSA actually is
SABSA is a framework and methodology for developing risk-driven enterprise security architectures. It is not a controls catalogue — it does not tell you which firewall to buy or which SIEM to deploy. What it provides is a structured approach for ensuring that every security decision traces back to something that actually matters to your organization.
The framework is organized in layers, each corresponding to a different level of abstraction — from the business context at the top to the physical implementation at the bottom. The key insight is that architecture flows downward: what you build at each layer is determined by the requirements established in the layer above it.
Business Context Layer
Your business objectives, regulatory obligations, risk appetite, and strategic drivers. This is the starting point — everything else derives from here. Security decisions without this foundation are guesses.
Conceptual Architecture
The high-level security concepts and principles that will govern the architecture — derived directly from the business context. What security properties does the business actually need?
Logical Architecture
The security services, information flows, and logical relationships that will deliver the required security properties. Still technology-independent — focused on what, not how.
Physical Architecture
The specific technologies, products, and implementations that will deliver the logical architecture. Technology choices are made here — justified by the layers above.
Component Architecture
The specific components, configurations, and standards that implement the physical architecture. Detailed specifications for builders and implementers.
The discipline of SABSA is working top-down — refusing to make technology decisions until the business requirements are understood, and refusing to make implementation decisions until the architecture is validated. In practice, most organizations do the opposite: they start with the technology they have or are being sold, and try to fit security requirements around it after the fact.
The difference this makes in practice
The practical difference between a SABSA-aligned architecture and a technology-first architecture shows up most clearly in three situations.
When the board asks security questions. A SABSA-aligned architecture is designed to be explained in business terms, because it was designed from business terms. When a board member asks "how exposed are we to a ransomware attack?" the answer connects directly to business risk, not to a list of security controls. Organizations with technology-first architectures struggle to answer this question coherently — because their security program was never designed around business risk in the first place.
When regulatory requirements change. Regulatory requirements are ultimately business requirements — they reflect what regulators expect of organizations operating in their sector. A SABSA-aligned architecture incorporates regulatory obligations at the business context layer, meaning that when requirements change the impact on the architecture can be assessed systematically. Technology-first architectures typically require expensive rework because there is no structured mapping between regulatory requirements and security controls.
When projects need security review. One of the most common failure modes in enterprise security architecture is the disconnect between the security architecture team and the project delivery teams. Projects get delivered with security problems because the security requirements were not clear, not communicated, or not enforced. SABSA addresses this by providing a structured approach to security architecture review — one that evaluates projects against the agreed business context and security principles, not against the personal preferences of the reviewing architect.
SABSA vs. NIST, ISO 27002, and other frameworks
A common question is how SABSA relates to NIST CSF, ISO 27002, and CIS Controls — the frameworks most organizations are already familiar with.
How SABSA and other frameworks relate
- SABSA is an architecture methodology — it tells you how to design and build security architecture aligned to business objectives
- NIST CSF is a risk management framework — it provides a structure for organizing security capabilities into functions (Identify, Protect, Detect, Respond, Recover)
- ISO 27002 is a controls catalogue — it provides a comprehensive list of security controls organized by domain
- CIS Controls is a prioritized set of security actions — practical guidance on what to implement, in what order
These are complementary, not competing. A mature security architecture uses SABSA to design the architecture, NIST CSF or ISO 27002 to organize the control requirements, and CIS Controls or similar guidance for implementation priorities.
In practice, most of our engagements use a hybrid approach: SABSA methodology for architecture design and business alignment, NIST CSF for program structure and maturity assessment, and ISO 27002 or sector-specific standards for control requirements. The specific combination depends on the organization's regulatory context and existing frameworks.
Capability mapping — finding the gaps you didn't know you had
One of the most practically useful outputs of a SABSA-aligned architecture engagement is the security capability map — a diagram that maps your existing security technologies and controls to the security capabilities they are meant to deliver.
In almost every engagement, this exercise reveals the same pattern: some capabilities are delivered by multiple overlapping controls (duplication and waste), and other capabilities have no controls delivering them at all (critical gaps). Neither is visible from a list of technologies or a controls compliance spreadsheet — they only become visible when you map technologies to capabilities.
What capability mapping typically reveals
- Critical capabilities with no controls delivering them — invisible from a technology inventory
- Multiple redundant tools delivering the same capability — consolidation opportunities
- Capabilities delivered by a single aging control with no backup — single points of failure
- Controls that are deployed but not actually delivering their intended capability — misconfiguration and drift
- Regulatory requirements with no mapped controls — compliance gaps waiting to be discovered in an audit
The credibility test
There is a simple test for whether your security architecture is genuinely business-aligned: can your CISO or security architect explain, in plain language, why each major security control exists — connecting it directly to a specific business risk or regulatory requirement?
If the answer is "because it's in the framework" or "because we've always done it this way," the architecture is not business-aligned. Controls that cannot be justified in business terms will not receive adequate funding, will not be properly maintained, and will eventually be bypassed or ignored.
SABSA enforces this discipline by building it into the methodology — every security decision must trace back to the business context layer. After 10+ years of applying this approach, it consistently produces architectures that leadership understands, can justify, and will fund.
Where to start
For most organizations, the right starting point is not a full SABSA architecture engagement — it is a security capability assessment. Map your current security technologies to the capabilities they deliver, identify the critical gaps, and build a prioritized roadmap from there.
That assessment, done well, provides the business context and gap analysis needed to make informed security investment decisions — regardless of whether you then proceed with a full SABSA architecture engagement or a more targeted improvement program.
Goni Sarakinov is a SABSA Chartered Security Architect (Foundation). Sarakinov Consulting provides SABSA-based security architecture advisory to regulated organizations across Canada.
Continue reading