Many managed service providers (MSPs) are starting to find the value in offering backup as a service. After all, MSPs are responsible for providing and managing IT services to their customers, why shouldn’t backup be part of the equation?
Yet when talking to prospects about managing backup and storing critical data, MSPs are finding that those potential clients are full of questions, as well as doubts. The questions range from where is my data stored to how is it actually backed up to how quickly can it be available if retrieval is needed. Naturally, any MSP worth its salt can quickly answer those questions and provide assurances to those prospective customers; however, the answers and assurances only count when they are committed to paper.
In other words, MSPs (and their customers) can only properly protect themselves by drawing up a service-level agreement (SLA), which defines what is expected. While SLAs are relatively common, data backup and restoration services introduce some new concepts into the legalese of an SLA. Simply put, MSPs need to approach drafting an SLA with caution, making sure they are not creating unreasonable expectations and also preventing any potential litigation created by perceived liabilities.
Best Practices for a Backup Service SLA
Designing an SLA to meet a customer’s backup needs should not be an overly complex process. However, MSPs must take care with the language used, as well as make sure expected deliverables are reasonable. With that in mind, a backup service SLA should include:
What is to be backed up?
The applications and the associated data that should be backed up must be well-defined. Customers should identify their line of business applications and the associated data that must be backed up and also agree to pertinent timelines for backup activities, the size of the data set, the frequency of the backup, and what, if any, archives are to be included. For some businesses, every transaction must be replicated to preserve data integrity, while others may need a backup to happen only after some type of processing, such as a payroll run or an accounts payable processing event. MSPs should make sure the SLA addresses critical systems, while also insulating themselves from “unknown” or shadow IT systems.
How is the data verified?
The SLA should include reasonable language stating that backup data is verified, to make sure the data has not become corrupted by the backup process. MSPs need to establish that they are protecting a customer’s data from corruption and are indeed backing up useful information.
How is the data secured?
MSPs should spell out what security practices are in place to protect customer data from theft. That includes what types of encryption is used, where the data is physically stored, how access to the data is controlled, and how retired data is disposed of.
Defining the restore process.
Every customer would like to think that data can be restored instantaneously. However, that very much remains an unrealizable fantasy. MSPs need to define the expectations around data restoration. In other words, critical systems should be identified, priorities determined, and schedules defined. That way real-world expectations can be aligned with what is actually possible when it comes to restoring data.
Illustrate change management.
IT systems rarely remain static, new applications are brought online all the time, while others are retired. MSPs should make sure that the SLA can act as a living document, allowing for change, if change is detected. Far too often, enterprises make changes to IT, and fail to notify service providers, who are then expected to recover those changed systems in the event of a failure. Include language that defines what change is, how it can impact backups, and how it should be addressed.
Backup and restoration should be tested on a regular basis, and the testing requirements should be included in the SLA. The only way to ensure that a backup has value is to test its viability before a disaster occurs.
MSPs should not take the requirements around backup as a service lightly and should use the necessary legal tools to protect themselves from undue liabilities, while also defining what customers should expect. When done properly, an SLA protects both the MSP and its clients.