Essential Objectives your Disaster Recovery Strategy Must Achieve

When we talk about disaster recovery and business continuity planning, we devote most of our time and space to backup operations. For technologists and systems administrators, that makes sense. However, this is not the full story.

For almost everyone else in a business, other things matter more. We touched on some of these points briefly while discussing the planning phase.

In this article, we will expand on them. Because IT often drives continuity and recovery planning, it may fall to you to motivate the other business units to participate.

Disaster Recovery Planning Beyond the Datacenter

During risk analysis, you likely found many hazards that would damage much more than data and systems. Fire threatens everyone and everything.

Floods have as much ubiquity; even if you build your business atop a mountain miles away from a river, you still have plumbing. Some sites need to worry about civil unrest and terrorism. Simple mistakes can have far-reaching implications.

Your disaster recovery strategy must consider all plausible (and perhaps some implausible) risks. Just as you plan to recover systems and data, you must also think of your people, buildings, equipment, and other property.

Use your findings as a basis to bring the non-technical groups into the process. You might need to convince executives in order to gain the leverage that you need. Remember that the best data protection and recovery schemes mean nothing if the organization has no plan to continue operations.

A question template to capture interest: “How do we satisfy customers/meet our contractual obligations/ continue making money in the event of…?”

Establish plan scope

During the initial discovery phase, you involved the leaders of other departments and teams. In addition to their technical requirements, they also have knowledge of the personnel, locations, and items needed to carry out their group’s function.

All of that information is vital to understanding the business’ critical IT operations. Hopefully, those sorts of things were included in the early stages of planning. The sample checklists provided in the appendixes have a handful of questions related to people and things.

To fully encompass your organization, your disaster recovery plan must expand further.

Covering locations

We will revisit the subject of business sites a few times during this discussion. Right now, we need to think in terms of which locations to include in your plan and what to record about them. It’s unlikely that you would exclude any working site, but your company might own some empty or unused properties.

When you update your plan in the future, you may need to remove locations that the organization no longer owns or controls.

When you place sites into the scope of your disaster recovery plan, you should centralize their role within that context. Labels like “main campus” don’t mean much to someone trying to address a catastrophe.

For every place listed in your plan, include:

• Where: Identify locations by address (e.g., 7904 West Front Road). If your organization has informal shorthand and anyone likely to read your disaster recovery document will understand it, you can use that as well (e.g., “Pinewood B” to represent the B building on your Pinewood Road campus).
• Normal operations purpose: Succinctly and clearly note the typical purpose of the site (e.g., “primary accounting site”). Small companies may not list anything other than “main operations” or “main office” or the like.
• Disaster recovery operations purpose: List the expected use of the site during or after a disaster if it survives. Be creative and get others involved, such as head of the team or department responsible for building maintenance. Use entries such as “overflow site for accounts receivable”, “alternative shipping and receiving facility”, and “tornado shelter”.

This exercise will expose many things that staff should consider. Where will employees go if you lose a site? What about customers? Does every location have a disaster response plan? Where can we shelter people?

If a loss impacts the loading dock, where else can we ship and receive freight? Look out for other vital information to include.

Protecting equipment

The term “equipment” connotes different things, depending on your industry and business function.

Your disaster recovery plan needs to account for all kinds. If it’s tangible and isn’t land, a building, or inventory that you sell as part of your normal business operations, then it might also have a place here. The equipment inventory portion of a disaster recovery document addresses these concerns:

• What was lost or damaged in a disaster, and what is still serviceable
• What qualifies for an insurance claim?
• What leases, loans, and rentals were impacted?
• What bulk small items would need replacements? (e.g., pens, paper stock)

Make your search broad. You need to cover vehicles, printers, desks, and anything else that your business would need in order to return to full functionality after a destructive event.

You will likely separate this portion from your major IT inventory. Personal computers, devices, and printers could logically appear in either place. You might also wish to create separate lists for different departments, sites, etc.

Use any organizational method that makes sense and would have value in the hectic aftermath of a calamity.

Handling business inventory

If your business works with inventory flow (retail, manufacturing, etc.), then you will need a section for it, separated from the equipment entry. Due to its fluid nature, precision gains you nothing but work. Instead, document its supporting structure. Examples:

