Introduction to SABSA
SABSA (Sherwood Applied Business Security Architecture) is the world's leading open framework and methodology for developing risk-driven enterprise information security and information assurance architectures. Unlike prescriptive control catalogues such as ISO/IEC 27001 Annex A or the PCI DSS requirements, SABSA is a meta-methodology: it provides a structured way of thinking about, designing, delivering, operating and continuously improving security architecture so that every control, service and mechanism is demonstrably traceable back to a business requirement. It answers the perennial auditor's question — 'why does this control exist and what business risk does it treat?' — by baking traceability into the very fabric of the architecture.
SABSA was first published in 1995 by John Sherwood and later developed with Andrew Clark and David Lynas. It is stewarded today by The SABSA Institute (TSI), which maintains the framework, the body of knowledge, and the professional certification scheme (SABSA Chartered Architect — Foundation, Practitioner and Master levels). SABSA is used globally across financial services, government, defence, telecommunications, healthcare, energy and critical national infrastructure. It is deliberately business-driven, risk-focused, model-based and open-source in the sense that the core framework is freely usable, although certain published works and course materials remain the copyright of TSI and its authors.
This guide provides an auditor-grade deep-dive into SABSA: its layered architecture model, the SABSA Matrix and its cells, the business attributes profiling technique, the SABSA lifecycle, and — most importantly for practitioners — a master assessment checklist enumerating every layer, view, matrix cell and core process, together with the evidence an assessor should expect to see. It is written for security architects, risk managers, CISOs, internal auditors and assurance professionals who must design, review or assure a SABSA-based architecture.
What is SABSA
SABSA is a framework and methodology for enterprise security and risk architecture that is characterised by four defining principles: it is business-driven (every architectural decision flows from business goals, drivers and risk appetite), risk and opportunity focused (it treats risk as two-sided — protecting against downside threats while enabling upside business opportunity), fully traceable (each control links upward to a business requirement and downward to an operational mechanism), and lifecycle-oriented (architecture is designed, delivered, managed and continuously improved rather than produced once and shelved).
At the heart of SABSA are three inter-related conceptual tools. First, the SABSA Layered Model, comprising six architectural layers (Contextual, Conceptual, Logical, Physical, Component and Operational), each representing the viewpoint of a different stakeholder — from the business owner down to the tradesman and facilities manager, borrowing the metaphor of the Zachman Framework. Second, the SABSA Matrix, a 6x6 grid that intersects the six layers with six interrogatives — What (Assets), Why (Motivation), How (Process), Who (People), Where (Location) and When (Time) — producing thirty-six cells each holding a distinct architectural artefact. Third, the Business Attributes Profiling technique, a patented conceptual layer that translates abstract business requirements into a taxonomy of measurable 'business attributes' (for example Available, Confidential, Traceable, Compliant, Recoverable, Reputable), each equipped with a metric and target so that security value can be measured and justified.
SABSA is complementary to, not a replacement for, control standards. An organisation typically uses SABSA as the architectural 'engine' that derives which controls are needed and why, then implements those controls using frameworks such as ISO/IEC 27001/27002, NIST CSF, COBIT, TOGAF, CIS Controls or PCI DSS. In this way SABSA provides the strategic and design rigour, while the control frameworks supply the operational specifics.
Who must comply with or adopt SABSA
SABSA is a voluntary, open methodology — there is no legal or regulatory mandate to 'comply' with SABSA in the way one must comply with PCI DSS or the DPDP Act. Instead, organisations adopt SABSA where a rigorous, traceable, business-driven security architecture is required. The following table summarises typical adopters and their drivers.
| Adopter / stakeholder | Why they adopt SABSA |
|---|---|
| Large regulated enterprises (banks, insurers, capital markets) | Need to demonstrate to regulators that every security control is risk-justified and traceable to business requirements; supports Basel, DORA, and supervisory expectations. |
| Government and defence organisations | Require assured, layered architecture with clear accountability across contextual-to-component views; SABSA aligns with national assurance schemes. |
| Critical national infrastructure (energy, utilities, telecoms, transport) | Must balance safety, security and operational continuity with formal risk traceability and resilience engineering. |
| Enterprise and security architects | Use SABSA as the professional method for designing security into enterprise architecture alongside TOGAF. |
| CISOs and security leadership | Adopt SABSA to justify security investment in business terms and to communicate risk to the board using business attributes. |
| Managed security service providers and consultancies | Deliver SABSA-based architecture engagements and assurance reviews for clients. |
| Internal audit and assurance functions | Assess whether the security architecture is complete, traceable, and aligned to business risk appetite. |
| Individual professionals | Pursue SABSA Chartered certification (SCF, SCP, SCM) to validate competence. |
Structure of SABSA — layers, views, matrix and core processes
SABSA's structure is best understood as a set of nested constructs: six architectural layers (plus a cross-cutting management/operational layer), each viewed through six interrogatives to form the SABSA Matrix; a second Service Management Matrix that overlays operational service management; and a lifecycle of core processes that governs how the architecture is created and maintained. The table below sets out the six layers, the stakeholder view each represents, and the primary artefact produced at that layer.
| SABSA layer (architectural view) | Stakeholder / perspective | Primary artefact / focus |
|---|---|---|
| Contextual Security Architecture | The Business (business owner's view) | Business context, goals, drivers, risk appetite, business attributes profile — the 'what and why' of the business. |
| Conceptual Security Architecture | The Architect (architect's view) | Control and enablement objectives, security strategy, domain model, trust model, risk management framework, business attributes taxonomy. |
| Logical Security Architecture | The Designer (designer's view) | Security services, information/data model, security policies, entity and trust framework, security domain definitions. |
| Physical Security Architecture | The Builder (builder's view) | Security mechanisms, data structures, rules and procedures, access control lists, cryptographic key management design. |
| Component Security Architecture | The Tradesman (tradesman's view) | Specific products, tools, technologies, standards, protocols, and detailed specifications — the actual components. |
| Operational (Management) Security Architecture | The Facilities Manager (service manager's view) | Security service management, operations, monitoring, incident and continuity management — cross-cuts all layers. |
Each layer is interrogated through six questions to build the full SABSA Matrix. The table below sets out the six matrix columns (interrogatives) and what each represents across the architecture.
| Interrogative (matrix column) | Dimension | What it captures across the layers |
|---|---|---|
| What | Assets | The information assets and business assets to be protected — from business decisions/value at the top to physical data and components below. |
| Why | Motivation | The risk, opportunity, control objectives and enablement objectives — the justification for the architecture. |
| How | Process | The functions, security services, mechanisms and technologies that deliver protection and enablement. |
| Who | People | The identities, roles, relationships, trust and entity schema — governance and human accountability. |
| Where | Location | The business geography, domains, network/platform locations and physical siting of assets. |
| When | Time | The business time dependencies, lifetimes, schedules, sequencing and time-related security (e.g. session, key lifetimes). |
The intersection of six layers and six interrogatives yields the 36-cell SABSA Matrix. In practice SABSA also defines a complementary Service Management Matrix that maps the same interrogatives against the operational layer, ensuring that architecture is not just designed but managed in service. The core lifecycle processes — Strategy & Planning, Design, Implement, and Manage & Measure — govern how the matrix is populated and kept alive.
Master assessment checklist — every layer, cell and core process
This is the central section of the guide. It enumerates every SABSA architectural layer, the key matrix cells, the business attributes technique, the domain and trust models, and the lifecycle processes. For each group, an assessor should verify the stated items and expect to see the typical evidence listed. A mature SABSA architecture will have populated, traceable artefacts for all thirty-six matrix cells plus the operational overlay; gaps in any cell indicate an incomplete architecture.
Group 1 — Contextual layer (The Business view)
The contextual layer establishes why the security architecture exists at all. It captures business goals, drivers, the risk and opportunity landscape, and the business geography and time dependencies. Everything below must trace back to this layer.
| What to verify | Typical evidence |
|---|---|
| Business assets and value have been identified (What) and prioritised. | Business asset register, value chain analysis, information asset inventory with business criticality ratings. |
| Business goals, drivers, and risk/opportunity appetite are documented (Why). | Business goals and drivers register, risk appetite statement, board-approved risk tolerance thresholds. |
| Business processes requiring protection or enablement are catalogued (How). | Business process inventory, process criticality assessment, harm and impact statements. |
| Organisation, relationships and governance structure are defined (Who). | Organisation chart, stakeholder register, RACI, governance charter. |
| Business geography and jurisdictional footprint are mapped (Where). | Business location/geography model, regulatory jurisdiction map, data residency requirements. |
| Business time dependencies and lifecycles are captured (When). | Business calendar, seasonality/peak analysis, transaction time-window and retention requirements. |
Group 2 — Conceptual layer (The Architect view)
The conceptual layer translates business context into an architectural strategy: control and enablement objectives, the business attributes taxonomy, the risk management framework, domain and trust concepts, and time management concepts.
| What to verify | Typical evidence |
|---|---|
| Business attributes profile has been derived and given metrics/targets. | Business Attributes Profile document with attribute definitions, measurement approach, and target performance levels. |
| Control objectives and enablement objectives are defined (Why). | Control objectives catalogue, enablement objectives, risk management framework and policy architecture. |
| Security strategies and architectural layering approach are set (How). | Security strategy document, architecture principles, layering and service concept definitions. |
| Trust framework and entity schema concepts are established (Who). | Conceptual trust model, entity relationship concepts, roles and responsibilities framework. |
| Security domain concept and domain model are defined (Where). | Security domain model, domain interaction and inter-domain trust concept diagrams. |
| Through-life risk management and time concepts are defined (When). | Risk management lifecycle concept, security-related lifetime and continuity concepts. |
Group 3 — Logical layer (The Designer view)
The logical layer specifies the security services (information flow, access control, assurance, etc.), the information model, security policies, entity schema, domain definitions, and time-dependency logic — the 'what services are needed' independent of technology.
| What to verify | Typical evidence |
|---|---|
| Information assets and data model are logically specified (What). | Logical information model, data classification scheme, inventory of information assets to be secured. |
| Security policies and risk management policies are defined (Why). | Security policy set, policy architecture, risk-driven policy statements mapped to attributes. |
| Security services are specified and catalogued (How). | Security services catalogue (e.g. authentication, authorisation, audit, integrity, confidentiality, availability services). |
| Entity schema and trust/privilege framework are designed (Who). | Entity schema, identity and access management design, privilege and trust framework. |
| Security domain definitions and associations are logical-mapped (Where). | Logical domain maps, domain policy associations, inter-domain security service definitions. |
| Security processing cycles and time dependencies are logical-defined (When). | Security processing schedules, session/token lifetime designs, logical continuity timelines. |
Group 4 — Physical layer (The Builder view)
The physical layer defines the concrete security mechanisms, data structures, access control rules, process control structures, and the physical layout of security across the estate.
| What to verify | Typical evidence |
|---|---|
| Data structures and security-relevant data forms are defined (What). | Data dictionary, cryptographic data structures, security metadata and log record formats. |
| Risk management practices and mechanisms are documented (Why). | Risk treatment plans, control mechanism specifications, security rule sets and procedures. |
| Security mechanisms are specified and mapped to services (How). | Mechanism specifications (cryptography, access control lists, filtering, monitoring), service-to-mechanism traceability matrix. |
| Human interface, access control lists and process controls are defined (Who). | Access control rule sets, ACLs, role-to-permission mappings, human interface security design. |
| Platform, network and host security layouts are defined (Where). | Network security architecture, platform hardening standards, physical siting and zoning designs. |
| Control structure execution and timing are defined (When). | Sequencing and timing rules, key rotation schedules, timed access and expiry mechanisms. |
Group 5 — Component layer (The Tradesman view)
The component layer identifies the actual products, tools, standards, protocols and technical components selected to realise the physical mechanisms, together with their detailed specifications.
| What to verify | Typical evidence |
|---|---|
| Specific ICT components and data repositories are selected (What). | Product/technology inventory, component specifications, configuration item register (CMDB). |
| Component-level risk management and tools are selected (Why). | Vulnerability and configuration management tooling, risk analysis tool outputs, control component justifications. |
| Security products, tools and standards are specified (How). | Product datasheets, standards and protocol list (e.g. TLS, SAML, OAuth, PKI), build and configuration baselines. |
| Identities, users, roles and access tokens are componentised (Who). | Directory/IAM product configuration, credential and token specifications, personnel/user records. |
| Processes, nodes, addresses and locators are specified (Where). | Network addressing, node/device inventory, location and topology component specifications. |
| Process schedules, clocks and timing components are specified (When). | Time-server/NTP configuration, scheduler definitions, certificate and key validity periods. |
Group 6 — Operational (Management) layer — Service Management view
The operational layer cross-cuts all the above. It ensures the architecture is delivered and run as a managed service: operational risk management, service continuity, monitoring, incident and problem management, and performance measurement against the business attributes.
| What to verify | Typical evidence |
|---|---|
| Operational continuity and availability of assets is assured (What). | Business continuity and disaster recovery plans, backup/restore records, service continuity tests. |
| Operational risk management and assurance is running (Why). | Operational risk registers, assurance reports, KRI/KPI dashboards against business attributes. |
| Security service delivery and operations management is in place (How). | Security operations runbooks, SOC procedures, change and release management records, patch management. |
| Personnel management, awareness and access administration operate (Who). | Access provisioning/de-provisioning logs, joiner-mover-leaver records, security awareness training records. |
| Site, platform and network operations security is managed (Where). | Environmental and physical security operations logs, network operations and monitoring records. |
| Timed operations, monitoring and audit schedules run (When). | Log retention and review schedules, audit calendars, incident response timelines, SLA/OLA reporting. |
Group 7 — Business Attributes Profiling technique
Business Attributes Profiling is the signature SABSA technique that bridges business requirements and measurable security value. Each business attribute (drawn from taxonomy categories such as User, Management, Operational, Risk Management, Legal/Regulatory, Technical Strategy, Business Strategy) is defined, justified, and equipped with a metric and target.
| What to verify | Typical evidence |
|---|---|
| A tailored business attributes profile has been created from the standard taxonomy. | Business Attributes Profile listing selected attributes (e.g. Available, Confidential, Traceable, Compliant, Recoverable, Reputable, Assurable). |
| Each attribute has a clear definition and business justification. | Attribute definition table linking each attribute to specific business goals and drivers. |
| Each attribute has a metric type and performance target. | Metrics catalogue with metric type (hard/soft), measurement method and traffic-light/target thresholds. |
| Attributes are traced to control and enablement objectives. | Traceability matrix mapping attributes to objectives, services, mechanisms and components. |
| Attribute performance is measured and reported. | Attribute performance dashboards, periodic measurement reports to governance forums. |
Group 8 — Risk and opportunity management (SABSA risk model)
SABSA treats risk as two-sided and integrates a full risk management process across the layers, distinguishing threats, vulnerabilities, impacts and opportunities and linking them to business attributes.
| What to verify | Typical evidence |
|---|---|
| Risk assessment covers both downside risk and upside opportunity. | Risk and opportunity register, two-sided risk assessment methodology documentation. |
| Threats, vulnerabilities, assets and impacts are systematically analysed. | Threat catalogues, vulnerability assessments, business impact analyses (BIA). |
| Risks are traced to business attributes and appetite. | Risk-to-attribute mapping, risk appetite alignment records, residual risk acceptance decisions. |
| Control objectives are derived from assessed risks. | Control objectives register traceable to specific risks and attributes. |
| Risk treatment and monitoring is ongoing. | Risk treatment plans, KRIs, periodic risk review and reporting minutes. |
Group 9 — Domain, trust and multi-tier control models
SABSA's security domain model, trust modelling and multi-tier control strategy (preventive, detective, corrective and directive/deterrent controls arranged in defence-in-depth tiers) define how the enterprise is partitioned and how trust flows between domains.
| What to verify | Typical evidence |
|---|---|
| Security domains are defined with clear policy authorities. | Security domain model, domain policy authority assignments, domain boundary definitions. |
| Inter-domain trust relationships and associations are documented. | Trust model, inter-domain association matrix, trust broker and gateway designs. |
| A multi-tiered control strategy (deter/prevent/detect/correct) is applied. | Multi-tier control map, defence-in-depth diagrams, control classification by tier and function. |
| Trust levels and assurance requirements per domain are specified. | Assurance level definitions, per-domain trust and authentication strength requirements. |
| Domain governance and change control is enforced. | Domain ownership records, change approval records for domain policy modifications. |
Group 10 — SABSA lifecycle core processes
The SABSA lifecycle ensures the architecture is a living capability. It comprises Strategy & Planning, Design, Implement, and Manage & Measure, feeding back continuously. Assessors must confirm all four phases operate and connect.
| What to verify | Typical evidence |
|---|---|
| Strategy & Planning process produces contextual/conceptual artefacts. | Architecture strategy documents, business requirements, attribute profiles, approved architecture vision. |
| Design process produces logical/physical artefacts with traceability. | Logical and physical architecture designs, service and mechanism specifications, traceability matrices. |
| Implement process delivers component architecture and operations. | Build/deployment records, configuration baselines, acceptance test and assurance evidence. |
| Manage & Measure process operates continuous assurance. | Performance measurement reports, assurance reviews, continuous improvement register. |
| Feedback loops drive continuous improvement of the architecture. | Change requests to architecture, lessons-learned logs, architecture review board minutes. |
Scoping a SABSA engagement
Because SABSA is enterprise-wide by nature, disciplined scoping is essential to keep an engagement tractable. Scoping decisions determine which business domains, which architectural layers, and which interrogatives the engagement will address, and how deeply.
- Define the business scope: which business units, products, services or value streams the architecture will cover, and the sponsoring stakeholders.
- Define the architectural depth: whether the engagement addresses all six layers or focuses (e.g.) on contextual-to-logical strategy work before deeper physical/component design.
- Define the domain scope: which security domains (e.g. corporate, customer-facing, cloud, OT/ICS) are in and out of scope.
- Establish the risk and regulatory context: which jurisdictions, regulations and compliance frameworks (ISO 27001, PCI DSS, DPDP, DORA) must be mapped in.
- Identify existing architecture assets to reuse: current EA (TOGAF) artefacts, control catalogues, risk registers and policies.
- Agree the level of traceability required: whether full 36-cell matrix population is expected or a targeted subset.
- Define time horizon and lifecycle expectations: one-off design vs. establishing an ongoing architecture practice.
- Document assumptions, constraints and exclusions explicitly in the engagement charter.
Implementation approach — a phased method
A SABSA implementation aligns with the four lifecycle processes and is typically delivered in phases. Each phase below lists its principal activities and the deliverables it should produce.
Phase 1 — Strategy and context (Contextual & Conceptual)
Activities: engage business stakeholders; capture business goals, drivers and risk appetite; derive the business attributes profile; establish control and enablement objectives; agree architecture principles and the domain/trust concept.
- Deliverable: Business context and requirements document.
- Deliverable: Business Attributes Profile with metrics and targets.
- Deliverable: Conceptual security architecture (strategy, principles, domain and trust concepts).
- Deliverable: Risk management framework and control objectives catalogue.
Phase 2 — Logical design (Logical layer)
Activities: define security services; design the information/data model and classification; author security policies; specify the entity/trust schema and logical domain definitions; establish traceability from services back to attributes.
- Deliverable: Security services catalogue.
- Deliverable: Logical information model and data classification scheme.
- Deliverable: Security policy architecture.
- Deliverable: Entity schema, trust framework and logical domain maps.
- Deliverable: Attribute-to-service traceability matrix.
Phase 3 — Physical and component design (Physical & Component)
Activities: specify security mechanisms; design data structures, ACLs and rule sets; select products, standards and protocols; produce build and configuration baselines; maintain full service-to-mechanism-to-component traceability.
- Deliverable: Security mechanism specifications and rule sets.
- Deliverable: Product/technology selection and standards list.
- Deliverable: Configuration and hardening baselines.
- Deliverable: Complete traceability matrix (attribute to component).
Phase 4 — Implementation and operations (Component & Operational)
Activities: build, integrate and deploy the components; establish security operations, monitoring and continuity; commission assurance testing; transition to service management.
- Deliverable: Deployed and configured security components with acceptance evidence.
- Deliverable: Security operations runbooks and monitoring setup.
- Deliverable: Continuity and incident management capability.
- Deliverable: Service management matrix populated.
Phase 5 — Manage, measure and improve (Operational)
Activities: measure business-attribute performance; run assurance reviews and audits; feed findings into a continuous improvement cycle; govern architecture change through an architecture review board.
- Deliverable: Attribute performance dashboards and assurance reports.
- Deliverable: Continuous improvement register and architecture change log.
- Deliverable: Governance minutes and re-baselined architecture artefacts.
SABSA maturity and capability model
SABSA architecture maturity can be assessed using a capability model that measures how completely and consistently the framework is applied and how well it is embedded as a living capability. The following five-level model (aligned to common capability-maturity conventions) helps assessors rate an organisation's SABSA adoption.
| Level | Name | Characteristics |
|---|---|---|
| 1 | Initial / Ad hoc | Security decisions are reactive and undocumented; no traceability from controls to business risk; SABSA concepts absent or informal. |
| 2 | Repeatable / Emerging | Some SABSA artefacts exist (e.g. an attribute profile or domain model) for isolated projects; traceability is partial and inconsistent. |
| 3 | Defined | SABSA layers, matrix and business attributes are documented and applied consistently across the enterprise; traceability matrices maintained. |
| 4 | Managed / Measured | Business-attribute metrics are actively measured and reported; risk and architecture are quantitatively governed; assurance reviews are routine. |
| 5 | Optimising | Architecture is a continuously improving, board-visible capability; feedback loops drive proactive change; risk and opportunity are balanced strategically. |
Assessment and audit approach
An auditor-grade SABSA assessment follows a structured sequence, moving top-down through the architecture and testing traceability at every layer.
- Confirm engagement scope, sponsor, and the architectural layers/domains to be assessed; obtain the architecture charter.
- Review the contextual layer: validate that business goals, drivers, risk appetite and business attributes are documented and current.
- Assess the conceptual layer: verify control/enablement objectives, risk framework, domain and trust concepts derive from context.
- Trace downward through logical, physical and component layers, testing that each service, mechanism and component maps to an attribute and objective.
- Evaluate the business attributes profile: check definitions, metrics, targets and actual measurement.
- Assess the domain, trust and multi-tier control models for completeness and enforcement.
- Review operational/service-management architecture: continuity, monitoring, incident and change management.
- Test lifecycle processes: confirm Strategy, Design, Implement and Manage & Measure operate with feedback loops.
- Perform gap analysis against the 36-cell matrix and the maturity model; identify empty or weak cells.
- Sample evidence and interview architects, risk owners and operators to corroborate documented traceability.
- Rate maturity per capability level and document findings, risks and recommendations.
- Produce an assessment report with prioritised remediation roadmap and re-assessment plan.
Evidence request list
Assessors should request the following categorised evidence ahead of and during a SABSA review.
- Governance and context: architecture charter, business goals/drivers register, risk appetite statement, stakeholder RACI.
- Business attributes: Business Attributes Profile, attribute definitions, metrics catalogue, performance dashboards.
- Risk management: risk and opportunity register, risk methodology, business impact analyses, risk treatment plans.
- Architecture artefacts: contextual, conceptual, logical, physical and component architecture documents, and the populated SABSA Matrix cells.
- Traceability: attribute-to-objective-to-service-to-mechanism-to-component traceability matrices.
- Domain and trust: security domain model, trust model, inter-domain association matrix, multi-tier control map.
- Policies and standards: security policy architecture, standards/protocol list, configuration and hardening baselines.
- Operations: security operations runbooks, monitoring/SOC procedures, continuity and DR plans and test results, incident records.
- Assurance and governance: assurance review reports, architecture review board minutes, continuous improvement register, prior audit reports.
- Certification and competence: evidence of SABSA-chartered practitioners engaged (SCF/SCP/SCM), training records.
Roles and responsibilities
Clear accountability across the SABSA layers is essential; the following table maps typical roles to their responsibilities.
| Role | Key responsibilities |
|---|---|
| Business owner / executive sponsor | Owns business goals, risk appetite and funding; approves the contextual architecture and business attributes. |
| Chief Information Security Officer (CISO) | Owns the overall security architecture and risk posture; presents attribute performance to the board. |
| Enterprise / security architect (SABSA-chartered) | Designs and maintains the layered architecture and matrix; ensures traceability across all layers. |
| Risk manager | Runs the risk and opportunity assessment; maintains risk register and treatment plans; aligns to appetite. |
| Domain owners | Own security domains, their policies and trust relationships; approve domain changes. |
| Solution / technical designers | Produce logical and physical designs; select components; maintain build baselines. |
| Security operations (SOC) manager | Runs operational/service-management architecture: monitoring, incident, continuity and change management. |
| Internal audit / assurance | Independently assesses completeness, traceability and maturity of the architecture. |
| Compliance officer | Maps architecture to regulatory obligations (ISO 27001, PCI DSS, DPDP, DORA) and evidences compliance. |
KPIs to track
SABSA's business attributes make security measurable. The following KPIs help demonstrate architecture value and health.
- Percentage of business attributes meeting their target performance level (green status).
- Traceability completeness: percentage of controls traceable to a business attribute and objective.
- Matrix coverage: percentage of the 36 matrix cells populated with current artefacts.
- Percentage of residual risks within board-approved risk appetite.
- Number and severity of architecture gaps identified vs. remediated per period.
- Mean time to detect and respond to security incidents (operational attribute performance).
- Percentage of changes passing architecture review board governance.
- Coverage of critical business processes by defined security services.
- Assurance review pass rate and number of overdue remediation actions.
- Maturity level trend against the capability model over time.
Readiness checklist
Use this checklist to confirm readiness for a SABSA assessment or to gauge architecture completeness.
- Business goals, drivers and risk appetite are documented and signed off by the sponsor.
- A tailored Business Attributes Profile with metrics and targets exists.
- Control and enablement objectives are defined and traceable to attributes.
- A risk and opportunity register and methodology are in place.
- The security domain model and trust model are documented.
- Logical security services are catalogued and mapped to attributes.
- Physical mechanisms and component selections are specified with traceability.
- Configuration and hardening baselines exist for selected components.
- Operational/service-management architecture (monitoring, continuity, incident) is in place.
- Attribute performance is actively measured and reported to governance.
- Lifecycle processes operate with feedback loops and an architecture review board.
- SABSA-chartered practitioners are engaged and traceability matrices are current.
Common gaps and pitfalls
- Treating SABSA as a control checklist rather than a traceability methodology, resulting in controls with no link to business risk.
- Producing contextual and conceptual artefacts but never completing logical/physical/component layers — 'architecture on paper'.
- Defining a business attributes profile but never assigning metrics or measuring performance.
- Weak or missing traceability matrices, so it cannot be shown why a control exists.
- Ignoring the operational/service-management layer, leaving a well-designed architecture that is not managed in service.
- Focusing only on downside risk and omitting the opportunity/enablement dimension SABSA emphasises.
- Domain and trust models that are drawn once and never governed as the estate changes.
- No feedback loop or architecture review board, so the architecture becomes stale.
- Confusing SABSA with a maturity certification — there is no organisational 'SABSA certification', only professional chartership.
- Failing to integrate SABSA with existing EA (TOGAF) and control frameworks, causing duplication and silos.
SABSA mapped to other frameworks
SABSA is complementary to control and governance frameworks. It provides the architectural and traceability rigour; other frameworks supply detailed controls, governance or EA structure. The table shows how SABSA relates to common frameworks.
| Framework | Relationship to SABSA |
|---|---|
| ISO/IEC 27001 & 27002 | SABSA derives which controls are needed and why; ISO 27002 supplies the control detail; SABSA can drive ISMS scope and Statement of Applicability justification. |
| NIST Cybersecurity Framework (CSF) | CSF functions (Identify, Protect, Detect, Respond, Recover) map to SABSA services and operational layer; SABSA adds business-risk traceability. |
| TOGAF | SABSA and TOGAF are formally aligned (SABSA Enhancements to TOGAF); SABSA supplies the security architecture viewpoint within the TOGAF ADM. |
| COBIT | COBIT provides IT governance and control objectives; SABSA translates governance intent into architected, traceable security services. |
| PCI DSS | SABSA can scope and justify the cardholder data environment controls, mapping PCI requirements to business attributes and domains. |
| CIS Controls | CIS provides prioritised technical safeguards; SABSA places them within a risk-traceable architecture at the physical/component layers. |
| ISO 31000 / risk standards | SABSA's two-sided risk model aligns with ISO 31000 principles while adding architecture-level traceability and attribute metrics. |
| SABSA professional certification (TSI) | SCF, SCP and SCM chart individual competence; not an organisational compliance certificate. |
Frequently asked questions
Need help with SABSA?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.