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”).
| Level | What it proves | What it does not prove | Impact on production |
|---|---|---|---|
| A. Tabletop | The document, the contacts, the roles | That the technical systems work | None |
| B. Isolated restore | That the standby starts and the application opens | The network failover and the failback | None |
| C. Real failover | The 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.
Sources
Documents consulted in October 2026.
- SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities (September 2006) — NIST
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Organising a cyber crisis management exercise — ANSSI
- Guide to drawing up a business continuity plan (2013 edition) — SGDSN
- Backing up information systems – The fundamentals (ANSSI-BP-100, v1.1, 27 November 2025) — ANSSI
- DRP offer: recovering operations after a disaster — WeDoBack
Planning a backup, DRP or BCP project?
More than 20 years of experience protecting business data.
Request a quote+33 9 72 50 78 28Protect your data with WeDoBack
Encrypted offsite backup, immutable storage, DRP and BCP: tell us about your servers and we will recommend the right combination.
