In my first article (http://disaster-recovery-risk-assesment.blogspot.com/) I discussed the value of information, risk management and disaster recovery.
In my second article (http://disaster-recovery-planningcontinuity.blogspot.com/), the following was discussed:
- The place of information systems contingency plans in the business continuity strategy.
- A methodical approach to developing and implementing information systems contingency plans.
The next step is to construct such a plan. In this third article, I will discuss the important components of a Disaster Recovery Plan (DRP) and the reasons for these components. Generally speaking, these components should apply to most plans. Before we carry on, we should, once again, define what is a DRP:
A DRP is a comprehensive and consistent statement of actions, tasks, dependencies and milestones along with resources required to accomplish a required level of recovery for given functions at given locations within given periods.
The key words or sentences to be extracted from this definition are: ACTIONS/TASKS, DEPENDENCIES, RESOURCES, LEVEL OF RECOVERY, FUNCTIONS, LOCATIONS and PERIODS. A good DRP should address all these key words or sentences. A good DRP should be detailed but to the point. It should exclude any lengthy policies and theoretical information. It is primarily an action plan giving very specific instructions. The rest of this article enumerates the components and explains their functions.
1. AIM/PURPOSE (SCOPE) OF PLAN.
This important component sets the parameters of the plan. It should briefly define the function(s) to be recovered and the potential contingencies that can be addressed. It can also define an overall time frame.
2. POLICY/PROCEDURE TO INVOKE PLAN.
A DRP is normally invoked when absolutely necessary. The decision to invoke must be taken at a senior level. This section defines who has the authority to invoke the plan and refers to a section where the tasks to initiate the plan are stated. Alternate persons who have the authority must be named here.
3. TASKS IN THE PLAN.
This component should list all the tasks to be performed in the plan. The tasks should be in chronological order with the first task starting at 0:00 hours reflecting initiation of the plan. Each task should, at least, include the following:
A one line statement of the task and a short but explicit description of what must be done.
Who (team and/or individual) is responsible for carrying out the task.
Where is the task to be performed.
Reference to list(s) of resources required by the task.
Reference to any procedure document to be followed.
The estimated duration of the task.
What task(s) should precede the task.
The tasks in a plan should not be confused with procedures which are usually longer documents describing in detail how certain functions must be carried out. A typical example of a task could be: "Restore data bases". Such a task should refer to a detailed document explaining all the steps and checks to be carried out when restoring the data bases.
The task list is a crucial component of a plan. It is the detailed road-map that states all the important steps in the recovery process. It is the checklist to ensure that all the necessary steps have been followed.
However, a single task list can be difficult to follow, especially if multiple teams, individuals and resources are involved. Very often tasks will run concurrently. In this case, it is advisable to have a logical breakdown of the task list as explained in the following sections. Other breakdowns might be necessary depending on the complexity of the plan.
3.1. TASKS TO INITIATE AND COORDINATE PLAN.
This task list is extracted from the integrated tasks and provides the steps to initiate the recovery and coordinate the rest of the plan. This list will normally apply to a "Management" team.
3.2. ALL TASKS IN THE PLAN.
This is an abbreviated list of all the tasks in chronological order containing the one line task statements. This list can prove invaluable in coordinating the total plan.
3.3. TASKS FOR TEAMS.
This is made up of separate task lists for each team. It facilitates each team's actions and allows each team to concentrate on their area of responsibility. Since each task will state predecessors, this will allow the teams to have checkpoints where they should stop and wait for other teams' tasks to be completed.
4. TEAMS IN THE PLAN.
This component should name each team and offer a brief description of each team's responsibilities in the plan.
4.1. TEAMS' MEMBERS.
This component should list members of each team by team. Details of telephone numbers, addresses and emergency contact numbers should be stated. The list could also contain alternate team members and team leaders in cases where persons are unavailable. The lists can also be used as call lists.
5. RESOURCES IN THE PLAN.
Up to now, we have addressed the following:
The scope of the plan and responsibility to initiate the plan.
What must be done and when, to achieve recovery.
Who must do what.
However, nothing can be achieved without the necessary physical resources. Resources can be purchased or hired. Certain resources must be available at very short notice and those will probably be stored at specific locations for quick retrieval. Other resources (e.g: a fully equipped backup computer centre) must be contracted for and kept in a state of readiness. We might require specific services (e.g: financial, transport, security and accommodation).
These resources must be explicitly defined and linked to the tasks to be carried out. All necessary details for each resource must be documented in the plan and each type of resource listed separately with cross references to tasks (establishing time criticality) and vendors.
Typical resources required in a plan should include the following:
- Facilities (e.g: computer rooms, hotels, storage locations, office accommodation). Details of contacts, addresses and capacities should be documented.
- Stored resources (e.g: reference manuals, procedure manuals, backup data and software, media and stationery required at short notice). Quantities to be stored must be documented for audit purposes and to satisfy requirements.
- Resources to be purchased (e.g: stationery, media, office equipment, special forms, production equipment, computer equipment). Vendor references, power requirements and lead times should be documented.
- Services (e.g: financial, insurance, transport, security). Details of contacts, addresses and service availability should be documented.
- Vendors with details of contact persons, addresses and products obtainable.
6. REVIEW POLICY/PROCEDURES.
As a DRP must always adapt to changing circumstances and requirements, it must be kept in a constant state of readiness. To achieve this, explicit review policies and procedures must be documented as part of the plan. The reviews must take place on a regular basis (e.g: monthly or quarterly). This part of the documentation must clearly state agendas to be followed and how resultant action items will be followed. It must clearly define responsibilities and report back requirements. It must also clearly define audits to be carried out (internal or external). The main aim of reviews should be to plan forward, establish future requirements and budgets. The review is normally carried out by a dedicated team under the coordination of one person. Team leaders in the plan should participate in the reviews. Preferably, the result of reviews should be documented in monthly management reports to the executive.
7. TESTING POLICY/PROCEDURES.
As mentioned in my previous article, an effective DRP is the END RESULT of adopting practical solutions that are proven by tests. It is therefore ESSENTIAL to test the plan on a regular basis to maintain effectiveness. Tests are the best form of audits for a plan. An important component of the plan is documented testing policies/procedures. The documentation must clearly state what tests will be carried out and for what purpose, how the results of the tests will be evaluated. It should establish a firm schedule of tests for at least one year. Depending on management strategy, unannounced surprise tests can also be carried out.
To conclude, I think that we must agree that a good plan must be fully integrated. The job of defining and maintaining multiple relationships between tasks and resources can prove to be complex. To ensure this, it is necessary to acquire and use the proper tools and methods. This will save a great amount of efforts and greatly facilitate maintenance, planning and training.
Copyright José Masson All rights reserved. Copying and publishing the content without prior written permission is prohibited.
