Computer Standards & Interfaces 62 (2019) 98–118

Contents lists available at ScienceDirect

Computer Standards & Interfaces

journal homepage: www.elsevier.com/locate/csi

Toward a unified framework for Cloud Computing governance: An approach T

for evaluating and integrating IT management and governance models
Yassine Bounaguia, , Abdellatif Mezriouia, Hatim Hafiddia,b
⁎

a
STRS Lab, INPT Rabat, Morocco
b
SIME Lab, ENSIAS Rabat, Morocco

ARTICLE INFO ABSTRACT

Keywords: Cloud Computing is currently one of the major trends in the computer industry. It offers a wide range of both
Cloud Computing opportunities and challenges. The lack of governance causes a slowdown in the adoption process, especially with
Cloud Computing governance an absence of a comprehensive approach supporting the Cloud Computing governance objectives. Regarding this
Unified framework issue, our goal is to develop a new management and governance framework based on endorsed IT models;
IT models evaluation
namely ITIL, COBIT, and ISO/IEC 27001/2. These models have been developed for different purposes and as-
IT models integration
pects of IT governance. The proposed framework is an attempt to a unified approach by taking into consideration
the models’ dissimilarities. Before we go further with the final unification stage, this study's main objective is to
develop both the evaluation and the integration approaches with regwards to the IT models. The results,
therefore, are to shed light on the relevant outcomes emanate from an elaboration within an entirely unified CC
governance framework.

1. Introduction
Cloud Computing (CC) is a model to deliver IT resources via the
network as an on-demand service. CC can allow organizations to out-
source their IT infrastructures and services to a pay-as-you-go model
based on the duration of use, the required service quality, etc. CC is
currently the latest revolution in the IT industry. It promises huge op-
portunities for its users; particularly for organizations which could
generate financial and operational interests. In [1], the National In-
stitute of Standards and Technology (NIST) defines CC as “a model for
enabling ubiquitous, convenient, on-demand network access to a shared
pool of configurable computing resources that can be rapidly provi-
sioned and released with minimal management effort or service pro-
vider interaction”. NIST also defines five essential characteristics of CC
(i.e. On-demand self-service, broad network access, resources pooling,
rapid elasticity, and measured service), three service models (i.e. Soft-
ware as a Service, Platform as a Service and Infrastructure as a Service),
and four deployment models (i.e. Private Cloud, Community Cloud,
Public Cloud, and Hybrid Cloud).
There are numerous benefits that CC can offer. This can make its
adoption highly desirable [2,3]. Although it has a lot of advantages, this
model also encounters challenges and risks that can limit its credibility
and pervasiveness such as [4,5]: Ensuring the confidentiality, integrity
and availability of the organization's data and services; providing end-
to-end security solutions; and complying with the regulations and
standards of good practices. According to the Cloud Security Alliance
[6], the main three CC security risks are unsecure interfaces and APIs,
data loss or leakage, and hardware failures. These risks respectively
account for 29%, 25%, and 10% of all the security risks in CC. The
service level agreements management realm also faces limitations and
challenges such as [7]: Difficulty to measure Cloud service providers
compliance; absence of mechanisms for automatic SLA/Service nego-
tiation and renegotiation; lack of procedures for supporting multiple
Cloud service providers; and absence of SLA translation when moving
from one Cloud service provider to another. The Cloud migration pro-
cess would also need several changes in the IT architecture. For in-
stance, migrating complex applications into Software as a Service
model may require detailed planning and testing prior to their im-
plementation. This can go up to fully change the code of some legacy
applications [8]. As a consequence, new requirements have emerged
and IT governance aspects should be reviewed and empowered [9,10].
Governance is the key discipline to address all these challenges and
maximize the organizations’ return on investment in CC [11]. CC
governance is defined as a set of policies, processes, roles, responsi-
bilities, and practices used to manage and control CC adoption and
implementation in accordance with business goals [12]. For these
purposes, an IT governance framework is highly recommended to allow
organizations to do different tasks such as: Maximizing the CC value;

⁎
Corresponding author.
E-mail address: bounagui@inpt.ac.ma (Y. Bounagui).

