SABSA UnlockedBusiness-driven security architecture for enterprise security architects
Beyond the Framework, Field-Proven Techniques for Security Architecture Success. A method and toolkit for business-driven security architecture, in two volumes.
A practitioner toolkit that helps enterprise security architects implement a business-driven SABSA security architecture: what to collect, in what order, which artefacts to produce, and how to keep every decision traceable to a business need.
SABSA® is a registered trademark of The SABSA Institute. The SABSA method was created by John Sherwood, Andrew Clark and David Lynas and is stewarded by The SABSA Institute. SABSA Unlocked is an independent implementation method written by GreyHyphen Labs; it is not part of the official SABSA body of knowledge, does not reproduce it, and is not endorsed or certified by The SABSA Institute. ArchiMate, ISO/IEC 27001, NIST, CIS Benchmarks and OWASP are the property of their respective owners.
SABSA Unlocked is a practitioner toolkit from GreyHyphen Labs. It helps enterprise security architects put a business-driven security architecture into practice: what to collect, in what order, which artefacts to produce, and how to keep every security decision traceable to a business need.
The guidelines are published in two volumes that follow the layers of the SABSA model.
Volume
Layers covered
SABSA lifecycle phase
What it produces
Volume 1 — Architecture Layers
Contextual and Conceptual
Strategy & Planning
Business requirements, security-focused business drivers, the business attributes profile, the business risk model, control objectives, security domains, lifetimes and the list of logical security services.
Volume 2 — Design Layers
Logical, Physical and Component
Design
A repeatable design pattern, a design canvas for each logical security service, specifications, logical designs and recorded design decisions.
This volume covers the first phase. It is written to be used, not only read: every section ends with the artefact the architect is expected to hold, and Annexes A to D provide ready-to-use templates, example artifacts, an interview guide, a threat catalogue and baseline non-functional security requirements.
Sections marked Example artifact show what a finished deliverable looks like. They are generalised from real enterprise security architecture engagements: organisation, people, regulator, vendor and product names have been removed. Treat them as illustrations to adapt, not as answers to copy.
NOTE SABSA® is a registered trademark of The SABSA Institute. The SABSA method was created by John Sherwood, Andrew Clark and David Lynas and is stewarded by The SABSA Institute. SABSA Unlocked is an independent implementation guideline written by GreyHyphen Labs. It is not part of the official SABSA body of knowledge, does not reproduce it, and is not endorsed or certified by The SABSA Institute. Practitioners should refer to the SABSA Institute's own publications for the authoritative method.
Who should use them
Enterprise and security architects who must show that a design follows from a business need.
Security leaders who need a defensible line from strategy to investment.
Risk, compliance and assurance teams whose registers feed the architecture.
Consultancies and integrators who build security architectures for clients and must hand over something traceable.
How to use this volume
Read Sections 1 to 4 once. They explain the model, the lifecycle and the reasoning behind a business-driven approach.
Use Section 5 (Contextual) and Section 6 (Conceptual) as the working method for each engagement, in order.
Copy the templates in each section and in the annexes into your own working documents. Fill them for your organisation; do not adopt the examples as they stand.
Carry the outputs of Section 6 — the logical security services — into Volume 2.
1. The SABSA model in practice
Security exists to protect business strategy, goals and assets by managing risk — and, just as importantly, to let the business take opportunities safely. SABSA provides a framework for developing risk-driven enterprise security architectures that trace every control back to a business requirement.
The SABSA model has six layers. Each layer is the view of a different participant in specifying, designing, building and running the architecture.
Layer
View
Architecture
SABSA Unlocked volume
1
The Business View
Contextual security architecture
Volume 1
2
The Architect's View
Conceptual security architecture
Volume 1
3
The Designer's View
Logical security architecture
Volume 2
4
The Builder's View
Physical security architecture
Volume 2
5
The Tradesperson's View
Component security architecture
Volume 2
6
The Service Manager's View
Security service management architecture
Spans both; applied through Manage & Measure
Figure 1Six layers, six views — and where each volume works
1
The Business ViewContextual security architecture
Volume 1
2
The Architect's ViewConceptual security architecture
Volume 1
3
The Designer's ViewLogical security architecture
Volume 2
4
The Builder's ViewPhysical security architecture
Volume 2
5
The Tradesperson's ViewComponent security architecture
Volume 2
6The Service Manager's View · Security service management architecture
Layer 6 spans the others: every layer has a management and measurement concern.
Across the layers, the model asks the same six questions — what, why, how, who, where and when. At the contextual layer these become the business assets, the business risk, the business process, the business governance, the business geography and the business time dependencies. This volume works through each of them.
What
Why
How
Who
Where
When
Assets
Motivation
Process
People
Location
Time
Business decisions, drivers, requirements and goals
Business risk
Business process
Business governance (roles and responsibilities)
Business geography
Business time dependence
FigureThe contextual architecture in eight steps
01Business requirementsWhat · 5.1
02Business driversWhat · 5.2
03Business attributesWhat · 5.3
04Business process modelHow · 5.4
05Organisation and extended enterpriseWho · 5.5
06Business geographyWhere · 5.6
07Time dependenciesWhen · 5.7
08Business risk modelWhy · 5.8
Each step ends with a register the next layer depends on.
End of the Volume 1 preview. The full volume continues with 9 more sections — every template, figure, example artifact and annex.
SABSA Unlocked is a practitioner toolkit from GreyHyphen Labs. It helps enterprise security architects put a business-driven security architecture into practice and keep every security decision traceable to a business need.
The guidelines are published in two volumes that follow the layers of the SABSA model.
Volume
Layers covered
SABSA lifecycle phase
What it produces
Volume 1 — Architecture Layers
Contextual and Conceptual
Strategy & Planning
Business requirements, security-focused business drivers, the business attributes profile, the business risk model, control objectives, security domains, lifetimes and the list of logical security services.
Volume 2 — Design Layers
Logical, Physical and Component
Design
A repeatable design pattern, a design canvas for each logical security service, specifications, logical designs, physical and component specifications and recorded design decisions.
This volume covers the Design phase. It starts where Volume 1 ends — with an agreed list of logical security services, each traced to business drivers, risks and mechanisms — and takes each service down through the logical, physical and component layers.
Sections marked Example artifact show what a finished design deliverable looks like. They are generalised from real enterprise security architecture engagements: organisation, people, regulator, vendor and product names have been removed and replaced with generic capability names. Treat them as illustrations to adapt, not as designs to copy.
NOTE SABSA® is a registered trademark of The SABSA Institute. The SABSA method was created by John Sherwood, Andrew Clark and David Lynas and is stewarded by The SABSA Institute. SABSA Unlocked is an independent implementation guideline written by GreyHyphen Labs. It is not part of the official SABSA body of knowledge, does not reproduce it, and is not endorsed or certified by The SABSA Institute. Practitioners should refer to the SABSA Institute's own publications for the authoritative method.
Who should use it
Security architects and designers who must turn a list of logical security services into designs that can be procured and built.
Solution and infrastructure architects who need to see how security services integrate with their platforms.
Engineering and operations teams who build, configure and run the resulting controls.
Consultancies and integrators who must hand over a design that remains traceable to the client's business drivers.
How to use this volume
Read Sections 1 and 2 once. They explain the three design layers and the design pattern every service follows.
For each logical security service from Volume 1, copy the templates in Annex B and complete the four sections of the pattern.
Use the Example artifacts in Sections 4 to 8 as a reference for depth and style.
Carry each logical design down to the physical and component layers (Section 9), then hand over to service management (Section 10).
2. The design pattern
Every logical security service is designed using the same reusable pattern, so that designs can be compared, reviewed and maintained consistently. Each service design has four sections, preceded by its traceability record.
Figure 3The reusable design pattern
0Traceability recordDriver → risk → mechanism → service → NFR
1OverviewAnd solution components
2SpecificationsAnd business requirements
3Design canvasLogical design
4Design decisionsDated and attributed
2.1 Traceability record
Open every service design with the line of reasoning that justifies it, taken directly from Volume 1:
Source
Statement
Business driver
The security-focused business driver the service supports.
Risk
The threat or threats from the business risk register that the service treats.
Mechanism — technical
The technical mechanism selected in the risk treatment.
Mechanism — procedural
The procedural mechanism that accompanies it.
Logical service
The logical security service, as listed at the end of the conceptual architecture.
Non-functional requirement
The baseline or specific non-functional security requirement the service enforces.
If a design cannot complete this table, it is either not needed or Volume 1 is incomplete. Either way, stop and resolve it before designing.
2.2 Service overview and solution components
A short write-up — one or a few paragraphs, depending on complexity — that introduces the service and its relationship to the business. The solution components subsection lists and describes the technical solutions included or planned to build the service.
2.3 Specifications and business requirements
This section lists:
Specifications — quantities and characteristics that drive sizing, licensing and platform choice: number and types of users, number of devices, servers, databases and applications, hosting model (cloud, virtualised, hardware), environments in scope.
Business requirements — the specific functions and configurations the service must provide to meet functional and non-functional requirements.
2.4 Design canvas and logical design
A clear understanding of the core components of a design, and of its flow from top to bottom and bottom up, is developed using a reusable base diagram drawn in ArchiMate notation. The canvas has six areas. On the left, read bottom up: technologies, the interfaces they are composed of, the functions those interfaces are assigned to, and the security services the functions realise. On the right: the business services to be served and the integrations — security monitoring, access management, mail and others — that the service relies on for non-functional purposes. Every logical design is drawn on the same canvas, using the same notation, in an ArchiMate-capable modelling tool.
Figure 4Logical design components and their relations
Figure 5The design canvas
Read bottom-up: technologies are composed of interfaces, interfaces are assigned to functions, functions realise security services, and security services serve the business.
2.5 Design decisions
Design is developed through workshops and meetings. This section records every decision made: a specific configuration, a recommendation to follow during implementation, a constraint accepted, or any other point that supports the design or its implementation. Each decision should be dated and attributed to the forum that made it.
4. Example artifact — Policy and compliance management
4.1 Traceability record
Source
Statement
Business driver BD01
Cyber security assured: maintain compliance with current and future cybersecurity regulations and with the organisation's information security certification.
Risk 1
Non-compliance with regulatory and standards requirements.
Mechanism — technical
Compliance monitoring (technical and procedural).
Mechanism — procedural
Compliance monitoring process.
Logical service 1
Policy and compliance management.
Non-functional requirement D.1 (3)
All parties comply with the organisation's security policies and applicable data protection law at all times.
4.2 Service overview
The policy and compliance management service ensures that policies are developed to recognised industry standards, communicated and made available to staff and stakeholders, acknowledged, and then measured for compliance. It covers both manual and automated assurance, across procedural and technical controls.
Built-in global authoritative sources such as ISO/IEC 27001 and NIST, with the option to import or author national regulations such as the applicable data protection law.
Overall compliance reporting
Dashboards and reports for executive and security management giving a holistic view of security compliance across the organisation.
Remediation and disciplinary actions
Findings are either linked to an approved exception or carried into remediation. Human resources and other relevant functions can be involved for disciplinary action.
Workflows
A configurable workflow engine with conditional logic to automate lifecycles, compliance assessments and related actions.
Policy management
Policy lifecycle management
A single platform to author policies, submit them for review and approval, communicate them across the organisation and track acceptance.
Exceptions management
A central mechanism to raise exceptions against control standards and route them for approval at the appropriate level.
Compliance — procedural
Control standards
Map policies to standards and control procedures, and link them to regulations, frameworks and good practice.
Automated compliance
Measure the operational effectiveness of policies and standards through automated and manual assessments, with a reusable question library.
Technical controls manual assessment
A standard, central way to record evidence, rate each control and track compliance gaps.
Compliance — technical
Discovery
Discover all networks and assets, managed and unmanaged.
Configuration checks
Run automated hardening checks — or ingest results from an independent scanner — and roll them up into a compliance rating.
Vulnerability checks
Run automated vulnerability checks — or ingest results from an independent scanner — and roll them up into a compliance status.
Further requirements:
Integration with third-party vulnerability management through APIs or an equivalent mechanism.
Configuration baselines for industry benchmarks (for example CIS Benchmarks), the cloud provider's security baseline, and ad-hoc checks.
Search across policies, standards and procedures.
Notification and portal templates in the organisation's own branding.
Specification
Example value
Corporate users
250
Network infrastructure devices
100
Servers
100
Databases
To be confirmed during discovery
Web applications
To be confirmed during discovery
4.4 Policy lifecycle
The policy lifecycle has five stages: (1) draft or update; (2) review and approve; (3) communicate and publish; (4) receive acknowledgement; (5) manage exceptions.
Figure 6Example artifact — the policy lifecycle and policy structure
4.5 Logical design
The logical design covers policy, procedural and technical compliance, in automated and manual forms. It does not yet deal with physical implementation or component distribution: it defines the functions the organisation needs and the logical integrations required to meet the business requirements.
Figure 7Example artifact — logical design for policy and compliance management
Scanners and connectors feed one compliance view; non-compliance raises events to security monitoring.
4.6 Design decisions
In line with the organisation's cloud-first principle, the solution is a cloud service, with scanners deployed both in the primary cloud platform and on premises for configuration and vulnerability checks.
Corporate users authenticate through single sign-on to search, read and acknowledge policies, standards and procedures.
A policy exception request form and workflow are built to support the exception process.
The service is installed in the production environment only.
Compliance of the ERP landscape is measured through the ERP's own governance, risk and compliance module, integrated with the compliance solution for a consolidated view.
Compliance of the collaboration and productivity suite is assessed through the suite's native compliance centre and aggregated into the compliance solution.
Non-compliance with technical standards — vulnerability or hardening checks — is alerted to the security operations centre through SIEM integration.
The policy and compliance portal is published on the intranet only, over HTTPS.
Notification emails, the portal and reports carry the organisation's branding.
End of the Volume 2 preview. The full volume continues with 10 more sections — every template, figure, example artifact and annex.
Choose Volume 1, Volume 2 or the bundle, and tell us how you plan to use it. Pay securely online and your personal copies arrive by email within minutes.
Choose the titles, the licence and any add-ons — your total is calculated as you go
Pay by card, Apple Pay or Google Pay — your personal, licence-numbered copies are emailed to you within minutes
Each product page has a free preview; NorthX and Dueline have free 14-day trials
