On IT Risk Management Ontology using DEMO

Mariana Rosa

1,2

, Sérgio Guerreiro

1,2

and Rúben Pereira

INESC-ID, Rua Alves Redol 9, 1000-029 Lisbon, Portugal

Instituto Superior Técnico, University of Lisbon, Av. Rovisco Pais 1, 1049-001 Lisbon, Portugal

Instituto Universitário de Lisboa (ISCTE-IUL), Lisbon, Portugal

Keywords:

DEMO, Essential Model, IT RM, Ontology, SLR.

Abstract:

Nowadays, organisations use and rely on Information Technology (IT) solutions. However, despite their ben-

eﬁts, IT solutions induct risks. Consequently, organisations implement Risk Management (RM), more specif-

ically Information Technology Risk Management (IT RM), in order to maximize the effectiveness of IT usage

while dealing with IT risks. Nevertheless, IT RM’s implementation is not easy, since numerous standards and

frameworks propose multiple RM processes to deal with IT risks. Moreover, these processes are composed

of different activities causing confusion. In the end, organisations are not capable of managing risks success-

fully due to IT RM’s complexity. To overcome IT RM diversity, a Systematic Literature Review (SLR) was

conducted. The goal is to identify which are the most essential IT RM activities. The SLR results were then

integrated with ISO 31000 and PMBOK standards in the form of an ontology using Design and Engineering

Methodology Ontology (DEMO). The contributions of this study are: the aggregate analysis of IT RM activ-

ities through the SLR; the identiﬁcation of reasons and beneﬁts of using DEMO; a description of an IT RM’s

essential model designed as an ontology; and a critical view of the beneﬁts of the ontological model proposed.

1 INTRODUCTION

Organisations depend on Information Technology

(IT) to survive in the current market. Despite the ben-

eﬁts of this dependency, it inducts risks that can af-

fect the achievement of corporate goals. To maximize

the effectiveness of IT usage and to manage the risks

associated with it, organisations implement a speciali-

sation of Risk Management (RM) - Information Tech-

nology Risk Management (IT RM) (Ernawati and Nu-

groho, 2012). RM is deﬁned as "coordinated activi-

ties to direct and control an organisation with regard

to risk" (ISO, 2018). In IT RM, RM activities are ap-

plied to IT so as to manage IT risks, such as security

breaches (T. Yaqoob et al., 2019), loss of computer

system data, among others (S. A. Torabi, 2016).

If an organisation has the ability to successfully

manage risk, it can modify it so that the organisa-

tion is more likely to meet its goals. Therefore it is

crucial for organisations to perform IT RM (Purdy,

2010). However, organisations face difﬁculties in im-

plementing IT RM. There are numerous standards,

frameworks and related literature that propose differ-

ent RM processes to deal with IT risks, causing some

confusion regarding the concepts/relationships of IT

RM. Furthermore, these standards and frameworks

have their own limitations, so the research commu-

nity is continuously proposing new frameworks(S. Is-

lam, 2014). To overcome IT RM’s diversity, this re-

search used the Systematic Literature Review (SLR)

methodology, based on the guidelines of Kitchen-

ham (2004), in order to answer the following research

question: Which are the concepts/relationships of IT

RM that should compose an ontology of this process?

Besides this process’s diversity, IT RM’s domain

is complex since it encompasses many processes and

concepts. Therefore, a well-deﬁned IT RM ontology

that captures IT RM concepts/relations would create

a great step forward in simplifying and clarifying IT

RM, thus facilitating IT RM’s implementation.

By searching for the topic of interest "risk man-

agement" AND "ontology" in the databases of Web

of Science Core Collection, KCI-Korean Journal

Database, Russian Science Citation Index, Current

Contents Connect and SciELO Citation Index, 73 ar-

ticles reaching as far back as 2019 (included) were

found. This number is considerably low when con-

sidering that the solo interest topic "risk management"

results in 55203 articles in the same databases. More-

over, the 73 articles related with ontology are applied

to multiple research areas and not as an abstract risk

258

Rosa, M., Guerreiro, S. and Pereira, R.

On IT Risk Management Ontology using DEMO.

DOI: 10.5220/0010146002580266

In Proceedings of the 12th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2020) - Volume 2: KEOD, pages 258-266

ISBN: 978-989-758-474-9

management approach. Therefore, it is hypothesized

that an RM ontology is still an open research area

and the domain-speciﬁc applications are preferred. IT

RM is a well-deﬁned domain-speciﬁc RM application