https://doi.org/10.1016/j.csi.2018.09.001
Received 11 July 2017; Received in revised form 13 September 2018; Accepted 21 September 2018
Available online 24 September 2018
0920-5489/ © 2018 Elsevier B.V. All rights reserved.
Y. Bounagui et al.
minimizing its inset challenges; handling all the CC governance aspects;
providing a widely accepted CC management and governance frame-
work; understanding the available capabilities; and defining the po-
licies that stand for the organizations’ needs. Furthermore, this frame-
work will provide effective means to check whether CC infrastructures
and services meet the business expectations. The elaboration of such a
framework requires meeting the following key objectives:
• Ensure the effective management of CC security risks: The CC
distributed nature and the removal of the security boundary separ-
ating IT traditional data centers from external environments have
introduced several security risks [13]. Risk management is essential
to understand organizations exposure to CC risks as well as to de-
velop suitable strategies for analyzing, assessing, mitigating, mon-
itoring, and reviewing the risks [14,15]. CC Risk management also
helps organizations understand Cloud service providers responsi-
bilities for ensuring continuous provision of CC services, review
their IT continuity plans, and provide alternative processing and
recovery capabilities [13].
• Align and communicate objectives: The business and IT objec-
tives of CC adoption should be effectively aligned to achieve the
desired outcomes [13]. They must be communicated both internally
and with Cloud service providers. This should be a part of an on-
going aligning and communication program [16].
• Integrate CC governance with existing IT governance ap-
proaches: As CC governance is an extension of IT governance, en-
suring the approaches concordance is a requirement [17]. Organi-
zations can therefore benefit from effective coexistence and
interaction between CC governance and existing IT governance ap-
proaches.
• Ensure the conversion of IT rules and decisions into policies:
The implementation of effective CC governance depends on how IT
rules and decisions are converted into policies. The conversion
process should be a part of a policy management program that al-
lows the elaboration, communication, tracking, and enforcement of
policies with regard to the CC utilization [15]. Additionally, the
program should check both the correctness of new and updated
policies and the potential inter-policy relations that may affect their
effectiveness (e.g. sub-sumptions and contradictions resulting from
change in policies) [18].
• Adapt easily: CC governance can allow organizations to easily
adapt flexibility, scalability, and services in the Cloud as business
requirements evolve [13]. It can also provide the ability to handle a
broad and complex ecosystem of services delivered by different
Cloud service providers. Consequently, organizations can overcome
IT complexity when changing their provisioning architecture from a
traditional to an on-demand model [19].
• Ensure regulatory and contractual compliance: One of the major
concerns that would be addressed by CC governance is to ensure
that the use of CC infrastructures, platforms and services comply
with existing laws and regulations as well as with the agreed con-
tractual requirements. It would particularly ensure the compliance
with the law and regulations in case the user and the provider are
from different countries [20]. Regulatory and contractual yielding
should be a part of a compliance management system that allows the
organization to track and assess the impact of new regulations as
well as to report breaches [15].
Currently, various approaches have been put forward to establish
methodologies for CC governance. Most of them aim at improving or
extending traditional IT governance and making it Cloud-aware
[11,21]. However, there is no framework that can accomplish all CC
governance objectives. The existing approaches have limitations. For
instance, either they are limited to one specific governance domain or
they only provide guidance instead of advancing a holistic approach. In
addition, none of the available studies can provide details on how CC
99
Computer Standards & Interfaces 62 (2019) 98–118
governance could be implemented [9,12].
Over the past decade, several IT management and governance
models have been developed. They are designed to provide good
practices for IT leaders to develop, implement, monitor, and continually
improve IT control and governance [16]. These models can help orga-
nizations to solve the CC governance issue. According to [4,22], com-
monly used IT models are ITIL [23], COBIT [24], and ISO/IEC 27001/2
[25,26]. Although these models are not basically designed to respond to
CC new risks and challenges, the use of a particular model or their
combination as a unified framework for CC has been recommended by
several studies [9,27]. However, evaluating the appropriateness of
these models is still required. The evaluation process should provide the
ability to quantitatively measure the adequacy of the models’ process
elements; and thus, determine their corresponding coverage rate with
regard to CC governance requirements. We would like to mention that a
process element is a fundamental and atomic unit for process definition;
for example, activities, tasks, controls, clauses, etc. The term process
element is used in this study to provide a standardized nomenclature for
different models.
Based on the evaluation results, the unification of these models into
a single comprehensive CC governance framework is required. The
unification should focus on integrating the models as well as homo-
genizing them by resolving their terminological and structural conflicts.
Thereby, the focus will be on how the models would be integrated to
better cover the new CC governance requirements. The models’
homogenization will be the subject of our future research.
Based on the following points, our main motivation is to quantita-
tively demonstrate that the unification of ITIL, COBIT, and ISO/IEC
27001/2 into a comprehensive framework is an effective means to
cover the insufficiencies in these models when they are applied to CC
governance.
• The adoption of cloud computing presents challenges within IT
governance from which new CC governance requirements are de-
rived.
• A CC governance framework that helps organizations address these
challenges is required.
• The existing approaches for CC governance have shortcomings.
• The commonly used IT management and governance models are
ITIL, COBIT, and ISO/IEC 27001/2.
• Except for COBIT, these models do not take into account the new CC
governance requirements.
• These models deal with several aspects relevant to CC governance.
• The unification of the three models may be an effective means to
overcome their insufficiencies.
This paper attempts to answer the following questions:
• What are the existing studies on CC governance?
• What is the impact of CC on the IT models: ITIL, COBIT, and ISO/IEC
27001/2?
• Why should these three models be applied to CC governance?
• What are the new CC governance requirements?
• How can we assess the suitability of these models with respect to the
identified CC governance requirements?
• How can these models be integrated to better meet the new CC
governance requirements?
It is important to note that our approach is not specifically designed
to support the unification of ITIL, COBIT, and ISO/IEC 27001/2 but
rather to provide a general and independent approach from the type of
the models being used. Thereby, the main proposition of this work is
the actual approach that is being put forward and not the application of
this approach to particular IT models.
Thus, the paper objectives are: First, to conduct a state-of-the-art
review of the main works and research studies on CC governance;
Y. Bounagui et al.
second, to review and analyze the impact of CC on IT governance
models; third, to identify the CC governance requirements and then
evaluate ITIL, COBIT, and ISO/IEC 27001/2 with regard to these re-
quirements; and finally, to set up the stage for the unification through
integrating the evaluated models.
The paper is organized as follows: The second section presents the
state-of-the-art review. The review and unification of IT models are
presented and discussed in the third section. In the fourth section the
evaluation of IT models is proposed. The latter's integration is detailed
in the fifth section. The final section, then, focuses on the paper's
overview and future work.
2. State-of-the-art review
As mentioned above, CC governance is the key discipline that allows
organizations to ensure the effective control over their CC infra-
structures and services. Currently, several approaches have been de-
veloped to deal with the CC governance issue. The relevant approaches
will be discussed and analyzed in this section.
Karkošková and Feuerlicht [4] have proposed a CC governance
lifecycle that provides guidance on the implementation and the con-
tinuous improvement of CC governance activities. The authors have
based their model on SOA governance through adapting its methodo-
logical components. They have also extended them to include CC
governance. The model has also been based on literature reviews on
SOA and IT governance. The proposed Cloud computing governance
lifecycle consists in four main phases: Planning, definition, im-
plementation, and monitoring. Each phase includes the required ac-
tivities to implement and continually improve CC governance. To de-
velop their model, the authors have first adapted and redefined the SOA
governance vitality method and the SOA governance reference model;
second, they have specified a maturity level for CC governance. The
proposed model, however, remains limited. It only provides guidance
instead of suggesting an integrated approach for CC governance. Fur-
thermore, CC governance aspects have not all been taken into account;
for example, the service level agreement management or the Cloud
service provider auditing.
Brandis et al. [21] have proposed a model that serves as a holistic
framework addressing CC governance. The authors have defined an
ontology that supports a semantic-based formalization of the model.
The framework provides an approach that combines enterprise archi-
tecture management, IT governance, and CC governance. The frame-
work has been developed around the three following paradigms: The
business–IT alignment paradigm; the governance paradigm; and the
cloud paradigm. The authors have distinguished two types of levels
corresponding to the two first paradigms (i.e. horizontal levels and
vertical levels). The horizontal levels provide consistency between
business objectives, operations, and IT infrastructures. The vertical le-
vels offer compliance and governance and consider data and informa-
tion, governance requirements as well as roles and responsibilities. The
cloud paradigm meanwhile focuses on assessing Cloud services to allow
a more feasible application of the model in architectural settings be-
lieved to be in complex. The proposed framework, however, only ad-
dresses the semantic consideration and its modeling through ontologies.
Besides, the authors did not provide details on the framework archi-
tecture, processes, and activities. It is important to note that the study
does not consider or deal with all the CC governance aspects; for in-
stance, the service level agreement management or the CC regulatory
compliance.
Bailey and Becker [9] have proposed a framework that defines the
necessary steps to implement CC governance. The authors have based
their work on existing IT models as COSO, ISO/IEC 27000, COBIT, or
ITIL. The framework allows organizations to align CC with business
value and deliver that value via an optimal resource allocation and
performance management. To build the framework, the authors have
deconstructed CC governance into six concentric dials: The process dial
100
Computer Standards & Interfaces 62 (2019) 98–118
(what is moving to the Cloud); the delivery dial (SaaS, PaaS, and IaaS);
the deployment dial (Public, Private, and Hybrid); the Cloud formation
dial (Internal/External, Proprietary/Open, Parameterized/De-para-
meterized, and In-sourced/Outsourced); the enterprise risk manage-
ment dial; and the control dial (the necessary control modifications for
a specific Cloud solution). The study, however, remains limited as it
only provides high-level description of the requirements without ex-
actly specifying how these requirements would be met. This limitation
has been justified by the authors as it should not be one-size fits-all or
unique proposition for integrating and extending IT models. Conse-
quently, it is the organization role to put into effect the necessary
methods and procedures to accomplish the integration and extension.
Moreover, relevant aspects of CC governance, such as process lifecycle
management and service level agreement management, are totally
missing.
He [17] has proposed a lifecycle process model for CC that helps
organizations to govern their Cloud-based IT services. The model pro-
vides guidelines to manage CC services and assets as well as to align CC
governance with business goals. The model serves as an input for Cloud
service providers to analyze their existing capabilities and enhance
them to better cover Cloud service users’ requirements. The author has
divided CC governance into five main domains: strategic planning, or-
ganizational alignment, service lifecycle management, policy manage-
ment, and service level agreements management. Each domain high-
lights the processes and activities required to ensure effective CC
governance. Nevertheless, the study still has got some limitations in
terms of the model's processes which are defined with high abstraction
level and do not provide sufficient details; the linkage between the
different roles and the model processes is absent; moreover, the in-
tegration with other IT governance approaches is missing.
Ahmad and Janczewski [20] have proposed a governance lifecycle
framework for public CC. Their work results in an approach to mitigate
CC security risks and improve CC governance and insurance. The fra-
mework has been designed based on legal principles and on the uni-
fication of relevant clauses of international standards, such as COBIT or
ISO/IEC 27001. The unified clauses have been categorized into three
distinct control types: The technical and operational controls; the
management controls; and the legal controls. The intersection between
the unified clauses, the CC layers, and the statutory laws constitutes the
CC governance framework. The proposed framework still suffers from a
number of drawbacks; for instance, the study has only focused on in-
formation security instead of suggesting a holistic approach for CC
governance, the authors have not addressed how IT governance models
are unified and integrated, and the study only provides high-level re-
quirements rather than providing particularities about these require-
ments.
Guo and Song [15] have proposed a CC governance model that
stresses the organizations needs in terms of policy schemes, service
profiles, services management, and governance processes. The model
also emphasizes the need for service lifecycle management, visibility,
and contextualization. To develop the model, the authors have made a
clear distinction between the policy model, the management model,
and the operational model. This is to allow adjustment to requirements
change and to different kinds of external events. The proposed model,
though, remains limited; for example, the authors have not mentioned
how the continuity of critical business processes is performed or how
their model would integrate with existing IT governance models. Fur-
thermore, the study only provides high-level requirements instead of
coming up with details on how these requirements would be achieved
by the authors model.
The Cloud Security Alliance (CSA) has published the “Security
Guidance for Critical Areas of Focus in Cloud Computing” [28]. The
report is intended to supply guidance for organizations in supporting
business objectives while managing and mitigating CC security risks.
The CSA has also released the Cloud Controls Matrix (CCM) [29] to
provide Cloud service users with fundamental controls for CC security.
Y. Bounagui et al.
The CCM is an amalgam of compliance, governance, and technical
controls that have been aligned with various industry-accepted stan-
dards and control frameworks; such as ISO/IEC 27001/2 or COBIT. The
CCM provides a domain-based approach consisting of 133 controls and
is developed around 16 security domains. The CSA works are, however,
restricted to cloud security and risks management instead of proposing
a comprehensive CC governance approach. Additionally, CC govern-
ance aspects have not all been taken into consideration; for instance,
the alignment of CC with business goals or the continuous improvement
of CC security domains.
Saidah and Abdelbaki [12] have proposed a CC governance fra-
mework that intends to enhance the Guo's governance model [15] by
adding the security controls of the CCM [29]. To develop the frame-
work, the authors have first identified the gaps in the Guo model.
Second, they have identified the controls of the CCM that relate to each
of the model processes. Finally, they have added, modified and updated
the missing components. The framework has been developed around
the five following stages to ensure the continuous improvement of CC
governance processes: Strategic trigger; define and align; build and
implement; deliver and measure; and operate and feedback. Although
the study has proposed an enhanced version of the Guo's model, it does
present the same limitations we have already identified.
The European Network and Information Security Agency (ENISA)
has published a report entitled “Cloud Computing Benefits, Risks and
Recommendations for Information Security” [30]. The report's aim is to
assist Cloud service users in assessing the security risks and benefits of
CC. The report proposes a detailed review of the political, organiza-
tional, technical and legal risks. The ENISA has also released the “Cloud
Computing Information Assurance Framework” [31] to help organiza-
tions assess the CC security risks, compare different Cloud service
provider offers, and obtain assurance from the selected Cloud service
providers. In addition, the ENISA has released the report “Security and
Resilience in Governmental Clouds” [32]. The report supplies govern-
mental organizations with a decision-making model to determine which
Cloud architectural solution best accommodates their security re-
quirements [33]. Similarly, The Committee of Sponsoring Organiza-
tions of the Treadway Commission (COSO) has released the “Enterprise
Risk Management for Cloud Computing” [34] based on the COSO En-
terprise Risk Management framework [35]. The CC framework targets
to both identify the CC security risks and their impact and to provide
strategies for monitoring and mitigating those security risks. Never-
theless, the works published by ENISA and COSO are limited to CC risk
management. Consequently, they should be combined with other IT
models in order to provide a holistic CC governance approach.
The review and analysis of CC governance studies have shown the
existence of various approaches with different backgrounds, archi-
tectures, and characteristics. In Table 1 we summarize these studies and
provide other criteria for comparison. We would like to mention that
the values assumed by the abstraction level column are either high or
low. The high level is used to designate the approaches that simply
Table 1
Comparative analysis of the existing studies on CC governance.
Authors, References Years Scope of CC governance Abstraction level
CSA, [29] 2016 Focuses on security governance Low
Karkošková and Feuerlicht [4] 2016 All CC governance aspects High
Brandis et al. [21] 2014 All CC governance aspects High
Bailey and Becker [9] 2014 All CC governance aspects High
Saidah and Abdelbaki [12] 2014 All CC governance aspects High
COSO [34] 2012 Focuses on risks governance Low
ENISA [30–32] 2012 Focuses on risks governance Low
2009
2011
He [17] 2011 All CC governance aspects High
Ahmad and Janczewski [20] 2011 Focuses on security governance High
Guo and Song, [15] 2010 All CC governance aspects High
101
Computer Standards & Interfaces 62 (2019) 98–118
explain their components, without specifying how these components
are elaborated. The low level describes the approaches that provide a
detailed description of their components. We would like also to mention
that the values assumed by the solution applicability column are either
partially applicable or totally applicable. The partially applicable stu-
dies are those that have been published with missing components which
would be developed in the future by the authors. The totally applicable
studies, on the contrary, refer to the studies that do not present any
missing components.
Despite the quality of the studies analyzed in this section, limita-
tions have been identified. However, a framework that meets the needs
of every type of Cloud service user and also accomplishes all CC gov-
ernance objectives has not yet been developed. This has been agreed
upon by several studies; for instance, [9,13,15]. The state-of-the-art
review achieved in this section has emphasized the need of a new CC
governance framework. This framework should provide an integrated
approach that takes into account all CC governance objectives. It should
particularly furnish solutions to the identified limitations.
3. IT models review and unification
Currently, there are several IT management and governance models.
They can help organizations achieve the CC governance objectives. The
role of these models in CC governance is one of the major trends in IT
[9]. Even though some studies consider CC as a new paradigm that
requires to define a new set of models, others consider it as a tech-
nology based on other existing and available technologies’ models [36].
Understanding the existing IT governance and management models is,
then, important to any discussion of CC governance. In this section, the
following IT models will be discussed and analyzed: ITIL v3, COBIT 5,
and ISO/IEC 27001/2:2013.
We would like to point out that the process of selecting these models
is first based on their ability to meet the CC governance objectives
outlined in Section one. Second, their relevance and level of use by the
scientific community and the industry are also taken into account.
Though these three models may not gather the varied needs of all or-
ganizations, studies (e.g. [22,37–39]) still agree that these models are
actually the widely adopted frameworks/standards in IT management
and governance. Accordingly, many organizations endure from the
models insufficiency with regard to CC challenges and requirements.
Third, COBIT and ISO/IEC 27001/2 provide guidance on what should
be done by IT processes through defining the overarching goals of
business “what”. The organization is hence responsible for choosing the
way to achieve those goals “how”. ITIL however provides guidance on
“how” IT processes would be planned, designed, and implemented.
Thus, the use of these three models can help organizations cover both
the “what” of CC governance and the “how” of CC management
[9,37–39]. Finally, although these three models are not specific to CC,
studies (e.g. [13,40,41]) still agree that they are comprehensive enough
and deal with many relevant aspects to support CC governance. We
Process oriented Lifecycle approach Solution applicability
Yes No Totally applicable
Yes Yes Totally applicable
No No Partially applicable
Yes No Partially applicable
Yes Yes Partially applicable
No No Totally applicable
No No Totally applicable
Yes Yes Totally applicable
Yes Yes Totally applicable
Yes Yes Totally applicable
Y. Bounagui et al.
Table 2.
Comparative analysis of the attributes of ITIL, COBIT, and ISO/IEC 27001/2.
Attribute ITIL
Name IT Infrastructure Library
Organization Developer OGC, UK
Version (Year) v3 (2007)
Scope IT service management
Focus How
Features Service delivery and support
Certification Certification of personnel
Usage Guidelines
Domain of application Service part of IT domains
Implementation guidance Guidance on processes implementation is
given
Architectural components 26 processes distributed across 5 lifecycle
stages and 4 functions
would like to mention that all the three models have been updated to
their latest version to ensure that the new needs and requirements of IT
governance are taken into account.
3.1. ITIL
ITIL is a widely accepted framework for IT service management and
delivery. It has been developed and distributed by the Office of
Government Commerce (OGC) in UK. ITIL is currently generating con-
siderable interest in IT service management. It focuses on aligning IT
services with business, improving the quality of IT service delivery, and
reducing IT costs [23]. The framework describes how IT resources and
services are organized to ensure value delivery and documents processes,
functions, and roles. ITIL provides IT leaders with a multidimensional
structure, a common semantic, and a lifecycle that describes the main
stages, processes, and activities for IT service management.
Although ITIL is not designed to support Cloud service management,
the effort required to extend this framework is reduced [42]. In fact,
according to [43,44], nearly all ITIL processes remain applicable and
valuable for the provisioning of IT services through CC. ITIL is, how-
ever, limited to IT services management and delivery. Therefore, its
adoption as a framework for CC governance will not provide a com-
prehensive approach in which all CC governance aspects are taken into
account.
3.2. COBIT
The Information Systems Audit and Control Association (ISACA) has
published COBIT as an IT management and governance framework.
COBIT helps organizations to manage IT risks, align IT strategy with
business goals, and ensure legal and regulatory compliance. COBIT is a
supporting tool-set that allows organizations to bridge the gap among
control requirements, technical issues, and business risks [45]. The
framework provides a set of generally accepted measures, indicators,
and processes to both maximize the IT value and develop the appro-
priate IT governance capabilities [46]. In addition to IT governance,
ISACA has developed COBIT to provide control and governance of CC,
supply best practices for maximizing its value, and manage its asso-
ciated risks [47,48]. ISACA has released the “IT Control Objectives for
Cloud Computing” [13] to assist organizations encounter the CC gov-
ernance challenges as well as develop a comprehensive governance
strategy around CC infrastructures and services.
Although COBIT provides a more comprehensive approach than
ITIL and ISO/IEC 27001/2 [42,49,50], its adoption for CC governance
presents limitations. One of its disadvantages is that it requires a deep
knowledge to implement its processes. Additionally, guidelines to im-
plement the framework or research studies that investigate the frame-
work's utilization are almost absent [49].
Computer Standards & Interfaces 62 (2019) 98–118
COBIT ISO/IEC 27001/2
Control Objectives for Information and Information technology – Security techniques – Code of
related Technology practice for information security management
ISACA ISO/IEC
V5 (2012) Second edition (2013)
IT governance Information security
What How
Control objectives Information security management system
N/A Certification of organization and personnel
Methodology Guidelines
All IT domains All information security domains
Generic and need customization Generic and need customization
37 processes grouped into 5 domains 14 clauses distributed across 35 categories and 114
controls
3.3. ISO 27001/2
The ISO/IEC 27k series of standards have been published by the
International Organization for Standardization (ISO) and the
International Electro technical Commission (IEC). These standards
provide security controls and best practices to establish, implement,
maintain, and continuously improve organizations’ Information
Security Management System (ISMS). The ISO/IEC 27001 and ISO/IEC
27002 standards are the core components of the ISO/IEC 27k series
responsible for implementing the ISMS. The ISO/IEC 27001 specifies
the cyclic management approach to continuously improve organiza-
tions’ ISMS. It also describes the concept of “Statement of Applicability”
which refers to the process of identifying the appropriate controls
(addressed in the “Annex A” of ISO/IEC 27001) that should be applied
to each lifecycle phase. Particularly, the annex addresses the informa-
tion security controls and control objectives, from the ISO/IEC 27002,
that should be implemented within each specific lifecycle phase. The
ISO/IEC has released the ISO/IEC 17788 [51] and ISO/IEC 17789 [52]
standards to help organizations face the new security and privacy issues
raised by CC adoption. The ISO/IEC 17788 specifies the CC overview
and vocabulary, whereas the ISO/IEC 17789 describes the CC reference
architecture. The ISO/IEC has also released the ISO/IEC 27017 [53]
and ISO/IEC 27018 [54] to, respectively, provide the code of practices
for information security in CC and ensure the protection of personally
identifiable information for CC services.
Although the ISO/IEC 27k Series of standards provide a risk-based
approach that covers the confidentiality, availability, integrity, and
compliance aspects, these are still limited to the information security
domain. Thereby, their combination with other IT models is required.
We would like to mention that only ISO/IEC 27001 and ISO/IEC 27002
(referred in this paper as 27001/2) are considered in this study as they
are the core standards of the ISO/IEC 27k Series.
3.4. Unification of IT models
Despite the diversity of the models involved (see Table 2), the
choice of a particular standard/framework or their combination de-
pends on the organization, the personnel, the maturity, and the effec-
tiveness of models’ process elements. Obviously, using a single model is
not enough. According to Sahibudin et al. [22], IT models are not
comprehensive enough on their own to provide an efficient IT gov-
ernance and management system. Additionally, despite the duplications
and overlaps that exist between these models, their unification will help
organizations to cover the “what, how, and scope” of IT governance
[42]. This can provide organizations with the ability to integrate dif-
ferent practices from different models, thus, allowing a more effective
IT control and governance [39,55].
The unification of multiple models can help organizations better
102
Y. Bounagui et al.
overcome the CC governance challenges. Each model presents strengths
and limitations variously when applied to CC governance. The uni-
fication will enable organizations to lessen the limitations and to better
fulfill the CC governance requirements. As each model determines its
own structure, terminology, definitions, and quality systems, etc. we
can then notice an increase in the complexity of models’ unification
[56]. We thus consider the unification process as a result of executing
the following unification methods. These methods have been designed
to support the evaluation, integration, and homogenization of multiple
models to elaborate a unified framework for CC governance.
• Evaluation method: It provides a quantitative approach to assess
the accuracy with which a specific model validates a set of CC
governance requirements. This method is performed by identifying
the CC governance requirements, mapping the models’ process ele-
ments to these requirements, and calculating the models’ coverage
rate.
• Integration method: It furnishes an approach to integrate the
evaluated IT models. This method focuses on identifying the pos-
sible combinations that can exist between the models’ process ele-
ments. The objective is to elaborate new integrated practices of
these process elements which better address the CC governance re-
quirements.
• Homogenization method: It affords an approach to resolve the
structural heterogeneities that exist between the models in the de-
scription of their process elements. The purpose of the homo-
genization method is to provide a homogenized representation of
the process elements that establish an integrated practice.
As we have already mentioned in the introduction, these three
methods are not specifically designed to support the unification of the
three IT models included in this study. They are rather designed to
support the unification of multiple models regardless of their type. The
main contribution of this research is the approach that we have put
forward to evaluate, integrate, and homogenize IT models and not the
application of this approach to particular IT models. The development
of the three methods has been based on the following research studies:
[22,37,39,56–58]. In the following sections, the evaluation and in-
tegration methods will be described. The homogenization method will
be the subject of what follows.
4. Evaluation method
This section is intended to provide details about the evaluation
method. The objective is to develop a method that provides the ability
to measure the coverage rate of models’ process elements with regard to
CC governance requirements. For this purpose, an approach has been
elaborated. It is used to evaluate ITIL, COBIT, and ISO/IEC 27001/2. As
shown in Fig. 1, the evaluation method embodies the following phases:
i Requirements identification: The first phase of the evaluation
method focuses on identifying the CC governance requirements.
These are identified through a systematic research review of the
literature. The CC governance requirements constitute the basis
upon which the models can be evaluated and subsequently in-
tegrated.
ii Models mapping: The second phase of the evaluation method
achieves the models mapping. This phase focuses on mapping the
models’ process elements to the identified CC governance require-
ments. The mapping is accomplished through a comparative analysis
between the requirements of the process elements and CC governance.
iii Models evaluation: The third phase of the evaluation method
measures the coverage rate of the mapped process elements to de-
termine their score. This score expresses the percentage of the CC
governance requirements that are validated by the mapped process
elements.
103
Computer Standards & Interfaces 62 (2019) 98–118
iv Result analysis: The final phase of the evaluation method analyzes
the findings. The models’ evaluation outcomes are then compared
and synthetized.
More details about the evaluation method and its application can be
found in [59]. This section will first present the CC governance re-
quirement identification. Second, it will try to provide details on the
evaluation approach; finally, it will discuss and analyze the findings.
4.1. Requirements identification
The first phase of the evaluation method concerns the identification
of the CC governance requirements. These requirements are the main
component of the evaluation method. They have been identified
through a systematic research review of CC governance studies. To
elaborate the systematic research review, we relied on the approach
proposed by Brereton et al. [60]. As show in Fig. 2, the review process
is divided into the three following steps: Plan the review; conduct the
review; and analyze and document the review. These steps are de-
scribed as follows:
(i.1) Plan the review:
The first step deals with the identification of the research questions
and the development of review protocol. First, we have defined the
three following research questions that constitute the basis of the re-
search strategy for extracting the literature.
Q1: What are the existing approaches for Cloud Computing gov-
ernance?
Q2: What are the types of approaches for cloud computing gov-
ernance?
Q3: What are the CC governance requirements?
Second, based on the identified research questions, we have devel-
oped the review protocol. The protocol supplies a detailed plan of the
review process. This includes, for instance, the necessary steps to follow
when conducting the review or the conditions to apply when selecting
the primary studies. Based on the developed protocol a search strategy
has been elaborated.
(i.2) Conduct the review:
The second step of the review process focuses on: identifying the
relevant research studies; selecting the primary studies; extracting the
required data; and synthetizing the extracted data. First, to identify the
relevant studies, we have searched the following databases with the
search string presented in Table 3: ACM Digital Library; IEEE Xplore;
Science Direct; Springer Link; Google Scholar; and Wiley. We have
extracted a significant amount of peer-reviewed publications from 2010
to 2017. Second, we have used the inclusion and exclusion criteria
presented in Table 4 to select the primary studies among the identified
relevant studies. Applying the inclusion and exclusion criteria has re-
sulted in the selection of 32 primary studies (see Table A1 of the ap-
pendix). Finally, the CC governance requirements are identified and
then synthesized. We would like to point out that the requirements
identification process is based on reviewing and synthesizing the CC
governance requirements that have been addressed by the primary
studies. Thus, for each primary study, a list of requirements is elabo-
rated by taking into account both the abstraction level as well as the
context.
To ensure a better understanding, structuring, and consistency of
these requirements, they have been organized into three hierarchical
levels. The first level gives the high-level functional requirements. They
are called Required Domains (RDs). The next level is Required Controls
(RCs). They provide more details about the RDs. Finally, the last level is
Required Activities (RAs). They highlight the low-level functional re-
quirements. The motivation behind the proposed structuring of CC
governance requirements is, first, to allow their definition at different
levels of abstraction and precision; second, to ensure efficiency and ease
Y. Bounagui et al. Computer Standards & Interfaces 62 (2019) 98–118

