Are You Prepared for an Audit?

Evaluating Your Disaster Recovery Plan

By Jim McQuade

Audits may be the bane of management, but in disaster recovery auditors become key players in the success of the plan. Their insight may be invaluable in identifying missing pieces or weak links. Rather than dread the experience, consider the audit as a chance to forge a working relationship with someone who can give you an impartial, objective appraisal of your work. If you are prepared, the audit will be smooth and your confidence in your plan and in your people will increase. If you are not prepared, consider this an opportunity to find out where to best allocate your resources.
The following questions specify objective and quantifiable criteria for evaluating your plan. While the auditor may not ask you these questions directly, the answers should still supply you with all of the ammunition you need.
1) How many man-hours went into producing the existing plan?
We invested about 600 man-hours over three months to develop our first plan, nearly from scratch. That’s roughly 150 man-hours per critical application, pulling on one full-time coordinator along with significant contributions by middle management and senior analysts as needed. We also held regular meetings with a steering committee.
2) Are lead recovery personnel intimately familiar with procedures and responsibilities?
The best way to ensure this is through preparatory walkthroughs, followed by mock disasters. Simulating a crisis is best because the crucial elements of your plan will be tested realistically, and the behavior of the people involved will be genuinely spontaneous. Planned tests are useful for new or recently changed plans, but may not fully exercise your logistics.
3) Are lead recovery personnel appropriately cross-trained to step in as alternates in the event of a key person’s absence?
This is obviously crucial. Cross-training ensures that the absence of one person will not foil your efforts. You’ve taken all this time to back up your hardware and software; back up your people, too.
4) Has the plan been critiqued by an outside agency or consutant?
This is the best countermeasure against tunnel vision. The cost is marginal relative to the total cost of your plan. The consultant has seen a wide range of plans, both good and bad, and can give you an honest appraisal of where you stand. Consider this step a pre-audit.
5) What resources are allocated to plan maintenance?
Ideally, you could employ a full-time equivalent with proven technical and managerial skills and a review committee drawn from existing staff. However, you may not be in a position to appoint a full-time disaster recovery coordinater, but instead be forced to have people in existing roles shoulder the responsibilities. Be sure to give them enough latitude to do the job. If you’re taking the relational database approach, dedicate a PC to the effort, too. Note that the disaster recovery plan is also a critical application and take appropriate steps to protect it with regular backup.
6) What audit trails are available to track plan maintenance? How are updates circulated among key personnel?
A simple change log will suffice to track changes. Note the date and the person who changed it along with what was changed and why. Distribute the plan in notebooks, distribute revised pages as necessary, and call a review meeting after significant changes.
7) What is your expected operating cost for plan maintenance?
We don’t have any real numbers here. One percent of the MIS annual budget seems to be the going rate for the entire plan, but that obviously includes things like hot-site subscriptions and capital acquisition. Consider this a solicitation.
8) When was the plan last tested? How was the plan tested? What were the results?
Test results should be documented by all participants and formally evaluated after the test. If your first test goes well, you are probably doing something wrong. Subsequent tests should continually become smoother. Successful testing is your best guarantee that the plan is kept up to date.
9) When was the plan last updated? Why? How many man-hours did it take?
If updates take too long, you may not be allocating enough resources to maintenance. If updating is too easy, you may be missing something critical. Of course, it may be quite reasonable that certain developments are easy or hard to incorporate into the plan. If you’re really serious, try longitudinal tracking. What’s too long or too short is obviously relative, but if updating takes more than a small fraction of the actual development, you have a problem. Again, regular testing is the best way to ensure that your updating procedures are adequate.
10) When do you expect to make the next update? Why?
Stay on top of the imminent change in your operation. Institute a change control procedure so that your disaster recovery coordinator is continually abreast of important developments. Tie the change control procedure into the planning and budgeting processes, too.
11) How many times a year, on average, do you expect to review and update the plan?
The best answer is 365 days a year, but many organizations do not need to or do not have the resources to do so. The correct answer depends on each organization; appropriate allocations of maintenance resources should answer the question automatically.
12) How many times a year, on average, do you expect to test the plan? How will test results be evaluated and incorporated into the plan?
As above, this is a function of the organization, but once a year is an absolute minimum. If possible, invite the auditor to observe your test. Always include an impartial referee. If things go well, examine the reasons why. If you had any problems, discover the elements you had not accounted for and expedite the changes into your plan.
As always, bring as much documentation as you can muster. Be sure to include contracts and agreements with recovery and storage sites along with the technical specifications of your hazard protection systems.
May lightning never strike....

Written by Jim McQuade, a graduate student in the University of Pittsburgh’s Interdisciplinary School of Library and Information Science.

This article adapted from Vol. 3 No. 1, p. 20.

Disaster Recovery Worldİ 1999, and Disaster Recovery Journalİ 1999, are copyrighted by Systems Support, Inc. All rights reserved. Reproduction in whole or part is prohibited without the express written permission form Systems Support, Inc.