BCP and DRP: the plan that keeps the business running, not just the servers

BCP and DRP are not the same thing

The two terms are used almost interchangeably, but they cover different ground. The business continuity plan (BCP) covers the whole company: people, sites, suppliers, communication, not just the IT systems. The disaster recovery plan (DRP) is the technical part that deals specifically with restoring IT systems, with RTO and RPO defined for each one.

A technically perfect DRP is of little use if nobody knows who has to decide what, or if people have nowhere to work while the systems are being restored. You need both, and the second sits within the first.

Side by side

What goes into a plan that really works

• A business impact analysis (BIA): which processes are critical, and what happens if they stop for an hour, a day, a week. It is also the starting point for RTO and RPO.
• Clear roles and responsibilities: who decides to activate the plan, who coordinates, who communicates, with actual names and not just abstract job titles.
• A communication plan, internal (people know what to do and where) and external (customers, suppliers, any authorities involved), that works even if the usual channels, such as company email, are unavailable.
• Alternative ways of working: where and how people work if the usual office cannot be reached or used.
• Continuity of critical suppliers: what happens if it is a supplier, rather than one of your systems, that goes down.
• The technical recovery plan (DRP), with RTO and RPO defined for each system according to how critical it is.

The most common mistakes

• Written once, never updated. New systems, new sites and new suppliers change the plan: without periodic review, the document describes a company that no longer exists.
• A plan that lives only in IT. If process owners and management do not know it, at the critical moment nobody knows whose call it is.
• No real testing, just paper. An untested plan is an assumption, not a guarantee: the same principle the guide on RTO and RPO explains for restore tests.
• Reliance on a single person. If only one person knows where the passwords are or how the plan is actually activated, their absence at the wrong moment becomes the biggest problem.

How to test it, at a sustainable pace

1. Tabletop exercise: a scenario is talked through, without touching the systems, to check that roles and decisions are clear. The simplest and cheapest way to start.
2. Partial test: you test the recovery of a single system or process, in an environment separate from production.
3. Full test, where the criticality justifies it: a larger simulated outage, run to a real schedule with actual timings measured.
4. Review after every real incident, even a minor one: what worked, what did not, what to update in the plan.

In the story The Friday evening the files changed their names, the recovery time was already known because it had been measured in a real test a few weeks earlier: that is the difference between a tested plan and one that only exists on paper.

Quick checklist

• there is a written continuity plan, not just an informal practice known to a few people;
• process owners and management know the plan, not just IT;
• the plan includes a way of communicating that works even without the usual channels;
• I know what to do if it is a critical supplier, rather than one of my own systems, that goes down;
• the plan has been tested in the last twelve months, at least with a tabletop exercise;
• the plan is updated when systems, sites or key suppliers change.

In short