6 questions to consider before implementing a disaster recovery plan

DRPs are about backing up data and recovering from loss as efficiently as possible, but a plan is only as good as its weakest link.

Video: How one university could use virtual networking to improve disaster recovery

Systems fail. Unfortunately, we do not get to choose when systems will go offline due to compromise, theft, hardware failure, or act of God. But we can implement a disaster recovery plan and put into play a series of policies that, if adhered to, will go a long way towards allowing IT to bounce back from just about any failure on the horizon.

How do you start? And more importantly, how do you get users to adhere?

SEE: Windows 10 security: A guide for business leaders (Tech Pro Research)

The following six questions identify the critical end-points that should be addressed before implementing a DRP.

1. What types of data can the company withstand losing and which can it not?

This may seem like a no-brainer, but sometimes organizations overlook just how critical a piece of data or application is until it is lost. I find it best to double-check (even triple-check) these things and err on the side of caution before beginning the roll out. Doubling-down will point IT in the direction of the most important devices and storage systems so that it may be protected first under the disaster recovery processes. It also has the added benefit of labeling systems and data sets that, while important, would otherwise take up precious resources better applied to the mission-critical infrastructure.

2. Will end-point protection be agent-based or agent-less?

This will vary widely based on vendor and any regulations that must be adhered to. Agents often work to ensure that a particular service or application works as it should. It typically manages certain aspects of the system or locks it down to prevent the function from being modified or disabled.

This may be a great resource for devices that are near-constantly connected to the corporate network and management server, but this would not bode well for mobile devices that do not connect often and/or "phone home" from low-bandwidth connections.
Though both may have its respective pros and cons, one thing is certain: The last thing IT wants is for a required feature to not work properly and prevent the very function it is trying to enforce from occurring.

3. Where are the third-party company's data centers located?

File this one under the "things to consider during the development phase." I chose to include it here as the initial answer to this question could be in one location and, due to forces outside of your organization's control, could end up being a different answer over time, so it is important to be on top of this.

For example, company A is government regulated and requires that its data--classified as trade secrets--be maintained and managed exclusively in North America. When company A signed agreement with vendor B their data centers were located only in North America. After several years, vendor B expanded to every continent on the globe and has now sent company A their contract revision stipulating that all data centers are co-mingled, meaning that some or all the data from the North America data center could end up in whole or in part in data centers located outside of North America. If left unchecked, this could have negative repercussions for company A.

4. What, if any, ancillary costs exist when considering mobile device backups vs desktop devices?

Mobile devices, particular those for road warrior-types that seldom reconnect with the home network will have a difficult time maintaining compliance with DRP's, so alternative plans should be considered for devices that still allow users to back up their data and recover it should the need arise.

This may come in the form of a secondary internal HDD, external storage device, or cellular wireless adapter that, in conjunction with specially configured software, allows the data to be backed up securely from anywhere in the world without relying on the managed resources of other hardwired devices with stable connections.

5. Are additional, on-going expenses required as part of the business continuity portion of the DRP?

This question does not directly deal with data backup for most organizations but does have its roots deep in the DRP as it refers to the use of hot/cold sites to facilitate continued operations in the event of a disaster, natural or otherwise.

Use of satellite locations is not generally a hard requirement for DRP's. With that said, DRP's are about backing up data and recovering from loss as efficiently as possible to stave off loss of revenue. A hot/cold site may be a requirement for your company to continue operations and/or bounce back from an incident that would otherwise prevent it from operating normally. If this is the case, additional expenses (data connectivity, infrastructure, client devices, software licenses, electrical/data wiring, failover support, to name the core ones) may be necessary and should be factored in prior to deployment commences.

6. Can users manage their own backups?

Speaking to user acceptance, I have always found that users are more willing to work with IT when they feel like they have skin in the game. By merely rolling out a solution and telling users about it often becomes something IT forces on them, which they have no control over. In other words, it's accepted, but not useful to them.

However, bringing users into the conversation and providing them with a function or capability that they can manage themselves often helps to foster a good working relationship between the user and the technology being deployed.

This is not to say that critical data should be left in the hands of a user to decide whether they will back it up. No, instead it is a compromise that provides peace of mind for IT and empowerment for the user.

See also

Disaster Plan written on a blackboard and notepads.

Image: Getty Images/iStockphoto