ISO/IEC 19086-1:2016

INTERNATIONAL ISO/IEC
STANDARD 19086-1
First edition
2016-09-15
Information technology — Cloud
computing — Service level agreement
(SLA) framework —
Part 1:
Overview and concepts
Technologies de l’information — Informatique en nuage — Cadre de
travail de l’accord du niveau de service —
Partie 1: Aperçu général et concepts
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 4
5 Overview of SLAs for cloud services . 5
6 Relationship between the cloud service agreement and cloud SLAs .6
7 Cloud SLA management best practices . 7
7.1 General . 7
7.2 Design . 7
7.3 Evaluation and acceptance . 7
7.4 Implementation and execution . 8
7.5 Changes to the cloud SLA . 8
8 The role of cloud service level objectives, cloud service qualitative objectives,
metrics, remedies and exceptions in the cloud SLA . 8
8.1 General . 8
8.2 Metrics . 8
8.3 SLOs and SQOs . 9
8.3.1 Service levels . 9
8.3.2 Cloud service level objectives . 9
8.3.3 Cloud service qualitative objectives . 9
8.4 Remedies and claims .10
8.4.1 Remedies .10
8.4.2 Claims process .10
8.5 Exceptions .10
9 Cloud SLA components .10
9.1 General .10
9.2 Covered services component .10
9.2.1 Description . . .10
9.2.2 Relevance . .11
9.3 Cloud SLA definitions component .11
9.3.1 Description . . .11
9.3.2 Relevance . .11
9.4 Service monitoring component .11
9.4.1 Description . . .11
9.4.2 Relevance . .11
9.4.3 Cloud service qualitative objectives .11
9.5 Roles and responsibilities component .11
9.5.1 Description . . .11
9.5.2 Relevance . .12
10 Cloud SLA content areas and their components .12
10.1 General .12
10.2 Accessibility content area .12
10.2.1 Accessibility component .12
10.3 Availability content area .13
10.3.1 Availability component .13
10.4 Cloud service performance content area .13
10.4.1 General.13
10.4.2 Cloud service response time component .13
© ISO/IEC 2016 – All rights reserved iii

10.4.3 Cloud service capacity component.14
10.4.4 Elasticity component . .15
10.5 Protection of personally identifiable information (PII) content area.16
10.5.1 Protection of PII component .16
10.6 Information Security content area .17
10.6.1 Information Security component .17
10.7 Termination of service content area .18
10.7.1 Termination of service component .18
10.8 Cloud service support content area .19
10.8.1 Cloud service support component .19
10.9 Governance content area . .21
10.9.1 Governance component .21
10.10 Changes to the cloud service features and functionality content area .22
10.10.1 Changes to the cloud service features and functionality component .22
10.11 Service reliability content area .23
10.11.1 General.23
10.11.2 Service resilience/fault tolerance component .23
10.11.3 Customer data backup and restore component .24
10.11.4 Disaster recovery component.25
10.12 Data management content area .26
10.12.1 General.26
10.12.2 Intellectual property rights (IPR) component .27
10.12.3 Cloud service customer data component .27
10.12.4 Cloud service provider data component .28
10.12.5 Account data component .28
10.12.6 Derived Data component .28
10.12.7 Data portability component .29
10.12.8 Data deletion component .29
10.12.9 Data location component.30
10.12.10 .
Data examination component .31
10.12.11 .
Law enforcement access component .31
10.13 Attestations, certifications and audits content area .31
10.13.1 Attestations, certifications and audits component.31
Bibliography .33
iv © ISO/IEC 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 38, Cloud computing and distributed platforms.
A list of all parts in the ISO/IEC 19086 series can be found on the ISO website.
© ISO/IEC 2016 – All rights reserved v