where many of the frameworks and standards avail-

able demand a consensus ontological deﬁnition effort.

The main goal of this research is to produce an

ontology of IT RM, using as input the results of the

SLR conducted. Design and Engineering Methodol-

ogy Ontology (DEMO) was used to produce the IT

RM ontology (J. L. Dietz, 2020).

The structure of this study is as follows. Section

2 provides a brief summary of the SLR methodology

applied to gather information and the results achieved.

The SLR offers a clear and comprehensive overview

regarding IT RM, that was used as a basis for deﬁn-

ing an IT RM’s ontology. The procedure of producing

the ontology and the models that constitute the ontol-

ogy itself are described and presented in Section 3.

Finally, the conclusions and directions for further re-

search are described in Section 4.

2 SYSTEMATIC LITERATURE

REVIEW

When we started to study the literature related to

IT RM, we found out that this process encompasses

several concepts and processes, and that there is

some confusion regarding IT RM concepts/relations,

more speciﬁcally the IT RM activities. Standards

such as the International organisation for Standard-

ization (ISO) 31000, Project Management Body of

Knowledge (PMBOK), among others, are not con-

sensual regarding IT RM activities. Moreover, the re-

search community is continuously proposing new RM

frameworks due to the limitations of such standards.

The goal of performing this SLR is to gather data

concerning IT RM activities and their relationships,

proposed or not by known standards and frameworks,

in order to ﬁnd out the essential activities of IT RM.

2.1 SLR Process

This work’s SLR is based on the guidelines of

Kitchenham (2004). The tasks taken to conduct this

review are shown in Table 1.

Four electronical repositories were used to obtain

information about the IT RM activities: IEEE Xplore

Digital Library, ACM, AIS, ScienceDirect.

This review was ﬁrst based on a search with the

chosen keywords in each repository and without any

ﬁlter, resulting in a total of 4074 articles. Then, ﬁve

ﬁlters were created following this order:

Table 1: Systematic Literature Review main phases.

Planning Systematic

Literature Review

Conducting Systematic

Literature Review

Reporting the Review

The need for a systematic review:

- IT RM is complex and diverse,

with no consensus regarding this

process activities.

Filters’ application and ﬁnal

articles:

- 50 articles.

Findings report:

- Discussion about

gathered data and

draw conclusions.

Research question:

- Which are the concepts and

relationships of IT RM that

should compose an ontology of

this process?

Data extraction and analysis:

- Reading and further analysis

of the articles resulted in a

ﬁnal set of 44 articles;

- Sample characteristics;

- Information extraction

regarding IT RM

concepts/relations.

Review protocol:

- Search string;

- Filters;

- Repositories;

- Inclusion criterion.

1. Searching for the keywords in the article’s title, or

abstract, or in the authors’ keywords;

2. Removing duplicate articles in the same reposi-

tory and between repositories;

3. Removing articles that were not in English, arti-

cles that were not published in Journals or Con-

ferences, and articles prior to 2009. Given that

IT RM is a topic that has evolved and has been

highly studied in the past 10 years, this restricted

period guarantees that the set of articles analysed

only considers recent publications;

4. Deletion of articles published in lower-ranked

publications/journals, which were assessed by