Fig. 1. Evaluation method.

Fig. 2. Steps to achieve the systematic research review.

of use; and finally, to maximize the potential of exploring a large set of

Table 3. CC governance requirements. More details about the approach followed
Search string. to identify these requirements can be found in [10].
Cloud Computing This approach has enabled us to identify the four following key
governance RDs: Cloud Migration (CM); Information Security (IS); Risk
[AND] Management (RM); and Service Level Agreements (SLA). The overall
Services 〈OR〉 Data 〈OR〉 Risk 〈OR〉 Performance 〈OR〉 Migration 〈OR〉 Information
objectives of these RDs are as follows: First, the CM required domain
security 〈OR〉 Confidentiality 〈OR〉 Service level agreement 〈OR〉 Compliance
〈OR〉 Service provider
aims to provide the required controls and activities for planning, ex-
[AND] ecuting, evaluating, and monitoring CC migration. Second, the IS re-
Governance 〈OR〉 Requirements quired domain intends to supply the required controls and activities
relating to the implementation of CC security measures. Third, the RM
required domain aims to furnish the required controls and activities

Table 4.
Inclusion and exclusion criteria.
Inclusion Studies that propose an approach for the governance of Cloud Computing or the governance of its subdomains (e.g. data governance, information security
governance, etc.).
Studies in English in the form of a peer-reviewed manuscript.
Studies in English published by recognized organizations (e.g. ISACA, CSA, etc.).
Exclusion Studies that do not explicitly propose an approach for the governance of Cloud Computing or the governance of its subdomains.
Studies developed for a very specific context (e.g., eHealth, national security, etc.).
Non-English and non-peer reviewed Studies, white papers, theses, books, and chapters.

104
Y. Bounagui et al.
dealing with the identification, analysis, mitigation, monitoring, and
review of CC security risks. Finally, the SLA required domain intends to
provide the required controls and activities concerned with the initia-
tion, negotiation, establishment, monitoring, enforcement, and termi-
nation CC service level agreements.
It can be noted that each RD is composed of several RCs. Similarly,
each RC comprises various RAs that describe the Cloud service user and
the Cloud service provider requirements. An example illustrating the
identified CC governance requirement of the SLA required domain is
given in Table A2 of the appendix. Moreover, Fig. A1 of the appendix
shows all the identified RCs and RAs with regard to the four RDs.
It is worth mentioning that the IS required domain follows the same
hierarchical structure provided by the ISO/IEC 27002 because this
standard provides a comprehensive approach and detailed processes
that consider all information security aspects. It is also worth noting
that the objectives of each RC have been elaborated based on the
overall objectives set for the RDs. This is performed thanks to a func-
tional breakdown of the overall objective of each RD into a set of sub-
objectives. These sub-objectives are further detailed and used to de-
velop the objectives of each RC (see Table A2 of the appendix).
The SLA required domain will be used afterwards to illustrate the
evaluation and integration approaches. Moreover, in order to further
elucidate the models mapping and evaluation phases, the focus will be
put on the required control “SLA_SNE: SLA Negotiation and
Establishment” (see Table A2 of the appendix). This RC focuses on the
establishment and maintenance of a stable, reliable, and measurable
business relationship between the Cloud service provider and the Cloud
service user. This RC includes the following RAs: “SLA_SNE_1: CSP
discovery”; “SLA_SNE_2: SLA negotiation and establishment” ;
“SLA_SNE_3: SLA monitoring and reporting”; and “SLA_SNE_4: SLA re-
view and enforcement”.
4.2. Models mapping
The second phase of the evaluation method is models mapping. In
this phase, the models’ process elements are mapped to the identified
RAs to determine which of these process elements validate the re-
quirements addressed by the RAs. As shown in Fig. 3 bellow, the models
mapping is performed as follows:
Fig. 3. Models mapping.
105
Computer Standards & Interfaces 62 (2019) 98–118
(ii.1) Knowledge acquisition:
The first step concerns the acquisition of knowledge about the
models involved. This step is first performed by analyzing the archi-
tectural components of the models in order to identify how each model
describes its process elements (see the last row of Table 2). Second, the
process elements of each model are analyzed in order to identify the
Candidate Process Elements (CPEs). The analysis process focuses on
performing a high-level examination of each process element descrip-
tion. Thus, if the description of a process element is adequate or par-
tially adequate to satisfy the overall objective of a RD, this process
element will be considered as a CPE. Hence, for each model and for
each RD, a list of CPEs is elaborated. Third, the list of CPEs is enriched
by analyzing the mapping proposed by existing studies; for instance, the
CCM [29] or ITGI guidance for aligning IT models [61]. Thus, if the
analysis of existing studies reveals other process elements that we have
not considered in the first place, these process elements are added to the
list of CPEs.
For instance, the execution of this first step has enabled us to
identify the following CPEs with regard to the SLA required domain:
“SD 3.[3–6]”, “SD 4.2.5 [1–10]”, and “SS 5.4″ from ITIL; “APO 09.
[01–05]”, “APO 11.03″, “DSS 01.02″, “BAI04.03″, and “BAI 06.01″
from COBIT; “Clauses 15.1.[2–3]”, “Clauses 15.2.[1–2]”, and “Clause
8.1.4″ from ISO/IEC 27001/2.
We would like to mention that the identifier “SD x.x” or “SD x.x.x.x”
(with x integer) is used by ITIL as an abbreviation to identify the pro-
cess elements that belong to the “Service Design” publication. Likewise,
the identifiers “APO x.x”, “BAI x.x”, and “DSS x.x” (with x integer) are
used by COBIT as abbreviations to identify the process elements that
respectively belong to the governance domains “Align, Plan and
Organise”, “Build, Acquire and Implement”, and “Deliver, Service and
Support”.
(ii.2) Process elements validation (1st level mapping):
The second step deals with the process elements validation. This
step is achieved through analyzing the objectives of each CPE with
regard to the RCs’ objectives. Thus, if a CPE contributes or partially
contributes to achieving the some objectives of a RC, it is mapped to
this RC; otherwise, it is eliminated. In order to simplify the mapping
between the CPEs and the RCs, all the objectives are considered at the
same significance level. For each model, the mapping between the CPEs
Y. Bounagui et al. Computer Standards & Interfaces 62 (2019) 98–118

Table 5.
Proposed mapping of ITIL, COBIT, and ISO/IEC 27001/2 for the RAs of the SLA required domain.
ID of RA ITIL mapping COBIT mapping ISO/IEC 27001/2 mapping

SLA_SI_1 SD 3.3, SD 3.4, SD 3.5, SD 3.6, SD 4.2.5.1, SD 4.2.5.9 APO 09.01, APO 09.02 Clause 15.1.1
SLA_SNE_1 SD 4.2.5.1, SS 5.4 APO 09.01, APO 09.02,DSS 01.02 N/A
SLA_SNE_2 SD 4.2.5.2, SD 4.2.5.5 APO 09.03, APO 09.04, BAI 04.03, BAI 06.01 Clause 15.1.2, Clause 15.1.3
SLA_SNE_3 SD 4.2.5.3, SD 4.2.5.6, SD 4.2.5.10 APO09.04 Clause 15.1.2, Clause 15.1.3, Clause 15.2.1, Clause 15.2.2
SLA_SNE_4 SD 4.2.5.4, SD 4.2.5.5, SD 4.2.5.7, SD 4.2.5.8 APO09.05 Clause 15.1.2, Clause 15.1.3,
SLA_ST_1 SD 4.2.5.4, SD 4.2.5.5, SD 4.2.5.8 APO09.04 Clause 8.1.4