Introduction
This document provides an overview, foundational concepts, and definitions for the cloud SLA
framework. ISO/IEC 19086 builds on the cloud computing concepts defined in ISO/IEC 17788 and
ISO/IEC 17789. This document establishes a common framework for helping organizations to
understand the purpose of all the parts of ISO/IEC 19086 and the relationships between those parts.
It also identifies other documents that have relationships with ISO/IEC 19086 and which are useful in
understanding cloud SLAs.
This document can be used by any organization or individual involved in the creation, modification
or understanding of a cloud service level agreement which conforms to ISO/IEC 19086. The cloud SLA
should account for the key characteristics of a cloud computing service and needs to facilitate a common
understanding between cloud service providers and cloud service customers.
In particular, it defines the following fundamental concepts of the cloud SLA framework:
— Cloud Service Agreement (CSA)
— Cloud Service Level Agreement (SLA)
— Cloud Service Level Objectives (SLO)
— Cloud Service Qualitative Objectives (SQO)
This document also describes the content areas and components that consist of a list of SLOs and SQOs.
— ISO/IEC 19086-2 provides the metrics model to be used for creating metrics used in SLOs and SQOs.
— ISO/IEC 19086-3 provides the core conformance requirements derived from the SLOs and SQOs
defined in this document.
— ISO/IEC 19086-4 builds upon the foundational concepts and definitions described by this document
by describing specific components and the conformance requirements for SLOs and SQOs in the
area of Security and Privacy.
More specifically, this document
a) promotes cohesion between the parts of ISO/IEC 19086 by explaining the concepts and terminology
used across all parts,
b) contributes to the understanding of ISO/IEC 19086 by clarifying the relationships between all the
parts, and
c) provides an overview of other International Standards which can be used in combination with
ISO/IEC 19086.
Figure 1 represents an overview of the content of ISO/IEC 19086 and the relationships between the
parts of ISO/IEC 19086 and other key International Standards relating to cloud computing.
vi © ISO/IEC 2016 – All rights reserved

Figure 1 — Relationship of parts of ISO/IEC 19086 and other cloud computing standards
This document addresses the contents of a cloud SLA in two main groupings: SLA Components,
addressed in Clause 9, and SLA Content Areas, addressed in Clause 10, as shown in Figure 2.
Figure 2 — SLA components and SLA content areas
© ISO/IEC 2016 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 19086-1:2016(E)
Information technology — Cloud computing — Service
level agreement (SLA) framework —
Part 1:
Overview and concepts
1 Scope
This document seeks to establish a set of common cloud SLA building blocks (concepts, terms,
definitions, contexts) that can be used to create cloud Service Level Agreements (SLAs).
This document specifies
a) an overview of cloud SLAs,
b) identification of the relationship between the cloud service agreement and the cloud SLA,
c) concepts that can be used to build cloud SLAs, and
d) terms commonly used in cloud SLAs.
This document is for the benefit and use of both cloud service providers and cloud service customers.
The aim is to avoid confusion and facilitate a common understanding between cloud service providers
and cloud service customers. Cloud service agreements and their associated cloud SLAs vary between
cloud service providers, and in some cases different cloud service customers can negotiate different
contract terms with the same cloud service provider for the same cloud service. This document aims
to assist cloud service customers when they compare cloud services from different cloud service
providers.
This document does not provide a standard structure that can be used for a cloud SLA or a standard set
of cloud service level objectives (SLOs) and cloud service qualitative objectives (SQOs) that will apply
to all cloud services or all cloud service providers. This approach provides flexibility for cloud service
providers in tailoring their cloud SLAs to the particular characteristics of the offered cloud services.
This document does not supersede any legal requirement.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 17788:2014, Information technology — Cloud computing — Overview and vocabulary
ISO/IEC 17789,Information technology — Cloud computing — Reference architecture
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 17788 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
© ISO/IEC 2016 – All rights reserved 1