using Scimago (https://www.scimagojr.com) and

Conference Ranks (http://www.conferenceranks.

com/#data). For conferences, only A, B, A1, A2,

B1 and B2 ranks of ERA and Qualis rankings

were considered. When an article was assessed

by both rankings, Qualis prevailed. For journals,

only Q1 and Q2 ranks were accepted;

5. Finally, manual assessment of article abstracts and

introductions. Only articles covering the imple-

mentation of RM to IT risks were selected.

The keywords used to do the research were: “IT

Risk Management” AND (“activities” OR “process”

OR “stages” OR “frameworks” OR “standards”).

2.2 Results

After applying the ﬁlters, the set was composed of

50 articles, which were subject to further analysis.

For each article, the following data was extracted: IT

RM activities and, if applicable, which standard or

framework proposed those activities. Subsequently,

six articles were then removed since these: focused

on IT problems after the IT risks occurred; described

methods that in future search might integrate IT RM,

not yet specifying the activities; made reference to IT

risks but not to an IT RM process applied to those.

On IT Risk Management Ontology using DEMO

259

The ﬁnal set of articles analysed is composed of

44 articles, forming the basis of the SLR results

During the data extraction, it was observed that

there is a big diversity of activities that can inte-

grate IT RM since 74 different activities were iden-

tiﬁed. When analysing the deﬁnitions and purposes

of these activities, it was noticed that many activities

with different names from different articles had the

same meaning, decreasing then the number of differ-

ent activities identiﬁed. Some articles proposed ac-

tivities into their IT RM based on known standards

and frameworks while others suggested new frame-

works. In total 23 different standards or frameworks

were mentioned on the articles analysed

After identifying the IT RM activities and their

relevance, relationships between the most defended

activities were established, in order to ﬁnd out which

of them are essential. After this extensive analysis,

and taking into account if the IT RM activities are de-

fended by known standards, a set of essential IT RM

activities is determined. The SLR results are based on

ISO 31000:2009 and PMBOK 5: Communication and

consultation; Context Establishment; Risk Identiﬁca-

tion; Risk Analysis; Risk Response Planning; Moni-

tor and Control Risk; Recording and Reporting.

To be aligned with the latest versions of the stan-

dards, we study and establish relationships between

ISO 31000:2009 and ISO 31000:2018, and PMBOK

5 and PMBOK 6, in order to check if the activities

from the previous versions still match the activities

proposed by the latest versions. After analysing, and

knowing that the literature covering the latest versions

is still scarce, we opt for a process based on the lat-

est version of the standards since these are simply

updated versions. For example, ISO 31000:2018 de-

scribes activities in a simpler and more concise man-

ner, since it contains less RM jargon and less deﬁned

terms, and also expands some activities, but it does

not change the basic structure and fundamentals of

the activities’ purpose and deﬁnition.

The ﬁnal IT RM process is composed of nine

activities: Communication and consultation; Scope,

context and criteria; Identify Risks; Perform Qualita-

tive Risk Analysis; Perform Quantitative Risk Analy-

sis; Plan Risk Responses; Implement Risk Responses;

Monitor Risks; Recording and Reporting. These ac-

tivities’ deﬁnitions will be presented in section 3.2.

3 IT RM ONTOLOGY USING

DEMO

The SLR performed provides the IT RM activities’

deﬁnitions based on ISO 31000:2018 and PMBOK 6,

plus their relationships, dependencies and who is re-

sponsible for what. This information serves as input,

as shown in Figure 1, for deﬁning an ontology of IT

RM using DEMO. An IT RM’s ontology is deﬁned

in order to facilitate the implementation of IT RM, by

dealing with the complexity of this process.

Figure 1: From an SLR to an ontology of IT RM.

3.1 Design and Engineering

Methodology Ontology

We chose DEMO because it is a widely accepted

methodology that can produce the IT RM’s ontology

in a systematic way and by simplifying the process.

Thus, DEMO facilitates IT RM’s implementation and

provides explicit and unambiguous concepts for the

constructs used in the models (P. Huysmans, 2010).

DEMO comprises a Way of Thinking that con-

sists of Enterprise Engineering (EE) theories, a Way

of Modelling containing aspect models, and a Way of

Working which supports the making of essential mod-

els. This implies that DEMO is mainly about Enter-

prise Ontology (EO) (J. L. Dietz, 2020).

EO has a strong scientiﬁc foundation and provides

abstract and high-quality models since it focuses on

the organisation’s essence regardless all implementa-

tion and realisation aspects (Perinforma, 2012). Thus,

it facilitates the comprehension of organisations and

their operations (Hoogervorst, 2009).

Every organisation is a social system, which

means that the system elements are social individu-

als (actors). An actor is a human being that fulﬁlls

an actor role. The actor role stipulates the author-

ity that the actor may exercise and the responsibility

to do so. Commitments are raised in Coordination

acts (C-acts) and these are always about Production

facts (P-facts), for example one may request, promise,

state, and accept the P-fact Alice has got the best pa-

per award of LAP’02. The outcome of performing a

C-act is the creation of the corresponding Coordina-

tion fact (C-fact) (J. L. Dietz, 2020). C-acts/facts al-

ways occur in speciﬁc patterns of interaction between

two actors called transactions, and every transaction

is of a particular transaction kind (J. L. Dietz, 2017).

An organisation’s actors can be divided into

three layers: the O-organisation (O from Origi-

nal), the I-organisation (I from Informational), and

KEOD 2020 - 12th International Conference on Knowledge Engineering and Ontology Development

260

the D-organisation (D from Documental). The

I-organisation supports the O-organisation by re-

membering, sharing, and deriving facts. The D-

organisation supports the I-organisation by storing

and fetching documents, or data. An organisation’s

essence is captured in its O-organisation and the on-

tological model of an organisation’s O-organisation is

called its essential model (J. L. Dietz, 2020).

In the O-organisation, Original Production acts

(P-acts) generate original, new P-facts (J. L. Dietz,

2017). A P-act can be the preparation of a cup of

tea and the corresponding P-fact is the cup of tea

(J. L. Dietz, 2020).

The core elements of an organisation’s essen-

tial model are the actor roles, C-acts/facts and

P-acts/facts. In DEMO Speciﬁcation Language

(DEMOSL)-3, the essential model of an organisation

consists of four aspect models: Construction Model

(CM), Action Model (AM), Process Model (PM) and

Fact Model (FM) (J. L. Dietz, 2017).

The CM is the ontological model of an organisa-

tion’s construction: contains the actor roles, the trans-

action kinds between actor roles and the information

exchanging between actor roles. In DEMOSL-3, the

CM is represented in an Organisation Construction

Diagram (OCD), a Transaction Product Table (TPT),

and a Bank Contents Table (BCT) (J. L. Dietz, 2020).

The AM is the ontological model of an organisa-

tion’s operation, it comprises action rules that spec-

ify the P/C-acts that must be carried out, along with

the P/C-facts that must be assessed. In DEMOSL-3,

the AM is represented in Action Rule Speciﬁcations

(ARS) (J. L. Dietz, 2020).

The PM is the ontological model of an organi-

sation’s state space and transition space of the Co-

ordination World. Concerning the state space, the

PM contains the process step kinds and the applica-

ble existence laws of transaction kinds. Regarding

the transition space, the PM comprises the coordina-

tion event kinds along with the applicable occurrence

laws. In DEMOSL-3, the PM is represented in a Pro-

cess Structure Diagram (PSD) (J. L. Dietz, 2020).

The FM is the ontological model of an organisa-

tion’s state space and the transition space of the Pro-

duction World. Concerning the state space, the FM

comprises all identiﬁed P-fact types. Regarding the

transition space, the FM contains the production event

types. In DEMOSL-3, the FM is represented in an

Object Fact Diagram (OFD) (J. L. Dietz, 2020).

3.2 IT RM Activities Analysis

The essential model will be based on the IT RM ac-

tivities’ deﬁnitions provided by the ISO 31000:2018

and PMBOK 6. The standards were analysed in order

to identify the O-organisation transaction kinds (O-

transactions) and actor roles, following DEMO.

When analysing the activities’ deﬁnitions, all

realisation aspects of an organisation were ig-

nored. These are I-organisation transaction kinds

(I-transactions) and D-organisation transaction kinds

(D-transactions). All implementation aspects are dis-

regarded, i.e., the technologies that perform the P-acts

and C-acts. Additionally, we abstracted the speciﬁc

subjects that fulﬁl the actor roles (Perinforma, 2012).

To identify the O-transactions of IT RM we con-

sider the following criteria: Original P-acts/facts en-

compass manufacturing, transporting, observing, de-

ciding, and judging (J. L. Dietz, 2020).

In the deﬁnitions of the activities, their O-, I- and

D-transactions are highlighted in italics.

Communication and Consultation, as stated by

ISO 31000:2018, is deﬁned as "Communication seeks

to promote awareness and understanding of risk and

the means to respond to it, whereas consultation in-

volves obtaining feedback and information ..." (ISO,

2018). Only I-transactions were identiﬁed, since

these are about sharing and remembering facts.

According to ISO 31000:2018, Scope, context and

criteria starts with "The organisation should deﬁne the

scope of its risk management activities", then "The

context of the risk management process should be es-

tablished ...", and ﬁnally "... deﬁne criteria to eval-

uate the signiﬁcance of risk and to support decision-

making processes" (ISO, 2018). Three O-transactions

were identiﬁed, since they are related to creating

something new: T1 scope deﬁning, the actor role is

A1 scope deﬁner; T2 context establishing, the actor

role is A2 context establisher; T3 risk criteria deﬁn-

ing, the actor role is A3 risk criteria deﬁner. These

three transactions access organisation data.

Identify Risks, according to PMBOK 6 is about

"identifying individual project risks as well as sources

of overall project risk ...". This standard advises the

involvement of experts, so that "Individual project

risks and sources of overall project risk can be iden-

tiﬁed..."(PMI, 2017). Two O-transactions were iden-

tiﬁed, since they are about creating something new:

T4 risks identifying, the actor role is A4 risks identi-

ﬁer; T5 individual risks and sources of overall activity

risk identifying, the actor roles are A4 and A5 subject

matter proﬁcient. During the process of carrying out

T4, the corresponding T5 is initiated, therefore is said

that T5 is enclosed in T4, implying that A4 starts T5.

In order to identify risks correctly, it is necessary to

access information that resulted from T1, T2, T3 and

also to access data from the organisation.

According to PMBOK 6, Perform Qualitative

On IT Risk Management Ontology using DEMO

261

Risk Analysis is about "... prioritizing individual

project risks ... by assessing their probability of oc-

currence and impact...". To successfully assess risks

probability of occurrence and their impact, "Risk data

quality may be assessed ...". Assessing the risks’ oc-

currence probability and impact is subjective, since

these assessments are based on perceptions of risk by

stakeholders and that is why these are O-transactions.

The assessment of risk data quality is also an O-

transaction, because a judgement is being made re-

garding the data available. This activity also "... iden-

tiﬁes a risk owner for each risk ..." (PMI, 2017). This

is an O-transaction, since decisions about who will

be responsible for what are being made. In total, ﬁve

O-transactions were identiﬁed: T6 risks priority as-

sessment, the actor role is A6 risks analyser; T7 risks

probability of occurrence assessment, the actor roles

are A6 and A7 risks probability of occurrence asses-

sor; T8 risks impact assessment, the actor roles are A6

and A8 risks impact assessor; T9 quality of risks in-

formation evaluating, the actor roles are A7 and A8,

and A9 risks information quality evaluator; T10 risk

owner identiﬁcation, the actor role is A10 risks own-

ers’ identiﬁer. The transactions T7 and T8 are en-

closed in T6, and T9 is enclosed in T7 and T8. To

perform T6, T7 and T8, the actors need information

from T4, and to identify the risk owner, it is neces-

sary to access information that resulted from T1, T2

and also to access data from the organisation.

Perform Quantitative Risk Analysis, as stated

by PMBOK 6, is the "... process of numerically

analysing the combined effect of identiﬁed individ-

ual project risks and other sources of uncertainty..."

(PMI, 2017). This is an I-transaction, since it is about

computing, calculating and analysing data.

According to PMBOK 6, Plan Risk Responses is

where "... plans should be developed by the nomi-

nated risk owner" to address risks. Also, "The strat-

egy or mix of strategies most likely to be effective

should be selected for each risk" and where "... ac-

tions are developed to implement the agreed-upon

risk response strategy ...". If necessary, "A contin-

gency plan...can be developed ...". "Secondary risks

should also be identiﬁed ..." (PMI, 2017). The previ-

ous descriptions correspond to O-transactions, since

they are about developing something and deciding:

T11 risk responses planning, the actor role is A11

risk owner; T12 risk responses strategies selecting,

the actor roles are A11 and A12 strategies selector;

T13 actions developing, the actor roles are A11 and

A13 actions developer; T4 risks identifying, the actor

roles are A11 and A4; T14 contingency plan devel-

oping, the actor roles are A11 and A14 contingency

plan developer. The transactions T12, T13 and T14

are all enclosed in T11. To plan risk responses, it is

required to take into account the priority of risks, so it

is necessary to access T6.

Implement Risk Responses, as stated by PMBOK

6, "Expertise should be considered... to validate or

modify risk responses...and decide how to implement

them...". Also, "Project documents that may be up-

dated as a result of carrying out this process", up-

dating outcomes of previous transactions(PMI, 2017).

Two O-transactions were identiﬁed, where one re-

gards decisions and the other relates to updates that

cannot be re-computed, since these depend on new

decisions: T15 risks proﬁle updating, the actor role is

A15 risk responses implementer; T16 risk responses

implementation deciding, the actor roles are A15 and

A16 subject matter expert. The transaction T16 is

enclosed in T15. To implement risk responses, it is

required to know which are the agreed-upon risk re-

sponses, so T15 and T16 actors access T11.

According to PMBOK 6, Monitor Risks relates to

"...monitoring the implementation of agreed-upon risk

response plans, identifying and analysing new risks,

and evaluating risk process effectiveness..." (PMI,

2017). These are all O-transactions, since they are

