TSI W103 SABSA Responsibility Assignment Model

W103
SABSA Responsibility
Assignment Modelling

Release 1.0

A White Paper published by The SABSA Press™, an imprint of The SABSA Institute™

June 2023

Page i
Copyright © 2023, The SABSA Institute C.I.C. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or
transmitted, in any form or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior permission of the copyright owners
unless it is presented in its current form as published by The SABSA Institute.
Document Title: SABSA Responsibility Assignment Modelling. (A SABSA White
Paper) 2023
Document Number: TSI W103

Published by The SABSA Press, (a trading name of The SABSA Institute C.I.C.) June
2023.
Comments relating to the material contained in this document may be submitted
to:
The SABSA Institute C.I.C, 110-114 Duke Street, Liverpool, England, L1 5AG
Registered in England and Wales, No. 08439587

Or by electronic mail to:

sabsapress@sabsa.org

Trademarks
SABSA® is a registered trademark of The SABSA Institute. Other trademarks
owned by The SABSA Institute are labelled with a TM mark on their first
occurrence in the text.
All other brands, company, and product names are used for identification
purposes only and may be trademarks that are the sole property of their
respective owners.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 2
This Document
Describes the SABSA Responsibility Assignment Modelling and the abstract and
conceptual view of stakeholders’ roles and responsibilities.
This document has been developed and approved by The SABSA Institute C.I.C.
Board of Trustees.

Acknowledgements
Authors: John Sherwood: Chief Architect, The SABSA Institute
Maurice Smit: Deputy Chief Architect, The SABSA Institute
David Lynas: Chief Education Officer, The SABSA Institute

Contributors: Martin Hopkins: Editor-in-Chief, The SABSA Institute

John J. Czaplewski
Siân John and all those that attended the COSAC 2014
workshop on this topic.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 3
Table of Contents
Background ..................................................................................................... 5
The SABSA Matrix™ ........................................................................................ 5
Governance Model ......................................................................................... 6
Responsibility Assignment Model (RAM) ................................................................ 7
Dealing with Overlaps and Gaps ............................................................................. 7
SABSA Responsibility Assignment Model (SABSA RAM) ....................................... 8
Example of SABSA RAM application........................................................................ 9
Applications of SABSA RAM: Stakeholders and Services ............................... 10
Service Stakeholder Categories ............................................................................. 13
Cross-Mapping RAM: Owners, Custodians, Trustees and Users ........................... 15
Assurance Roles .................................................................................................... 18
Applying SABSA RAM across the Enterprise .......................................................... 19

Table of Figures
Figure 1: The SABSA People View ................................................................... 5
Figure 2: The SABSA Governance Model ........................................................ 6
Figure 3: Example SABSA RAM Matrix on a Process ..................................... 10
Figure 4: Example SABSA RAM Matrix on Attributes .................................... 10
Figure 5: Everything as a Service (EaaS) Model ............................................ 11
Figure 6: The SABSA Business Stack .............................................................. 12
Figure 7: Stakeholder Roles in the SABSA EaaS Model ................................. 13
Figure 8: The Service Security Manager as a Custodian ............................... 15
Figure 9: Simple Ownership Model............................................................... 16
Figure 10: Domain Model Construct concept to visually present authorities
and their roles & responsibilities ....................................................... 20
Figure 11: Domain Model Construct populated with notional domain names
and authorities ................................................................................... 20
Figure 12: Domain Model Construct with Responsible Trustee added ........ 21

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 4
 SABSA Responsibility Assignment Modelling

The SABSA View of Stakeholder Roles