— ISO Online browsing platform: available at http://www.iso.org/obp
3.1
accessibility
usability of a product, service, environment or facility by people within the widest range of capabilities
Note 1 to entry: The concept of accessibility addresses the full range of user capabilities and is not limited to
users who are formally recognized as having disability.
Note 2 to entry: The usability-oriented concept of accessibility aims to achieve levels of effectiveness, efficiency
and satisfaction that are as high as possible considering the specified context of use, while paying attention to
the full range of capabilities within the user population.
Note 3 to entry: It is important in the context of ISO/IEC 19086 to distinguish between the specialized meaning
of “accessibility” as defined here and the term “accessible” which is used with its dictionary meaning of “able to
be reached or entered.”
[SOURCE: ISO 9241-171:2008, 3.2]
3.2
business continuity
capability of the organization to continue delivery of products or services at acceptable predefined
levels following disruptive incident
[SOURCE: ISO/IEC 22301:2012, 3.3]
3.3
cloud service agreement
documented agreement between the cloud service provider and cloud service customer that governs
the covered service(s)
Note 1 to entry: A cloud service agreement can consist of one or more parts recorded in one or more documents.
3.4
cloud service level agreement
cloud SLA
part of the cloud service agreement (3.3) that includes cloud service level objectives (3.5) and cloud
service qualitative objectives (3.6) for the covered cloud service(s)
3.5
cloud service level objective
SLO
commitment a cloud service provider makes for a specific, quantitative characteristic of a cloud service,
where the value follows the interval scale (3.9) or ratio scale (3.17)
Note 1 to entry: An SLO commitment may be expressed as a range.
3.6
cloud service qualitative objective
SQO
commitment a cloud service provider makes for a specific, qualitative characteristic of a cloud service,
where the value follows the nominal scale (3.11) or ordinal scale (3.12)
Note 1 to entry: A cloud service qualitative objective may be expressed as an enumerated list.
Note 2 to entry: Qualitative characteristics typically require human interpretation.
Note 3 to entry: The ordinal scale allows for existence/non-existence.
2 © ISO/IEC 2016 – All rights reserved

3.7
disaster recovery
ability of the ICT elements of an organization to support its critical business functions to an acceptable
level within a predetermined period of time following a disaster
[SOURCE: ISO/IEC 27031:2011, 3.7]
3.8
failure notification policy
policy specifying the processes by which the cloud service customer and cloud service partner can
notify the cloud service provider of a service outage and by which the cloud service provider can notify
the cloud service customer and cloud service partner that a service outage has occurred.
Note 1 to entry: The policy may also include the process for providing updates on service outages, who receives
notifications and updates, the maximum time between the detection of a service outage and the issuance of a
notice of service outage, the maximum time interval between service outage updates and how service outage
updates are described.
3.9
interval scale
continuous scale or discrete scale with equal sized scale values and an arbitrary zero
[SOURCE: ISO 3534-2:2006, 1.1.8]
3.10
metric
standard of measurement that defines the conditions and the rules for performing the measurement
and for understanding the results of a measurement
Note 1 to entry: A metric implements a particular abstract metric concept.
Note 2 to entry: A metric is to be applied in practice within a given context that requires specific properties to be
measured, at a given time(s) for a specific goal.
3.11
nominal scale
scale with unordered labelled categories or ordered by convention
[SOURCE: ISO 3534-2:2006, 1.1.6]
3.12
ordinal scale
scale with ordered labelled categories
[SOURCE: ISO 3534-2:2006, 1.1.7]
3.13
personally identifiable information
PII
any information that (a) can be used to identify the PII principal to whom such information relates, or
(b) is or might be directly or indirectly linked to a PII principal
Note 1 to entry: To determine whether a PII principal is identifiable, account should be taken of all the means
which can reasonably be used by the privacy stakeholder holding the data, or by any other party, to identify that
natural person.
[SOURCE: ISO/IEC 29100:2011, 2.9]
© ISO/IEC 2016 – All rights reserved 3

