SLA: What they are and why you need them

The late singer-songwriter Jim Croce gave us sage advice about life: “You don't step on Superman's Cape. You don't spit into the wind. You don't take the mask off the old Lone Ranger and you don't mess around with Jim.” The same can be said for something much more mundane: signing a contract with a cloud service provider. You don't assume your provider is a superman that can overcome every potential breach or vulnerability. You don't tempt fate with poor computing hygiene. You don't challenge hackers to defeat your security because they will. And you still don't mess around with Jim. (Who is this Jim, anyway?) When all is said and done, a successful cloud deployment comes down to reducing potential vulnerabilities using strong authentication, encryption and other security practices to limit your attack surfaces to potential hackers;  you put policies and procedures in place, along with strong audit controls to limit potential vulnerabilities; and you sign a service-level agreement (SLA) with your provider that outlines clearly your performance and service expectations, the provider's responsibilities in case there is a performance disruption, and exactly when and how system issues and interruptions will be handled. For many companies, it is the SLA that spells the difference between smooth operations and confusion along with unanticipated expenses with the service provider. For example, let us assume the provider will be handling trouble tickets associated with the cloud service. When a ticket is generated, when and how does the client have the ability to escalate the ticket to a higher priority? Who determines how important the trouble is and what steps need to be taken to solve the issue? What are the potential associated costs to the client if they choose to escalate a ticket that the service provider has identified as a low-priority issue? Without spelling out each potential issue in detail, it is possible that a misunderstood definition such as “mission-critical” could lead to serious problems between the provider and the client. Often non-technical personnel associate an SLA as simply related to how fast the connection is and how much uptime is promised, but SLAs can cover a lot more.  Let's say a service provider is responsible for installing software patches. Who pays for the associated software tools that might be needed to install the patches? Who actually owns the tools and licenses if the relationship ends? How will the transfers of licenses take place? Again, the greater the clarity in the contract the fewer disputes later on. SLAs are as much about operations as they are about performance. How things are done is often as important, and potentially more important, than when things are done. For example, let's say your service provider is keeping backups of your data. The SLA should state the format and time-frame in which a company's data will be returned to it. Without spelling out such details in the SLA, the data potentially could be turned over in an incompatible format. If the agreement says the data will be turned over “after” an event occurs but does not state how soon afterwards, that confusion could impact negatively a company's business operations and continuity. SLAs are hardly new or unusual. Companies that hire third-party vendors generally have some kind of agreement that covers who does what, when, why and how. Even internal support groups generally have some type of SLA with its users — the departments that depend on it for support.  Educause review, a publication that serves the higher education market segment, explained in detail why it is necessary for schools to have SLAs with their service vendors in the aptly named 2010 article “If it's in the Cloud, Get It on Paper: Cloud Computing Contract Issues.” The article, while dated, lays out well the basics of what non-technical staffers or executives who deal with service providers should know about what SLAs are and what should be included, along with some samples that describe how they work. If you have an SLA with your cloud vendor but don't know what's in the agreement, you might want to take some time to sit down with your general counsel to discuss the particulars of the agreement. The better both sides understand the details, the fewer challenges they both will face should an emergency occur.