Background
Stakeholders are an Without stakeholders, the concept of enterprise is meaningless. Stakeholders in
integral part of the all their capacities are the purpose of an enterprise, the lifeblood that enable the
enterprise
enterprise to operate, those who stand to benefit or suffer, and the ultimate
cause of its success or failure.
Stakeholder Understanding stakeholders and, more importantly, ensuring that their various
responsibility roles & responsibilities in the enterprise are properly architected, is arguably the
assignments are part
of the architecture most important aspect of architecture.
Traditional Unfortunately, traditional architecture is often seen as a technical overlay on an
architecture methods enterprise wholly disconnected from stakeholders, which requires stakeholders to
rarely cover this view
adapt to the architecture.
SABSA views the SABSA®, on the other hand, ensures that the architecture meets the needs of
business as reflecting
the needs of
stakeholders. It is business driven and risk based. In its essence, the term business
stakeholders is synonymous with the needs, desires and aspirations of stakeholders.

The SABSA Matrix™

The SABSA Matrix One of the six columns in each of the SABSA Matrices1 is People (see Figure 1: The
People View is the SABSA People View, and these columns represent the main stakeholder domain
stakeholder domain
in architecture within the architecture.

Figure 1: The SABSA People View

1For a full up-to-date description of the SABSA Matrices refer to the 2018 document TSI R101, which
can be found at https://sabsa.org/download/tsi-r101-sabsa-matrices-2018-release-notes/

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 5
 SABSA Responsibility Assignment Modelling

SABSA considers The SABSA People columns of the matrices cover a range of stakeholder roles,
both internal and including business owners, asset owners and their custodians and service
external stakeholders
in the extended providers, internal and prospective staff, and customers. The SABSA Framework™
enterprise also includes external parties such as regulators, auditors and compliance officers
to support assurance.

Governance Model
The SABSA A key element of the SABSA Framework for People is the SABSA Governance
Governance Model
shows the interaction
Model™ (Figure 2: The SABSA Governance Model). It is overlaid on the SABSA
between key Lifecycle™ and integrates the accountable and responsible entities (stakeholder
business roles roles) within each business domain.
The governor sets In any given business domain, there are operational staff carrying out the day-to-
performance targets, day activities and a senior manager overseeing, directing and governing their
operational staff work
to meet the targets work. The governor sets performance targets, and the staff report back on the
actual performance achieved.
SABSA governance SABSA is highly focused on performance management. Notice that all the verbs in
focuses on the governance framework are behavioural – they are action verbs shown in
performance
management italics in the diagram. Though-life assurance roles such as audit, inspection and
oversight are also incorporated in the form of the Manage Through Life aspect in
the centre of the diagram.

Copyright © The SABSA Institute 1995 – 2023. All rights reserved.

Figure 2: The SABSA Governance Model

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 6
 SABSA Responsibility Assignment Modelling

Responsibility Assignment Model (RAM)

RACI modelling is the The most popular and commonly used RAM is the RACI Matrix, which, for each
most commonly used process or asset in scope, describes the stakeholder accountable for the outcome
form of RAM
(the owner) and the responsible supporting parties.
A summary of The standard RACI model also identifies those stakeholders to be consulted and
standard RACI informed of outcomes. The following summarises the RACI modelling approach:
• A RACI Matrix is widely used to describe the roles and responsibilities of
various stakeholders (teams or people) in delivering a project or operating a
process.
• It is especially useful in clarifying roles and responsibilities in, and the patterns
of communications between, cross-functional/departmental projects and
processes.
• The acronym stands for:
• Responsible (R):
The person or team that performs the tasks to achieve the objectives.
There may be multiple resources that are responsible for delivery of
these outputs.
• Accountable (A):
The person who is ultimately answerable for the correct and thorough
completion of the task. There MUST be EXACTLY ONE specified for each
task. Accountability implies ‘ownership’.
• Consulted (C):
Those whose [expert] opinions are sought and delivered. Two-way
communication.
• Informed (I):
Those who are kept up to date on progress. One-way communication.

Dealing with Overlaps and Gaps

Gaps and overlaps in Sometimes gaps and overlaps may be found in the role assignments. If this
role assignments happens, they need to be resolved.
must be resolved
• If more than one resource is designated as being ‘accountable’, or ‘the
owner’, there is a problem of overlap.
This may be resolved by making an executive decision – which of the possible
candidates is to be held accountable?
This may also be solved by drilling down to the next level of detailed analysis,
where perhaps ‘accountability’ splits up into a number of sub-accountabilities
for individual owners.
• Where no-one is identified as being the owner and held accountable,
someone must be assigned that role.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 7
 SABSA Responsibility Assignment Modelling

SABSA Responsibility Assignment Model (SABSA RAM)

SABSA RAM uses The SABSA RAM takes the RACI concept as a starting point but adapts and
the RACI concept, as customises it with extensions and refinements. The reason for adapting and
a starting point
customising the RACI concept in SABSA lies in the fact that we want to prevent
unwanted and unforeseen negative impact on other relevant stakeholders when a
domain authority of the Domain of Focus sets and implements a security policy
that may impact another domain authority. We also want to leverage positive
impact when presented to those impacted due to activities from a Domain of
Focus.
Some of the custom roles that have been used in SABSA work in the past are
presented below. If you need other roles, just design them. SABSA Thinking™ is a
flexible approach to creative use of many techniques to build an architectural
framework. The SABSA RAM is a flexible model.
Concept of ‘Domain All the roles listed here apply to a Domain of Focus, the Accountable domain. This
of Focus’ Domain of Focus may be anywhere in the hierarchical domain structure, with a
super domain governing from above, subdomains being governed below, and
peer domains on the same horizontal level. The core role and responsibility types
are as follows:
• Accountable (A):
The Accountable Authority is accountable for the correct definition of and
compliancy to their policy, the achievement of performance targets on their
SABSA Attributes™ and managing the risks to stay within appetite for the
Domain of Focus.
• Consulted (C):
Those stakeholders consulted for their policy to avoid unwanted and
unforeseen systemic negative impact, and possible missed realisation of
positive impact in the domains of those consulted.

• Owner of Impact (OI)

The Owner of Impact is outside the Domain of Focus and is impacted on their
policy, performance targets and possibly risks by work product output of an
Accountable Authority. Most often the OI is the super domain of the
Accountable Authority of the ‘Domain of Focus’.
• Informs about Responsibilities (IR)
The Accountable domain informing downwards to sub-domains or to external
domains from a position of Accountable authority, delegating responsibilities.
One-way communication from an authority.
• Informs about Performance (IP)
The Accountable domain informing (reporting) upwards on performance to its
super-domain and possible other domains consulted. One-way
communication to an authority.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 8
 SABSA Responsibility Assignment Modelling

• Responsible Trustee (RT)

Responsible for carrying out trustee administration and operations on behalf
of the owner under delegated authority. Acts as Accountable Authority but
remains Responsible.

• Responsible Custodian (RC)

Responsible for carrying out custodian administration and operations on
behalf of the owner under delegated authority. By default, all responsible
Domains are custodians.

• Assurance Compliance (AC):

Those responsible for checking and reporting the performance of the work
product output in a specific domain on behalf of the domain owner.
• Assurance Audit (AA):
Those responsible for auditing and reporting the performance of the work
product output in a specific delegated domain on behalf of the owner of a
domain.
Additional responsibility types that could be of use include:
• Communicates (Com):
Those who are responsible for initiating and managing communications,
either to ‘consult’ or ‘inform’ others.

• Monitors (M):
Those who are responsible for monitoring and reporting on progress, on risk
levels, or on other similar changing parameters.

• Signs off (S):

The party who formally approves the AC and AA reports. This usually is the
party holding the A role though could also be the RT role. Alternatively, when
an official sign off is needed by an external domain not owning the impact of
the work product output.

Example of SABSA RAM application

Example of a SABSA Figure 3 shows one way in which a SABSA RAM matrix can be presented for a
RAM Matrix process.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 9
 SABSA Responsibility Assignment Modelling

Figure 3: Example SABSA RAM Matrix on a Process

Figure 4 shows another way in which a SABSA RAM is applied in relation to
Attributes for a variety of stakeholders.

Figure 4: Example SABSA RAM Matrix on Attributes

Applications of SABSA RAM: Stakeholders and Services

Everything as a In SABSA Thinking, security and risk management are viewed as the set of services
Service (EaaS): the provided to an enterprise within the overall enterprise architecture, with
layered stack
stakeholders having specific service roles. Figure 5 shows the SABSA concept of
‘Everything as a Service’ (XaaS), in which the enterprise architecture is
represented as a layered stack.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 10
 SABSA Responsibility Assignment Modelling

Figure 5: Everything as a Service (EaaS) Model

The SABSA Every layer in the stack is treated as a service layer, providing services to the layer
Business Stack above (layer n + 1) and demanding services from the layer below (n – 1). This
analyses the
enterprise top down supply-demand model standardises the way in which the layers interact2. Figure 6
as a series of layered shows a derived version of this layered service stack. This is the SABSA Business
service layers with Stack™. A Business Attributes Profile™ (SABSA BAP™) that specifies the
performance targets
at each layer performance characteristics for the service bundle describes every service layer.
Each layer has its Stakeholders with RAM assignments exist at every layer. A stakeholder can be a
own set of service regulator, a service owner, a service custodian or a service user. This stack
stakeholders
not only defines the relationships between service layers, but also defines
relationships and patterns of communications between stakeholder roles, both
intra-layer and inter-layer.

2The supply-demand concept for layered services is borrowed from the Master’s Degree thesis by
Jeroen van Esch, Ideas-to-Interconnect, NL.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 11
 SABSA Responsibility Assignment Modelling

Figure 6: The SABSA Business Stack

Each layer interface One of the key rules for applying this layered service model is that a service layer
has a service level may only demand services from the layer immediately below (n – 1) and may only
agreement between
service supplier and supply services to the layer immediately above (n + 1). Skipping a layer
service consumer. (disintermediation) is forbidden. This ensures that service level agreements
Disintermediation is between layers (which are negotiated, enforced and monitored between the
forbidden.
appropriate stakeholders) are applied rigorously and there are no ‘escape routes’.
It should be mentioned that disintermediation is also not possible due to the
distribution of the performance targets on the services to the layer below (n – 1)
and the aggregation of the performances reported to the layer above (n + 1). Such
aggregation makes no sense when skipping a layer (n + 2) or (n – 2).
Figure 7 shows this conceptual rule in diagrammatic form.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 12
 SABSA Responsibility Assignment Modelling

Figure 7: Stakeholder Roles in the SABSA EaaS Model

Service Stakeholder Categories

Service Regulators
Regulators have The Service Regulators category in the widest sense includes external regulators
authority over the for which policy applies to the enterprise, as well as internal super-domain and
service
impacted peer domain authorities. These are the stakeholders with authority over
the service, and with vested interest in its performance. Auditors are also
associated with service regulators, as they fulfil the service review process for
Service Regulators.

Service Owners
Service owners make The Service Owners category also includes Service Trustees with delegated
policy and their responsibility for administering policy implementation. In this context, the owner
trustees administer
the policy is the policy domain authority for the domain in which the asset resides.

Service Trustees
Service Trustees act Service Trustees have authority delegated from the Service Owner to act on
on behalf of the behalf of the owner on matters of policy administration and implementation. (See
Owner with
delegated authority also Service Owners above).

Service Providers (Custodians)

Service providers are The Service Providers category includes internal service managers, external
custodians of the service providers, and other custodians. Suppliers included in this category are
policy set by the
owner providers of goods as well as services. Custodians apply and implement policy set
by the owner and in some cases administered by a trustee.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 13
 SABSA Responsibility Assignment Modelling

Service Users
Service users are the The Service Users category includes those parts of the business that use the
consumers services, any part of the business including owners and suppliers. An individual
may act in different roles at different times – for instance, a service owner may
also be a user of the service from time to time. Example: a senior bank executive
in charge of retail banking will also have a personal bank account.

Service Security Manager

The service security A specific role in the enterprise is the Service Security Manager, which is a specific
manager enforces custodian role of primary importance in SABSA. The Service Security Manager as a
security policy set by
the service owner custodian manages the security services and enforces security policies covering
users and information – but does not set policy. Policy decisions are the
accountability of the owner. Trustees perform policy administration on behalf of
owners and may be delegated by the owner to develop and set policy, subject to
(implicit) owner approval. An example is shown in Figure 8 below.

Service Stakeholder Categories Example

An example of a dual In this example there are two owners. One has ownership of the customer
service ownership service. The other has ownership of the information that is used by the service.
model where there is
coupling between the Consider a retail bank. It has large number of retail customers. The master
services database of customer details is owned by Customer Information Owner who is a
senior manager in the Bank. This database is used by a number of customer facing
services. One such service is Credit Card issue and management. This service has a
different senior manager who owns it – the Customer Credit Card Service owner.
Both owners have Trustees (Authorisers) who do the administration work to
administer the security policy decided upon by the Owner. Senior Managers do
not spend time on administration – they are decision makers. The service
custodian is the Service Security Manager who implements and enforces the
security policies of both owners.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 14
 SABSA Responsibility Assignment Modelling

Figure 8: The Service Security Manager as a Custodian

Cross-Mapping RAM: Owners, Custodians, Trustees and Users

SABSA ownership A simplified SABSA model of asset ownership is represented in the form shown in
model with RAM Figure 9. This captures the role of Custodian, someone who looks after enterprise
cross mappings
assets on behalf of the designated asset Owner, the role of Trustee, someone who
administers the implementation of security policy set by the Owner or sets the
policy on behalf of the owner, and User, someone who uses the assets in
everyday work.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 15
SABSA Responsibility Assignment Modelling

Figure 9: Simple Ownership Model

Owner
Asset Owners determine policy for those assets within their span of control.
• Definition:
The Owner is the domain policy authority who sets goals, risk appetite, and
performance targets in a specific domain.
• Role:
Accountable for compliance to policy, managing risks and the performance of
the attribute(s) in a specific domain.
• Position on Governance Model:
Vision & Strategy and Adopt.
• Risk Management Communications Role:
• Consults: super domain authority for policy, performance targets and risk
appetite.
• Inform (IP): risk performance to super domain authority.
• Informs (IR): policy, performance targets and risk appetite to subdomains
(custodians).

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 16
 SABSA Responsibility Assignment Modelling

Owner Responsibility Delegation

Requirements for When a risk owner is not qualified or is inexperienced for the task of making the
delegation best decisions for self-preservation and in the best interest of the enterprise, they
can delegate responsibility. There are two delegation roles to which the Owner
may delegate responsibility: The Trustee role and the Custodian role. Both these
roles will take upon them the task to mitigate the risk on behalf of the owner.
Accountability It does not transfer Accountability or Liability away from the Owner.
remains with the
Owner
Trustee
A Trustee is appointed by the Owner.
• Definition:
A Trustee is appointed by a domain owner as a subject matter expert being
responsible (R) in a specific domain. Policy authority is delegated to the
trustee which means that the Trustee can set the policy on behalf of the
Owner, although the Owner remains Accountable (A) and Liable.
• Role:
Responsible (RT) for complying with the policy, achieving the performance
targets and manage risks within appetite in a specific domain, though they
can set the policy.
Examples of Trustees:
(1) A manager of a business unit with hundreds of employees delegates the
administration of joiners, movers and leavers to more clerical staff who
are empowered to apply the policies set by the manager for allocating
roles for access to business systems according to job function. The
trustees report to the manager and are part of that business unit.
(2) The Chief Financial Officer is going on a fortnight leave and appoints a
team manager to run the show during their absence.
• Position on Governance Model:
Vision & Strategy and Adopt.
• Risk Management Communications Role:
• Consults: super domain authority for policy, performance targets and risk
appetite.
• Inform (IP): risk performance to super domain authority.
• Informs (IR): policy, performance targets and risk appetite to subdomains
(custodians).

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 17
 SABSA Responsibility Assignment Modelling

Custodian
A Custodian is appointed by the Owner.
• Definition:
A Custodian is appointed by a domain owner as a subject matter expert being
responsible (R) in a specific domain.
• Role:
Responsible (RC) for complying with the policy, achieving the performance
targets and manage risks within appetite in a specific domain.
• Position on Governance Model:
Transformation, Transition, Operation, and Assess.
• Risk Management Communications Role:
Informed by (IR): domain authority on policy, performance target, and risk
appetite.
Informs (IP): risk performance to domain authority.

Assurance Roles
Common assurance There are number of possible assurance roles in the enterprise. Two of the most
roles common such roles are the Audit role and the Compliance role.

Compliance Role
A Compliance role holder is appointed by the Owner.
• Definition:
The Compliance Role is appointed by a domain owner as a subject matter
expert to provide a compliance checking service and to report on the degree
to which the work product output complies with the policy, the owner
manages risk within appetite, and achieves performance targets as set by the
owner.
• Role:
Responsible (R) for checking the policy compliance, performance targets
achieved, and risk appetites not exceeded in a specific domain on behalf of
the owner.
• Position on Governance Model:
Transformation, Transition, Operation, and Assess.
• Risk Management Communications Role:
Informed by (IR): domain authority on policy, performance target, and risk
appetite.
Informs (IP): domain authority on policy compliance.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 18
 SABSA Responsibility Assignment Modelling

Audit Role
An Auditor is appointed by the Owner.
• Definition:
The Auditor role is appointed by a domain owner as a subject matter expert
to provide an audit service and to report independently on the degree to
which work product output of a subdomain complies with the policy of the
owner, the subdomain manages risks within appetite, and if the subdomain
achieves performance targets as set by the owner.
• Role:
Responsible (R) for auditing the policy compliance, performance targets
achieved, and risk appetites not exceeded in a specific subdomain on behalf
of the owner.
• Position on Governance Model:
Transformation, Transition, Operation, and Assess.
• Risk Management Communications Role:
Informed by (IR): domain authority on policy, performance target, and risk
appetite.
Informs (IP): domain authority on policy compliance of subdomain.

Applying SABSA RAM across the Enterprise

Through-life To present the application of the SABSA RAM it is recommended that a domain
application of SABSA model construct is used for each attribute to visually represent the relationships.
RAM
It can, of course also, be achieved with a matrix as shown in Figure 4.
Figure 10 shows a visual representation of such a domain model concept that can
be populated with domain names and authorities of those domains.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 19
SABSA Responsibility Assignment Modelling

Figure 10: Domain Model Construct concept to visually present

authorities and their roles & responsibilities
After applying the SABSA RAM using the Domain Model shown in Figure 10, in
Figure 11 we can see notional domain names and domain authorities populated.

Figure 11: Domain Model Construct populated with

notional domain names and authorities
In Figure 12 we can see the addition of a Responsible Trustee assignment in the
Domain Model construct.

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 20
 SABSA Responsibility Assignment Modelling

Figure 12: Domain Model Construct with Responsible Trustee added

Apply SABSA RAM at every stage of the Enterprise Lifecycle.

•
Develop the SABSA RAM Matrix in relation to SABSA Attributes or Activities
for every:
• Strategy
• Programme
• Project
• Operational process
Extended enterprise- Apply SABSA RAM at every level of every domain hierarchy.
wide application of
SABSA RAM • Develop the SABSA RAM Matrix in relation to SABSA Attributes or Activities
for every:
• Business unit
• Business function
• Business process
• Business service

Copyright © The SABSA Institute 1995—2023. All rights reserved. Release 1.0 June 2023. Page 21