about observing and creating something new: T17 im-

plementation of risk responses monitoring, the actor

role is A17 risk monitor; T18 risk management pro-

cess effectiveness evaluating, the actor roles are A17

and A18 RM process effectiveness evaluator; T4 risks

identifying, the actor roles are A17 and A4; T6 risks

priority assessment, the actor roles are A17 and A6.

The transactions T4, T6 and T18 are enclosed in T17.

To monitor the implementation of risk responses, it is

necessary to access T15.

The last activity is Recording and Reporting, and

according to ISO 31000:2018 "The risk management

process and its outcomes should be documented and

reported..." (ISO, 2018). These are both I and D-

transactions.

3.3 Essential Model of IT RM

Based on the previous analysis, the essential model of

the IT RM process was produced

The CM was the ﬁrst model to be produced and

it is represented by the TPT, presented in Table 2. It

shows the transaction kinds, identiﬁed in the subsec-

tion 3.2, and corresponding product kinds.

The CM is also represented by the OCD, exhibited

in Figure 2. In the OCD the solid lines without a black

diamond, between actor roles (squares) and transac-

tion kinds (discs with a red diamond), are called ini-

tiator link. These mean that the actors in the actor role

(e.g. A6) are an authorised initiator in transactions of

KEOD 2020 - 12th International Conference on Knowledge Engineering and Ontology Development

