ISO/IEC 19086-1:2016

DRAFT INTERNATIONAL STANDARD
ISO/IEC DIS 19086-1
ISO/IEC JTC 1/SC 38 Secretariat: ANSI
Voting begins on: Voting terminates on:
2016-01-04 2016-04-04
Information technology — Cloud computing — Service
level agreement (SLA) framework —
Part 1:
Overview and concepts
Titre manque
ICS: 35.020
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/IEC DIS 19086-1:2015(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO/IEC 2015

ISO/IEC DIS 19086-1:2015(E)
© ISO/IEC 2015, 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 2015 – All rights reserved

ISO/IEC DIS 19086-1
Contents Page
Foreword v
Scope 1
Normative references . 1

Terms and definitions . 1

Symbols and abbreviated terms . 4

Overview of SLAs for cloud services . 5

Relationship between the cloud service agreement and SLAs . 6

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

The role of cloud service level objectives, cloud service qualitative objectives, metrics,
remedies, and exceptions in the SLA . 8

8.1
General . 8

8.2
Metrics . 8

8.3
Service levels . 9

8.3.1
Cloud service level objectives . 9

8.3.2
Cloud service qualitative objectives . 9

8.4
Remedies . 10

8.4.1
Claims process . 10

8.5
Exceptions . 10

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

Cloud SLA content areas . 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 2015 – All rights reserved iii

ISO/IEC DIS 19086-1
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 . 20

10.8.1
Cloud service support component . 20

10.9
Governance content area . 22

10.9.1
Governance component . 22

10.10
Changes to the cloud service features and functionality content area . 23

10.10.1
Changes to the cloud service features and functionality component . 23

10.11
Service reliability content area . 24

10.11.1
General . 24

10.11.2
Service resilience/fault tolerance component . 24

10.11.3
Customer data backup and restore component . 24

10.11.4
Disaster recovery component . 26

10.12
Data management content area . 27

10.12.1
General . 27

10.12.2
Intellectual property rights (IPR) component . 27

10.12.3
Cloud service customer data component . 28

10.12.4
Cloud service provider data componen . 28

10.12.5
Account data component . 29

10.12.6
Derived Data component . 29

10.12.7
Data portability component . 30

10.12.8
Data deletion component . 30

10.12.9
Data location component . 31

10.12.10
Data examination component . 31

10.12.11
Law enforcement access component . 32

10.13
Attestations, certifications and audits content area . 32

10.13.1
Attestations, certifications and audits component . 32

Bibliography . 34

iv © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 19086-1
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
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.
ISO/IEC 19086-1 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 38, Cloud Computing and Distributed Platforms.
ISO/IEC 19086 consists of the following parts, under the general title Information technology — Cloud
computing ─ Service Level Agreement (SLA) framework:
⎯ Part 1: Overview and concepts
⎯ Part 2: Metrics
⎯ Part 3: Core requirements
⎯ Part 4: Security & Privacy
© ISO/IEC 2015 – All rights reserved v

COMMITTEE DRAFT ISO/IEC DIS 19086-1

1 Information technology — Cloud computing ─ Service Level
2 Agreement (SLA) framework — Part 1: Overview and concepts
3 1 Scope
4 This International Standard specifies an overview of Service Level Agreements (SLA)s for cloud services,
5 identification of the relationship between the cloud service agreement and the SLA, concepts that can be
6 used to build cloud SLAs, and terms commonly used in SLAs for cloud services. This standard is for the
7 benefit and use of both cloud service provider and cloud service customer.
8 This International Standard does not provide a standard structure that can be used for a cloud SLA or a
9 standard set of cloud service level objectives (SLOs) and cloud service qualitative objectives (SQOs) that
10 will apply to all cloud services or all cloud service providers. Contracts vary between cloud service providers,
11 and in some cases different cloud service customers can negotiate different contract terms with the same
12 cloud service provider for the same cloud service, so this standard seeks to establish a set of common
13 cloud SLA building blocks (concepts, terms, definitions, contexts) that can then be used to create cloud
14 SLAs that help avoid confusion and facilitates a common understanding between cloud service providers
15 and cloud service customers.
16 This International Standard does not supersede any legal requirement.
17 2 Normative references
18 The following referenced documents are indispensable for the application of this document. For dated
19 references, only the edition cited applies. For undated references, the latest edition of the referenced
20 document (including any amendments) applies.
21 Recommendation ITU-T Y.3500 | ISO/IEC 17788:2014, Information technology — Cloud computing —
22 Overview and vocabulary
23 Recommendation ITU-T Y.3502 | ISO/IEC 17789:2014, Information technology — Cloud computing —
24 Reference architecture
25 3 Terms and definitions
26 For the purposes of this document, the terms and definitions given in Rec. ITU-T Y.3500 | ISO/IEC 17788
27 and the following definitions apply.
28 3.1
29 accessibility
30 usability of a product, service, environment or facility by people within the widest range of capabilities
31 Note 1 to entry: The concept of accessibility addresses the full range of user capabilities and is not limited
32 to users who are formally recognized as having disability.
© ISO/IEC 2015 – All rights reserved 1

ISO/IEC DIS 19086-1
33 Note 2 to entry: The usability-oriented concept of accessibility aims to achieve levels of effectiveness,
34 efficiency and satisfaction that are as high as possible considering the specified context of use, while
35 paying attention to the full range of capabilities within the user population.
36 Note 3 to entry: It is important in the context of ISO/IEC 19086 to distinguish between the specialized
37 meaning of “accessibility” as defined here and the term “accessible” which is used with its dictionary
38 meaning of “able to be reached or entered”.
39 [SOURCE: ISO 9241-171:2008, 3.2]
40 3.2
41 cloud service agreement
42 documented agreement between the cloud service provider and cloud service customer that governs the
43 covered service(s)
45 Note 1 to entry: A cloud service agreement can consist of one or more parts recorded in one or more
46 documents
48 3.3
49 failure notification policy
50 policy specifying the processes by which the cloud service customer and cloud service partner can notify
51 the cloud service provider of a service outage and by which the cloud service provider can notify the cloud
52 service customer and cloud service partner that a service outage has occurred.
53 Note 1 to entry: The policy may also include the process for providing updates on service outages, who
54 receives notifications and updates, the maximum time between the detection of a service outage and the
55 issuance of a notice of service outage, the maximum time interval between service outage updates and
56 how service outage updates are described
57 3.4
58 remedy
59 compensation available to the cloud service customer in the event the cloud service provider fails to meet a
60 specified cloud service level objective.
61 3.5
62 resilience
63 ability of a cloud service to recover operational condition quickly after a fault occurs
64 3.6
65 cloud service level objective
66 SLO
67 commitment a cloud service provider makes for a specific, quantitative characteristic of a cloud service,
68 where the value follows the interval or ratio scale
70 Note 1 to entry: an SLO commitment may be expressed as a range
71 3.7
72 cloud service qualitative objective
73 SQO
74 commitment a cloud service provider makes for a specific, qualitative characteristic of a cloud service,
75 where the value follows the nominal or ordinal scale
76 Note 1 to entry: a cloud service qualitative objective may be expressed as an enumerated list
77 Note 2 to entry: qualitative characteristics typically require human interpretation
78 Note 3 to entry: The ordinal scale allows for existence/nonexistence
2 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 19086-1
79 3.8
80 metric
81 a standard of measurement that defines the conditions and the rules for performing the measurement and
82 for understanding the results of a measurement.
83 Note 1 to entry: A metric implements a particular abstract metric concept.
84 Note 2 to entry: A metric is to be applied in practice within a given context that requires specific properties
85 to be measured, at a given time(s) for a specific goal.
86 3.9
87 disaster recovery
88 ability of the ICT elements of an organization to support its critical business functions to an acceptable level
89 within a predetermined period of time following a disaster
90 [SOURCE: ISO/IEC 27031:2011, 3.7]
91 3.10
92 personally identifiable information (PII)
93 any information that (a) can be used to identify the PII principal to whom such information relates, or
94 (b) is or might be directly or indirectly linked to a PII principal
96 Note to entry: To determine whether a PII principal is identifiable, account should be taken of all the means
97 which can reasonably be used by the privacy stakeholder holding the data, or by any other party, to identify
98 that natural person.
99 [SOURCE: ISO/IEC 29100:2011, 2.9]
101 3.11
102 PII processor
103 privacy stakeholder that processes personally identifiable information (PII) on behalf of and in accordance
104 with the instructions of a PII controller
105 [SOURCE: ISO/IEC 29100, 2.12]
106 3.12
107 service level agreement (SLA)
108 part of the cloud service agreement that includes cloud service level objectives and cloud service qualitative
109 objectives for the covered service(s)
111 3.13
112 business continuity
113 capability of the organization to continue delivery of products or services at acceptable predefined levels
114 following disruptive incident
115 [SOURCE: ISO/IEC 22301:2012(en), 3.3]
116 3.14
117 PII controller
118 privacy stakeholder (or privacy stakeholders) that determines the purposes and means for processing
119 personally identifiable information (PII) other than natural persons who use data for personal purposes
120 [SOURCE: ISO/IEC 29100:2011, 2.10]
121 3.15
122 PII principal
123 natural person to whom the personally identifiable information (PII) relates
124 [SOURCE: ISO/IEC 29100:2011, 2.11]
© ISO/IEC 2015 – All rights reserved 3

ISO/IEC DIS 19086-1
125 3.16
126 nominal scale
127 scale with unordered labelled categories or ordered by convention
129 [SOURCE: ISO 3534-2:2006(en), 1.1.6]
131 3.17
132 ordinal scale
133 scale with ordered labelled categories
134 [SOURCE: ISO 3534-2:2006(en), 1.1.7]
135 3.18
136 interval scale
137 continuous scale or discrete scale with equal sized scale values and an arbitrary zero
138 [SOURCE: ISO 3534-2:2006(en), 1.1.8]
139 3.19
140 ratio scale
141 continuous scale with equal sized scale values and an absolute or natural zero point
142 [SOURCE: ISO 3534-2:2006(en), 1.1.9]
143 4 Symbols and abbreviated terms
144 For the purposes of this document, the following abbreviations apply:
145 AUP Acceptable Use Policy
146 BLOB Binary Large Object
147 CSA Cloud Service Agreement
148 CSC Cloud Service Customer
149 CSP Cloud Service Provider
150 DDoS Distributed Denial of Service
151 IaaS Infrastructure as a Service
152 ICT Information and Communications Technology
153 IPR Intellectual Property Rights
154 IT Information Technology
155 KPI Key Performance Indicator
156 MBRT Maximum Batch Response Time
157 MTTSR Maximum Time to Service Recovery
158 PaaS Platform as a Service
159 PII Personally Identifiable Information
4 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 19086-1
160 RPO Recovery Point Objective
161 RTO Recovery Time Objective
162 SaaS Software as a Service
163 SCRUD search, create, read, update and delete
164 SLA Service Level Agreement
165 SLO Cloud Service Level Objective
166 SQO Cloud Service Qualitative Objective
167 TTSR  Time to Service Recovery
168 VM  Virtual Machine
169 WCAG W3C Web Content Accessibility Guidelines
170 5 Overview of SLAs for cloud services
171 A service level agreement (SLA) is a part of the cloud service agreement that includes cloud service level
172 objectives and cloud service qualitative objectives for the covered service(s). The cloud SLA should
173 account for the key characteristics of cloud computing as described in Clause 6.2 of Rec. ITU-T Y.3500 |
174 ISO/IEC 17788 that include:
175 ⎯ Self-service – A CSC may gain access to cloud services without human interaction with the CSP. The
176 cloud service agreement (CSA) (see Clause 6) and the associated cloud SLA may be presented and
177 agreed through software tools and financial arrangements that are automated.
178 ⎯ Resource pooling – The public cloud deployment models allow sharing resources across many CSCs
179 that do not have a relationship. The private cloud models allow users to share resources within the
180 same organization. The hybrid cloud models allow users to share some resources within the same
181 organization and some resources across many CSCs that do not necessarily have a relationship. The
182 community cloud deployment models allow sharing resources across CSCs that have some
183 relationship.
184 ⎯ Multi-tenancy – Cloud environments are enabled through the use of large-scale virtualization of
185 servers, storage and networks. Overall system usage is typically spread over many CSCs.  Cloud
186 environments typically have no persistent relationship between particular physical resources and their
187 use by CSCs. The CSCs are assigned virtual resources, and logging of usage is done at this level of
188 abstraction.
189 ⎯ Rapid elasticity and scaling – A characteristic of cloud computing where physical or virtual resources
190 can be rapidly and elastically adjusted, in some cases automatically, to quickly increase or decrease
191 resources.
192 ⎯ Tradeoff between cost and control – Large-scale, standardized cloud services may be provided on a
193 low unit cost, utility basis, in conjunction with standardized contracts and cloud SLAs. If a CSC requires
194 more control and customization of cloud services than is available from a standard utility service model,
195 then this may be provided at additional cost and with a specific cloud SLA.
196 ⎯ Measured service - A feature where the metered delivery of cloud services is such that usage can be
197 monitored, controlled, reported, and billed. This is an important feature needed to optimize and validate
198 the delivered cloud service. The focus of this key characteristic is that the CSC may only pay for the
199 resources that they use.
© ISO/IEC 2015 – All rights reserved 5

ISO/IEC DIS 19086-1
200 ⎯ Broad network access – The capabilities of cloud services are made available over the network and
201 are typically accessed through standard mechanisms that promote use by heterogeneous client
202 platforms (for example, access through mobile phones, laptops and workstations).
203 Details of cloud SLAs, SLOs and SQOs can vary for different cloud service categories, cloud capabilities
204 types and different cloud deployment models (see Rec ITU-T Y.3500 | ISO/IEC 17788). Cloud SLAs in this
205 standard are intended to be useful for CSCs and CSPs across the variety of cloud service categories and
206 cloud deployment models. As the definition of cloud SLOs and SQOs is intended to be technology and
207 business model neutral, so not all of these SLOs or SQOs will apply to every cloud service, and those that
208 do apply may be structured and applied in different ways to specific cloud services. For example, service
209 availability can be measured in different ways, some of which depend on the specific cloud service; a
210 computational cloud service is different than an email cloud service and service availability for each will be
211 computed differently.
212 6 Relationship between the cloud service agreement and SLAs
213 Cloud services, particularly public cloud services, generally involve an agreement between the CSC and
214 the CSP concerning the acquisition and use of the cloud services. For the purposes of this standard, the
215 legal agreement is referred to as the “Cloud Service Agreement” or CSA. The CSA has a number of
216 synonyms such as “Master Service Agreement”, "Customer Agreement", "Terms of Service" or simply
217 "Agreement".
218 A CSA comprises one or more parts recorded in one of more documents. Contents of each part can appear
219 in more than one document. There is no normative relationship between parts and documents i.e. a part
220 does not have to be in a single document, and a document does not have to contain a whole part. There is
221 neither a standard naming convention for the parts or documents of a CSA, nor a standard structure for the
222 documents or parts.
223 Examples of common parts of CSAs include
224 • Cloud Service Level Agreement (cloud SLA).
225 The cloud SLA ordinarily contains a collection of SLOs and SQOs relating to the cloud service,
226 covering aspects of the service. This might include availability, reliability, performance, security,
227 data protection, compliance and data handling.
228 • Acceptable Use Policy (AUP).
229 The acceptable use policy usually defines boundaries for the CSC's use of the cloud service. This
230 might include restrictions that prevent the CSC from installing malware on the cloud service or limit
231 the kind of data that can be stored.
232 • Security Policy.
233 The security policy typically describes responsibilities that apply to the CSC and to the CSP, SLOs
234 and SQOs which the CSP applies to the cloud service in security terms and potentially indicates
235 which security certifications or standards are met by the cloud service.
236 • Data Protection Policy
237 The data protection policy typically deals with the handling of personal data or sensitive data by the
238 cloud service, including SQOs for specific data protection measures and privacy certifications or
239 standards that apply to the service.
240 • Business Continuity Policy.
241 The business continuity policy typically deals with the resilience aspects of the cloud service and
242 can include measures that are implemented by the CSP to avoid data loss and to deal with
243 outages, such as backups and redundant components.
244 • Termination Policy.
245 The Termination Policy usually deals with the issues that arise when a CSC terminates their use of
246 one or more cloud services. The termination policy might include SQOs for areas such as
247 notifications, data reversibility and data deletion.
6 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 19086-1
248 The content of each of the parts and the number of parts in the CSA can vary between different cloud
249 services – any particular item, including the SLOs and SQOs described in this International Standard, can
250 appear in different parts for different services. As an example, security SLOs and SQOs might be described
251 in the Security Policy or they might appear in the cloud SLA. However, it is important for the CSC to know
252 the complete set of documents that govern the cloud service and the CSA must reference all applicable
253 documents.
254 7 Cloud SLA management best practices
255 7.1 General
256 Cloud SLA management covers the issues related to cloud SLA design, evaluation, negotiation and
257 acceptance, implementation and execution and changes to the cloud SLA. CSCs should ensure that cloud
258 SLAs and other governing documents align with their business cases and overall strategy. CSCs should be
259 aware that there could be several documents that govern a cloud service. See Clause 6 for more details.
260 7.2 Design
261 A cloud SLA applies to the covered services identified within the cloud SLA. A single cloud SLA may apply
262 to multiple CSCs or to a single CSC. In cases where the cloud SLA is designed jointly by the CSC and the
263 CSP, both parties should undertake the steps outlined in this clause together. A CSP should design the
264 cloud SLAs to meet the needs of their CSCs and to align with the capabilities of the covered services.
265 The cloud SLA design process should account for the appropriate roles. Rec. ITU-T Y.3502 | ISO/IEC
266 17789 should be used as a reference for determining the appropriate key roles. Key roles for the cloud SLA
267 design process discussed in Rec. ITU-T Y.3502 | ISO/IEC 17789 include:
268 ⎯ Cloud service customer, party which is in a business relationship for the purpose of using cloud
269 services
270 ⎯ Cloud service provider, party which makes cloud services available
271 ⎯ Cloud service partner, party which is engaged in support of, or auxiliary to, activities of either the CSP
272 or the CSC, or both
273 The Ref ITU-T Y.3502 | ISO/IEC 17789 standard contains concepts that can be used in the construction of
274 a cloud SLA. The choice of concepts to be included in a cloud SLA depends on the cloud service and on
275 the business context. The process to change the cloud SLA and notify CSCs of changes should be within
276 the cloud SLA or other governing document
277 The design phase should also consider the mechanisms that the CSC and the CSP can use to monitor
278 each service chacteristic and report failures to meet SLO and SQO commitments.
279 7.3 Evaluation and acceptance
280 CSCs can use this standard as a reference when evaluating cloud SLAs. CSCs can review all of the
281 concepts and determine which are critical to their business objectives. CSCs can then consider the CSP’s
282 SLAs (and remedies) in evaluating whether the CSP’s services meet the CSC’s business objectives.
283 CSCs can review cloud SLAs in the context of their organization’s business policies and other requirements,
284 and can identify which SLOs, SQOs and service features are important for each of their use cases.
285 Standards such as the ISO/IEC 20000 series and the ISO/IEC 27000 series may be referenced in cloud
286 SLAs or other documentation. In some cases, CSPs certify their conformance with specific industry
287 standards. CSCs can determine what standards are important to their business objectives or are desirable
288 for their organization’s governance and determine whether a cloud service is certified to conform with that
289 standard, or if it is referenced in the cloud SLA or other documentation. CSCs can determine how they
© ISO/IEC 2015 – All rights reserved 7

ISO/IEC DIS 19086-1
290 monitor cloud service characteristics and report failures to meet SLO and SQO commitments by
291 familiarizing themselves with a CSP’s failure notification policy, if available. Methods for monitoring and
292 reporting include management systems, web portals, email, text messages, telephone and posts to social
293 media sites.
294 Acceptance of a cloud SLA may occur by clicking a check box on a web page, by registering for the cloud
295 service, or by a formal signing of the agreement by both parties. Each party should ensure they are ready
296 to undertake the implementation and execution of the cloud SLA, independent of the means of acceptance.
297 In the case of an agreement with unique terms, both parties should ensure they are prepared to support
298 implementation and execution of those terms.
299 7.4 Implementation and execution
300 Implementing a cloud SLA involves setting up processes for monitoring and managing cloud service
301 characteristics, reporting any failures to meet SLOs and SQOs, and claiming any remedies. In some cases
302 the CSP may need to collaborate with the CSC when implementing the cloud SLA. CSCs should also
303 include the cloud SLA in their internal governance. The choice of concepts to be included in cloud SLA
304 monitoring and auditing processes depends on the cloud service and the business context.
305 Execution of the cloud SLA involves the provision and operation of the cloud service by the CSP, including
306 the management and monitoring of service levels. If a CSC believes a SLO or SQO has not been met, the
307 CSC may follow the failure notification policy.
308 7.5 Changes to the cloud SLA
309 Change is an inevitable part of any ICT system, and cloud SLAs are no exception. The CSP can include a
310 process to make changes to the cloud SLA and provide notifications to CSCs, and can include mechanisms
311 that allow the CSCs to request changes to the cloud SLA. In the evaluation and acceptance phase CSCs
312 can evaluate the cloud SLA change and notification processes.
313 When making changes to cloud SLAs, CSPs can consider the evolving requirements of their CSCs and
314 CSCs can determine whether the changes meet their business objectives.  The CSCs can evaluate the
315 cloud SLA changes and notification processes in the evaluation and acceptance phase. Simultaneously,
316 there should be a process to allow the CSCs to request changes to the cloud SLA.
317 8 The role of cloud service level objectives, cloud service qualitative objectives,
318 metrics, remedies, and exceptions in the SLA
319 8.1 General
320 It is essential to be able to monitor the cloud service to ensure that the SLOs and SQOs in the cloud SLA
321 are being met. It is important to have remedies described within the cloud SLA or a related document in the
322 event that an objective is not met. Finally there might be events or incidents that are declared as exceptions.
323 In those cases even though an SLO or SQO is not met, the related remedy is not triggered.
324 8.2 Metrics
325 The definition and usage of appropriate metrics and their underlying measures and measurements is an
326 essential aspect of the cloud SLA. The metrics are used to set the boundaries and margins of error the
327 CSP abides by and their limitations. These metrics may be used at runtime for service monitoring or
328 remediation.
329 Cloud service metrics address the following needs (list non-exhaustive):
330 ⎯ Determine if SLOs are met
8 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 19086-1
331 ⎯ Categorize service capabilities
332 ⎯ Define a purpose for measures and measurements
333 ⎯ Deliver a consistent representation of measure and measurement information
334 ⎯ Link properties, measurements and metrics
335 ⎯ Enable comparison of monitoring between services
336 ⎯ Determine cloud service effectiveness for business objectives
337 Cloud service metrics need to be used in the context of the cloud SLA and a given cloud service. Metrics
338 help define the cloud service properties to be measured. The metric can be defined in terms of its related
339 measures, measurements, relevant parameters, calculating formulas, as well as measure and
340 measurement rules. The metrics can be used to determine whether a measurement of a cloud service
341 property at a specific point is within stated boundaries of the property. Using a standard set of metrics in the
342 cloud SLA makes it easier and faster to define cloud SLAs and SLOs, and to compare one cloud SLA to
343 another.
344 Without proper metrics it is difficult or impossible to enforce a cloud SLA.
345 8.3 Service levels
346 Service levels are measurement results for specific attributes of the cloud service and may change while
347 the service is operating. Service levels are expressed using metrics that may be based on a single measure
348 or may be calculated using several different measures.
349 Service levels are reported against one or more SLOs (which ordinarily are fixed during service use) and
350 they are often described in the context of the service covered. For example, a “service availability” service
351 level for compute services might be reported against a SLO of “uptime” where uptime would be described in
352 the context of compute as instances being accessible and usable upon demand by an authorized entity,
353 while a “service availability” SLO for storage services might be reported against a SLO of “uptime”
354 described in the context of requests for the stored object returning errors. Specific SLOs, and remedies, are
355 context driven and are clearly defined in the cloud SLA.
356 Cloud SLOs and cloud SLA content can vary for different cloud deployment models and different cloud
357 service categories.
358 8.3.1 Cloud service level objectives
359 SLOs are commitments a CSP makes for specific, quantitative characteristics of a cloud service. Each
360 service level ordinarily has a target commitment that the CSP agrees to meet, typically either a single
361 boundary value or a range of values. For example, for a “service availability” service level, the SLO might
362 be “uptime” and the target might be expressed as a percentage (of uptime to total time) which is a lower
363 bound for the service level, or the SLO might be “downtime” and the target might be a percentage or an
364 amount of time over a time interval which is an upper bound for the service level.
365 The CSP may offer a range of SLOs and associated remedies.
366 8.3.2 Cloud service qualitative objectives
367 SQOs are commitments a CSP makes for specific, qualitative characteristics of a cloud service, where the
368 value follows the nominal or ordinal scale. The ordinal scale allows for cases where the characteristic either
369 exists or does not exist (e.g. “true or false”).
370 SQO observations require human interpretation and cannot be manipulated algebraically. For example,
371 “security certification” could be an SQO and a related assurance could be “[CSP] will maintain a current
© ISO/IEC 2015 – All rights reserved 9

ISO/IEC DIS 19086-1
372 certification for ISO/IEC 27001.” Verification of such an assurance could be the availability of a scanned
373 copy of the certificate. Verification of the performance on an assurance related to an SQO may take many
374 forms including the process of legal discovery.
375 8.4 Remedies
376 Remedies may be provided by the CSP to the CSC in the event the cloud service fails to meet the SLOs or
377 SQOs defined in the cloud SLA. Remedies for failure to achieve SLOs or SQOs stated in the cloud SLA
378 may take different forms such as refunds on charges, free services, or other forms of compensation.
379 8.4.1 Claims process
380 The claims process describes the process for a CSC to claim a remedy if a SLO or SQO is not met. It may
381 be up to the CSC to determine when the cloud service has failed to meet its SLOs or SQOs and report
382 claims to the CSP, while in other cases the CSP will monitor the service levels
...