3.14
PII controller
privacy stakeholder (or privacy stakeholders) that determines the purposes and means for processing
personally identifiable information (PII) other than natural persons who use data for personal purposes
[SOURCE: ISO/IEC 29100:2011, 2.10]
3.15
PII principal
natural person to whom the personally identifiable information (PII) relates
[SOURCE: ISO/IEC 29100:2011, 2.11]
3.16
PII processor
privacy stakeholder that processes personally identifiable information (PII) on behalf of and in
accordance with the instructions of a PII controller
[SOURCE: ISO/IEC 29100:2011, 2.12]
3.17
ratio scale
continuous scale with equal sized scale values and an absolute or natural zero point
[SOURCE: ISO 3534-2:2006, 1.1.9]
3.18
remedy
compensation available to the cloud service customer in the event the cloud service provider fails to
meet a specified cloud service level objective (3.5)
Note 1 to entry: This definition of the term in English is based on the “legal reparation” meaning defined in The
Shorter Oxford English Dictionary.
3.19
resilience
ability of a cloud service to recover operational condition quickly after a fault occurs
4 Symbols and abbreviated terms
BLOB Binary Large Object
CSA Cloud Service Agreement
CSC Cloud Service Customer
CSP Cloud Service Provider
ICT Information and Communications Technology
IPR Intellectual Property Rights
IT Information Technology
PII Personally Identifiable Information
RPO Recovery Point Objective
RTO Recovery Time Objective
4 © ISO/IEC 2016 – All rights reserved

SLA Service Level Agreement
SLO Cloud Service Level Objective
SQO Cloud Service Qualitative Objective
VM Virtual Machine
5 Overview of SLAs for cloud services
A cloud service level agreement (cloud SLA) is a part of the cloud service agreement that includes
cloud service level objectives and cloud service qualitative objectives for the covered cloud service(s).
The cloud SLA should account for the key characteristics of cloud computing as described in
ISO/IEC 17788:2014, 6.2 that include the following.
— On-demand self-service — A CSC may gain access to cloud services without human interaction
with the CSP. The cloud service agreement (CSA) (see Clause 6) and the associated cloud SLA may be
presented and agreed through software tools and financial arrangements that are automated.
— Resource pooling — The public cloud deployment models allow sharing resources across many
CSCs that do not have a relationship. The private cloud models allow users to share resources within
the same organization. The hybrid cloud models allow users to share some resources within the
same organization and some resources across many CSCs that do not necessarily have a relationship
with one another. The community cloud deployment models allow sharing resources across CSCs
that have some relationship.
— Multi-tenancy — Cloud environments are enabled through the use of large-scale virtualization
of servers, storage and networks. Overall system usage is typically spread over many CSCs. Multi-
tenancy allows sharing of resources in such a way that multiple tenants and their computations
and data are isolated from and inaccessible to one another. Cloud environments typically have no
persistent relationship between particular physical resources and their use by CSCs. The CSCs are
assigned virtual resources, and logging of usage is done at this level of abstraction.
— Rapid elasticity and scalability — A characteristic of cloud computing where physical or virtual
resources can be rapidly and elastically adjusted, in some cases automatically, to quickly increase
or decrease resources.
— Tradeoff between cost and control — Large-scale, standardized cloud services may be provided
on a low unit cost, utility basis, in conjunction with standardized contracts and cloud SLAs. If a CSC
requires more control and customization of cloud services than is available from a standard utility
service model, then this may be provided at an additional cost and with a specific cloud SLA.
— Measured service — A feature where the metered delivery of cloud services is such that usage can
be monitored, controlled, reported and billed. This is an important feature needed to optimize and
validate the delivered cloud service. The focus of this key characteristic is that the CSC may only pay
for the resources that they use.
— Broad network access — The capabilities of cloud services are made available over the network
and are typically accessed through standard mechanisms that promote use by heterogeneous client
platforms (for example, access through mobile phones, laptops and workstations).
Details of cloud SLAs, SLOs and SQOs can vary for different cloud service categories, cloud capabilities
types and different cloud deployment models (see ISO/IEC 17788). Cloud SLAs in this document
are intended to be useful for CSCs and CSPs across the variety of cloud service categories and cloud
deployment models. As the definitions of SLOs and SQOs are intended to be technology and business
model neutral, so not all of these SLOs or SQOs will apply to every cloud service, and those that do
apply may be structured and applied in different ways to specific cloud services. For example, service
availability can be measured in different ways, some of which depend on the specific cloud service: a
© ISO/IEC 2016 – All rights reserved 5

