Disaster recovery procedures for auditing and maintenance

Learn how to avoid the key pitfalls in the development of disaster recovery procedures for auditing, maintenance and continuous improvement of disaster recovery plans.

Having developed detailed disaster recovery plans on the basis of risk and business impact assessments and planned disaster recovery training, awareness and testing programmes, you have finally reached the final stages of your disaster recovery project.

Now is the time to develop disaster recovery procedures for auditing, maintenance and continuous improvement of your programme. In these phases the core of your disaster recovery programme -- the concrete plans that will get your operations going again after an unplanned outage -- will be maintained and improved as change occurs over time in your organisation.

In this interview, SearchStorage.co.UK Bureau Chief Antony Adshead speaks with Paul Kirvan, board member with the Business Continuity Institute, about the key pitfalls in disaster recovery maintenance and auditing plus the secrets to success in continuous improvement of disaster recovery plans.

Read the transcript or listen to the podcast on disaster recovery procedures for auditing and maintenance.

Play now:
Download for later:

Disaster recovery procedures: Auditing and maintenance

  • Internet Explorer: Right Click > Save Target As
  • Firefox: Right Click > Save Link As

SearchStorage.co.UK: What are the key pitfalls to avoid with regard to maintenance and auditing disaster recovery procedures?

Kirvan: The primary pitfall is actually to not organise and conduct maintenance and audit activities for business continuity and disaster recovery programs. These two activities are often the most overlooked in the entire business continuity lifecycle, and yet both are highly important to the overall success of any business continuity and/or disaster recovery programme.

Clearly, changes will occur regularly in your organisation, such as additions or deletions to staff, changes in an employee’s work address and/or phone number, changes to employee email addresses, changes to an employee’s job title, and many others. And of course when the IT department adds, removes and changes systems, applications, telecoms and other assets, these changes should also be reflected in disaster recovery and business continuity plans.

For example, suppose a software vendor releases a new version of a product that is considered a critical application. Naturally, any existing documentation will be updated, technical staff will be trained in the changes, and the newly updated system will undergo testing before it is placed into production. These changes can and should be reflected in disaster recovery plans.

Here’s another example: When making a change to a system, it’s likely the process for recovering that system will include detailed scripts for recovery and restart. Be sure these new scripts are included in the DR plan for that system. This is what maintenance is all about -- keeping all aspects of your BC/DR plans up to date, not just the contact lists -- although these are very important.

Another pitfall is ignoring or totally abandoning the plan’s maintenance activities as too cumbersome, too costly, too time-consuming, too staff-intensive or some other excuse. The process of creating a spreadsheet is relatively simple; the challenge is to complete the tasks as outlined on the spreadsheet. Assuming your IT disaster recovery programme is audited, remember that maintenance or the lack of [it] will be a key audit finding, so you really can’t ignore it.

SearchStorage.co.UK: What are the secrets of success in bringing continuous improvement to disaster recovery plans?

Kirvan: Developing disaster recovery plans is a complex process. You must complete many steps before you can stand back and say, “We’ve completed our IT disaster recovery programme.” Regrettably, that’s often where many organisations end their relationships with business continuity and disaster recovery. They feel that once the programme and plans are completed, their work is done.

This is a sad but true reality, and an effective way to avoid this unfortunate situation is to establish a continuous improvement programme. Among the secrets of success in establishing a successful continuous improvement activity are:

1) Senior management support and commitment to continuous improvement at all levels in the organisation;

2) Access to funding for the programme;

3) Coordination with relevant departments in IT, such as planning, operations, security, change management and even the help desk;

4) Coordination with and support from other departments, such as human resources and risk management;

5) Adding DR activities to existing continuous improvement programmes;

6) Leveraging DR activities such as programme maintenance and programme auditing to identify areas for improvement; and

7) Launching a process to transform maintenance and audit findings into real and tangible improvements.

Finally, be sure to document all continuous improvement activities and report regularly to management on your efforts with the programme.

Read more on Disaster recovery