and the RCs is performed according to the following mapping criteria:
a When the objectives of a CPE totally or partially match the objec-
tives of a single RC, a (1:1) mapping is performed.
b When the objectives of a CPE totally or partially match the objec-
tives of more than one RC, a (1:n) mapping is performed.
c If a and b fail, no mapping is performed.
We would like to mention that the mapping is accomplished without
considering the RAs included in the RCs. The validated CPEs will then
establish the list of the Process Elements to Be Mapped (PEBMs). For
each model, the output of this step is a list of RCs and their corre-
sponding PEBMs. We also would like to stress that the first and second
steps of the mapping procedure are iteratively executed until there are
no more CPEs.
For instance, the CPEs that have been mapped to the RC “SLA_SNE”
are the ones that appear in rows 2, 3, 4, and 5 of Table 5 below. We note
that the following CPEs: “SD 4.2.5.9: Develop contacts and relation-
ships” from ITIL and “APO11.03: Focus quality management on cus-
tomers” from COBIT are not mapped to the RC “SLA_SNE” since they do
not match its objectives.
(ii.3) Keywords identification:
The third step focuses on analyzing the models in order to elaborate
the list of Key Words that Identify Requirements (KWIRs). To identify
these keywords, we have first relied on existing guidelines to determine
the common keywords used in the literature to document the require-
ments; for example, Bradner guideline of RFC Series [62]. Second, we
have analyzed the three models and we have extracted the KWIRs that
each model uses to describe its requirements. The context of each KWIR
is also identified. For instance, the statement “Should [verb] that” is
used by the ISO 27001/2 to indicate the list of requirements derived
from a particular process, activity, or task; while the same statement is
used by COBIT to indicate the requirements that must be satisfied by a
particular activity. We would like to mention that a process is a logical
group of activities which uses resources to transform inputs into out-
puts. An activity, meanwhile, is a logical group of tasks (set of atomic
units of work to be completed) that occurs over time and necessarily
produces a recognizable result.
For each model, the output of this step is a list of KWIRs and their
corresponding contexts. We present in Table 6 below the list of key-
words that are used by each of the three models to describe their re-
quirements. The analysis of the three models has shown that the re-
quirements may be expressed without the use of KWIRs. This
corresponds to the two forms of requirements expressing “[verb]…”
and “[verb]… and [verb]”. Although these two forms do not contain
keywords, they are considered in the study as KWIRs since their context
can vary across the models.
(ii.4) Mapping performance (2nd level mapping):
In this step, the mapping is performed between the RAs and the
PEBMs. The mapping is achieved by accomplishing a comparative
analysis between the RAs’ requirements and those of the PEBMs. The
KWIRs play an important role in the comparison as they enable us to
easily identify the key requirements of a PEBM. Thus, when the re-
quirements of a PEBM partially or totally meet the requirements of at
least one RA, it is mapped to this RA; if not, it is eliminated. For each
model the mapping between the PEBMs and the RAs is performed by
considering the following mapping criteria:
a When the requirements of a PEBM totally or partially address the
requirements of a single RA, a (1:1) mapping is performed.
b When the requirements of a PEBM totally or partially address the
requirements of more than one RA, a (1:n) mapping is performed.
c If a and b fail, no mapping is performed.
We would like to mention that when two RAs or more are validated
with the same process element (which corresponds to n:1 mapping
between the RAs and the PEBM), this process element will be dupli-
cated in all the RAs. Thereby, the n: 1 mapping will be substituted by n
mapping of the type 1: 1; where n is the number of the RAs that are
validated by the same PEBM. For each model, the output of this step is a
list of RAs and their corresponding mapped process elements. We pre-
sent in Table 5 the obtained results from mapping ITIL, COBIT, and ISO
27001/2 to the RAs included in the SLA required domain.
For instance, the PEBMs “APO09.03″, “APO09.04″, “BAI04.03″, and

Table 6.
List of KWIRs for ITIL, COBIT, and ISO/IEC 27001/2.
Model KWIRs Context description

ITIL [verb]… / [verb]… and [verb] / Should [verb] / Should [verb] … and Indicates the requirements that must be satisfied by a particular process, activity,
[verb] / Must [verb] / Must [verb] … and [verb] or action.
Should be [verb] / Must be [verb] Specifies the characteristics of a particular process, activity, or action.
Should include / Must include Indicates the details to include in a particular process, activity or action.
COBIT [verb]… / [verb]… and [verb] / Should [verb] / Should [verb] … and Indicate the requirements that must be satisfied by a particular activity.
[verb] / should [verb] that
Should be [verb] / Must be [verb] Specifies the characteristics of a particular activity.
Should include Indicates the details to include in a particular activity.
ISO/IEC 27001/2 [verb]…/ [verb]… and [verb] / Should [verb] / Should [verb] … and Indicate the processes, procedures, activities, or tasks that should be developed
[verb] and maintained.
Should [verb] that Indicates the requirements that must be satisfied by a particular process,
procedure, activity, or task.
Should be [verb] Specifies the characteristics of a particular process, procedure, activity, or task.
Should include Indicates the details to include in a particular process procedure, activity, or task.

106
Y. Bounagui et al.
Fig. 4. Models evaluation.
“BAI06.01″ of COBIT are mapped to the RA “SLA_SNE_2″ as follows:
The requirements description of the RA “SLA_SNE_2″ (see Table A2 of
the appendix) and those of the PEBMs “APO09.03″, “APO09.04″,
“BAI04.03″, and “BAI06.01″ are decomposed into multiple independent
and integrated sub-descriptions of requirements. The sub-descriptions
of the PEBMs “APO09.03″, “APO09.04″, “BAI04.03″, and “BAI06.01″
are denoted by a numerical value. They are then mapped to the sub-
descriptions of the RA “SLA_SNE_2″ which are displayed on the left side
of a matrix. Table A3 of the appendix gives the performed mapping
between the RA “SLA_SNE_2″ and the PEBMs “APO09.03″, “APO09.04″,
“BAI04.03″, and “BAI06.01″.
(ii.5) Mapping analysis:
In this last step, an analysis of the mapping results is performed. The
analysis process focuses on verifying the findings, making the necessary
modifications if errors have been made during the mapping process,
and synthesizing the results.
For instance, the analysis of the mapping results of the three models
shows that all the SLA required activities are validated by ITIL with two
process elements or more. COBIT validates 50% of the SLA required
activities with one process element, and the rest is validated with two
process elements or more. Concerning the ISO/IEC 27001/2, 16.67% of
the of the SLA required activities are not validated by any process
elements, 33.33% of the SLA required activities are validated with one
process element, and the rest is validated with two process elements or
more.
4.3. Models evaluation
The third phase of the evaluation method aims to calculate the
coverage score of the models for each RA, RC, and RD. As shown in
Fig. 4 bellow, the models evaluation is performed as follows:
(iii.1) Design of required activities evaluation:
The first step focuses on designing the measurement scale that we
will use to determine the coverage score of the mapped process elements.
Given the difficulty to measure the correlation between the descriptions
of the process elements and those of the RAs (due to their qualitative
nature), the measurement scale will only contain six levels of coverage
scores. These levels will range from 0 to 100% with a step equal to 20%.
As shown in Table 7 bellow, these levels are respectively: Not addressed;
107
Computer Standards & Interfaces 62 (2019) 98–118
few aspects addressed; some aspects addressed; many aspects addressed;
semi-complete coverage; and complete coverage. The rationale behind
using this scale and not a more granular one (for example, a scale that
contains 11 levels of coverage scores with a step equal to 10%) is to
reduce the complexity of how the diverse RAs are evaluated.
For instance, if an 11 levels scale is used, it would be difficult to
determine with precision the coverage score of the process elements
“APO09.03″, “APO09.04″, “BAI04.03″, and “BAI06.01″ from COBIT
with regard to the RA “SLA_SNE_2″ (see Table A3 of the appendix). In
this case, the coverage score of these process elements would be 80 or
90% since the RA is almost completely covered by these process ele-
ments. If a 6 level scale is used, the coverage score of these process
elements will be exactly 80% since the RA is not completely covered,
and the mapped process elements would cover more than 60% of the
RA's requirements.
(iii.2) Required activities evaluation:
The second step focuses on measuring the coverage score of the
mapped process elements for each RA (CS _RAi ). This score gives the
percentage of the CC governance requirements that have been validated
by the proposed mapping. Based on the elaborated measurement scale,
we present in Table 8 (columns C8, C9, and C10) the coverage scores of
ITIL, COBIT, and ISO/IEC 27001/2 for the RAs included in the SLA
required domain.
For instance, the analysis of the mapping results presented in
Table A3 of the appendix shows that the process elements “APO09.03″,
“APO09.04″, “BAI04.03″, and “BAI06.01″ from COBIT cover almost all
the requirements addressed by the RA “SLA_SNE_2″. Based on the scale
presented in Table 7 above, the coverage of these process elements
corresponds to a semi-complete coverage (level 4). Thus, the coverage
score of these process elements will be 80%.
We would like to point out that even if the number of the mapped
process elements to a RA is high, it does not mean that the coverage
score of these process elements will be as high. What allows the cov-
erage score to increase is the number of requirements that are validated
by the mapped process elements. For instance, the “SLA_SNE_3″ is
covered by four different process elements from ISO/IEC 27001/2 and
the corresponding coverage score is 60%; whereas, this RA is covered
by just a single process element from COBIT and the corresponding
coverage score is 100%.
Y. Bounagui et al. Computer Standards & Interfaces 62 (2019) 98–118

Table 7.
Scale for determining the coverage score of the RAs.
Level Converge score (%) Description Detail

0 0 Not addressed There is no match between the RA's requirements and those of the mapped process elements.
1 20 Few aspects addressed Few requirements are addressed by the mapped process elements.
2 40 Some aspects addressed Some requirements are addressed by the mapped process elements.
3 60 Many aspects addressed Many requirements are addressed by the mapped process elements.
4 80 Semi-complete coverage The RA is almost completely covered by the mapped process elements.
5 100 Complete coverage The RA is completely covered by the mapped process elements.

(iii.3) Required controls evaluation: Table 9.

The third step of the models evaluation focuses on calculating the Coverage score of ITIL, COBIT, and ISO/IEC 27001/2 for the four RDs (CS_RDi).
coverage score for each RC (CS _RCi ) . This coverage score is calculated RDi CS_RDi
using Eq. (1) and gives the average score of the RAs comprised in a
particular RC. To compute the coverage score of a RC, a relative weight ITIL COBIT ISO/IEC 27001/2
CM 85.10 81.05 51.45
is first determined for each of its RAs (RW _RAi ). This relative weight
IS 44.10 79.29 90.33
emphasizes the relation between the RAs and the RCs by considering RM 51.47 95.47 35.73
the number of the supporting studies or the appearance frequency of SLA 80.40 61.87 21.67
each RA ( AF _RAj ). The relative weight of a RA is calculated using Eq.
(2). We can notice that the more the appearance frequency of a RA
increases the more the relative weight follows suit. We give in Table 8 Eq. (3). Calculating the coverage score of RDs.
(columns C6 and C7) the appearance frequencies and the calculated m
CS_RCj
relative weights for the RAs included in the SLA required domain. We CS_RDi =
j=1
*100
also give in Table 8 (columns C2, C3, and C4) the calculated coverage m
scores of ITIL, COBIT, and ISO/IEC 27001/2 for the RCs included in where,
same RD. CS _RDi : Coverage score of mapped process elements for the RDi.
(iii.4) Required domains evaluation: CS _RCj : Coverage score of mapped process elements for the RCj.
The final step of the models evaluation deals with computing the m: Number of RCs included within the RDi.
coverage score for each RD (CS _RDi ). This Score is calculated using Eq. (iii.5) Results analysis:
(3) and gives the average score of the RCs included within a specific In this last step, an analysis of the evaluation results is carried out.
RD. However, since all the RCs are obligatory for each RD, they will The analysis process focuses on verifying the obtained results, making
consequently have the same relative weight when considering the re- the necessary modifications if errors have been made during the eva-
lation between the RCs and the RDs. We give in Table 9 the calculated luation process, and synthesizing the results.
coverage scores of ITIL, COBIT, and ISO/IEC 27001/2 for the four RDs.
Eq. (1). Calculating the coverage score of RCs. 4.4. Findings analysis
n
CS _RCi = CS _RAj *RW _RAj Based on the models assessment, the following can be observed.
j=1 First, as shown in Table 9 above, the CM required domain is validated
by the process elements of ITIL, COBIT, and ISO/IEC 27,001/2 with a
where,
coverage score respectively equal to 85.10%, 81.05%, and 51.45%. We
CS _RCi : Coverage score of mapped process elements for the RCi.
note that ITIL and COBIT have demonstrated a high coverage for the
CS _RAj : Coverage score of mapped process elements for the RAj.
requirements addressed by this RD, while ISO/IEC 27001/2 has shown
RW _RAj : Relative weight of the RAj.
an acceptable coverage. As shown in Table A4 of the appendix, ITIL
n: Number of RAs included within the RCi.
validates 40% of the CM required activities with a coverage score equal
Eq. (2). Calculating the relative weight of RAs.
to 100%, and validates the rest with a coverage score ranging from 40
FA_RAj to 80%. COBIT validates 33.33% of the CM required activities with a
RW_RAj = n
AF_RAk coverage score equal to 100%, and validates 66.67% of the RAs with a
k=1
coverage score ranging from 40 to 80%. All the CM required activities
where, are validated by ISO/IEC 27001/2 with a coverage score inferior or
RW _RAj : Relative weight of the RAj. equal to 80%.
AF _RAj : Appearance frequency of the RAj (number of supporting Second, the IS required domain is validated by the process elements
studies). of ITIL, COBIT, and ISO/IEC 27001/2 with a coverage score respec-
n: Number of RAs included within the RC that contains RAj. tively equal to 44.10%, 79.29%, and 90.33% (see Table 9 above). The

Table 8.
Coverage scores for the RAs and RCs of the SLA required domain (CS_RAi and CS_RCi).
ID of RCi(C1) CS_RCi ID of RAj (C5) AF_RAj(C6) RW_RAj(C7) CS_RAj
ITIL(C2) COBIT (C3) ISO/IEC 27001/2 (C4) ITIL (C8) COBIT(C9) ISO/IEC 27001/2(C10)

SLA_SI 80 60 20 SLA_SI_1 8 1 80 60 20
SLA_SNE 81.2 85.6 26.8 SLA_SNE_1 7 0.22 60 60 0
SLA_SNE_2 9 0.28 80 80 20
SLA_SNE_3 9 0.28 100 100 60
SLA_SNE_4 7 0.22 80 100 20
SLA_ST 80 40 20 SLA_ST_1 6 1 80 40 20

108
Y. Bounagui et al.
evaluation of ISO/IEC 27001/2 and COBIT has revealed a high cov-
erage for the requirements addressed by the IS required domain, while
the evaluation of ITIL has demonstrated a less than acceptable cov-
erage. As shown in Table A5 of the appendix, only one RA is validated
by ITIL with a coverage score equal to 100%, and the rest is validated
with a coverage score inferior or equal to 80%. COBIT validates 37.14%
of the IS required activities with a coverage score equal to 100%, and
validates the rest with a coverage score inferior or equal to 80%. ISO/
IEC 27001/2 validates 60% of the IS required activities with a coverage
score equal to 100%, and validates 40% of the RAs with a coverage
score ranging from 60 to 80%.
Third, the RM required domain is validated by the process elements
of ITIL, COBIT, and ISO/IEC 27001/2 with a coverage score respec-
tively equal to 51.47%, 95.47%, and 35.73% (see Table 9 above). We
note that COBIT has shown a high coverage score for the requirements
addressed by the RM required domain, while ITIL and ISO/IEC 27001/2
have respectively demonstrated an acceptable and quasi-acceptable
coverages. As shown in Table A6 of the appendix, all the RM required
activities are validated by ITIL with a coverage score ranging from 20 to
60%, and validated by ISO/IEC 27001/2 with a coverage score inferior
or equal to 80%. COBIT validates 28.57% of the RM required activities
with a coverage score equal to 80%, and the rest is validated with a
coverage score equal to 100%.
Finally, the SLA required domain is validated by the process ele-
ments of ITIL, COBIT, and ISO/IEC 27001/2 with a coverage score re-
spectively equal to 80.40%, 61.87%, and 21.67% (see Table 9 above).
The evaluation of ITIL has shown a high coverage for the requirements
addressed by this required domain, while COBIT and ISO/IEC 27001/2
have respectively shown a moderate and low coverages. As shown in
Table 8 above, 17% of the SLA required activities are validated by ITIL
with a coverage score equal to 100%, while 83% of the RAs are vali-
dated with a coverage score ranging from 60 to 80%. COBIT validates
33.33% of the SLA required activities with a coverage score equal to
100, and validates the rest with a coverage score ranging from 40 to
80%. All the SLA required activities are validated by ISO/IEC 27001/2
with a coverage score inferior or equal to 60%.
The evaluation of the three models with regard to the CC govern-
ance requirements has revealed several strengths and limitations. These
vary according to the models. The obtained results from evaluating ITIL
are quite consistent since the mapped process elements of this model
provide detailed practices for defining the Cloud migration strategy,
planning and managing change as well as IT service transition, and
managing service level agreements. The results obtained from evalu-
ating COBIT are also fairly consistent stressing the comprehensiveness
of this framework that shows a high coverage score for all the RDs;
except for the SLA required domain. The evaluation findings of ISO/IEC
27001/2 are also reasonably consistent since its process elements focus
on information security, which explain the low coverage scores shown
by the model with regard to the CM, RM, and SLA required domains.
5. Integration method
The evaluation method described in the previous section has en-
abled us to measure the adequacy of each IT model with regard to the
CC governance requirements. However, to better cover these require-
ments, the models integration is required. This section aims both at
describing the integration approach and analyzing the integration re-
sults of ITIL, COBIT, and ISO/IEC 27001/2.
5.1. IT models integration
The integration is based on the models assessment. It aims at pro-
viding an approach to identify the possible combinations among the
mapped process elements. The integration is performed at the RAs
level. This will enable us to measure the coverage score of integrated
process elements at this level first, and then to calculate the coverage
109
Computer Standards & Interfaces 62 (2019) 98–118
score of each RC and RD as described by the evaluation method. It is
significantly noted that when a process element PE validates more than
one RA with different sub-process elements (PEi.1, PEi.2 …), each sub-
process element will be considered as a normal process element in the
integration process. This is reclusively performed as long as there are
more RAs validated with the same upper process element.
To reduce the complexity of integrating the process elements of
multiple models, the integration will be carried out in a group of two.
For instance, to integrate the process elements of models A, B, and C
with regard to a specific RA, the process elements of models A and B are
first integrated to form a hybrid practice AB. This practice will be in-
tegrated thereafter with the process elements of model C to form the
final integrated practice. We would like to reveal that a practice is the
result of integrating various process elements from different models.
Two types of practices can be distinguished: The reference and the
complement practices. The reference practices contain the process
elements that constitute the basis of models integration. The comple-
ment practices are particularly used when the organization has a pre-
ference for one model instead of another; otherwise, the com-
plementary practice is rejected.
Let's mention that if a model (say M1) validates a RA (say RA1) (or
part of a RA – say p1) with n process elements (n ≥ 1), and a model M2
validates RA1or p1 with m process elements such that m > n, then M1 is
considered more detailed than M2 with respect to RA1 (or p1) because
it performs the validation with fewer process elements than M2. This
means that the n process elements through which M1 validates RA1 (or
p1) are more detailed, on average, than the m process elements that M2
requires in order to validate RA1 (or p1). It is important to mention that
the detail level considered in this study does not correspond to the
abstraction level of the process elements. This is not quantified in this
study since the focus of the three models is different. In fact, COBIT and
ISO/IEC 27001/2 focus on what should be done while ITIL focuses on
how it should be done. In this way, ITIL will always be the model that
provides the lowest abstraction level compared with COBIT and ISO/
IEC 27,001/2. Accordingly, the process elements of ITIL will always be
prioritized in the models integration. The detail level that we take into
consideration corresponds to the number of process elements that va-
lidate the requirements of a particular RA. The more the number of
process elements decreases the higher the detail level will be. The detail
level is quantified using Eq. (4).
Eq. (4). Calculating the level of detail.
1
DL p,i =
NPE p,i
where,
DLp,i: Detail level of a model that validates a part p of a RA i.
NPEp,i: Number of process elements of a model that validates a part
p of a RA i.
For instance, assuming that ITIL validates the same requirements as
the process elements “APO09.03″, “APO09.04″, “BAI04.03″, and
“BAI06.01″ from COBIT with regard to the RA “SLA_SNE_2″ (see
Table A3 of the appendix); but with only one process element. The
process element of ITIL will be considered as more detailed and will
have a detail level equal to one, whereas the process elements
“APO09.03″, “APO09.04″, “BAI04.03″, and “BAI06.01″ from COBIT
will be considered as less detailed and will have a detail level equal to
0.25.
The process elements of two models A and B are integrated based on
the method described in Fig. 5. It is absolutely important to mention
that the “α” parameter figuring in the value of the new coverage score
represents the percentage of requirements that are validated by the
process elements of A and B. For each RA, the integration is performed
as follows:
i When the RA is not validated by any process element, no integration
is performed.
Y. Bounagui et al.
ii When the RA is validated by the process elements of only one model,
the process elements of this model are taken as a reference practice.
iii When the RA is validated by the process elements of two models,
this implies considering the following:
a When the coverage score of A is superior to the coverage score of
B (or vice versa), this implies considering the following:
• When the process elements of B partially validate the same re-
quirements as the process elements of A (B ⊂ A), the process
elements of A are taken as a reference practice and the process
elements of B are taken as a complement practice.
• When the process elements of B validate different requirements
than the process elements of A (A ∩ B = ∅), the process ele-
ments of A and B are integrated and considered as a reference
practice.
• When the process elements of A validate both the same and
different requirements than the process elements of B (A ∩ B ≠
∅ and B ⊄ A), the process elements of A and B that validate
different requirements are integrated into a provisional prac-
tice. The process elements of A and B that validate the same
requirements are selected based on the detail level that A and B
provide. Thus, the less detailed process elements are rejected.
The more detailed process elements are integrated with the
provisional practice and are considered as a reference practice.
b When the coverage score of A is equal to the coverage score of B,
this implies considering the following:
• When the process elements of A validate different requirements
than the process elements of B (A ∩ B = ∅), the process ele-
ments of A and B are integrated and considered as a reference
practice.
• When the process elements of A validate both the same and
different requirements than the process elements of B (A ∩
B ≠ ∅ and A ≠ B), the process elements of A and B that va-
lidate different requirements are integrated into a provisional
practice. The process elements of A and B that validate the same
requirements are selected based on the detail level that A and B
provide. Thus, the less detailed process elements are rejected.
The more detailed process elements are integrated with the
provisional practice and are considered as a reference practice.
• When the process elements of A validate the same requirements
as the process elements of B (A = B), more detailed process
elements of A and B are considered as a reference practice, less
detailed process elements are, then, considered as a comple-
ment practice.
5.2. Results analysis
Following the method described in the previous subsection, the
following results are obtained from integrating ITIL, COBIT, and ISO/
IEC 27001/2. Table A7 of the appendix gives the integrated practices
for the required activities included in the SLA required domain. For
each RA, we specify the reference and the complement practices. For
each practice, the integrated process elements are specified according
to the model in which they are included. On the basis of the results
provided in Table 8, the six RAs of the SLA required domain are in-
tegrated as follows:
First, with regard to the RA “SLA_SI_1″, the ITIL coverage score is
greater than the COBIT and ISO/IEC 27001/2 coverage scores. The
process elements “SD 3.[3–6]”, “SD 4.2.5.1″, and “SD 4.2.5.9″ from ITIL
and the process elements “APO 09.01″ and “APO 09.02″ from COBIT
are integrated since they cover different requirements. They are
therefore considered as a reference practice. The process element
“Clause 15.1.1″ from ISO/IEC 27001/2 is considered as a complement
practice.
Second, regarding the RA “SLA_SNE_1″, the ITIL and COBIT cov-
erage scores are equal. The process elements “SD 4.2.5.1″ and “SS.5.4″
from ITIL and the process elements “APO 09.01″, “APO 09.02″, and
110
Computer Standards & Interfaces 62 (2019) 98–118
“DSS 01.02″ from COBIT are integrated since they cover different re-
quirements. They are therefore considered as a reference practice.
Third, with respect to the RA “SLA_SNE_2″, the ITIL and COBIT
coverage scores are equal and greater than the ISO/IEC 27001/2 cov-
erage score. The process elements “Clause 15.1.2″ and “Clause 15.1.3″
from ISO/IEC 27001/2 are thus considered as a complement practice.
The process elements “SD 4.2.5.2″ and “SD 4.2.5.5″ from ITIL and the
process elements “APO 09.03″, “APO 09.04″, “BAI 04.03″, and “BAI
06.01″ from COBIT are integrated since they cover different require-
ments. They are therefore considered as a reference practice.
Fourth, concerning the RA “SLA_SNE_3″, the ITIL and COBIT cov-
erage scores are equal and greater than the ISO/IEC 27001/2 coverage
score. The process elements “Clause 15.1.2″, “Clause 15.1.3″, “Clause
15.2.1″, and “Clause 15.2.2″ from ISO/IEC 27001/2 are thus considered
as a complement practice. The process elements “SD 4.2.5.3″, “SD
4.2.5.6″, and “SD 4.2.5.10″ from ITIL are less detailed than the process
element “APO 09.04″ from COBIT. The COBIT process element will be
considered as a reference practice, while the ITIL process elements will
be considered as a complement practice.
Fifth, concerning the RA “SLA_SNE_4″, the COBIT coverage score is
greater than the ITIL and ISO/IEC 27001/2 coverage scores. The pro-
cess element “APO 09.05″ from COBIT is thus considered as a reference
practice. The process elements “SD 4.2.5.4″, “SD 4.2.5.5″, “SD 4.2.5.7″,
and “SD 4.2.5.8″ from ITIL and the process elements “Clause 15.2.1″
and “Clause 15.2.2″ from ISO/IEC 27001/2 are therefore considered as
a complement practice.
Finally, regarding the RA “SLA_ST_1″, the ITIL coverage score is
greater than the COBIT and ISO/IEC 27001/2 coverage scores. The
process elements “SD 4.2.5.4″, “SD 4.2.5.5″, and “SD 4.2.5.8″ from ITIL
and the process element “APO 09.04″ from COBIT are integrated since
they cover different requirements. They are thus considered as a re-
ference practice. The process element “Clause 8.1.4″ from ISO/IEC
27001/2 is therefore considered as a complement practice.
Once the integration is performed, a post evaluation phase of the
integrated process elements is achieved. This process follows the same
evaluation method described in Section 4. It aims at calculating the
coverage score of the integrated process elements for each RA, RC, and
RD. Hence, we give in Fig. 6 the coverage scores of the integrated
practices and their comparison with to the results described in Table 9.
The findings have shown the added value to integrate the three
models. For all the RDs, we note that the integrated practices have
demonstrated a coverage score that is superior to the max coverage
score when the models’ process elements are used separately. We note
that the coverage score of the integrated process elements increased the
max coverage by: 10.75% for the requirements addressed by the CM
required domain; 4.9% for the requirements addressed by the IS re-
quired domain; 2.4% for the requirements addressed by the RM re-
quired domain; and 18.13% for the requirements addressed by the SLA
required domain. We also note that the models integration has led to a
radical increase in the coverage score of the CM and the SLA required
domains. It has also led to a minor increase in the coverage score of the
IS and RM required domains.
6. Conclusion and outlooks
This paper has proposed a general approach to CC governance based
on the unification of IT models and more particularly on the latter's
evaluation and integration. This approach has been particularly applied
to ITIL, COBIT, and ISO 27001/2 to elaborate a unified CC management
and governance framework.
The performed state-of-the-art review has shown the existence of
several approaches for CC governance. Despite of the existing ap-
proaches quality, several shortcomings have been spotted and the need
for a comprehensive and complete approach for CC governance has
been highlighted.
As ITIL, COBIT, and ISO 27001/2 constitute a promising starting
Y. Bounagui et al. Computer Standards & Interfaces 62 (2019) 98–118

Fig. 5. Method used to carry out the models integration.

97.87 98.53
100.00 95.85 95.23 95.47
90.33
90.00 85.10
81.05 79.29 80.40
Coverage Score of RDs (%)

80.00
70.00 61.87
60.00
51.45 51.47
50.00 44.10

40.00 35.73

30.00
21.67
20.00
10.00
0.00
CM IS RM SLA
ITIL COBIT ISO/IEC 27001/2 Integrated models

Fig. 6. Coverage score of the integrated process elements for the four RDs.

point for the elaboration of a CC governance framework, their review
has revealed strengths and weaknesses when used separately to support
the CC governance. The models review has also exposed the need to
unify these models to better support and back up the new CC govern-
ance requirements. To perform the unification several methods have
been suggested to become the topic of the evaluation and the
integration methods that have been developed and described in this
paper.
The proposed evaluation method has been based on the identified
CC governance requirements. The evaluation of ITIL has shown a high
coverage score for the requirements addressed by the CM and SLA re-
quired domains, an acceptable coverage score for the requirements

111
Y. Bounagui et al. Computer Standards & Interfaces 62 (2019) 98–118

