AuditNet Resource List
Audit Programs
AuditNet Virtual Library
AuditNet Newsletter
Ask the Auditor
AuditNet Mailing Lists
Audit Jobs
Travel
Career Links
Partner Discounts
Search
Sign Guestbook
AuditNet Sponsors
Advertising Opportunities
About AuditNet
About Jim Kaplan
AuditNet Seminars

DISASTER RECOVERY AUDIT & PLANNING: 
AN INTRODUCTION

One of the strengths of AuditNet is that it offers simplicity. It saves reinvention of the wheel via straight forward solutions.

This approach is equally valid for disaster recovery planning and audit, although you might not think so if you listen to software vendors for too long!

Like many topics, disaster recovery isn't actually as bad as it seems once you
take a closer look. The key is to use the same logical approach that you might
employ for a regular audit or project - break it down, fragment it, analyze it.

Whether planning or auditing, you will have to establish the needs of the
organization with respect to continuity:

- identify the critical business functions
- identify the key dependencies (which resources or services are essential)
- identify the requisite recovery time scales for each of of these.

Having obtained all this information, you can then use it - for either building
a plan or auditing a plan (and of course support arrangements). Granted, this
is an extremely high level view, but it is a start.

Within of the above, another break down will of course be required, as will
more detailed assessment. But tackled chunk by chunk this type of operation is both intuitive and manageable. Try it!

SUPPORT TOOLS
Now what about those support tools? There is of course a whole industry out
there, so any comments are bound to be generalizations. However, some truths are self evident.

The main plank of contention is understanding. Do your people understand the disaster recovery plan? Do they understand the continuity process? Do they understand the basics?

This is one of the x-factors of auditing, certainly within the continuity
arena. It is fundamental.

If there is a good understanding of the plan and the process it is likely that
the plan is sound and that it will be accurately deployed if needed. An
assessment of understanding should therefore be included within the remit.

This is a risk that can arise via the use of some sophisticated software
planning tools. This is not just with respect to the possibility of loss of
focus as people learn the tool, but with the chance that allowing software
to 'do the thinking' leads to loss of understanding of the process.

For these reasons, and others, I always recommend the use of simple tools:
perhaps recovery plan frameworks in Word, or checklists. These are readily
available via the net - you can find some free material on AuditNet and more
complete offering on portals like Disaster Recovery World for nominal sums.

Either way, the tool/framework should NOT be taking the decisions. It should
only be an aid, simply taking away some of the mundane elements.

In future articles I will explore some of the above disciplines in more depth,
beginning with an examination of business impact analysis. For more information
on the simple approach to disaster recovery planning and audit, see my own
portal: The Disaster Recovery Guide (www.disaster-recovery-guide.com)