Home›Guides›DRP and BCP

DRP and BCP

How do you test a DRP?

You test a DRP by trying to work on the standby environment, not by rereading the document. The weakest test is a meeting; the strongest is a real failover with users, followed by a failback. In between, a series of levels lets you make progress without bringing the company to a halt each time.

Updated October 20264 min read6 sources cited

Key points

  • Level A, tabletop test: is the document still accurate? Two to three hours, without touching the technical systems.
  • Level B, isolated restore: does the standby start and does the application open, without cutting off production?
  • Level C, real failover: the only one that measures the RTO and tests the failback.
  • An automatic boot check is useful, but it does not prove that the business can work.
  • Every test produces a dated report: times, gaps, decisions.

What the reference frameworks say

The SGDSN, the French government’s general secretariat for defence and national security, recommends three complementary approaches: having the documents checked, ideally by a trusted third party; testing how the arrangements are implemented, for example by failing certain functions over to a backup site; and finally checking, through exercises, that the procedures are known, understood and can be applied within the planned timeframes. ANSSI, France’s national cybersecurity agency, states in its backup guide that a procedure for restoring the information system should be written and regularly carried out.

NIST, the US standards body, distinguishes two forms of exercise. The tabletop exercise is a discussion in which each participant describes their role in response to a scenario. The functional exercise has participants carry out the real actions in a simulated environment. The three levels below follow this progression.

Level A. Tabletop test

The people named in the plan go through the steps out loud, with their phones in front of them. You check that the numbers answer, that the key can be found and that the server order is still correct. Duration: for a tabletop cyber crisis exercise, ANSSI allows two to three hours, including briefing and debriefing, and around six weeks of preparation; NIST mentions two to eight hours depending on the objectives. Minimum frequency: after each departure of a key person. This level proves nothing about the technical side. It proves that the document is still accurate.

Level B. Isolated technical restore

You restore or start the standby without cutting off production. You log in. You open the application. You record the time from the decision to the business screen. Real users are not switched over. This is the test that reveals a missing disk, a licence, a password or a closed network.

Limitation: since production was not cut off, you have not proved the failover step (DNS, IP, agent) or the failback.

Level C. Real failover, in an announced time slot

One evening or on a Sunday, production is stopped or traffic is sent to the standby. A few users carry out a genuine business task: issuing a document, checking off an order, reading a file. Then you fail back and check that the entries made on the standby have not been lost.

This is the only level that measures the RTO and tests the failback. It is planned, it is communicated and it has a stop criterion (“if the standby is not up by 11 pm, we cancel”).

LevelWhat it provesWhat it does not proveImpact on production
A. TabletopThe document, the contacts, the rolesThat the technical systems workNone
B. Isolated restoreThat the standby starts and the application opensThe network failover and the failbackNone
C. Real failoverThe actual RTO, business work, the failback—Announced time slot

Checklist before level C

  • Date and time slot approved by management, users informed.
  • Last successful backup verified, encryption key at hand.
  • Stop criterion written down, with the deadline and the person who decides.
  • One business user per application tested, with a specific task to carry out.
  • Failback procedure reread, and production backed up just beforehand.
  • One person tasked with recording times and gaps as they occur.

What the report should contain

Date, level, people, start time, time at which the business task succeeded, gaps, decisions. A sentence such as “test OK” is of no use six months later. NIST calls this document an after-action report: it records observations and recommendations for improving the plan. ANSSI makes lessons learned a step in its own right in every exercise.

What an automatic boot test proves, and what it does not

Some services start the copies every month and check that they boot. This is useful: an image that no longer boots is detected without disrupting production. It is not a level C test. The application may be broken, the database inconsistent, the failover network untested and the failback unknown. Presenting this check as “the DRP has been tested” is inaccurate. What should be said is: “the boot of the images is checked; the business failover is not yet”.

At WeDoBack

The monthly test included with the DRP falls into this last category: an automatic procedure starts the stored instances and reads their boot screen, without touching production. A test under real conditions, corresponding to level C or an extended level B, is available for up to ten hours and is subject to a quote. Both have their role. One does not replace the other. Human support is available from 9 am to 1 pm and from 2 pm to 5:30 pm (Paris time), on +33 9 72 50 78 28: a real test is scheduled within these hours, or explicitly planned outside them.

Frequently asked questions

Can you test a DRP without stopping production?

Yes, for levels A and B: the tabletop test and the restore in an isolated environment do not touch production. Only the real failover (level C) requires an announced time slot, in the evening or at the weekend, with a stop criterion defined in advance.

Who should take part in the test?

The people named in the plan: the person who decides to fail over, the person who administers the systems, the person who holds the encryption key, and at least one business user able to check that they can actually work. Without a business user, you are testing IT, not business recovery.

What should you do if the test fails?

That is the purpose of a test: finding what does not work before a disaster strikes. Record the gap, fix it and schedule a new test on that point. Both NIST and ANSSI stress the importance of lessons learned, which turn a failure into an improvement of the plan.

Planning a backup, DRP or BCP project?

More than 20 years of experience protecting business data.

Request a quote+33 9 72 50 78 28

Protect your data with WeDoBack

Encrypted offsite backup, immutable storage, DRP and BCP: tell us about your servers and we will recommend the right combination.