addressed by RM required domain and a low coverage score for the
requirements addressed by the IS required domain. COBIT evaluation
has shown a high coverage score for the requirements addressed by the
CM, the IS, and the RM required domains; and a moderate coverage
score for the requirements addressed by the SLA required domain. The
evaluation of ISO/IEC 27001/2 has demonstrated a high coverage score
for the requirements addressed by the IS required domain, an accep-
table coverage score for the requirements addressed by the CM required
domain, and a low coverage score for the requirements addressed by
the RM and the SLA required domains.
The integration method has been based on the evaluation results
and has proposed an approach for integrating the mapped process
elements. The post-evaluation phase of the integrated models has
shown a remarkable increase in the coverage score with regard to the
max coverage score obtained when the models are used separately.
Based on the research paper results, future works will focus on de-
veloping the homogenization method, elaborating a supporting tool for
assisting the unification process, and validating the proposed frame-
work. First, the development of the homogenization method will focus
on resolving the heterogeneities that can exist among the models when
describing their process elements. This would be done through pro-
viding an independent representation of the models concepts and re-
lationships. This representation, which is in the form of a meta-model,
will be used to rearrange the models’ content into a common process
structure in order to solve their multiple structural differences in the
first place; and also, to reduce the complexity when dealing with a
multi-model environment. Second, given the large number of elements
to be considered and processed in the unification process, a supporting
platform will be needed so as to automate the activities and tasks to
achieve the elaborated methods. Moreover, it would facilitate the uni-
fication process to become more efficient. Finally, the proposed CC
governance framework will be tested and validated through multiple
industrial case studies. The validation will focus on implementing the
elaborated methods in real cases and demonstrate the added value of
unifying IT models.
We are aware that our work may have some limitations. The first
concerns the granularity of the measurement scale we have used to
determine the process elements coverage score for the RAs. As we have
already stated, we couldn't perform the measurement on more granular
scale than the one we have used. The second limitation is concerned
with the objectives significance level when performing the mapping
between the CPEs and the RCs. In fact, all the objectives have been
considered at the same significance level and importance in the com-
parison process. Unfortunately, it was not possible to consider such an
aspect in our approach. The third limitation is linked to the partial
matching between the requirements when performing the mapping
between the PEBMs and the RAs. For example, the sub-requirement 17
of the process element “BAI04.03″ (see Table A3 of the appendix)
partially matches the sub-requirement “The negotiation process should
be extended with mechanisms for dynamic negotiation…” of the RA
“SLA_SNE_2″. Unluckily, our approach was unable to consider such a
partial matching between the requirements. We think that these lim-
itations could be a motivation for developing a more complete ap-
proach in our future work.

Appendix

Table A1.
List of primary selected studies.
Reference Authors, Title Channel Year

[29] Cloud Security Alliance (CSA), Cloud Controls Matrix Version 3.0.1 CSA 2016
[63] K. Lu, R. Yahyapour, P. Wieder, E. Yaqub, Fault-tolerant Service Level Agreement lifecycle management in clouds using actor system FGCS 2016
[4] S. Karkošková, G. Feuerlicht, Cloud Computing Governance Reference Model BIR 2016
[64] F. Faniyi, R. Bahsoon, A Systematic Review of Service Level Management in the Cloud CSUR 2015
[12] A.S. Saidah, N. Abdelbaki, A new cloud computing governance framework CLOSER 2014
[65] FedRAMP, FedRAMP Baseline Security Controls FedRAMP 2014
[9] J. Becker, E. Bailey, A Comparison of IT Governance & Control Frameworks in Cloud Computing AMCIS 2014
[21] K. Brandis, S. Dzombeta, K. Haufe, Towards a framework for governance architecture management in cloud environments: A FGCS 2014
semantic perspective
[66] T. Labidi, A. Mtibaa, F. Gargouri, Ontology-Based Context-Aware SLA Management for Cloud Computing MEDI 2014
[67] W.A. Ghumman, Automation of the SLA life cycle in cloud computing ICSOC 2014
[68] A. Hammadi, O.K. Hussain, T. Dillon, F.K. Hussain, A framework for SLA management in cloud computing for informed decision Cluster Computing 2013
making
[69] K. Sun, Y. Li, Effort estimation in cloud migration process SOSE 2013
[70] P. Jamshidi, A. Ahmad, C. Pahl, Cloud Migration Research: A Systematic Review IEEE TCC 2013
[71] A.U. Khan, M. Oriol, M. Kiran, M. Jiang, K. Djemame, Security risks and their management in cloud computing CloudCom 2012
[34] C.H. LLP, W. Chan, E. Leung, H. Pili, Enterprise Risk Management for Cloud Computing COSO 2012
[30] ENISA, Cloud Computing: Benefits, Risks and Recommendations for Information Security ENISA 2012
[72] F. Xie, Y. Peng, W. Zhao, D. Chen, X. Wang, X. Huo, A risk management framework for cloud computing CCIS 2012
[73] G. Nie, X. E., D. Chen, Research on Service Level Agreement in Cloud Computing AEE 2012
[74] J. Ding, Z. Zhao, Towards autonomic SLA management: A review ICSAI 2012
[75] N.V. Pavan Kumar Illa, Sushma Nathani, Enterprise Cloud Migration: A Phase Driven Step-by-Step-Strategy intended for Scalability, IJCA 2012
Elasticity, Agility and Reliability
[76] P. V. Beserra, A. Camara, R. Ximenes, A.B. Albuquerque, N.C. Mendonca, Cloudstep: A step-by-step decision process to support legacy MESOCA 2012
application migration to the cloud
[8] S. Mehfuz, G. Sahoo, A five-phased approach for the cloud migration IJETAE 2012
[77] T.-C. Kao, C.-H. Mao, C.-Y. Chang, K.-C. Chang, Cloud SSDLC: Cloud Security Governance Deployment Framework in Secure System TrustCom 2012
Development Life Cycle
[13] ISACA, IT Control Objectives for Cloud Computing: Controls and Assurance in the Cloud ISACA 2011
[78] M. Cochran, P. Witman, Governance and service level agreement issues in a cloud computing environment JITM 2011
[20] R. Ahmad, L. Janczewski, Governance Life Cycle Framework for Managing Security in Public Cloud: From User Perspective CLOUD 2011
[79] W. Jansen, T. Grance, Guidelines on security and privacy in public cloud computing NIST 2011
[80] D. Catteddu, Cloud Computing: Benefits, Risks and Recommendations for Information Security IBIWAS 2010
[81] J.O. Fitó, M. Macias, J. Guitart, Toward business-driven risk management for Cloud computing CNSM 2010
[82] M. Alhamad, T. Dillon, E. Chang, SLA-Based Trust Model for Cloud Computing NBiS 2010
[83] X. Zhang, N. Wuwong, H. Li, X. Zhang, Information Security Risk Management Framework for the Cloud Computing Environments CIT 2010
[15] Z. Guo, M. Song, A Governance Model for Cloud Computing MASS 2010

112
 Table A2.
Identified CC governance requirements for the SLA required domain.
Required control Required activity
Y. Bounagui et al.

Name of the Objectives of the required control Name of the required Supporting studies Cloud service user requirements Cloud service provider requirements
required control (ID) activity (ID)

SLA initiation (1) Model service level agreements.(2) Define
(SLA_SI) service level agreements attributes.(3) Define
and Design service attributes.
SLA Negotiation and (1) Identify the relevant Cloud service providers.
Improvement (2) Agree about the level of service required. (3)
(SLA_SNE) Formalize and document service level
agreements. (4) Monitor, measure, report, and
review the level of services provided.
SLA definition and [7,63,66,67,73,74,82,84] Procedure for the definition and modeling of SLAs Cloud Service Providers (CSPs) should analyze
modeling (SLA_SI_1) should be established and should consider: their business objectives through a business
1. SLA modeling (i.e. QoS model, pricing model) modeling process to optimize their offerings. Based
2. Service level objectives definition (SLOs) on this model, an SLA template in terms of
3. SLA metrics design attributes values should be established.
4. Service design (i.e. dependencies between service
components, elasticity rules, performance estimation,
etc.)
CSP discovery [7,63,67,73,74,82,84] The Cloud Service User (CSU) should locate the CSPs The established SLA template should be published
(SLA_SNE_1) that effectively satisfy its business requirements. The by the CSP within a unified registration system e.g.
CSU should consider: 1. Procedures for the discovery UDDI to serve for the discovery process. The
and selection of CSPs. These procedure should be template corresponding to the selected CSP will
established based on the identified SLOs. 2. Additional serve thereafter for the negotiation and
non-functional requirements as security, scalability, establishment of the SLA.
dynamic changes, heterogeneity, etc.
SLA negotiation and [7,63,64,66,67,73,74,82,84] The CSU and CSP should define the terms of service and agree about the level at which a service will be
establishment provided. The negotiation process should be based on the service level requirements and should be extended
(SLA_SNE_2) with mechanisms for dynamic negotiation and re-negotiation between the CSU and CSP. In addition to the CSU
and the CSP, the negotiation process should also take into account different actors related to Cloud computing,
such as Cloud auditors, Cloud brokers or Cloud carriers. Finally, the SLA document should be created based on
the negotiation strategies and signed by the CSU and CSP. The SLA document should cover CSU and CSP
commitments, synopsis of the services, metrics for service measurement, financial charges, change procedures,

113
security and privacy aspects, level of service, roles and responsibilities, and compensation/penalties for non-
achievement. The SLA should consider additional items such as continuity and disaster recovery, availability,
capacity management, target performance, operating level agreements, system redundancy, maintenance and
support, location of data, seizure of data, and failure of the CSP, etc.
SLA monitoring and [7,63,64,66,67,73,74,82,84] The CSU should continually monitor SLA metrics at The CSP should continually monitor and report
reporting (SLA_SNE_3) different dimension to determine whether SLOs are SLA metrics at different dimension to determine
achieved or violated by the CSP. Monitoring activities whether SLOs are achieved or violated. The CSP
should incorporate mechanisms for automatic detection should provide capabilities for intervening
and reporting of SLA violations. Reporting mechanisms proactively in order to take necessary measures
should also consider changes in the provision of (e.g. providing more virtual machines, provide
services by the CSP. secure end-to-end communications, etc.) that
would avert imminent SLA violations.
SLA review and [63,64,67,73,74,82,84] The CSU should assess and review the reports generated The CSP should provide capabilities for enforcing
enforcement not reaching the agreed SLOs and SLAs. The CSU should SLAs based on CSU enforcement requirements. The
(SLA_SNE_4) also assess the corresponding compensation and CSP should also provide mechanisms for dynamic
penalties for all the SLA violations committed by the SLA enforcement (e.g. ability to recover from an
CSP. The performed reviews and assessments should be SLA violation during the execution).
used to further enforce the SLA. SLA enforcement
activities should also involves taking the necessary
actions to ensure no further SLA violations.
SLA Termination (1) Define capabilities for terminating service SLA conclusion [7,64,67,73,74,84] The CSU should define procedures for terminating the The CSP should use accounting and billing
(SLA_ST) level agreements. (2) Request compensations (SLA_ST_1) SLA when the service delivery is concluded, the SLA mechanisms to provide details on services use to
and penalties for any violations of service level validity period is over or the agreements are violated by the CSU. For any violation, the corresponding
agreements. any of the parties as specified in the SLA. compensations/penalties should be calculated and
Compensations/penalties should be requested by the resolved as specified in the SLA.
CSU for the violations committed by the CSP.
Computer Standards & Interfaces 62 (2019) 98–118
Y. Bounagui et al. Computer Standards & Interfaces 62 (2019) 98–118

Table A3.
Mapping of “APO09.03″, “APO09.04″, “BAI04.03″, and “BAI06.01″of COBIT to the RA “SLA_SNE_2″.
Description of the PEBMs “ APO09.03″, “ APO09.04″, “ BAI04.03″, and “ BAI06.01″

APO09.03: Define and prepare service agreements

Activities:
1. Analyse requirements for new or changed service agreements received from business relationship management to ensure that the requirements can be matched1. Consider aspects
such as service times2, availability3, performance4, capacity5, security6, continuity7, compliance8 and regulatory issues9, usability, and demand constraints10.
2. Draft customer service agreements based on the services, service packages and service level options in the relevant service catalogues11.
3. Determine, agree on and document internal operational agreements to underpin the customer service agreements, if applicable12.
4. Liaise with supplier management to ensure that appropriate commercial contracts with external service providers underpin the customer service agreements, if applicable13.
5. Finalise customer service agreements with business relationship management14.
APO09.04: Monitor and report service levels.
Activities:
1. Establish and maintain measures to monitor and collect service level data15.
5. Agree on action plans and remediations for any performance issues or negative trends16.
BAI04.03: Plan for new or changed service requirements
Activities:
4. Adjust the performance and capacity plans and SLAs based on realistic, new, proposed and/or projected business processes and supporting services, applications and infrastructure
changes as well as reviews of actual performance and capacity usage, including workload levels17.
BAI06.01: Evaluate, prioritise and authorize change requests
Activities:
7. Consider the impact of contracted services providers (e.g., of outsourced business processing, infrastructure, application development and shared services) on the change
management process, including integration of organisational change management processes with change management processes of service providers and the impact on contractual
terms and SLAs18.

Description of RA “SLA_SNE_2″ Mapping

APO09.03 APO09.04 BAI04.03 BAI06.01

The CSU and CSP should define the terms of service and agree about the level at which a service will be provided. 1, 13, 14- – –
The negotiation process should be based on service level requirements. 1, 13, 14- 17 –
The negotiation process should be extended with mechanisms for dynamic negotiation and re-negotiation between – 17 –
the CSU and CSP.
The negotiation process should also take into account different actors related to Cloud computing, such as Cloud – – – –
auditors, Cloud brokers or Cloud carriers.
The SLA should Cover: CSU and CSP commitments 11 – – –
Synopsis of the services 2, 10 – – –
Metrics for service measurement – 15 – –
Financial charges – – – –
Change procedures – – – 18
Security and privacy aspects 6 – – –
Level of service – – – –
Roles and responsibilities – – – –
Compensation/penalties for non-achievement 8 16 – –
The SLA should consider additional items such as: Continuity and disaster recovery 7 – – –
Availability 3 – – –
Capacity management 5 – – –
Target performance 4 – – –
Operating level agreements 12 – – –
System redundancy – – – –
Maintenance and support – – – –
Data location 9 – – –
Seizure of data and failure of CSP – – – –

Table A4.
Coverage score of the RAs for the CM required domains.
ID of RA ITIL Coverage Score COBIT Coverage Score ISO 27001/2 Coverage Score

CM_PM_1 100 100 20