262

Table 2: Transaction Product Table of IT RM.

Transaction Kind Product Kind

T1 scope deﬁning P1 Scope is deﬁned

T2 context establishing P2 Context is established

T3 risk criteria deﬁning P3 Risk criteria is deﬁned

T4 risks identifying P4 Risk is identiﬁed

T5 individual risks and sources

of overall activity risk identifying

P5 Individual risk and source of

overall activity risk is identiﬁed

T6 risks priority assessment P6 the priority of Risk is assessed

T7 risks probability of

occurrence assessment

P7 the probability of occurrence

of Risk is assessed

T8 risks impact assessment P8 the impact of Risk is assessed

T9 quality of risks information

evaluating

P9 the information’s quality of

Risk is evaluated

T10 risks owner identiﬁcation P10 Risk Owner is identiﬁed

T11 risk responses planning P11 Risk Response is planned

T12 risk responses strategies

selecting

P12 the risk responses strategy

of Risk Response is selected

T13 actions developing

P13 the action of Risk Response

is developed

T14 contingency plan

developing

P14 the contingency plan of

Risk Response is developed

T15 risks proﬁle updating P15 Risk Proﬁle is updated

T16 risk responses

implementation deciding

P16 Risk Response

Implementation is decided

T17 implementation of risk

responses monitoring

