8 DRaaS risks to identify and remediate

The use of disaster recovery as a service presents an array of opportunities for IT operations personnel to protect their infrastructure and its resources. The technology, which uses the infrastructure and computing resources of cloud services, provides a realistic alternative to an on-site technology DR program. Administrators can use it to supplement existing DR activities by adding greater performance capabilities. They can also use the technology to completely replace existing DR activities.

Like any advanced technology, disaster recovery as a service (DRaaS) and similar offerings bring risks to the discussion. For example, where the DR program was once completely managed by the IT department, one or more new players, e.g., cloud service firms and managed service providers, introduce new unknowns to the process. Although a third party can take a more proactive interest in your DR requirements, DRaaS users must increase their diligence when dealing with the new player(s).

A key tool for reducing DRaaS risks is a service-level agreement (SLA). It spells out what the DRaaS vendor is to provide based on various performance metrics, such as percent uptime, percent availability of resources and security breaches blocked. It also spells out remedies, such as financial penalties or refunds of maintenance costs, for vendor failure to satisfy SLA requirements.

Risk issues and remedies

Let's briefly examine some DRaaS risks and corresponding mitigations.

1. Security. Considering that critical company data might soon reside in a cloud environment, protection of that data will be of greater importance than when the data was on site. Ensure that the DRaaS provider has comprehensive security resources to guarantee that your critical data is protected and available. One such approach is to work with a firm that has multiple data centers with redundant storage facilities so that critical data can be stored in more than one location.
2. Access control. In an emergency, secure access to critical systems and data is essential so that unauthorized access -- and potential damage -- can be prevented. If the vendor has a Service Organization Control 2 (SOC 2) report, be sure to ask for a copy, as it provides audit data that addresses availability, security, processing integrity, confidentiality and privacy metrics.
3. Recovery and restoration. These are two critical metrics in a DRaaS program, as they indicate how quickly an organization's systems and data can be returned to service after a disruptive event. If the DRaaS provider's track record during disasters gives you pause for concern, adjust the parameters in the SLA or consider returning critical systems and data on-site or possibly to another DRaaS vendor.
4. Availability. Resources should be available when and where they are needed. In a disaster, every minute that technology and/or data isn't restored, the business runs the risk of a serious disruption to operations. Data in a SOC 2 report can shed light on possible availability issues.
5. Scalability and elasticity. One of the principal reasons for the popularity of managed services is their ability to adapt quickly to changing business requirements. Be sure when negotiating contracts and SLAs to investigate what additional resources can be made available in an emergency and how quickly they can be activated. Full disclosure by the vendor of where data and systems are stored, and how resources are federated among other vendors, is essential to ensure that data is available when needed.
6. Data protection. Lack of adequate data integrity controls can jeopardize customer systems and data. Ensure that the vendor provides suitable data protection controls.
7. Verification of data backups, replicated data and disaster recovery. The vendor's ability to rapidly verify data backup and system recovery is essential for IT management, in that those critical activities can be fully confirmed.
8. Updating of protected systems. System and data backups must be made according to customer requirements, e.g., full backups and incremental backups, and security access to those backups must be protected. SOC 2 reports can provide useful information on these activities.