DRP · Disaster Recovery Plan

When systems go down, the board's first questions are how long and how much data is gone — and both answers are decided long before the incident. A Disaster Recovery Plan (DRP) exists so that the return of IT systems and data is an engineered procedure, not a night of heroics. It gives executives the basis for the two commitments that matter in the first hours: when services will be back (RTO) and how much data may be lost (RPO). Without a DRP, those commitments are guesses made in front of customers.

In practice the DRP is owned by IT, derived from the business targets in the BIA, and specific to systems: restore order, infrastructure dependencies, responsible engineers, backup locations and switchover steps. If ransomware encrypts the production environment at night, the plan defines the decision point — for example, fail over to the standby site if recovery is not confirmed within 2 hours — and who is authorised to take it. Backups are kept offline or immutable, and the plan is proven by restore tests, not by the existence of backup jobs. A DRP that has never restored a system in a test has never worked.

The recurring mistake is a DRP written around technology alone, with recovery targets that were never agreed with the business — so IT restores servers in an order nobody asked for. Another is discovering during a real event that the backups cover the systems but not the recent data. In the ERGP programme, recovery of technology as part of the wider response is treated in module M4, Crisis management and decision making.