Home›Guides›DRP and BCP

DRP and BCP

How often should you test your DRP?

Check automatically that the copies still boot, at least every month, and run a real failover, with a genuine business task, at least once a year. Test again as soon as the server, the network, the provider or the person holding the key changes.

Updated October 20263 min read6 sources cited

Key points

  • Every day: review backup failures. Every month: technical boot of the standby system.
  • Every quarter: a timed restore. Every year: a real failover with failback.
  • NIST provides for an annual test of recovery capabilities; CERT-MU and ANSSI require regular testing.
  • Any major change (server, major version, administrator, provider, Internet link) triggers a test.
  • What matters most: the written date of the last test and the gaps that were fixed.

What the frameworks say

  • NIST. The SP 800-34 guide, written for US federal systems, provides for testing recovery capabilities and teams every year in order to identify weaknesses. The plan itself must be kept up to date at a frequency set by the organisation, for example every year, and after every major change.
  • CERT-MU. Mauritius’s national computer emergency response team recommends, in its guideline on devising a backup plan, an off-site copy and regular restore tests. The Data Protection Act 2017 (section 31), for its part, requires appropriate security measures against the loss or destruction of personal data.
  • ANSSI (France’s national cybersecurity agency). Backups must be tested regularly, and a procedure for restoring the information system must be written and regularly carried out. For crisis exercises, the agency recommends thinking in terms of a multi-year strategy, with formats that gradually increase in scope.

None of these texts requires “every month under real conditions”. All of them point towards frequent checks and a full test at least once a year.

Why not “every month under real conditions”

A real failover interrupts, or risks interrupting, production. Doing it every month is costly in hours and fatigue, and teams end up rushing it. A serious annual test is better than a monthly ritual in which nobody opens the application.

On the other hand, waiting a year to discover that a backup no longer boots is too long. Hence the frequent, lightweight technical check, and the rare but complete business test.

A sustainable schedule for an SME

WhenWhat
Every dayReview backup failures. A DRP fed by a broken copy is a broken DRP
Every monthTechnical boot of the standby system, without cutting production
Every quarterTimed restore of a file or a database
Every yearReal failover or equivalent, with a business user and failback
At every changeNew server, new major version, departure of the administrator, change of provider or Internet link

Highly regulated sectors or critical systems (healthcare, continuous manufacturing) shorten the “every year” line, sometimes to every six months. That is not the minimum standard for a services SME. Each level is detailed in How do you test a DRP?.

What matters more than frequency

The written date of the last test, and the gaps that were fixed. A DRP tested eleven months ago, with a report, is in better shape than a DRP “tested continuously” with no record of what was checked. NIST requires every exercise to produce a report recording the observations and recommendations for improvement.

If the last test is more than twelve months old, tell management exactly that. It is information, not a disgrace. The mistake is to tell a customer or an insurer that the plan is operational.

After a real incident

A real disaster is a test, provided you write the report within the week: what took longer than planned, what was missing, what you change in the plan. Without that, you suffer the same way twice. See also My server is down: what should I do?.

At WeDoBack

The boot check is monthly and included in the DRP, without touching production: it covers the “every month” line of the table, for the image, not for the business task. The test under real conditions is scheduled, for up to ten hours, on a quote basis: it is the natural candidate for the annual line. Nothing in the offer tests the human procedure on your behalf (who decides, where the key is, how the team is alerted). That part follows the pace of departures and new hires, not the pace of the software.

Frequently asked questions

Is there a legal requirement on test frequency?

There is no general rule for all SMEs. CERT-MU and ANSSI, France’s national cybersecurity agency, ask for “regular” testing without setting a pace; the Data Protection Act 2017 (section 31) requires appropriate security measures, without a set frequency. NIST, for US federal systems, settles on an annual test. Some regulated sectors, or your contracts and your insurer, may require a more frequent schedule.

Does a real disaster count as a test?

Yes, provided you write the report within the week: what took longer than planned, what was missing, what changes in the plan. Without that record, the incident does not help improve the plan.

What should you tell a customer or an insurer if the last test is more than a year old?

The truth, with the date. Stating that a plan is operational without a recent test exposes you to a gap between the promise and reality on the day of the disaster. It is better to give the planned date of the next test.

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.