P17 Risk Response

Implementation is monitored

T18 risk management process

effectiveness evaluating

P18 Risk Management Process

Effectiveness is reported

the transaction kind (e.g. T8). The solid lines with

a black diamond, between actor roles and transaction

kinds, represent executor links. These indicate that

actors in the actor role (e.g. A8) are an authorised

executor in transactions of the transaction kind (e.g.

T8). Dashed lines between actor roles and transaction

kinds represent information links, the transactions are

now conceived as transaction banks. This means that

the actors in the connected actor role (e.g. A4) have

access to the facts of the transaction bank of the trans-

action kind (e.g. T1) (J. L. Dietz, 2020).

The next model produced was the PM and is rep-

resented by the PSD (Figure 3). It shows the de-

pendencies between the identiﬁed processes and in

which way a transaction kind is enclosed in another

one (Perinforma, 2012).

In the PSD the solid lines represent response links,

for example the C-act [+rq] is performed in response

to the occurrence of the C-fact (+pm). The dashed

lines represent wait links, for example performing the

P-act [+ex] must wait for having reached status C-fact

(+ac). The discs of the transaction kind shapes are

‘stretched’ horizontally.

In responding to (T6/rq) A6 performs two acts:

one [T6/pm] and [T6/rq]. Next, in response to

(T6/pm) A6 initiates T7 and T8. This means that, in

order to assess the risks priority, the A6 risks analyser

ﬁrst needs to request for the risks probability of oc-

currence and the risks impact of occurrence. As soon

as the assessments are ﬁnished, T6 can be executed.

Notice that the brackets "(" and ")" represent C-facts

and square brackets "[" and "]" represent C-acts.

In both Figure 2 and 3, the terms “+rq”, “+pm”,

“+ex” and “+ac” mean, respectively request, promise,

execute and accept. (J. L. Dietz, 2020).

The next model produced was the FM, represented

in an OFD (Figure 4). It speciﬁes which facts are rel-

evant in the Production world (Perinforma, 2012).

In the OFD, the roundangles represent classes, for

example RISK. The production event types are repre-

sented by red diamonds. For example, the event type

“the priority of Risk is assessed” concerns the entity

