Cloud-based networks are becoming increasingly important to businesses of all sizes and, as a result, there is a growing demand for MSPs to act in support of or in place of an in-house IT support team. But with cloud compliance policy still in its infancy and the power of sales and marketing to influence procurement, the critical issue of the Service Level Agreement (SLA) is regularly relegated to an afterthought. This is a mistake; making sure that an SLA is adequate to protect a business’s service in the event of both minor and major mishaps needs to take a central place in MSP negotiations as this article explains:
Three Big Reasons to Value your Service Level Agreement (SLA)
The most important reason to value your SLA is because without it, the security and stability of your entire IT function is seriously undermined. As with every legally-binding document, the SLA between your business and your MSP protects both sides from misunderstanding and – in rare cases outright deception.
Second, SLAs are almost certainly going to become an issue of compliance as the industry evolves with businesses required to demonstrate more clearly that their clients’ data is in the hands of reputable third parties. It makes sense to get ahead of the game now rather than face the disruption of changing provider or rewriting contracts when the compliance environment toughens up. To help provide an idea of what a good SLA looks like, in the summer of 2016, the Cloud Standards Customer Council published version 2.0 of their public cloud SLA document which can be found at: http://www.cloud-council.org/press-release/07-20-16.htm
Another big reason to focus on creating a robust SLA is that, for the same reasons given above, you can use it as a powerful sales tool. By detailing the lengths you have gone to to keep data safe and systems reliable, you are helping clients to feel safe and secure in your hands. The cloud is still an uncomfortably nebulous concept for many people and the protection provided by legal contracts can ease their fears.
Breaking down an SLA
Your MSP is duty-bound to manage, maintain and monitor your IT services but that can mean a hundred different things to a hundred different providers and their clients unless codified into a legally binding contract. You hopefully wouldn’t wait until your cell-phone was stolen before checking whether your contents insurance covered items taken outside the home. In that case, why would you wait until your email server was hacked before checking your SLA to see whether you or your MSP has responsibility for dealing with it?
When going through your SLA, here are the main areas you need to be clear on:
his element of your SLA can be more difficult to pin down than it seems. Many businesses are happy to be told that their MSP will guarantee 99% up time but that doesn’t say anything about latency and data accessibility. Larger MSPs (read Amazon) will often compartmentalize their service, guaranteeing the performance of some components but not others. Even in terms of raw up time you will probably find that your MSP stops short – sometimes well short – of a blanket guarantee. For example, they might stipulate, ‘except for circumstances out of our control,’ which could excuse them from any responsibility for downtime due to a DDoS attack, for example.
Of course, no MSP would want to take complete responsibility for the health of an enterprise IT network. For example, problems caused by wilful destruction or negligent security procedures, or very minor IT issues (a paper jam in a local printer) should quite rightly be omitted from the service. The important consideration is that all inclusions and omissions are detailed in the SLA.
Another critical area of performance management covers the MSP’s response to issues both in terms of initial response time and also resolution time – how long it takes them to actually fix the issue. Clarity regarding the MSPs support tier and escalation process will help service users to access the appropriate level of support when needed.
There will be some situations which are beyond solution (e.g. if the data center holding a client’s mail server is burnt down!) so there needs to be a definition of what counts as serviceable and a disaster recovery plan for such worst case scenarios.
A system can be functioning efficiently and reliably 24/7/365 yet still be leaking data like a sieve. Your MSP needs to work with you to determine the full extent of your existing environment, stipulate the minimum security requirements that need to be in place from your employees (e.g. no more 12345 as passwords!) and then, depending on the services they are supplying, detail the encryption protocols they will be using during data transmission and the data storage protection measures in place on their servers and repositories.
Even the best MSP will take their eye off the ball sometimes and there needs to be a clear, unambiguous remedial process laid out in your SLA. This is often in the form of an account credit tied to the scale of the service failure (e.g. 5 per cent credit per hour over resolution time). An exit strategy is also wise to help a business and MSP separate amicably without recourse to a lawyer if one or the other consistently fails to deliver on the agreement.
A Special Note on Data
Just like its nebulous namesake, the IT cloud can expand and drift to span counties and states and cross oceans. But while the cloud may not respect boundaries, the consumer watchdogs responsible for enforcing data security compliance most certainly do. Into almost every piece of privacy documentation is written a clause that demands that data only be passed to third parties originating in countries which operate under the same data protection protocols as that in which the business responsible for client data security operates.
Issues regarding data compromise are increasingly involving the biggest companies and regularly make the news. Losing customer data is not only expensive in terms of legal compensation but can ruin a brand overnight. Therefore, if there’s one part of your SLA that you simply can’t afford to leave to chance then it’s data security and protection policy both in terms of stored data and data transmission.
SLA Good Practise
Once your SLA is in place, it is important not to just sit back and forget it. It is good practise to schedule regular reviews (perhaps quarterly) whereby both parties can evaluate the agreement and, if necessary adjust it to suit evolving expectations.
It is also good practise to involve in-house IT specialists in drawing up the SLA. These employees can often spot potential areas of conflict which might be missed by senior management personnel.
Above all, every SLA should be written in plain language, without ambiguities and be realistic. This will help to build a productive and long-term relationship between a business and their chosen MSP.
Brent Whitfield is CEO of DCG Technical Solutions Inc. DCG specialize in providing the high quality and experienced IT Consulting Los Angeles businesses need and deserve. Brent has been featured in Fast Company, CNBC, Network Computing, Reuters, and Yahoo Business. https://www.dcgla.com was recognized among the Top 10 Fastest Growing MSPs in North America by MSP mentor. Twitter @DCGCloud