CM_PM_2 80 100 40
CM_PM_3 80 80 0
CM_PM_4 80 80 40
CM_PM_5 40 40 20
CM_PM_6 100 100 0
CM_PM_7 80 80 60
CM_MEX_1 100 60 80
CM_MEX_2 60 60 40
CM_MEX_3 60 80 20
CM_MEX_4 100 80 20
CM_MEX_5 80 40 80
CM_MEV_1 100 60 60
CM_MEV_2 100 100 60
CM_MR_1 80 100 60

114
Y. Bounagui et al. Computer Standards & Interfaces 62 (2019) 98–118

Table A5.
Coverage score of the RAs for the IS required domains.
ID of RA ITIL COBIT ISO 27001/2

IS_ISP_1 60 80 80
IS_OIS_1 60 60 80
IS_OIS_2 0 60 100
IS_HRS_1 0 100 100
IS_HRS_2 40 60 100
IS_HRS_3 60 100 100
IS_AM_1 20 60 80
IS_AM_2 40 80 100
IS_AM_3 60 60 100
IS_AC_1 40 100 80
IS_AC_2 80 100 80
IS_AC_3 80 100 100
IS_AC_4 60 60 100
IS_CR_1 0 80 100
IS_PES_1 40 80 80
IS_PES_2 60 80 100
IS_OS_1 80 80 100
IS_OS_2 0 60 100
IS_OS_3 40 100 80
IS_OS_4 20 80 80
IS_OS_5 20 80 100
IS_OS_6 20 60 100
IS_OS_7 20 100 60
IS_CO_1 60 60 80
IS_CO_2 60 60 100
IS_SADM_1 40 60 60
IS_SADM_2 100 80 100
IS_SADM_3 80 100 100
IS_SR_1 60 100 80
IS_SR_2 80 100 100
IS_ISIM_1 60 80 100
IS_SBCM_1 20 100 100
IS_SBCM_2 20 100 100
IS_CM_1 20 80 60
IS_CM_2 20 100 80

Table A6.
Coverage score of the RAs for the RM required domains.
ID of RA ITIL COBIT ISO 27001/2

RM_RMP_1 60 100 20
RM_RMP_2 60 100 40
RM_RMI_1 20 80 20
RM_RMI_2 80 80 80
RM_RMI_3 60 100 0
RM_RMR_1 40 100 0
RM_RMR_2 40 100 80

Table A7.
Integration of the mapped process elements for the SLA required domain.
ID of RA Reference practice Complement practice

