The DRaaS Alphabet Soup: From SLA to RTO and RPO

You’ve decided to pursue a Disaster Recovery as a Service (DRaaS)  solution for your organization. The c-suite is on board. You’ve received preliminary budget approval, outlined your requirements, conducted research, and narrowed down the field of prospective providers. All that’s left to do is make your final choice of cloud service provider (CSP) and sign the contract, right?

Not so fast. No matter how much “due diligence” you’ve done, there are still some very essential considerations. The IT industry is full of acronyms, and the considerations for DRaaS solutions include a few of them, starting with the service level agreement or SLA.

It’s not enough that a DRaaS solution is backed by a SLA — even if a prospective CSP boasts that it’s “industry-leading” or employs some other superlative. The SLA will do you no good if it doesn’t clearly address your specific requirements.

All DRaaS SLAs should include definitions of what their promised recovery point objectives (RPO) and recovery time objectives (RTO) are. RPO refers to the point in time in the past to which you will recover. Recovery Time Objective RTO refers to the point in time in the future at which you will be up and running again.

Just as all DRaaS solutions are not alike, you can expect a great deal of variation in the SLAs provided for them — starting with the definition. Some service providers consider an SLA to define the service they will deliver. For others, it defines the service promised and includes the provision of a service credit if that promise is broken. It’s important to note that not all services are backed by a credit remedy.

Here are a few other general things to keep in mind regarding SLAs and contract issues for DRaaS offerings:

• A comprehensive review. To ensure an SLA and the contract with the service provider fully meets your organization’s needs, include relevant stakeholders from your business in the review process. An attorney that specializes in information technology-specific SLAs and contracts is also a “must have”.
• Data storage location. The CSP should disclose where it will store your data. Some CSPs work with other providers to ensure elasticity, but doing so could open the door for noncompliance or a privacy breach.
• Proven restoration time. The SLA should cover the expected recovery time – RTO – should a disaster occur. This is especially important as it guarantees when your organization will have access to mission-critical systems following a downtime incident. US Signal guarantees restoration time in its SLA , and provides for a service credit in the unlikely event that it fails to meet the specified time. Make sure any CSP you choose to work with regularly conducts scheduled and unscheduled DR tests to demonstrate its DRaaS solution can be executed as promised.
• Failure to meet the SLA. The SLA should spell out what happens if the CSP can’t meet the requirements stated in it. Typically, this means the issuance of service credits.  Including this clause will provide you with an extra level of protection — and additional motivation for the CSP to follow through on its promises.  As noted above, US Signal does include this in its SLA for restoration time.
• Infrastructure availability. Without continuously available infrastructure, data replication and recovery are impossible. This should be covered under SLA for the cloud service to which data is being replicated. In the case of US Signal, the replication target would be US Signal’s Hosted Private Cloud or Resource Pools .
• Recovery point objective (RPO). Make sure the CSP properly maintains the necessary replication technology at the production and DR sites to ensure it can meet your RPO.
• Response time. Every second counts. You’ll want the CSP to specify the level of responsiveness you’ll get if a downtime incident occurs.  This is especially important if your IT team is not able to complete the recovery process on its own. This isn’t necessarily something that will be included in an SLA, it is information you’ll need.
• Security. The SLA should address how the CSP will minimize data leakage and theft. Many DRaaS SLAs include encryption keys and certifications to prevent security breaches and unauthorized data access. In the case of a security, compliance or privacy breach, the SLA promises prompt notification – and the ability to respond quickly and efficiently.
• Flexibility. Review the SLA frequently to make sure it accommodates your organization’s changing needs in terms of strategic, operational, and technical requirements. It’s up to you to make sure your CSP is aware of your changing needs and can make the necessary adjustments to accommodate them. For a DRaaS solution to be successful and robust, transparency between both parties is key.

Of course, there are several other things to consider when evaluating a DRaaS solution. Many of them will come up when you involve the various stakeholders in your organization in the process. However, if you’d like more information on evaluating DR solutions and the associated SLAs, US Signal’s solution engineers are available to help. Just call us at 866.2. SIGNAL or email [email protected] .