type Risk (or the entity class RISK). Property types

are expressed by lines between classes, for instance

the property type “the risk proﬁle of Risk is Risk Pro-

ﬁle” is a function that maps RISK to RISK PROFILE.

The “>” indicates that RISK is the domain of the func-

tion and RISK OWNER the range. The class RISK is

the core concept of IT RM, and the domain of ﬁve

product kinds, P4, P6, P7, P8 and P9.

After producing the FM, the BCT (Table 3) was

built, completing the CM. It relates all transaction

kinds in the CM with the P-fact types in the FM.

Table 3: Bank Contents Table of IT RM.

bank Independent/dependent facts

SCOPE

Scope is deﬁned

CONTEXT

Context is established

RISK CRITERIA

Risk criteria is deﬁned

RISK

Risk is identiﬁed

the risk owner of Risk is Risk Owner

the risk response of Risk is Risk Response

the risk proﬁle of Risk is Risk Proﬁle

INDIVIDUAL RISK AND SOURCE OF

OVERALL ACTIVITY RISK

Individual risk and source of overall activity risk

is identiﬁed

the priority of Risk is assessed

the priority level of Risk is Float

the probability of occurrence of Risk is assessed

the risk probability of Risk is Float

the impact of Risk is assessed

the risk impact of Risk is Float

T9 the information’s quality of Risk is evaluated

T10

RISK OWNER

Risk Owner is identiﬁed

T11

RISK RESPONSE

Risk Response is planned

the risk response implementation of Risk Response

is Risk Response Implementation

T12

the risk responses strategy of Risk Response is

selected

T13 the action of Risk Response is developed

T14 the contingency plan of Risk Response is developed

T15

RISK PROFILE

Risk Proﬁle is updated

T16

RISK RESPONSE IMPLEMENTATION

Risk Response Implementation is decided

T17 Risk Response Implementation is monitored

T18 Risk Management Process Effectiveness is reported

AT1

organisation

the data of organisation

The AM, consisting of a set of ARS, was the last

model to be produced. Action rules are guidelines

for actors when dealing with events that they must re-

spond to, and are divided into three parts: the event

On IT Risk Management Ontology using DEMO

263

Figure 2: Organisation Construction Diagram of IT RM.

Figure 3: Process Structure Diagram of IT RM, regarding

T6. The Plena tool produces a PSD for each transaction.

Complete PM at https://rb.gy/9e0lhj.

part, the assess part, and the response part (J. L. Di-

etz, 2020). One transaction has multiple actions rules,

as an example one ARS for T6 is shown in Figure 5.

In Figure 5 the event to respond to is risks prior-

ity assessment being promised (T6/pm), however the

events in the while clause must also have occurred. In

this case, the actual settlement of the event must wait

until the events in the while-clause (T7/ac and T8/ac)

has occurred. In the assess part, we assess the event

and check if the actor has the authority to take the role

A6 risks analyser. After assessing the conditions, the

response part is entered. After checking the intention

of promise, if the addressee considers that the inten-

tion is valid the addressee will proceed with the event

[T6/ex] followed by [T6/st]. The addressee and per-

former of the promise is the same actor, because T6 is

a self-initiating transaction.

The acceptance of risks impact assessment (or

risks probability of occurrence assessment) is the oc-

currence of the C-fact “accept”. A6 only executes

risks priority assessment after accepting the outcomes

of risks impact assessment and risks probability of oc-

currence assessment. A6 can only assess the priority

of a risk after assessing its probability of occurrence

and its impact. So, A6 accepts the result of T7 and T8.

The dependency between the execution of T6 with the

acceptance of T7 and T8 is shown in Figure 2.

4 DISCUSSION AND

CONCLUSIONS

Organisations face difﬁculties in implementing IT

RM, due to its diversity and complexity. When we

started studying IT RM, we found out that there is

a lack of consensus regarding the IT RM activities.

Therefore, an SLR was undertaken to study and anal-

yse RM processes applied to IT risks in order to iden-

tify the most essential IT RM activities.

With the main goal of dealing with the complexity

of IT RM, an essential model of IT RM using DEMO

was produced. The IT RM’s activities deﬁnitions, re-

sulting from the SLR, were used as an input to pro-

duce the ontology. By having its roots on EO the-

ory, when producing an essential model using DEMO

one acquires an understanding of the organisation’s

essence that is comprehensive, coherent, consistent,

and concise (J. L. Dietz, 2020).

