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

Approvals

Revision history

Contents

1. Purpose, scope and approach
2. Business context and drivers
3. Business attributes profile
4. Risk and opportunity
5. Contextual layer
6. Conceptual layer
7. Logical layer
8. Physical layer
9. Component layer
10. Security service management
11. Traceability
12. Metrics and performance reporting
13. Governance, lifecycle and roadmap
14. Glossary and references

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

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.

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

2.2 Stakeholders

2.3 Constraints

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.

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.

All targets above are illustrative. Agree real values with the business sponsor and record the approval date.

3.3 Attribute conflicts

4. Risk and opportunity

4.1 Attribute-based risk

4.2 Opportunities enabled by security

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

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

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

6.2 Why: security strategies and principles

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

6.5 Where: security domain concept

Each domain has one policy authority and a defined set of inter-domain trust relationships. Record them:

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

Logical information flows between domains are listed with their classification and the service that protects them:

8. Physical layer

9. Component layer

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

11. Traceability

Completeness checks:

• Every attribute in section 3 has at least one objective, service, mechanism and component.
• Every component in section 9 traces to at least one attribute.
• Every attribute has a metric that is being collected.
• Every high risk in section 4 has a response realised in the layers.
• External frameworks the organisation reports against (for example NIST CSF 2.0 or ISO/IEC 27001) are mapped from the objectives, not bolted onto components.

12. Metrics and performance reporting

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

13.2 Roadmap

14. Glossary and references

14.1 Glossary

14.2 References

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.