13 questions to ask your service providers to better understand their service offerings and your risks.

Jamie Tischart, CTO, Cloud & SaaS Technologies, Intel Security

May 18, 2016

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:

  1. Do you publish SLAs, and how are these documents accessed?

  2. If you do not publish SLAs, do you publish service level objectives (SLOs)?

  3. How do your SLA targets differ from your competitors? You may be surprised that SLAs do no vary that much.

  4. Why were your SLA targets chosen? Targets are often defined competitively or based on the best or worst capability of the underlying products.

  5. How often have you violated your SLAs in the last three months, six months, 12 months?

  6. Do you publish your SLA results openly? How frequently?

  7. Which SLA metrics do you fail at most often, even if it has no impact on your customers?

  8. 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.

  9. What SLA metrics have been removed in the last 12 months?

  10. How often do you test your own SLAs? You really want to hear that the metrics are continuously tested.

  11. 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.

  12. 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.

  13. 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(s)

Jamie Tischart

CTO, Cloud & SaaS Technologies, Intel Security

Jamie Tischart is the CTO for Cloud/SaaS (Security as a Service) and is responsible for leading the creation of Intel Security's future generation cloud solutions and creating sustainable competitive advantage. He has been with Intel Security for more than 10 years in a wide variety of technical roles, including senior director of cloud engineering, operations, and research; and senior director McAfee Labs, quality engineering and operations.

 

Prior to joining then McAfee, Tischart held several executive, QA architect, management, and engineering positions at such companies as MX Logic, Blackbaud, Openwave, Newbridge Networks, and Corel.

 

Tischart holds an MBA from Aspen University. He lives with his family in Colorado where he pursues his passions for SaaS development, DevOps, and cloud operations along with agile coaching and quality engineering leadership. He also enjoys skiing, writing, and hockey.

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.

You May Also Like


More Insights