Business Continuity and Disaster Recovery: Key Differences Between Policy and Procedure

Every business stakeholder (owners, senior management) knows that their business should be prepared for any event that can have a significant impact on the ability to conduct normal business, commonly known as disasters. To be prepared for a disaster means to have a plan. Otherwise, as the saying goes, you plan to fail. Business Continuity Policy

Policies need to be defined by the most senior management/ownership of a company before procedures are put in place to recover from a disaster. However, management often abdicates this responsibility, leaving it up to the IT Department. Abdicate here using the secondary definition of “the failure to fulfill or undertake a responsibility or duty.”

The policies that the stakeholders of a business should write are simply stating objectives that others will carry out. So why do stakeholders ignore writing these policies? There are two main reasons, one intentional and one not, money and ignorance.

1) Money: Stakeholders know that the result of writing down concrete Business Continuity and Disaster Recovery objectives will cost money. Not doing so means that no funds will be expended. Is this logical or prudent?

2) Ignorance: I placed the word “should” in italics in the second paragraph for a reason. Maybe the stakeholders don’t know that they need to have a plan for dealing with harmful or potentially fatal (to the business) disasters. If not someone needs to tell them, possibly a peer, staff member, consultant or vendor.

When no recovery policy is defined IT staff members often write procedures and put systems in place with no idea if they meet the company’s survival objectives. But I digress. Let’s talk about the actual Policies that need to be put in place.

Written Policies for IT Disaster Recovery

After conducting a Business Impact Analysis, which identifies potential risks to the business, it’s time to set written policies for preventing or recovering from disasters. These policies will assign time frames to two the key IT Disaster Recovery metrics, Recovery Point and Recovery Time Objectives.

Here’s some sample policies.

1) Building unavailability: Since it is impossible to determine all of the potential risks to business operations the term building unavailability is defined as the company’s offices being completely unavailable for use, including access to digital data, paper files and all associated office equipment.

a. In order to recover from such a disaster the Information Technology Department is charged with designing and implementing a solution that will allow the business to restore access to Mission Critical digital data and the systems that support that access within the following time frames

i. Recovery Time Objective: 24 Hours ii. Recovery Point Objective: 4 Hours

2) Data unavailability: Risks to data availability include, but are not limited to, server hardware failures, software corruption, theft, data loss, etc..

a. In order to recover from such disasters the Information Technology Department is charged with designing and implementing solutions that will allow the business to resume access to Mission Critical digital data within the following time frames

i. Recovery Time Objective: 4 Hours ii. Recovery Point Objective: 1 Hours

These policies clearly define the recovery objectives of the company for two types of events, building unavailability and data unavailability.

Written Procedures for IT Disaster Recovery

Now that the IT Department has clear objectives to meet as defined by the Disaster Recovery Policy statement they can go about researching, designing and implementing solutions, and write procedures, to meet those objectives.

It can take some time to determine what data and applications are Mission Critical and all of the options available, their costs (both internal and external) for putting a solution in place.

This document will be the most fluid of the two, as solutions and procedures will need to be continually updated to meet the recovery objectives of the policy statement as the business changes. Thus and IT Disaster Recovery Plan is more of a process than a project.

Now the onus is on the IT Department to meet these recovery requirements. This means that there is now a de facto Service Level Agreement between the IT Department and the business.

In summary, senior management of a business needs to prepare a policy statement regarding the organizations recovery objectives from various types of disasters. Based on this policy statement the IT Department can deploy solutions and write procedures for meeting the policies objectives.