computational cloud service is different from an email cloud service, and service availability for each
will be computed differently.
6 Relationship between the cloud service agreement and cloud SLAs
Cloud services, particularly public cloud services, generally involve an agreement between the CSC and
the CSP concerning the acquisition and use of the cloud services. For the purposes of this document,
the legal agreement is referred to as the “Cloud Service Agreement” or CSA. The CSA has a number of
synonyms such as “Master Service Agreement,” “Customer Agreement,” “Terms of Service,” or simply
“Agreement.”
A CSA comprises one or more parts recorded in one or more documents. Contents of each part can
appear in more than one document. There is no normative relationship between parts and documents,
i.e. a part does not have to be in a single document, and a document does not have to contain a whole
part. There is neither a standard naming convention for the parts or documents of a CSA, nor a standard
structure for the documents or parts.
Examples of common parts of CSAs include the following.
— Cloud Service Level Agreement (cloud SLA)
The cloud SLA ordinarily contains a collection of SLOs and SQOs relating to the cloud service,
covering aspects of the service. This might include availability, reliability, performance, security,
data protection, compliance and data handling.
— Acceptable Use Policy
The acceptable use policy usually defines boundaries for the CSC’s use of the cloud service. This
might include restrictions that prevent the CSC from installing malware on the cloud service or
limit the kind of data that can be stored.
— Security Policy
The security policy typically describes responsibilities that apply to the CSC and to the CSP, SLOs
and SQOs which the CSP applies to the cloud service in security terms and potentially indicates
which security certifications or standards are met by the cloud service.
— Data Protection Policy
The data protection policy typically deals with the handling of personal data or sensitive data by
the cloud service, including SQOs for specific data protection measures and privacy certifications
or standards that apply to the service.
— Business Continuity Policy
The business continuity policy typically deals with the resilience aspects of the cloud service and
can include measures that are implemented by the CSP to avoid data loss and to deal with outages,
such as backups and redundant components.
— Upgrade Policy
The upgrade policy usually covers changes to the features and functions for the covered services
and related management interface changes. Periodic updates are also usually covered by the
upgrade policy.
— Termination Policy
The Termination Policy usually deals with the issues that arise when a CSC terminates their
use of one or more cloud services. The termination policy might include SQOs for areas such as
notifications, data reversibility and data deletion.
6 © ISO/IEC 2016 – All rights reserved

The content of each of the parts and the number of parts in the CSA can vary between different cloud
services — any particular item, including the SLOs and SQOs described in this document, can appear
in different parts for different services. As an example, security SLOs and SQOs might be described in
the Security Policy or they might appear in the cloud SLA. However, it is important for the CSC to know
the complete set of documents that govern the cloud service, and the CSA is expected to reference all
applicable documents.
7 Cloud SLA management best practices
7.1 General
Cloud SLA management covers the issues related to cloud SLA design, evaluation, negotiation and
acceptance, implementation and execution and changes to the cloud SLA. CSCs should ensure that cloud
SLAs and other governing documents align with their business cases and overall strategy. CSCs should
be aware that there could be several documents that govern a cloud service. See Clause 6 for more
details.
7.2 Design
A cloud SLA applies to the covered services identified within the cloud SLA. A single cloud SLA may
apply to multiple CSCs or to a single CSC. In cases where the cloud SLA is designed jointly by the CSC and
the CSP, both parties should undertake the steps outlined in 7.2 together. A CSP should design the cloud
SLAs to meet the needs of their CSCs and to align with the capabilities of the covered services.
The cloud SLA design process should account for the appropriate roles. ISO/IEC 17789 can be used
as a reference for determining the appropriate key roles. Key roles for the cloud SLA design process
discussed in ISO/IEC 17789 include
— cloud service customer, party which is in a business relationship for the purpose of using cloud
services,
— cloud service provider, party which makes cloud services available, and
— cloud service partner, party which is engaged in support of, or auxiliary to, activities of either the
CSP or the CSC, or both.
ISO/IEC 17789 contains concepts that can be used in the construction of a cloud SLA. The choice of
concepts to be included in a cloud SLA depends on the cloud service and on the business context. The
process to change the cloud SLA and notify CSCs of changes should be within the cloud SLA or other
governing document.
The design phase should also consider the mechanisms that the CSC and the CSP can use to monitor
each service characteristic and report failures to meet SLO and SQO commitments.
7.3 Evaluation and acceptance
CSCs can use this document as a reference when evaluating cloud SLAs. CSCs can review all of the
concepts and determine which are critical to their business objectives. CSCs can then consider the CSP’s
cloud SLAs (and remedies) in evaluating whether the CSP’s services meet the CSC’s business objectives.
CSCs can review cloud SLAs in the context of their organization’s business policies and other
requirements, and can identify which SLOs, SQOs and service features are important for each of their
use cases. Standards such as the ISO/IEC 20000 series and the ISO/IEC 27000 series may be referenced
in cloud SLAs or other documentation. In some cases, CSPs certify their conformance with specific
industry standards. CSCs can determine what standards are important to their business objectives or
are desirable for their organization’s governance and determine whether a cloud service is certified to
conform with that standard, or if it is referenced in the cloud SLA or other documentation. CSCs can
determine how they monitor cloud service characteristics and report failures to meet SLO and SQO
© ISO/IEC 2016 – All rights reserved 7