• Link to sites (warehouse, retail outlet, etc.)
• Methods to account for damaged, destroyed, or stolen inventory
• Disposal processes for damaged and destroyed inventory
• Mitigations in place (fire suppressant systems, backup generators for freezers, etc.)
• Contacts to repair, replace, and reset mitigations
• Information on insurance coverage and processes

Remember to stay on target: you are not trying to duplicate your inventory system. You only want to incorporate inventory management into your disaster recovery plan.

Preparing and safeguarding personnel

Human life and safety concerns make this portion of your planning stand out. For the bulk of your physical items, you will have to wait to respond until after the disaster. People need immediate attention and care.

As this article primarily targets technology workers, these responsibilities may not fall to you. Either way, the organization’s disaster recovery plan must include people-related preparedness and response points. Elements to consider:

• Building exit points
• Evacuation routes
• Emergency power and light sources
• First aid kits
• Fire suppression devices and systems
• Extreme weather shelter
• Staff drills
• Notification/call trees
• Check-in procedures

Some of these items might be excessive for your situation. For instance, if you have a one-room shop with two employees, then your evacuation route is “door”, your call “tree” is a flat line, and drills are not the best use of your time.

If something does not make sense to include in your plan, skip it or use some sort of placeholder to fill in as your company grows. No one should disregard this step entirely. All organizations of all sizes can find something of value here.

Do not consider this list comprehensive. Compare it to your identified risks. Gather input from others. If your business already has safety or emergency management teams, join forces. They have likely worked through all of this, and you only need to find logical connection points to your data and systems recovery plans.

Even if you do not have a designated team, someone might have done some of this work to comply with regulatory demands.

Prioritizing and documenting departmental tie-ins

Take exceptional care with organizational seams. In the example that mixed IT and sales, the sales staff will depend on other teams (depending on the disaster conditions). They will be limited in their response until those other components fall into place.

Without a predefined process, IT will likely receive a call every few minutes from a different salesperson asking, “Are we up yet?” To prevent that, specify how response teams will utilize the notification system.

Designate points of contact between the departments. When you take those spurious calls, notify the caller who is in their department and was selected to disseminate information. These small preparations reduce frustration and interruptions.

Delegating information collection and retention

One person will not bear the responsibility of all items covered in this chapter. Depending on the size and makeup of your organization, you may need to involve people from several departments. You will have the best luck with subject-matter experts, especially if they have already done some of this work.

For instance, most manufacturing companies that existed before computers have had equipment and inventory control systems in place for a long time.

Plan to encounter some resistance. Department heads might see this as an encroachment into their territory. Some people just will not want any more work to squeeze into their day. Have some points ready to show the benefits of cooperation.

Disaster recovery planning is a unified effort for the entire company, not a way to wrest control. In a disaster, every department will be expected to take responsibility for their part. A plan will help to establish the rules in advance.

The central plan only needs sufficient information to coordinate a recovery effort. If a department already has a detailed procedure, then you might only need to document its input and output junction points to other departments.

However, make it clear that you cannot simply use something like, “to recover the billing department, call Bill.” A disaster recovery plan cannot depend on any individual.

If all else fails, you should have gotten executive sign-off when beginning this project. Leverage that as a last resort.

Just as you have learned that business continuity planning is an ongoing process, not an event, you will need to make the leaders of the other business units aware. Set up a quarterly or biannual schedule for everyone to bring their updates and to review the document.

Keep as much of the documentation together as possible. Some departments may insist on maintaining their own. IT often takes on business continuity planning because it is the hub, but the plan belongs to the entire organization. Integrate as much of it as you can.

Restoring Non-data Services

Just as we need to document and prepare for disaster to strike our business units, we also need to have a path back to functionality.

We’ve touched on this in previous points of the text where it made sense. Recovery requires a substantial amount of time and effort to perform. It should have a matching level of representation in your plan.

If you worked straight down through this section, then you have already begun to think about the necessary components. Buildings need to be made usable, equipment needs to return to service, inventory needs to flow.

All those activities represent individual pieces. As they start up and come online, employees will move to the next tier: coordinate the pieces to enable your business’ functions and services.

With modern digitized infrastructure, IT often provides a backbone for everyone else. Unfortunately, the world will not stop just because the computers do not work. You need an alternative course of action.