SLA_SI_1L - ITIL: [SD 3.3, SD 3.4, SD 3.5, SD 3.6, SD 4.2.5.1, SD 4.2.5.9] - ITIL: [N/A]
- COBIT: [APO 09.01 APO 09.02] - COBIT: [N/A]
- ISO 27001/2: [N/A] - ISO 27001/2: [Clause 15.1.1]
SLA_SNE_1 - ITIL: [SD 4.2.5.1, SS 5.4] - ITIL: [N/A]
- COBIT: [APO 09.01, APO 09.02, DSS 01.02] - COBIT: [N/A]
- ISO 27001/2: [N/A] - ISO 27001/2: [N/A]
SLA_SNE_2 - ITIL: [SD 4.2.5.2, SD 4.2.5.5 - ITIL: [N/A]
- COBIT: [APO09.03, APO09.04, BAI04.03, BAI06.01] - COBIT: [N/A]
- ISO 27001/2: [N/A] - ISO 27001/2: [Clause 15.1.2, Clause 15.1.3]
SLA_SNE_3 - ITIL: [N/A] - ITIL: [SD 4.2.5.3, SD 4.2.5.6, SD 4.2.5.10]
- COBIT: [APO 09.04] - COBIT: [N/A]
- ISO 27001/2: [N/A] - ISO 27001/2: [Clause 15.1.2, Clause 15.1.3, Clause 15.2.1, Clause 15.2.2]
SLA_SNE_4 - ITIL: [N/A] - ITIL: [SD 4.2.5.4, SD 4.2.5.5, SD 4.2.5.7, SD 4.2.5.8]
- COBIT: [APO 09.05] - COBIT: [N/A]
- ISO 27001/2: [N/A] - ISO 27001/2: [Clause 15.1.2, Clause 15.1.3]
SLA_ST_1 - ITIL: [SD 4.2.5.4, SD 4.2.5.5, SD 4.2.5.8] - ITIL: [N/A]
- COBIT: [APO 09.04] - COBIT: [N/A]
- ISO 27001/2: [N/A] - ISO 27001/2: [Clause 8.1.4]

115
Y. Bounagui et al.
Fig. A1. CC Governance requirements architecture.
References
[1] P.M. Mell, T. Grance, The NIST Definition of Cloud Computing, National Institute of
Standards & Technology, 2011, https://doi.org/10.6028/NIST.SP.800-145.
[2] M. Bayramusta, V.A. Nasir, A fad or future of IT?: A comprehensive literature re-
view on the cloud computing research, Int. J. Inf. Manage. 36 (2016) 635–644,
https://doi.org/10.1016/j.ijinfomgt.2016.04.006.
[3] D. Chou, Cloud computing: a value creation model, Comput. Stand. Interfaces
(2015), http://www.sciencedirect.com/science/article/pii/S0920548914000981
accessed July 5, 2017.
[4] S. Karkošková, G. Feuerlicht, Cloud Computing Governance Reference Model,
Springer, Cham, 2016, pp. 193–203, https://doi.org/10.1007/978-3-319-45321-
7_14.
[5] M. Almorsy, J. Grundy, A.S. Ibrahim, Collaboration-based cloud computing security
management framework, Proc. - 2011 IEEE 4th Int. Conf. Cloud Comput. CLOUD,
2011 IEEE, 2011, pp. 364–371, , https://doi.org/10.1109/CLOUD.2011.9.
[6] Cloud Security Alliance, Top threats to cloud computing, Security (2010) 1–14
https://www.google.com/search?q=Top+threats+to+cloud+computing+v1.
+0&ie=utf-8&oe=utf-8&client=firefox-b-ab accessed November 27, 2017.
[7] D. Kyriazis, Cloud computing service level agreements - exploitation of research
results, Eur. Commun. 61 (2013), https://ec.europa.eu/digital-single-market/en/
116
Computer Standards & Interfaces 62 (2019) 98–118
news/cloud-computing-service-level-agreements-exploitation-research-results ac-
cessed July 5, 2017.
[8] S. Mehfuz, G. Sahoo, A five-phased approach for the cloud migration, Int. J.
Emerging Technol. Adv. Eng. 2 (2012) 286–291, https://doi.org/10.1007/978-3-
642-13645-0.
[9] J. Becker, E. Bailey, A comparison of IT governance & control frameworks in cloud
computing, Assoc. Inf. Syst. Conf. (2014) 1–16 http://aisel.aisnet.org/cgi/
viewcontent.cgi?article=1160&context=amcis2014 accessed July 5, 2017.
[10] Y. Bounagui, H. Hafiddi, A. Mezrioui, Requirements definition for a holistic ap-
proach of cloud computing governance, Proc. IEEE/ACS Int. Conf. Comput. Syst.
Appl. AICCSA, IEEE, 2016, pp. 1–8, , https://doi.org/10.1109/AICCSA.2015.
7507245.
[11] S.O. Owuonda, D. Orwa, Cloud computing governance readiness assessment : case
study of a local Airline Company, Int. J. Appl. Inf. Syst. 10 (2016) 33–42, https://
doi.org/10.5120/ijais2016451543.
[12] A.S. Saidah, N. Abdelbaki, A new cloud computing governance framework, CLOSER
2014, Proc. 4th Int. Conf. Cloud Comput. Serv. Sci, 2014, pp. 671–678 https://files.
ifi.uzh.ch/stiller/CLOSER 2014/CLOSER/CLOSER/FedCloudGov/Full Papers/
FedCloudGov_2014_2_CR.pdf (accessed July 5, 2017).
[13] IT ISACAControl Objectives for Cloud Computing, Controls and assurance in the
cloud, ISACA (2011) 1–23 http://dl.acm.org/citation.cfm?id=2829203 accessed
July 5, 2017.
Y. Bounagui et al.
[14] J. Morin, J. Aubert, B. Gateau, Towards cloud computing SLA risk management:
issues and challenges, 2012 45th Hawaii Int. Conf. Syst. Sci. 2012, pp. 5509–5514, ,
https://doi.org/10.1109/HICSS.2012.602.
[15] Z. Guo, M. Song, A governance model for cloud computing, 2010 Int. Conf. Manag.
Serv. Sci, IEEE, 2010, pp. 1–6, , https://doi.org/10.1109/ICMSS.2010.5576281.
[16] IT Governance Institute, COBIT 4 ISA, 2007, p. 1 http://dl.acm.org/citation.cfm?
id=1534415 accessed July 5, 2017.
[17] Y. He, The lifecycle model for cloud, https://www.google.com/search?q=THE
+LIFECYCLE+MODEL+FOR+CLOUD+GOVERNANCE&ie=utf-8&oe=utf-8&
client=firefox-b-ab, (2011) accessed October 30, 2017.
[18] R. Dautov, S. Veloudis, I. Paraskakis, S. Distefano, Policy Management and
Enforcement Using OWL and SWRL for the Internet of Things, Policy Management
and Enforcement Using OWL and SWRL for the Internet of Things, Springer, Cham,
2017, pp. 342–355, https://doi.org/10.1007/978-3-319-67910-5_28.
[19] M.H. Hugos, D. Hulitzky, Business in the Cloud : What Every Business Needs to
Know About Cloud Computing, Wiley, 2011, https://books.google.co.ma/books?
id=Qn9OA8JVmscC&pg=PA2&lpg=PA2&dq=adapt+easily+to+change
+cloud&source=bl&ots=0EQJJ9Btxj&sig=dWXLHbh_lV61J0nhsE01iKnOu7A&
hl=fr&sa=X&ved=0ahUKEwjPx9CzgpvXAhXD6xQKHeNuAusQ6AEIRTAI#v=
onepage&q&f=false accessed October 31, 2017.
[20] R. Ahmad, L. Janczewski, Governance life cycle framework for managing security in
public cloud: from user perspective, 2011 IEEE 4th Int. Conf. Cloud Comput. IEEE,
2011, pp. 372–379, , https://doi.org/10.1109/CLOUD.2011.117.
[21] K. Brandis, S. Dzombeta, K. Haufe, Towards a framework for governance archi-
tecture management in cloud environments: A semantic perspective, Future Gener.
Comput. Syst. 32 (2014) 274–281, https://doi.org/10.1016/j.future.2013.09.022.
[22] S. Sahibudin, M. Sharifi, M. Ayat, Combining ITIL, COBIT and ISO/IEC 27002 in
order to design a comprehensive IT framework in organizations, 2008 Second Asia
Int. Conf. Model. Simul. IEEE, 2008, pp. 749–753, , https://doi.org/10.1109/AMS.
2008.145.
[23] Office of Government Commerce, ITIL v3: Service Strategy - Service Design - Service
Transition - Service Operation - Continual Service Improvement, (2007) UK https://
www.itil.org.uk/all.htm accessed July 6, 2017.
[24] Isaca, Cobit 5, ISA, 2012, https://dl.acm.org/citation.cfm?id=2361913 accessed
March 5, 2018.
[25] ISO/IEC, ISO/IEC 27001:2013 – Information Technology – Information Security
Management Systems – Requirements 23 (2013) https://www.iso.org/standard/
54534.html accessed July 5, 2017.
[26] ISO/IEC, ISO/IEC 27002 - Information Technology - Security Techniques - Code of
Practice for Information Security Controls 80 (2013) https://www.iso.org/
standard/54533.html accessed July 5, 2017.
[27] Z. Enslin, Cloud Computing : COBIT-Mapped Benefits, Risks and Controls for
Consumer Enterprises, Thesis Present. Partial Fulfilment Requir. Degree Masters
Commer (Computer Audit. Stellenbosch Univ.), 2012.
[28] CSA, Security Guidance for Critical Areas of Focus in Cloud Computing v3.0,
(2011).
[29] Cloud Security Alliance, Cloud Controls Matrix Version 3.0.1 (2016), https://
cloudsecurityalliance.org/group/cloud-controls-matrix/#_overview accessed
November 5, 2017.
[30] ENISA, Cloud Computing: Benefits, Risks and Recommendations for Information
Security, (2012) https://resilience.enisa.europa.eu/cloud-security-and-resilience/
publications/cloud-computing-benefits-risks-and-recommendations-for-
information-security accessed February 7, 2018.
[31] D. Catteddu, G. Hogben, Cloud Computing, Information Assurance Framework,
(2009) https://www.enisa.europa.eu/publications/cloud-computing-information-
assurance-framework/ accessed March 3, 2018.
[32] D. Catteddu, Security & Resilience in Governmental Clouds–Making an Informed
Decision, Security & Resilience in Governmental Clouds–Making an Informed
Decision 146 ENISA, 2011 ENISA ReportJanuary 2011 https://www.enisa.europa.
eu/publications/security-and-resilience-in-governmental-clouds accessed March 3,
2018.
[33] ITU-T, Focus Group on Cloud Computing Technical Report, (2012) http://wwwa.
itu.int/pub/T-FG-CLOUD-2012-P5/fr accessed March 3, 2018.
[34] C.H. LLP, W. Chan, E. Leung, H. Pili, Enterprise Risk Management for Cloud
Computing, (2012) https://www.coso.org/Documents/Cloud-Computing-Thought-
Paper.pdf accessed February 25, 2018.
[35] R.R. Moeller, COSO Enterprise Risk Management: Establishing Effective
Governance, Risk, and Compliance Processes, (2011), https://doi.org/10.1002/
9781118269145.
[36] G.A. Lewis, Role of standards in cloud-computing interoperability, 2013 46th
Hawaii Int. Conf. Syst. Sci, IEEE, 2013, pp. 1652–1661, , https://doi.org/10.1109/
HICSS.2013.470.
[37] ITGI/OGC, Aligning COBIT 4.1, ITIL V3 and ISO/IEC 27002 for Business Benefit,
(2008) http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/
Pages/Aligning-COBIT-4-1-ITIL-V3-and-ISO-IEC-27002-for-BusinessBenefit.aspx
accessed July 5, 2017.
[38] Y. Ozdemir, H. Basligil, P. Alcan, B.M. Kandemirli, Evaluation and comparison of
COBIT, ITIL and ISO27K1/2 standards within the, Int. J. Tech. Res. Appl. 11 (2014)
22–24 https://scholar.googleusercontent.com/scholar.bib?q=info:rlnm-
XRs3B0J:scholar.google.com/&output=citation&scisig=
AAGBfm0AAAAAWe9MdiGjYCra1fG_00naDrXRLFaX4LCX&scisf=4&ct=citation&
cd=-1&hl=fr&scfhb=1 accessed October 24, 2017.
[39] P. Năstase, F. Năstase, C. Ionescu, Challenges generated by the implementation of
the IT standards CobiT 4.1, ITIL v3 and ISO/IEC 27002 in enterprises, Econ.
Comput. (2009), http://www.ecocyb.ase.ro/articles 3.2009/Pavel Nastase.pdf
(accessed July 5, 2017.
117
Computer Standards & Interfaces 62 (2019) 98–118
[40] ISACA, CLOUD GOVERNANCE, (2013) https://www.google.com/search?q=Cloud
+Security+Standards%3AWhat+to+Expect+%26+What+to
+NegotiateVersion+2.0&ie=utf-8&oe=utf-8&client=firefox-b-ab accessed
November 23, 2017.
[41] AXELOS, IT Service Management and Cloud Computing, (2014) https://www.
google.com/search?client=firefox-b-ab&ei=lgMXWvjaCdDDkwXp0Y_oDw&q=
IT+service+management+and+cloud+computing&oq=IT+service
+management+and+cloud+computing&gs_l=psy-ab.12..0i19k1j0i22i30i19k1.
309891.309891.0.310872.1.1.0.0.0.0.239.239.2-1.1.0 accessed November 23,
2017.
[42] J. Becker, E. Bailey, IT controls and governance in cloud computing, Proc. Twent,
2014 https://pdfs.semanticscholar.org/b802/
6fa4e58bd193fdfc0e6d37bd2ebe2c6722a2.pdf accessed July 5, 2017.
[43] M. Al Mourad, M. Hussain, The impact of cloud computing on ITIL service strategy
processes, Int. J. Comput. (2014), http://search.proquest.com/openview/
14fe77b57588ee16024bcaf0ca749616/1?pq-origsite=gscholar&cbl=2027424 ac-
cessed July 5, 2017.
[44] M. Nieves, Best Practice in the Cloud: An Introduction, (2014) Retrieved http://
ibpi.vanharen.net/Player/eKnowledge/best_practice_in_the_cloud_an_introduction.
pdf accessed July 5, 2017.
[45] ISACA (Serving IT Governance Professionals), Security, Audit, and Control
Features : Oracle Database, ISACA, 2009.
[46] R. Sheikhpour, N. Modiri, An approach to map COBIT processes to ISO/IEC 27001
information security management controls, Int. J. Secur. Appl. (2012), https://
www.researchgate.net/profile/Razieh_Sheikhpour2/publication/292833500_An_
approach_to_map_COBIT_processes_to_ISOIEC_27001_information_security_
management_controls/links/582eaf6108ae102f072e6dbd/An-approach-to-map-
COBIT-processes-to-ISO-IEC-27001-in accessed July 5, 2017.
[47] ISACA, CLOUD GOVERNANCE, Questions Boards of Directors Need to Ask, (2013)
https://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/
Cloud-Governance-Questions-Boards-of-Directors-Need-to-Ask.aspx accessed
October 31, 2017.
[48] O. Illoh, S. Aghili, S. Butakov, Using COBIT 5 for Risk to Develop Cloud Computing
SLA Evaluation Templates, Springer, Cham, 2015, pp. 236–249, https://doi.org/10.
1007/978-3-319-22885-3_21.
[49] S. Zhang, F. Le, An Examination of the Practicability of COBIT Framework and the
Proposal of a COBIT-BSC Model, J. Econ. (2013), https://openaccess.leidenuniv.nl/
handle/1887/24618 accessed July 5, 2017.
[50] G. Ridley, J. Young, P. Carroll, COBIT and its utilization: a framework from the
literature, Syst. Sci. (2004) 2004 http://ieeexplore.ieee.org/abstract/document/
1265566/ accessed July 5, 2017.
[51] ISO/IEC, ISO/IEC 17788:2014 - Information Technology – Cloud Computing –
Overview and Vocabulary, 1st ed., (2014) https://www.iso.org/standard/60544.
html accessed July 5, 2017.
[52] ISO/IEC, ISO/IEC 17789:2014 - Information Technology – Cloud Computing –
Reference Architecture, 1st ed., (2014) https://www.iso.org/standard/60545.html
accessed July 52017.
[53] ISO/IEC, ISO/IEC 27017:2015 - Information Technology – Security Techniques –
Code of Practice for Information Security Controls Based on ISO/IEC 27002 for
Cloud Services, 1st ed., (2015) https://www.iso.org/standard/43757.html accessed
July 5, 2017.
[54] W. Fumy, M. De Soete, E.J. Humphreys, T. Chikazawa, J. Amsenga, K. Rannenberg,
ISO/IEC 27018:2014 - Information Technology – Security Techniques – Code of
Practice for Protection of Personally Identifiable Information (PII) in Public Clouds
Acting as PII Processors 8 (2014), p. 23 https://www.iso.org/standard/61498.html
accessed July 5, 2017.
[55] L.M. Jeannine Siviy, P. Kirwan, J. Morley, Maximizing your Process Improvement
ROI through Harmonization, (2008) http://resources.sei.cmu.edu/library/asset-
view.cfm?assetid=28907 accessed July 5, 2017.
[56] C. Pardo, F.J. Pino, F. García, M. Piattini Velthius, M.T. Baldassarre, Trends in
Harmonization of Multiple Reference Models, Springer, Berlin, Heidelberg, 2011,
pp. 61–73, https://doi.org/10.1007/978-3-642-23391-3_5.
[57] C. Pardo, F.J. Pino, F. García, M. Piattini, M.T. Baldassarre, An ontology for the
harmonization of multiple standards and models, Comput. Stand. Interfaces 34
(2012) 48–59, https://doi.org/10.1016/j.csi.2011.05.005.
[58] C. Pardo, F.J. Pino, F. Garcia, M.T. Baldassarre, M. Piattini, From chaos to the
systematic harmonization of multiple reference models: a harmonization frame-
work applied in two case studies, J. Syst. Software 86 (2013) 125–143, https://doi.
org/10.1016/j.jss.2012.07.072.
[59] Y. Bounagui, H. Hafiddi, A. Mezrioui, COBIT evaluation as a framework for cloud
computing governance, Int. J. Cloud (2016), http://www.igi-global.com/article/
cobit-evaluation-as-a-framework-for-cloud-computing-governance/173772 ac-
cessed July 5, 2017).</.
[60] P. Brereton, B.A. Kitchenham, D. Budgen, M. Turner, M. Khalil, Lessons from ap-
plying the systematic literature review process within the software engineering
domain, J. Syst. Software 80 (2007) 571–583, https://doi.org/10.1016/j.jss.2006.
07.009.
[61] G. Hardy, J. Hesch, Aligning CobiT® 4.1, ITIL® V3 and ISO/IEC 27002 for Business
Benefit, IT Gov. Inst., 2008, pp. 1–130 www.isaca.org.
[62] S. Bradner, RFC 2119 - key words for use in RFCs to indicate requirement levels
status, Netw. Work. Gr. (1997), pp. 1–3 http://www.ietf.org/rfc/rfc2119.txt.
[63] K. Lu, R. Yahyapour, P. Wieder, E. Yaqub, M. Abdullah, B. Schloer, C. Kotsokalis,
Fault-tolerant service level agreement lifecycle management in clouds using actor
system, Future Gener. Comput. Syst. 54 (2016) 247–259, https://doi.org/10.1016/
j.future.2015.03.016.
[64] F. Faniyi, R. Bahsoon, A systematic review of service level management in the
Y. Bounagui et al.
cloud, ACM Comput. Surv. 48 (2015) 1–27, https://doi.org/10.1145/2843890.
[65] FedRAMP, FedRAMP Baseline Security Controls, (2014) https://www.google.com/
search?client=firefox-b-ab&ei=mil6Wrr5J8KoUdPqi_AC&q=fedramp+baseline
+xls&oq=fedramp+baseline+xls&gs_l=psy-ab.3..33i160k1.8535.10767.0.
11015.4.4.0.0.0.0.141.485.0j4.4.0....0...1c.1.64.psy-ab..0.3.376...
0i19k1j0i22i30i19k1j33i21k1.0 accessed February 6, 2018.
[66] T. Labidi, A. Mtibaa, F. Gargouri, Ontology-Based Context-Aware SLA Management
for Cloud Computing, Springer, Cham, 2014, pp. 193–208, https://doi.org/10.
1007/978-3-319-11587-0_19.
[67] W.A. Ghumman, Automation of the SLA Life Cycle in Cloud Computing,
Automation of the SLA Life Cycle in Cloud Computing, (2014), pp. 557–562,
https://doi.org/10.1007/978-3-319-06859-6_51.
[68] A. Hammadi, O.K. Hussain, T. Dillon, F.K. Hussain, A framework for SLA man-
agement in cloud computing for informed decision making, Cluster Comput. 16
(2013) 961–977, https://doi.org/10.1007/s10586-012-0232-9.
[69] K. Sun, Y. Li, Effort estimation in cloud migration process, Proc. - 2013 IEEE 7th Int.
Symp. Serv. Syst. Eng. SOSE 2013, IEEE, 2013, pp. 84–91, , https://doi.org/10.
1109/SOSE.2013.29.
[70] P. Jamshidi, A. Ahmad, C. Pahl, Cloud migration research: a systematic review,
IEEE Trans. Cloud Comput. 1 (2013) 142–157, https://doi.org/10.1109/TCC.
2013.10.
[71] A.U. Khan, M. Oriol, M. Kiran, M. Jiang, K. Djemame, Security risks and their
management in cloud computing, 4th IEEE Int. Conf. Cloud Comput. Technol. Sci.
Proc, 2012, pp. 121–128, , https://doi.org/10.1109/CloudCom.2012.6427574.
[72] F. Xie, Y. Peng, W. Zhao, D. Chen, X. Wang, X. Huo, A risk management framework
for cloud computing, 2012 IEEE 2nd Int. Conf. Cloud Comput. Intell. Syst. IEEE,
2012, pp. 476–480, , https://doi.org/10.1109/CCIS.2012.6664451.
[73] G. Nie, X. E., D. Chen, Research on Service Level Agreement in Cloud Computing,
Springer, Berlin, Heidelberg, 2012, pp. 39–43, https://doi.org/10.1007/978-3-642-
28744-2_5.
[74] J. Ding, Z. Zhao, Towards autonomic SLA management: a review, 2012 Int. Conf.
Syst. Informatics, IEEE, 2012, pp. 2552–2555, , https://doi.org/10.1109/ICSAI.
2012.6223574.
[75] N.V. Pavan Kumar Illa, Sushma Nathani, Enterprise cloud migration: a phase driven
step-by-step-strategy intended for scalability, elasticity, agility and reliability, Int. J.
Comput. Appl. 2 (n.d.) (2018) 6 https://www.google.com/search?q=Enterprise
118
Computer Standards & Interfaces 62 (2019) 98–118
+cloud+migration%3A+a+phase+driven+step-by-step-strategy+intended
+for+scalability%2C+elasticity%2C+agility+and+reliability&ie=utf-8&oe=
utf-8&client=firefox-b-ab accessed January 31.
[76] P.V. Beserra, A. Camara, R. Ximenes, A.B. Albuquerque, N.C. Mendonça, Cloudstep:
a step-by-step decision process to support legacy application migration to the cloud,
2012 IEEE 6th Int. Work. Maint. Evol. Serv. Cloud-Based Syst. MESOCA 2012, IEEE,
2012, pp. 7–16, , https://doi.org/10.1109/MESOCA.2012.6392602.
[77] T.-C. Kao, C.-H. Mao, C.-Y. Chang, K.-C. Chang, SSDLC Cloud, Cloud security gov-
ernance deployment framework in secure system development life cycle, 2012 IEEE
11th Int. Conf. Trust. Secur. Priv. Comput. Commun. IEEE, 2012, pp. 1143–1148, ,
https://doi.org/10.1109/TrustCom.2012.106.
[78] M. Cochran, P. Witman, Governance and service level agreement issues in a cloud
computing environment, J. Inf. Technol. Manage. 22 (2011) 41–55 https://www.
google.com/search?client=firefox-b-ab&ei=5VV_WrnFEsvsUrCJpfgF&q=
GOVERNANCE+AND+SERVICE+LEVEL+AGREEMENT+ISSUES+IN
+A+CLOUD+COMPUTING+ENVIRONMENT&oq=GOVERNANCE+AND
+SERVICE+LEVEL+AGREEMENT+ISSUES+IN+A+CLOUD
+COMPUTING+ENVIRONMENT&gs_l=psy-ab.3..0i3 accessed February 10, 2018.
[79] W. Jansen, T. Grance, Guidelines on Security and Privacy in Public Cloud
Computing, (2011), https://doi.org/10.6028/NIST.SP.800-144 Gaithersburg, MD.
[80] D. Catteddu, Cloud Computing, Benefits, Risks and Recommendations for
Information Security, Springer, Berlin, Heidelberg, 2010, https://doi.org/10.1007/
978-3-642-16120-9_9 pp. 17–17.
[81] J.O. Fitó, M. Macias, J. Guitart, Toward business-driven risk management for Cloud
computing, Netw. Serv. Manag. (CNSM), 2010 Int. Conf. 2010, pp. 238–241, ,
https://doi.org/10.1109/CNSM.2010.5691291.
[82] M. Alhamad, T. Dillon, E. Chang, SLA-based trust model for cloud computing, 2010
13th Int. Conf. Network-Based Inf. Syst. IEEE, 2010, pp. 321–324, , https://doi.org/
10.1109/NBiS.2010.67.
[83] X. Zhang, N. Wuwong, H. Li, X. Zhang, Information security risk management
framework for the cloud computing environments, 2010 10th IEEE Int. Conf.
Comput. Inf. Technol. IEEE, 2010, pp. 1328–1334, , https://doi.org/10.1109/CIT.
2010.501.
[84] L. Wu, R. Buyya, Service level agreement (SLA) in utility computing systems, ArXiv
Prepr. ArXiv1010.2881. (2010) 27. doi:10.4018/978-1-60960-794-4.ch001.