Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
Cloud SLAs: What Everyone Should Know
13 questions to ask your service providers to better understand their service offerings and your risks.
3 Min Read
When you sign up with a cloud provider for computing, storage, or application functionality, you should get a service level agreement that describes what the provider promises to deliver. An SLA should be fully transparent to customers and published on the provider’s website for prospective customers to review.
Unfortunately, SLAs are often difficult to find and can be even more difficult to decipher. SLAs are not really there to protect you, the customer. While they may provide some customer protection as a byproduct, they are really a marketing tool and a method to limit service provider responsibility in the event of an outage. This should not be viewed as negative. Every cloud provider I have worked for, talked to, and evaluated wants to provide their customers with 100% uptime and great service. But the complexity of software, infrastructure, humans, and reliance on third-party technologies and infrastructures makes 100% attainment near impossible.
I believe in the benefits, security, and financial opportunities that cloud services provide, but there are also risks that you should fully understand. In my last blog, I wrote about data disclosure and what you needed to ask your providers. This article is focused on service level agreements and what general questions to ask your providers to better understand their service offerings and your risks. Here are some practical questions to ask:
Do you publish SLAs, and how are these documents accessed?
If you do not publish SLAs, do you publish service level objectives (SLOs)?
How do your SLA targets differ from your competitors? You may be surprised that SLAs do no vary that much.
Why were your SLA targets chosen? Targets are often defined competitively or based on the best or worst capability of the underlying products.
How often have you violated your SLAs in the last three months, six months, 12 months?
Do you publish your SLA results openly? How frequently?
Which SLA metrics do you fail at most often, even if it has no impact on your customers?
How often do you increase or decrease your SLA targets, and what has the trend been? Any reduction or removal of a target may mean scalability challenges.
What SLA metrics have been removed in the last 12 months?
How often do you test your own SLAs? You really want to hear that the metrics are continuously tested.
How are SLA claims validated? How am I compensated for an SLA violation? Your provider should be doing the work here, not requiring you to prove a failure.
Do I receive detailed incident response information? This is necessary to fully inform your organization or customers of the problem and the solution. Never waste a failure; make sure your provider is identifying the root cause and resolving it.
Do you use any third parties to monitor your SLAs? This can provide additional validation of the seriousness of SLA measurement.
One final word on compensation for SLA violations: I believe that neither the customer nor the provider wants to focus on compensation. The customer wants the level of service they contracted for, not a lower level of service with some credits. The provider wants to deliver the contracted service, not disappoint and pay their customers. Compensation is currently seen as a stick to hold providers accountable, but it may be having the opposite effect and inadvertently causing providers to limit or withhold their SLAs. Having clear, accessible, and realistic SLAs published by the service provider and reviewed by the customer helps to reduce the focus on compensation.
In my next blog, I will explore questions to ask your provider about specific SLA measures.
About the Author
You May Also Like
More Insights
Webinars
_KonstantinNechaev-Alamy.jpg?width=700&auto=webp&quality=80&disable=upscale)