Downtime procedures

Each department or team needs to develop downtime procedures. Define a minimum time period that staff have no access to the system before switching procedures. If IT can bring things back in a few minutes, the switchover probably consumes too much time.

The upcoming “Business Process” section will expand these concepts. Right now, we mostly want to present its tie-ins to the non-technology portions of the business. A few ideas to get you started on developing downtime procedures:

• Prepared paper forms, receipts, and ledgers
• Traditional telephone lines as backup to VoIP
• Cell phones or handheld radios for internal communications

To reiterate, these procedures specifically apply to continuing business processes through a system failure. Do not mix them with response and recovery activities.

As an example, “periodically add gasoline to the backup generator” is fine to include. Something like, “notify carriers of alternative pick-up and drop-off sites” should go elsewhere.

Staff that do not need to devote their time to resumption efforts will follow downtime procedures.

Dependency hierarchies

Create visual aids that illustrate the differences between necessary and desired dependencies. For simple designs, text trees might suffice. However, you already have tools that can easily produce suitable graphics. As an example, consider the following diagram of a shipping/receiving department’s operation:

The structure of this graphic implies that the “Shipping and Receiving” function must have people to work the freight and a place to load and unload. The placement of the service atop two separate blocks shows that it can operate with either but must have at least one.

Inventory software appears first (in a left-right culture), indicating that it has preference over the paper-based solution. If some other service relies on the shipping and receiving function, then start another diagram for it with a single “Shipping/ Receiving” block at its bottom.

An image like this works well for simple hierarchies and is easy to make. This particular graphic was built in Microsoft PowerPoint and exported as an image. PowerPoint also includes several standard flowcharting shapes for more complicated trees.

If you need even more detail, you can bump up to a dedicated diagramming product such as Microsoft Visio.

Organizing disparate documentation

With everything in this section added in with your IT documentation, your disaster recovery plan may become unwieldy. To minimize the problem:

• Decide on a logical document organization strategy and apply it uniformly
• Use your tools’ features to create a navigable table of contents
• Split the document

If possible, build a template for departments to follow. If you find that needs are too diverse for a single form, you can create multiple forms from the same source, or you can have a generic starting point with custom content.

Maintain the core principle that the people who initially create and innately understand the document may not be the same people that put the document into action. Recovery efforts might be coordinated by project managers who don’t know what some of the words mean. Clarity, consistency, and uniformity matter.

Microsoft Word and most common PDF generation tools can establish intra-document links. Some can automatically create a table of contents from headers and sub-headers.

Although a major disaster may make it possible that no one will have a digital copy, the pervasiveness of small devices and highly redundant cloud storage heavily reduce those odds.

When connecting different parts of a document, ensure that the linkage exists as both a clickable item and with words (e.g., “voice engineering must have restored telephone services before inbound sales can resume”.

Consider splitting the document. This action breaks and sometimes removes links, so use it only as a last resort. You will need to maintain an absolute minimum of one complete digital and one complete physical document.

Each revision will require you to repeat splitting operations. Even if you only revise one section, a shift in page numbering could throw off all unsynchronized copies and splits. As a mitigation, you can use only monolithic digital copies but allow people to selectively print the pages that pertain to them.

You can also use a document management system or multi-document software, such as SharePoint, OneNote, or a wiki. Tools of that kind often have challenges with creating hard copies, though.

---

To properly protect your virtualization environment and all the data, use Hornetsecurity VM Backup to securely back up and replicate your virtual machine.

We ensure the security of your Microsoft 365 environment through our comprehensive 365 Total Protection Enterprise Backup and 365 Total Backup solutions.

For complete guidance, get our comprehensive Backup Bible, which serves as your indispensable resource containing invaluable information on backup and disaster recovery.

To keep up to date with the latest articles and practices, pay a visit to our Hornetsecurity blog now.

---

Wrapping up Non-technical Planning

Now you can gather the other people needed for the tasks in this section. If they were not included in previous steps, make sure that they understand the goal: surviving, working through, and recovering from major and minor disasters that affect their departments, their customers, and their interactions with other parts of the business.

As they start work gathering information and preparing their documentation, you can move on to the technical details of recovery.