What 2016 Has In Store for Cloud Service Level Agreements

Whether you’re a stickler for standards or not, the U.S. federal cloud computing market is better off because of them. Thanks to the Federal Risk and Authorization Management Program (FedRAMP), there are now baseline requirements for securing cloud products and services in use governmentwide.

But the work doesn’t end after an agency finds a FedRAMP-compliant vendor. One of the struggles governments at all levels face is articulating the level of service they expect from their cloud providers and, in turn, understanding the limitations of what can and cannot be provided.

Part of the problem is that service-level agreements (SLAs) vary widely across cloud providers, and sometimes different divisions within the same company offer the government very different SLAs, said John Messina, a Computer Scientist at NIST. “The customers really couldn’t compare the cloud services,” Messina said. “Even if the cloud services were identical, the underlying SLAs couldn’t be compared.”

Customers were frustrated, uncertain and less inclined to move to cloud services because they did not fully understand the risks.

“Agencies who have not done much in cloud computing, they don’t even know what questions to ask or what components should be in the contract, based on their particular business needs,” Messina said. He expects that cloud adoption will accelerate as agencies gain a better understanding of what services cloud providers will and will not offer.

What agencies need is guidance. And it’s coming in the form of a new international standard that 29 countries are developing. Messina is part of the U.S. group working on the standard. The group’s name is a mouthful — ISO/IEC JTC 1/SC 38 — and includes representation from most of the major players in the cloud space.

The standard will include multiple parts. The first part, which will provide an overview for using common vocabulary and terminology in SLAs, will be completed in early 2016. Two other sections are slated for completion around the fall of 2016, and they will help agencies identify the major metrics and requirements that are used in SLAs. But the sections are not prescriptive.

Although the draft standard prompts agencies to address termination of service requirements and service reliability in their contracts, the standard won’t specify whether agencies should request 99.9999 percent availability of their cloud service vs. 99.99 percent. These specifics will vary based on individual agencies’ requirements, and remember, costs usually increase as the level of service does.

What the standard will give customers and agencies is a checklist of the major concepts that could appear within their SLAs, Messina said. “At the very least, each customer and provider should then go through this list of components and have a frank discussion on whether it makes sense for any specific contract.”

The United States, China, Australia and the United Kingdom are among the 29 countries collaborating to develop an international SLA standard. Eight more observing countries are interested in the end result. (You can view a map of the participating countries here)

If you can’t wait until 2016 to see what’s included in the SLA standard, we have a sneak peek for you. The standard is currently in draft form, but here is some terminology that is likely to appear in the final version. These key terms are common in cloud SLAs, and they deal with business agreements:

Covered Services Component identifies the cloud services the SLA covers. Roles and Responsibilities: A description of the roles and responsibilities for the stakeholders (typically cloud provider and customer).

Availability is the property of being accessible and usable on demand. (This is where the provider would make a promise of amount or percentage of time in a given period that the cloud service is accessible or usable.)

Protection of Personally Identifiable Information is where the provider would make assurances relating to the protections of personally identifiable information. Several examples include the time periods for erasing temporary files, the length of time data logs are kept and the time period notification for data breaches.

Termination of Service deals with the orderly exit process when the use of the cloud service is terminated. (Elements would include notification of service termination, acceptable methods of returning assets and the length of time the vendor retains data at the end of service.)

Service Reliability is the overall process by which reliability is considered typically consists of three parts: service resilience, customer data backup/restore and disaster recovery. (Elements include specific allowable number of service failures in a given time period, time it takes for services to recover, backup methods, period of time between backups, number of backup generations stored, etc.)