The business impact analysis and risk analysis are the two foundations upon which an actual contingency is planned in an IT disaster recovery plan.

Some of the tried-and-true methods are:

Dedicated and empowered staff :A dedicated department within IT should be proficient in managing business continuity and disaster recovery.

Divide and conquer: Business continuity and disaster recovery (DR) should be categorized into two different initiatives. Each should have its own governance and goals. Technical recovery is the objective of DR. The plan is created and managed by developers and engineers. Goal for business continuity is business process stability, and the plan for this is developed in partnership with IT by business unit representatives.

Ensure that the plan can stand alone: If the staff who wrote the recovery plan is not available at the time of disaster, there should a backup trained staff to execute it.

Challenge the business: Check the criticality of the application that needs to be recovered. Ask the concerned department if they can really go without that application.

Disaster Recovery should be aligned with application development: Develop an isolate test environment that tests all the systems and applications. There should be a report on application-testing status so that it is clear when a system was last tested.

Tabletop tests: Reviewing your plan on paper is important. Mock disaster on crisis management team, constituting of board members and staff should be done. Replica data center must be set up so that it is operational within a few hours in case a disaster strikes.

Hold postmortems and results: What to do with the result of the disaster recovery plan is crucial. In case you are not availing services of a third party to recover, create an action-item checklist out of your review of what went smoothly and what didn't.