Your Disaster Recovery Plan is Out of Date

Some would call it an unfair, overly broad and possibly untrue statement that your Disaster Recovery Business Continuity plan is out of date. But unless you were working on it this week, it probably is.

If you even have one.

Disaster Recovery plans change
Companies change, employees' change, management decisions that impact a Disaster Recovery plan are not always filtered down to the person that needs to actually know.

Worse, if your Disaster Recovery plan was an afterthought put together when the business buzz word changed and briefly brought this to someone's attention you will not be able to stay current.

I was told a short story by a colleague of her personal experience.

She personally had no backup plan for her outsourced call center. She assumed that either:

• the Call Center would have a plan in place
• her company was running a state of the art, top of the line, nothing could be better plan.

She was wrong. Twice.

A customer called in related to an issue that had been previously managed. The computer system that had gone down before was down again. In between failures, the teams had changed and the new team did not know how to fix the issue.

In a standard call center, old data is available. This call center normally had such a system in place, but for this call, some of the data had been corrupted and my colleague needed old data recovered.

She contacted the outsourced call center IT team and was told that client data was not stored on site for confidentiality issues.

She contacted her company IT team and was told that data was on the server, but no special backup plan had been requested, so her call center data was backed up at level with no priority.

Searching for the previous answer would take 48 man hours and an entire backup system needed to be built out to recover this one item. IT refused. She was outraged and insisted. The IT team refused because the time and cost of recovering the information would be more than the cost of figuring out the answer for the client a second time.

The Solution

To make an already long story short, a backup server was built identical to the primary system. A full backup of the primary system was made on a regular basis and stored off site. The secondary system had incremental updates made daily. An incremental backup only updates the things that have recently changed, so there was less time involved to complete the process.

This story emphasizes an area that many organizations overlook when working with an outsource business partner. Disaster recovery plans. Either there is no plan, or there is a plan that is not kept up to date.

This is not a just problem for smaller companies with one server and 5 employees. The colleague in question worked for a Fortune Global 100 company.

There lessons from this example.

1. Verify or create your Disaster Recovery plan
2. Integrate Disaster Recovery into your business process management
3. Actively test your Disaster Recovery plan

If your Disaster Recovery plan was put together by anyone but you, verify it. Put a dollar value next to failure and make sure that management is aware of this number.

With a monetary value next to failure you should be able to get some management support and integrate Disaster Recovery into your standard business management processes.

Actively test your Disaster Recovery plan and as thoroughly as possible. If you have resistance, use the term Business Continuity.

You don't want to be in the same situation as my colleague was and these three steps can help keep you from disasters path.

Keywords: