Know who does what, in what order, during and after the outage
A disaster recovery plan brings your systems back. A business continuity plan keeps essential work going in the meantime. You decide how demanding it needs to be; we build it with your team so they can follow it under pressure.
A plan nobody has opened won’t help on the day
A procedure that just says “call IT” or “restore the backup” helps no one in a crisis. A useful plan says who triggers it, who acts, in what order, with which access, and how to check that things are running again. It has to work without its author in the room.
DRP or BCP: two different questions
| DRP — Disaster recovery plan | BCP — Business continuity plan | |
|---|---|---|
| The question | How do we bring the systems and functions we need back into service after an outage? | How do we keep essential activities going during the outage, without the usual IT? |
| Starting point | Your recovery objectives and the results of a test | The business activities that can’t stop |
| What’s in it | Scenarios, triggers, owners, restart order, procedures, checks, return to normal | Fallback modes, manual procedures, backup communication, temporary organisation, delegated authority |
| Who you work with | IT, your provider, leadership | Leadership and business owners |
| How it’s checked | Exercise and retest | Simulation exercise |
One, the other, or both?
| Your situation | Look first at |
|---|---|
| You mainly need to restore systems, and your operations can wait for recovery | A DRP |
| You need to keep serving customers or producing while systems are down | A DRP and a BCP |
| Continuity depends on both temporary procedures and an IT restore | A coordinated DRP and BCP, with shared switch-over and return criteria |
Not every business needs a BCP, or one of the same size. We propose the scope based on what an outage would do to your operations; you approve it.
The disaster recovery plan (DRP)
A DRP starts from what an outage does to your business, not from the infrastructure. It covers:
- the scenarios you retain (hardware failure, ransomware, loss of a site, a provider outage, human error);
- trigger conditions and who is authorised to trigger the plan;
- the crisis organisation: owners, deputies, roles;
- backup communication, outside the affected systems;
- the scope to restore and the restart order;
- the backups to use and the emergency access, with whoever holds it;
- step-by-step procedures, with expected timing and a checkpoint;
- the criteria that prove a system is usable again;
- the return to normal, then keeping the plan up to date.
Sample procedure sheet (fictional example)
| Field | Content |
|---|---|
| System | Case management software |
| Depends on | Internal network, directory, database server |
| Triggered by | Crisis lead, once the directory restart is confirmed |
| Run by | Provider’s engineer; named deputy |
| Steps | Numbered, each with its expected result |
| Business check | A staff member opens a case and saves a change |
| If it fails | Named escalation, and switch to the BCP fallback mode if planned |
The business continuity plan (BCP)
A BCP answers a different question: if your usual IT isn’t available, how do you keep going on what can’t stop? It starts from your business activities. Each measure has an owner, resources, limits and a trigger:
- a temporary manual procedure (for example, numbered paper order forms);
- a backup communication channel;
- a degraded operating mode: urgent cases first;
- a fallback solution prepared in advance;
- a temporary team organisation;
- delegated decision rights;
- ready-to-send messages for customers and suppliers;
- criteria for switching to fallback mode and back.
A BCP relies on your business teams’ commitment. We design it with them; you organise and run it.
For business crisis exercises, we can bring in a partner.
Your recovery objectives: you set them
Two ideas are enough:
- Recovery time objective (RTO): how quickly a system or activity must be running again.
- Recovery point objective (RPO): how much data you can afford to lose. If the last usable copy is from last night, everything entered since is gone.
| Value | Who sets it |
|---|---|
| Tolerable downtime for the activity | You, based on business impact |
| Recovery time objective | You, on our proposal, with a margin |
| Time actually measured | CERVOX, during a test |
| Final decision | You, comparing the three values above |
How the plan is built
| Step | What you get |
|---|---|
| 1. Interviews with leadership and business owners | Interview notes |
| 2. Essential activities identified | List of priority activities |
| 3. Systems, data and dependencies | Dependency map |
| 4. Recovery objectives set and approved | Approved objectives table |
| 5. Current capability assessed | Results of a recovery test |
| 6. DRP and BCP procedures built | DRP, BCP if retained, crisis contact list |
| 7. Fixes prioritised | Action plan |
| 8. Exercises and tests | Exercise and test reports |
| 9. Review and upkeep | Update schedule |
What you receive
- For the DRP: the approved document, one procedure sheet per system, the crisis contact list, the list of open points, the exercise schedule.
- For the BCP, if retained: the activities to maintain, the continuity measures and their owners, switch-over and return criteria, message templates, the exercise report.
- In both cases: your recovery objectives table, approved in writing.
What a plan doesn’t do
A plan that has never been run is still just an intention. It counts as operational only after a successful exercise or test on its scope. You remain the decision-maker and the one who runs it; we don’t give legal advice on your obligations.
Check that a plan actually runs: CERVOX Jour ZéroFAQ
What’s the difference between a DRP and a BCP?
A DRP brings your systems back after an outage. A BCP keeps your essential activities going during that outage.
Do we need a BCP?
Only if some activities can’t wait for the restore to finish. We help you work that out.
Who sets the recovery times?
You do. We explain, offer options and show the consequences; you approve in writing.
Should we test before writing the plan?
It isn’t required, but it’s stronger: the plan then rests on an observed restart order and observed times rather than assumptions.
Do our obligations require a DRP?
Some contractual or regulatory obligations may set recovery times or tests. Check them with your advisers.
Do you run crisis exercises?
Yes for exercises on restoring your systems; for business crisis exercises, we can bring in a partner.
Build a plan that holds under pressure
Tell us where you stand: no plan, an old plan, or a plan that’s never been exercised.