SABSA Security Architecture: [Enterprise, domain or solution name]
Business-driven security architecture record organised on the layers
and questions of SABSA, the enterprise security architecture method
maintained by The SABSA Institute. It starts from business drivers,
builds a business attributes profile with a measurement approach,
metric and target for each attribute, and traces those attributes down
through the contextual, conceptual, logical, physical and component
layers, with security service management across all of them. Each
layer is analysed by six questions: what (assets), why (motivation),
how (process), who (people), where (location) and when (time). The
text, examples and guidance are original; use your licensed SABSA
material for the method itself. Replace every [bracketed] value and
every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [SSA-001] |
| Architecture scope | [Enterprise / Security domain / Solution]: [name] |
| Business sponsor | [@business-sponsor] |
| Method basis | SABSA (The SABSA Institute), [edition or white paper used under licence] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@security-architect] |
| Approvers/reviewers | [@ciso], [@enterprise-architect], [@risk-officer], [@service-owner] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Enterprise architecture], [Risk methodology], [Security policy framework] |
Approvals
| Role | Name | Decision | Date |
|---|
| Business sponsor (attributes profile and risk appetite) | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Enterprise architecture board | [@name] | [Decision] | YYYY-MM-DD |
| Risk and compliance | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Attributes profile and conceptual layer approved by the business sponsor |
| 1.1 | YYYY-MM-DD | [@name] | Example: Physical and component layers added for the cloud migration |
Contents
1. Purpose, scope and approach
1.1 Purpose
This document defines the security architecture for [scope] so that
every security requirement, service and mechanism can be justified by a
business need and measured against an agreed target. It is used to:
- agree with the business what "secure enough" means, as attributes
with metrics and targets;
- derive control and enablement objectives, security services and
mechanisms from those attributes;
- show auditors and investors the two-way traceability from business
driver to running control and back;
- prioritise investment by the gap between target and measured
performance.
1.2 Scope
| In scope | Out of scope |
|---|
| Example: Retail banking channels, payments and customer data platform | Corporate real estate |
| Example: Hybrid hosting: two data centres and one public cloud provider | Subsidiaries with separate licences |
| [Item] | [Item] |
1.3 Layers and questions used
The architecture is described in layers, each written for a different
audience, and every layer answers the same six questions. The matrix
below shows the structure of this document only; the content of each
cell is defined in sections 5 to 10.
| Layer (audience) | What: assets | Why: motivation | How: process | Who: people | Where: location | When: time |
|---|
| Contextual (business leadership) | 5.1 | 5.2 | 5.3 | 5.4 | 5.5 | 5.6 |
| Conceptual (architect) | 6.1 | 6.2 | 6.3 | 6.4 | 6.5 | 6.6 |
| Logical (designer) | 7 | 7 | 7 | 7 | 7 | 7 |
| Physical (builder) | 8 | 8 | 8 | 8 | 8 | 8 |
| Component (specialist and product owner) | 9 | 9 | 9 | 9 | 9 | 9 |
| Security service management (operations, across all layers) | 10 | 10 | 10 | 10 | 10 | 10 |
1.4 Method notes
- Work from the top layer down for design, and from the bottom layer up
to check completeness: every component must serve something above it.
- Write each layer in the vocabulary of its audience. The contextual
layer contains no technology names; the component layer contains
product names and versions.
- Record decisions as you go in the Architecture decision log
(
architecture/architecture-decision-log).
2. Business context and drivers
2.1 Business drivers
| ID | Business driver | Source | Owner | Horizon |
|---|
| BD-001 (Example) | Grow digital account openings by moving onboarding fully online | Strategy 20XX to 20XX | @retail-director | 3 years |
| BD-002 (Example) | Offer partners real-time payment initiation through APIs | Open banking programme | @payments-director | 2 years |
| BD-003 (Example) | Exit one data centre and run core services in the public cloud | Technology strategy | @cio | 3 years |
| BD-004 (Example) | Meet operational resilience obligations from the financial regulator | Regulation | @coo | Ongoing |
| [BD-NNN] | [Driver] | [Source] | [@owner] | [Horizon] |
2.2 Stakeholders
| Stakeholder | Interest in security | Influence | Engagement |
|---|
| Board risk committee (Example) | Risk appetite and resilience | High | Quarterly scorecard (section 12) |
| Product owners (Example) | Fast, low-friction customer journeys | High | Attribute workshops |
| Regulators (Example) | Evidence of control and resilience | High | Through compliance team |
| Customers (Example) | Privacy, fraud protection, availability | Medium | Through customer research |
| [Stakeholder] | [Interest] | [H / M / L] | [Engagement] |
2.3 Constraints
| ID | Constraint | Type | Effect on the architecture |
|---|
| CON-001 (Example) | Customer data must stay in [jurisdiction] | Legal | Location column at every layer |
| CON-002 (Example) | Core banking platform supports only legacy authentication protocols | Technical | Identity broker in the logical layer |
| [CON-NNN] | [Constraint] | [Legal / Contractual / Technical / Financial / Cultural] | [Effect] |
3. Business attributes profile
3.1 Attribute selection
Choose between 10 and 25 attributes for an enterprise scope and fewer
for a solution. Group them in categories that make sense to your
stakeholders (for example user experience, operations, risk management,
legal and regulatory, technology strategy, business strategy). Write the
definition in your own organisation's language.
| ID | Attribute | Category | Definition for this organisation | Drivers served |
|---|
| BA-001 (Example) | Available | Operations | Customers can open accounts and make payments whenever they choose, including during a regional outage | BD-001, BD-004 |
| BA-002 (Example) | Easy to use | User experience | Security steps add no more than one interaction to a standard customer journey | BD-001 |
| BA-003 (Example) | Confidential | Risk management | Customer data is visible only to the customer and to staff with a current business need | BD-001, BD-002 |
| BA-004 (Example) | Auditable | Legal and regulatory | Every significant action can be attributed to a person or system and reconstructed after the event | BD-004 |
| BA-005 (Example) | Partner-ready | Business strategy | A vetted partner can be connected through standard APIs within agreed onboarding times | BD-002 |
| BA-006 (Example) | Recoverable | Operations | Important business services return within tolerance after severe but plausible disruption | BD-003, BD-004 |
| BA-007 (Example) | Portable | Technology strategy | Workloads can move between hosting locations without redesigning security controls | BD-003 |
| [BA-NNN] | [Attribute] | [Category] | [Definition] | [BD-NNN] |
3.2 Measurement approach, metrics and targets
Each attribute needs a way to measure it. The targets express the risk
appetite: the business sponsor approves them, not the security team.
| ID | Measurement approach | Metric | Target | Data source | Frequency | Owner |
|---|
| BA-001 (Example) | Service monitoring of customer journeys | Availability of onboarding and payment journeys | 99.95 % monthly | Synthetic monitoring | Monthly | @sre-lead |
| BA-002 (Example) | Journey analytics | Added steps from security controls in the standard journey | 1 or fewer | Product analytics | Quarterly | @product-owner |
| BA-003 (Example) | Access analytics and incident records | Confirmed unauthorised disclosures of customer data | 0 per quarter | Incident register | Quarterly | @ciso |
| BA-004 (Example) | Log coverage review | Share of critical systems with complete, tamper-evident audit trails | 100 % | Logging platform | Monthly | @security-operations |
| BA-005 (Example) | Onboarding records | Median partner onboarding time from approval to production | 20 working days | Partner portal | Quarterly | @api-platform-lead |
| BA-006 (Example) | Resilience testing | Important business services recovered within tolerance in tests | 100 % of tests | Test reports | Twice a year | @resilience-lead |
| BA-007 (Example) | Architecture review | Workloads using provider-neutral security patterns | 80 % | Review records | Yearly | @enterprise-architect |
| [BA-NNN] | [Approach] | [Metric] | [Target] | [Source] | [Frequency] | [@owner] |
All targets above are illustrative. Agree real values with the business
sponsor and record the approval date.
3.3 Attribute conflicts
| ID | Attributes | Tension | Resolution |
|---|
| ACF-001 (Example) | BA-002 Easy to use, BA-003 Confidential | Strong authentication adds friction | Risk-based step-up: extra checks only for unusual context |
| ACF-002 (Example) | BA-005 Partner-ready, BA-003 Confidential | Partner APIs widen data exposure | Consent-scoped tokens and per-partner data minimisation |
| [ACF-NNN] | [Attributes] | [Tension] | [Resolution] |
4. Risk and opportunity
4.1 Attribute-based risk
| ID | Attribute at risk | Threat or cause | Likelihood | Impact on target | Appetite | Response |
|---|
| RSK-001 (Example) | BA-001 Available, BA-006 Recoverable | Ransomware on shared infrastructure | Medium | Target missed for days | Low | Reduce: segmentation, isolated recovery |
| RSK-002 (Example) | BA-003 Confidential | Partner token misuse | Medium | Disclosure of customer data | Very low | Reduce: consent scopes, anomaly detection |
| RSK-003 (Example) | BA-004 Auditable | Log loss during cloud migration | Low | Regulatory finding | Low | Reduce: dual logging during transition |
| [RSK-NNN] | [BA-NNN] | [Cause] | [L / M / H] | [Impact] | [Appetite] | [Response] |
4.2 Opportunities enabled by security
| ID | Opportunity | Attribute | Enabler | Benefit owner |
|---|
| OPP-001 (Example) | Instant account opening without branch visit | BA-001, BA-002 | Remote identity proofing at the required assurance level | @retail-director |
| OPP-002 (Example) | New revenue from premium partner APIs | BA-005 | Partner security certification process | @payments-director |
| [OPP-NNN] | [Opportunity] | [BA-NNN] | [Enabler] | [@owner] |
Use the organisation's Risk methodology (compliance/risk-methodology)
for scales and record accepted risks in the Risk register
(compliance/risk-register).
5. Contextual layer
5.1 What: business assets
| ID | Business asset | Value to the business | Attributes that apply |
|---|
| AST-001 (Example) | Customer trust and brand | Retention, lower acquisition cost | BA-002, BA-003 |
| AST-002 (Example) | Customer and transaction information | Regulatory obligation, product insight | BA-003, BA-004 |
| AST-003 (Example) | Ability to move money in real time | Core revenue | BA-001, BA-006 |
| [AST-NNN] | [Asset] | [Value] | [BA-NNN] |
5.2 Why: business motivation
Link each driver from section 2.1 to the attributes and risks it
creates. Example: BD-002 (partner APIs) motivates BA-005 and BA-003
and introduces RSK-002 and OPP-002.
5.3 How: business processes
| Process | Attributes most at stake | Notes |
|---|
| Customer onboarding (Example) | BA-002, BA-003 | Fully digital from [year] |
| Payment initiation and settlement (Example) | BA-001, BA-004, BA-006 | Real-time scheme participation |
| Partner onboarding (Example) | BA-005 | New process |
| [Process] | [BA-NNN] | [Notes] |
5.4 Who: people and organisations
Example: Retail customers, small business customers, branch and call
centre staff, partner fintech firms, outsourced operations provider,
regulators and auditors. Record any party with special trust needs.
5.5 Where: geography
Example: Customers in [countries]; operations in [locations]; data
hosted in [jurisdiction] only (CON-001).
5.6 When: business time
Example: Real-time payments 24 hours a day; month-end and year-end
peaks; regulatory reporting deadlines; change freeze periods.
6. Conceptual layer
6.1 What: control and enablement objectives
| ID | Objective | Attribute | Type |
|---|
| CO-001 (Example) | Ensure only authorised parties can read or change customer data | BA-003 | Control |
| CO-002 (Example) | Keep important business services within impact tolerance | BA-001, BA-006 | Control |
| CO-003 (Example) | Let vetted partners consume data with customer consent | BA-005 | Enablement |
| CO-004 (Example) | Make significant actions attributable and reconstructable | BA-004 | Control |
| [CO-NNN] | [Objective] | [BA-NNN] | [Control / Enablement] |
6.2 Why: security strategies and principles
| ID | Principle | Objectives served |
|---|
| SP-001 (Example) | Verify every access request explicitly, wherever it comes from | CO-001, CO-003 |
| SP-002 (Example) | Design for recovery as well as prevention | CO-002 |
| SP-003 (Example) | Prefer controls built into platforms over controls added by each team | CO-001, CO-004 |
| [SP-NNN] | [Principle] | [CO-NNN] |
Align these with the Architecture principles
(architecture/architecture-principles) and the Zero trust
architecture plan (security/zero-trust-architecture).
6.3 How: security process concept
Example: Identity lifecycle, access governance, secure delivery,
monitoring and response, resilience testing and third-party assurance
are the security processes that realise the objectives. Detail them in
the logical layer.
6.4 Who: roles and trust concept
| Party | Trust level | Basis of trust |
|---|
| Customer (Example) | Verified identity, low privilege | Identity proofing, risk-based authentication |
| Partner (Example) | Contracted, scoped | Certification, consent, signed agreements |
| Staff (Example) | Vetted, role-based | Screening, least privilege, monitoring |
| [Party] | [Level] | [Basis] |
6.5 Where: security domain concept
Each domain has one policy authority and a defined set of inter-domain
trust relationships. Record them:
| Domain | Policy authority | Trusted by | Trusts |
|---|
| Channel (Example) | @digital-security-lead | Core (through gateway only) | Security management |
| Core (Example) | @core-security-lead | None directly from external | Channel, Security management |
| [Domain] | [@authority] | [Domains] | [Domains] |
6.6 When: time concept
Example: Session lifetimes, credential validity periods, review cycles
and recovery time objectives per attribute (BA-006 tolerance 2 hours
for payments).
7. Logical layer
| ID | Logical security service | Question | Objectives met | Domain | Policy reference |
|---|
| LS-001 (Example) | Customer authentication with risk-based step-up | Who | CO-001 | Channel | POL-IAM-01 |
| LS-002 (Example) | Partner authorisation and consent enforcement | Who, Why | CO-003 | Channel | POL-API-02 |
| LS-003 (Example) | Data classification and protection policy service | What | CO-001 | Core | POL-DAT-01 |
| LS-004 (Example) | Security event collection and correlation | How | CO-004 | Security management | POL-LOG-01 |
| LS-005 (Example) | Backup isolation and recovery orchestration | When | CO-002 | Core | POL-RES-01 |
| LS-006 (Example) | Inter-domain policy enforcement point | Where | CO-001, CO-003 | All boundaries | POL-NET-01 |
| [LS-NNN] | [Service] | [Question] | [CO-NNN] | [Domain] | [Policy] |
Logical information flows between domains are listed with their
classification and the service that protects them:
| Flow | From domain | To domain | Classification | Protecting services |
|---|
| Payment instruction (Example) | Channel | Core | Confidential | LS-001, LS-006 |
| Partner data request (Example) | External | Channel | Confidential | LS-002, LS-006 |
| [Flow] | [Domain] | [Domain] | [Class] | [LS-NNN] |
8. Physical layer
| ID | Security mechanism | Implements | Platform or location | Notes |
|---|
| PM-001 (Example) | OpenID Connect with phishing-resistant authenticators and adaptive policies | LS-001 | Cloud identity platform | Step-up rules in policy store |
| PM-002 (Example) | OAuth 2.0 with a high-security API profile, consent records | LS-002 | API gateway | Partner certificates bound to tokens |
| PM-003 (Example) | Field-level encryption with customer-managed keys | LS-003 | Core data platform | Keys in a hardware-backed service |
| PM-004 (Example) | Central log pipeline with tamper-evident storage | LS-004 | Security management domain | Retention per legal register |
| PM-005 (Example) | Immutable backups in an isolated account with separate identities | LS-005 | Cloud and data centre 2 | Restore drills quarterly |
| [PM-NNN] | [Mechanism] | [LS-NNN] | [Platform] | [Notes] |
9. Component layer
| ID | Component (product and version) | Mechanism | Configuration standard | Owner | Support end |
|---|
| CMP-001 (Example) | [Identity platform, version] | PM-001 | [Hardening guide ID] | @iam-lead | YYYY-MM-DD |
| CMP-002 (Example) | [API gateway product, version] | PM-002 | [Gateway baseline] | @api-platform-lead | YYYY-MM-DD |
| CMP-003 (Example) | [Key management service] | PM-003 | [Key policy standard] | @platform-lead | YYYY-MM-DD |
| CMP-004 (Example) | [SIEM or log platform] | PM-004 | [Logging standard] | @security-operations | YYYY-MM-DD |
| [CMP-NNN] | [Product, version] | [PM-NNN] | [Standard] | [@owner] | YYYY-MM-DD |
For cloud estates, link components to the Cloud security reference
patterns (security/cloud-security-reference-patterns) and the guardrails
in the Landing zone design (architecture/landing-zone-design).
10. Security service management
| Question | Operational design | Owner |
|---|
| What (Example) | Security service catalogue with service levels for LS-001 to LS-006 | @security-service-manager |
| Why (Example) | Operational risk reporting against attribute targets (section 12) | @risk-officer |
| How (Example) | Change, vulnerability, incident and access review processes | @security-operations |
| Who (Example) | Roles, skills and training plan; outsourced provider responsibilities | @ciso |
| Where (Example) | Operations centres, hosting locations, partner sites in scope | @security-operations |
| When (Example) | Operating calendar: daily triage, monthly metrics, quarterly drills, yearly review | @security-service-manager |
| Layer | Management activity | Cadence |
|---|
| Contextual (Example) | Business sponsor reviews drivers and attribute targets | Yearly |
| Conceptual (Example) | Architecture board reviews objectives and principles | Yearly or on major change |
| Logical (Example) | Service owners review service performance | Quarterly |
| Physical (Example) | Mechanism effectiveness tests | Twice a year |
| Component (Example) | Patch, configuration and lifecycle management | Continuous |
11. Traceability
| Business driver | Attribute | Risk or opportunity | Objective | Logical service | Physical mechanism | Component | Metric |
|---|
| BD-002 (Example) | BA-005 | OPP-002 | CO-003 | LS-002 | PM-002 | CMP-002 | BA-005 onboarding time |
| BD-001, BD-002 (Example) | BA-003 | RSK-002 | CO-001 | LS-001, LS-003 | PM-001, PM-003 | CMP-001, CMP-003 | BA-003 disclosures |
| BD-004 (Example) | BA-004 | RSK-003 | CO-004 | LS-004 | PM-004 | CMP-004 | BA-004 log coverage |
| BD-004 (Example) | BA-001, BA-006 | RSK-001 | CO-002 | LS-005 | PM-005 | [CMP-NNN] | BA-006 recovery tests |
| [BD-NNN] | [BA-NNN] | [RSK or OPP] | [CO-NNN] | [LS-NNN] | [PM-NNN] | [CMP-NNN] | [Metric] |
12. Metrics and performance reporting
| Attribute | Target | Current | Trend | Status | Action |
|---|
| BA-001 Available (Example) | 99.95 % | 99.97 % | Stable | On target | None |
| BA-002 Easy to use (Example) | 1 added step or fewer | 2 | Improving | Off target | Passkey roll-out (ROAD-002) |
| BA-004 Auditable (Example) | 100 % | 92 % | Improving | Off target | Migrate remaining systems to central logging (ROAD-003) |
| [BA-NNN] | [Target] | [Value] | [Trend] | [On / Off target] | [Action] |
Present the scorecard to the [risk committee] each [quarter]. Map the
same attributes to the NIST CSF profile (compliance/nist-csf) where
the board also receives CSF reporting, so the two views agree.
13. Governance, lifecycle and roadmap
13.1 Lifecycle
| Layer | Change authority | Change trigger |
|---|
| Contextual and attributes profile | Business sponsor | New strategy, regulation, merger |
| Conceptual | Architecture board | Contextual change, major incident |
| Logical and physical | Security architect | New service, failed metric |
| Component | Service owner within standards | Product lifecycle, vulnerability |
13.2 Roadmap
| ID | Initiative | Attributes improved | Layer | Target date | Owner |
|---|
| ROAD-001 (Example) | Isolated recovery capability for payments | BA-006, BA-001 | Physical and component | YYYY-MM-DD | @resilience-lead |
| ROAD-002 (Example) | Passkeys for customer authentication | BA-002, BA-003 | Physical and component | YYYY-MM-DD | @iam-lead |
| ROAD-003 (Example) | Central logging for remaining core systems | BA-004 | Physical | YYYY-MM-DD | @security-operations |
| [ROAD-NNN] | [Initiative] | [BA-NNN] | [Layer] | YYYY-MM-DD | [@owner] |
14. Glossary and references
14.1 Glossary
| Term | Meaning in this document |
|---|
| Business attribute | A named quality the business requires from its systems and services, defined in business language |
| Attributes profile | The selected set of business attributes with definitions, metrics and targets |
| Control objective | A statement of what must be prevented, detected or limited to protect an attribute |
| Enablement objective | A statement of what security must make possible to deliver an attribute or opportunity |
| Security domain | A set of elements under one security policy authority |
| Two-way traceability | The ability to follow every requirement down to its implementation and every implementation up to its business reason |
| Layer | A level of the architecture written for one audience, from business context to components and operations |
14.2 References
| Reference | Version or date checked | Use |
|---|
| The SABSA Institute, sabsa.org | Checked YYYY-MM-DD | Method owner, licensing terms, current publications |
| [SABSA publication used under licence] | [Edition] | Method detail |
| NIST Cybersecurity Framework 2.0 (CSWP 29, February 2024) | Final | Optional external mapping in sections 11 and 12 |
| [Enterprise architecture repository] | [Version] | Business context |
Standard and licence note
Structure aligned with SABSA, the enterprise security architecture
method of The SABSA Institute. SABSA is protected by copyright, and SABSA
and related names are the property of The SABSA Institute. This template
uses only the names of the SABSA layers (contextual, conceptual,
logical, physical, component and security service management), the six
analysis questions and the business attributes profiling concept; no
matrix cell text, taxonomy content, definitions or course material is
reproduced, and all text and examples are original. This template is
not affiliated with or endorsed by The SABSA Institute. Check the
current official SABSA publications and their terms of use before
relying on the method. Template licence: MIT.