Exit Plans Should be Part of Cloud SLAs
Federal policy dictates “cloud first” thinking. Your chief information officer is telling you to move faster, but you’re holding back because the details are daunting. There’s security of course, and layers of it. But there’s also a lot of legal contractual terminology.
As federal investment in cloud computing skyrockets — a new report from market analyst Govini pegs growth at 24.8 percent and the overall market at $3.3 billion in 2015 – systems managers focus on getting their systems safely into cloud solutions. Service level agreements (SLAs) lay out in extensive detail infrastructure availability, applications uptime requirements, assured access to data and required response times for remediating vulnerabilities and responding to security incidents.
They should also worry about their exit strategy – exactly what it will cost in time and treasure to change providers should today’s cloud bargain turns into tomorrow’s money pit.
Termination is “one of the biggest problems with SLAs that tends to come up,” says John Messina, senior computer scientist at the National Institute of Standards and Technology (NIST). “What happens when you’re done with your cloud service? That’s an element that’s not typically included in the SLA, but it should be.”
Yet vendors have little incentive to make that process easy or cheap. SLAs often fail to address the issue in detail.
“Most of the SLAs that I’ve seen say, ‘The cloud service provider will work with the customer to get the data out,’” Messina says. “But how? That is a very big problem facing a lot of people down the road.”
For example, one leading cloud service provider’s standard agreement states only “we will provide you with the same post-termination data retrieval assistance that we generally make available to all customers.” Exactly what that assistance is, however, is not specified.
SLAs are written by lawyers to protect the interest of the vendor. First-time buyers may see those contracts as take-it-or-leave-it propositions and walk away. More experienced buyers will counter with their own terms and conditions. Some vendors negotiate, but others do not.
Messina has helped lead NIST’s effort to establish international standards for cloud SLAs. Rather than create a NIST standard with U.S. reach, the group sought out international partners and participation through the International Standards Organization (ISO). The standards will be broken down into three parts:
- ISO 19086-1: SLA overview and concepts.
- ISO 19086-2: SLA metrics
- ISO 19086-3: SLA conformance requirements
Messina describes the approach as flexible, using “building blocks” designed to give customers and providers, common terms and definitions and to allow for the emergence of new technologies and solutions over time.
Specific termination or portability standards will not be spelled out, Messina says. But the standards will specify the issues vendors and customers could face and advise both parties to negotiate terms answering questions like:
- How long will agency data remain on the commercial vendor’s system once the contract is over?
- What mechanisms are in place to extract the data from the cloud service provider?
- What assurances the vendor can provide that data will be erased once it is transferred to a new location?
“That’s the conversation you need to have with the provider,” Messina says. “You need to know that down the road, when you’re done, how are you going to get your data and your services back out? It’s not clear. It’s not particularly easy.”
SLAs that can be highly detailed in many areas often gloss over this part, he said, leaving both sides in the dark when and if a move becomes necessary.
Contract officers and their technical advisors need to be on the ball before the SLAs are finalized and the contract is signed. “It’s essential that agencies think about these challenges before entering into agreements. But that’s not something that’s universally understood or that will necessarily be the same from one situation to the next, Messina says.
Consider a cloud storage contract, for example. A customer might have petabytes of information stored with a cloud vendor. But when that contract ends, the customer is unlikely to have the storage on-site to take that data back in house. More likely, the agency customer will want to move its data from one commercial cloud vendor to another. That requires either that the two vendors can establish a safe means for the exchange or that a third party must be hired to act as middleman.
The new cloud SLAs now in development doesn’t go so far as to prescribe a solution, Messina says, but it does help. “The SLA contract is designed to make them have that conversation.”
Messina expects the new cloud SLA standards to be published later this year and next and to be in wide international use within three years. By then, it will be time to add additional details related to data mobility, portability and interoperability in the cloud. His group has already started work on that, he said.