KEOD 2020 - 12th International Conference on Knowledge Engineering and Ontology Development

264

Figure 4: Object Fact Diagram of IT RM.

Figure 5: Action Rule Speciﬁcation for T6. Complete ARS

at https://rb.gy/r3c1a7.

EO provides clear deﬁnitions for the constructs

used in the aspect models, hence reducing the

degrees-of-freedom for the modeler, ensuring that

only one correct model can be developed. DEMO

also provides clear guidelines, by having a solid the-

oretical foundation, thus restricting the subjectivity in

the modeling process(P. Huysmans, 2010). By being

based on the Performance in Social Interaction theory,

DEMO models are coherent and consistent.

At ﬁrst glance, the models produced may be hard

to understand by those unfamiliar with the notation.

Nevertheless, DEMO models use a limited number

of constructs (simplicity) and follow the transaction

pattern (completeness and integrity). This limits the

number of concepts that someone must learn in order

to understand DEMO models(P. Huysmans, 2010).

Additionally, DEMO models do not contain any

implementation-related details. Even though this can

be considered an advantage regarding ﬂexibility and

integration, it is not advised to use DEMO as a stan-

dalone for communicating and reenacting IT RM

models to other parties. Hence the need to comple-

ment it with other techniques and models(P. Huys-

mans, 2010).

This research contributes to the simpliﬁcation and

clariﬁcation of IT RM by facilitating its design, im-

plementation and assessment. Consequently, we in-

crease the chances of successfully implementing an

essential IT RM process that is less expensive, either

in terms of human and ﬁnancial resources.

As future work, the IT RM’s essential model will

On IT Risk Management Ontology using DEMO

265

be validated through its application to a real case

study, and we will evaluate its completeness. We will

then discuss if the IT RM’s ontology meets or does

not meet the desired objectives, through an analysis

and assessment of key performance indicators regard-

ing the outcomes from applying the ontology.

ACKNOWLEDGEMENTS

This work was supported by the European Com-

mission program H2020 under the grant agreement

822404 (project QualiChain) and by national funds

through Fundação para a Ciência e a Tecnologia with

reference UIDB/50021/2020 (INESC-ID).

REFERENCES

Ernawati, T. and Nugroho, D. (2012). It risk management

framework based on iso 31000: 2009. In 2012 Inter-

national Conference on System Engineering and Tech-

nology (ICSET), pages 1–8. IEEE.

Hoogervorst, J. A. (2009). Enterprise governance and en-

terprise engineering. Springer Science & Business

Media.

ISO (2018). 31000: 2018—risk management—guidelines.

262.

J. L. Dietz, H. B. M. (2020). Enterprise Ontology:

A Human-Centric Approach to Understanding the

Essence of Organisation. Springer Nature.

J. L. Dietz, J. A. H. (2017). Foundations of enterprise engi-

neering.

P. Huysmans, K. Ven, J. V. (2010). Using the demo method-

ology for modeling open source software develop-

ment processes. Information and Software Technol-

ogy, 52(6):656–671.

Perinforma, A. P. (2012). The essence of organisation.

South Holland: Sapio Enterprise Engineering.

PMI, A. (2017). guide to the project management body of

knowledge (pmbok guide), 6. ver. PROJECT MAN-

AGEMENT INSTITUTE (PMI).

Purdy, G. (2010). Iso 31000: 2009—setting a new standard

for risk management. Risk Analysis: An International

Journal, 30(6):881–886.

S. A. Torabi, R. Giahi, N. S. (2016). An enhanced risk as-

sessment framework for business continuity manage-

ment systems. Safety science, 89:201–218.

S. Islam, H. Mouratidis, E. R. W. (2014). An em-

pirical study on the implementation and evaluation

of a goal-driven software development risk manage-

ment model. Information and Software Technology,

56(2):117–133.

T. Yaqoob, A. Arshad, H. A. et al. (2019). Framework

for calculating return on security investment (rosi) for

security-oriented organizations. Future Generation

Computer Systems, 95:754–763.

Notes

Consult the articles’ references at https://rb.gy/6fdtkz.

Consult the IT RM activities, and frameworks and stan-

dards at https://rb.gy/m24gqg

The Plena tool (https://www.teec2.nl/plenaen/

plena-the-tool/) that runs on the Enterprise Architect

software was used to produce the essential model. The

previous sections of this paper refer to DEMOSL-3 because

Plena currently supports DEMO version 3.7.

KEOD 2020 - 12th International Conference on Knowledge Engineering and Ontology Development

266