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 carry out a real failover, with a genuine business task, at least once a year. Test again as soon as the server, the network, the service 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.
  • Every quarter: a timed restore. Every year: a real failover with failback.
  • NIST, the US standards body, calls for an annual test of recovery capabilities; the CNIL, France’s data protection authority, and ANSSI, France’s national cybersecurity agency, call for regular tests.
  • Any significant change (server, major version, administrator, service provider, Internet link) triggers a test.
  • What matters most: the written date of the last test and the gaps that have been fixed.

What the reference frameworks say

  • NIST. The SP 800-34 guide, written for US federal systems, calls for recovery capabilities and teams to be tested 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 significant change.
  • CNIL. Its guide to the security of personal data calls for regular testing of backup integrity, of the ability to restore backups and of the application of the business continuity or disaster recovery plan.
  • ANSSI. 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”. They all 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 frequent, lightweight technical checks, and rare, complete business tests.

A realistic 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, without cutting off 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 service provider or Internet link

Highly regulated sectors or critical systems (healthcare, continuous industrial processes) shorten the “every year” line, sometimes down to every six months. That is not the minimum standard for a service 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 have been fixed. A DRP tested eleven months ago, with a report, is in better shape than a DRP that is “tested continuously” but with no record of what was checked. NIST requires every exercise to produce a report recording observations and recommendations for improvement.

If the last test is more than twelve months old, tell management exactly that. It is information, not a source of shame. 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 expected, what was missing, what you are changing in the plan. Otherwise, you will 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. A test under real conditions can be scheduled, for up to ten hours, on the basis of a quote: 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 for testing frequency?

There is no general rule for all SMEs. The CNIL, France’s data protection authority, and ANSSI, France’s national cybersecurity agency, call for ‘regular’ testing without setting a frequency. NIST, the US standards body, specifies an annual test for US federal systems. 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 expected, what was missing, what changes in the plan. Without this record, the incident does not help improve the plan.

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

The truth, with the date. Claiming 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 state 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.