The Service Level Agreement – Understanding a Critical Document
When companies migrate their business processes to the cloud, CEOs need to be reassured that a minimum acceptable level of service will be provided and that legal safeguards will accompany this. Only when a vendor offers guarantees instead of disclaimers will any prudent CEO agree to move away from the certainty of on-premise IT.
All competent cloud services providers understand that a well-written Service Level Agreement (SLA) is a document that instills confidence in the corporate user and is instrumental in getting more customers. There are also nuances to the SLA that must be understood by users if they are to get the best out of their solutions.
In a number of cases, vendors specify an uptime of 99.5% or more for your service. They also say that to get to this level, you need to hire the service so as to operate from two different geographic locations. Obviously, if you do not hire the service correctly, you will not obtain the guaranteed up-time. This is a typical area of the SLA which needs to be better understood.
There are several issues in cloud SLAs that are different from other service level agreements due to the very nature of the cloud itself, and these factors need to be understood well and carefully handled. Some of these issues are discussed below.
Who owns the Metadata?
The first of these relates to the ownership of data. If you were simply hiring storage space in the cloud, things would be straightforward. Whatever data you store is yours. But if you are hiring Software as a Service, things can get more complex. The business-related data that the software generates is obviously yours, but what about other data that the software creates – the data related to usage trends, failed login attempts, metadata, user feedback, preferences, complaints and traffic statistics? Do these belong to the client hiring the software, or the company hosting the software? You will need to understand these issues and the criticality of these to your business before drafting the SLA.
What happens if the government wants to see your data?
Your service level agreement must define what will happen in case a government agency makes a request for your data. While the service provider may be legally bound to comply with the government request, your SLA must clarify that your company will be informed before any data is actually handed over. This is, of course, so that you have the opportunity to contest the demand or seek legal counsel. On the other hand, there are legal requirements for archiving and maintaining your data, especially for financial or medical data. The service provider must be told this specifically through the SLA so that he or she becomes duty bound to protect the data. Also make it clear that in case there is a failure to meet these obligations, what would be the extent of legal penalties etc for which the service provider would be liable?
Well-Defined Metrics
The SLA must also describe in detail how the level of service and the uptime that the vendor is providing will be measured. How will service requests be handled, and in what timeframe? What would the penalties be for not meeting them?
Data Security
Other important issues that the SLA must address in detail are levels of data security and segregation that the vendor will provide, and what will constitute a security breach. While it may seem unnecessary to define what a breach would be, it is important to do so because at times there could be an incident that does not result in a loss of data or business but is nevertheless important. The SLA must specify that every breach or incident affecting your company or its data is reported to you along with the remedial action taken. You must also ensure that the provider gives you advance warning of any maintenance being carried out that may slow down your service. It is also critical to define in case of a disaster – natural or man-made – what the service provider’s role will be in supporting your business continuity.
Termination
In the event of termination of the relationship, what assistance will the vendor provide in case you want to migrate your applications to another vendor or bring them back in-house? Can the vendor outsource your work to another cloud provider? If so, what terms of the SLA would apply to the new vendor? These must all be clarified in the SLA.
Is all of this possible?
Will you be able to meet all these terms and more when you set out to move to the cloud? If you are a small company without much leverage, the chances are you will not. You may not even get to meet any of the staff of the cloud company since all activities may be completed on-line with a standard SLA. However, these are issues that you must think about. Obviously, if you are a large company giving big business to the vendor, you will have more leverage, but whether you are big or small, the importance of understanding the SLA clearly cannot be overstated.
GMO Cloud ensures its clear-cut provisions on Terms of Use and the SLA, to give you a better idea, you may download the Terms of Service provided by GMO Cloud America.
Be Part of Our Cloud Conversation
Our articles are written to provide you with tools and information to meet your IT and cloud solution needs. Join us on Facebook and Twitter.
About the Guest Author:
Sanjay Srivastava has been highly active in computing infrastructure for several years, participating in major projects on cloud computing, networking, VoIP and in creation of applications running over distributed databases. His military background has influenced his focus on stability and availability of infrastructure. Sanjay was the Director of Information Technology in a major enterprise and managed the transition from legacy software to fully networked operations using private cloud infrastructure. He now writes extensively on cloud computing and networking and is about to move to his farm in Central India where he plans to use cloud computing and modern technology to improve the lives of the local rural population.