commitments by familiarizing themselves with a CSP’s failure notification policy, if available. Methods
for monitoring and reporting include management systems, connected devices apps, web portals, email,
text messages, telephone and posts to social media sites.
Acceptance of a cloud SLA may occur by clicking a check box on a web page, by registering for the cloud
service, or by a formal signing of the agreement by both parties. Each party should ensure they are
ready to undertake the implementation and execution of the cloud SLA, independent of the means
of acceptance. In the case of an agreement with unique terms, both parties should ensure they are
prepared to support implementation and execution of those terms.
7.4 Implementation and execution
Implementing a cloud SLA involves setting up processes for monitoring and managing cloud service
characteristics, reporting any failures to meet SLOs and SQOs and claiming any remedies. In some
cases, the CSP may need to collaborate with the CSC when implementing the cloud SLA. CSCs should
also include the cloud SLA in their internal governance. The choice of concepts to be included in cloud
SLA monitoring and auditing processes depends on the cloud service and the business context.
Execution of the cloud SLA involves the provision and operation of the cloud service by the CSP, including
the management and monitoring of service levels. If a CSC believes an SLO or SQO has not been met, the
CSC may follow the failure notification policy.
7.5 Changes to the cloud SLA
Change is an inevitable part of any ICT system, and cloud SLAs are no exception, whether due capability
change or evolution of CSC requirements. The CSP can include a process to make changes to the cloud
SLA and provide notifications to CSCs. The CSP can also include mechanisms that allow the CSCs to
request changes to the cloud SLA.
The CSCs can evaluate the cloud SLA change and notification processes in the evaluation and acceptance
phase. CSCs can also determine whether the current SLAs or proposed SLA meet their business
objectives and if not, request changes to the SLA.
8 The role of cloud service level objectives, cloud service qualitative objectives,
metrics, remedies and exceptions in the cloud SLA
8.1 General
It is essential to be able to monitor the cloud service to ensure that the SLOs and SQOs in the cloud SLA
are being met. It is important to have remedies described within the cloud SLA or a related document
in the event that an objective is not met. Finally, there might be events or incidents that are declared as
exceptions. In those cases, even though an SLO or SQO is not met, the related remedy is not triggered.
8.2 Metrics
The definition and usage of appropriate metrics and their underlying measures and measurements are
an essential aspect of the cloud SLA. The metrics are used to set the boundaries and margins of error
the CSP abides by and their limitations. These metrics may be used at runtime for service monitoring or
remediation.
Cloud service metrics address the following needs (list non-exhaustive).
— Determine if SLOs are met.
— Categorize service capabilities.
— Define a purpose for measures and measurements.
8 © ISO/IEC 2016 – All rights reserved

— Deliver a consistent representation of measure and measurement in
...