Start with one business question: if operations stop tonight, what must come back first?

The right question is not “do we have a backup?” but “can we bring back, quickly and without surprises, the data that keeps the business running?”. CNIL says backups should be tested regularly for integrity and restore capability, while ANSSI treats backup and restoration as dedicated operational processes with procedures and tests.

For an SME, “essential data” does not mean “everything we keep forever”. It means the minimum needed to restart: active customer files, open orders, recent invoicing, product reference data, access rights, and sometimes a key application database or import/export file. The usual trap is restoring a huge volume and then discovering that the last usable export is missing—or that the application cannot read the data anymore.

  • Goal: prove restore capability, not just backup existence.
  • Scope: only what is needed to resume operations.
  • Main risk: finding out it failed on outage day.

A practical 5-step method for a realistic test

Step 1: pick a scenario. Keep it concrete: server failure, accidental deletion, ransomware, or data corruption. NIST stresses the value of incident-specific recovery playbooks and exercises to improve recovery.

Step 2: define the target state. For each critical dataset, note the acceptable recovery date, where the backup sits, and the expected restore format: file, database, virtual machine, or importable export. CNIL recommends keeping at least one backup offline and one on a separate site.

Step 3: test in a separate environment. Restore into a sandbox, never straight into production. First confirm the medium can be read, then the files open, then the application restarts and reconnects to its data relationships. ANSSI and CNIL both emphasize integrity and restore capability, not only the existence of a backup.

  • 1. Choose a plausible incident.
  • 2. Define minimal data and the target date.
  • 3. Restore in isolation.
  • 4. Check readability, consistency, and app restart.
  • 5. Record gaps and fix them.

Fictional numerical example: 4 hours to restart, not 4 days

Suppose a wholesale SME needs to recover customer orders, active client files, and this week’s invoices. It tests a restore on an isolated machine, using an offline backup from the previous day and an older secondary replica. Result: the files open, but two linking tables are corrupted and a financial export fails to import. The test reveals a real issue before the outage, not during it.

In this fictional scenario, the company sets a simple rule: critical data restored in under 4 hours, the rest of the history later. That is not a universal promise. It is an operational target that must be calibrated to your activity, contracts, and technical constraints. CNIL also notes that when availability requirements are high, replication to a secondary site can be relevant.

  • A restore test should expose hidden dependency failures.
  • Set practical targets by business need, not by habit.
  • Use your own constraints to calibrate the recovery window.

What the test does not prove

A successful restore of a sample does not prove that a full recovery will work. Likewise, restoring files does not necessarily validate permissions, automations, ERP integrations, or the handling of personal data after restart. CNIL also reminds organizations to protect backups and backup systems appropriately, and to use logging to understand the origin of an incident.

Another common limit is freshness. A usable backup may still be too old for the business need. That is why technical restoration must be separated from business expectations: “the data is back” is not the same as “operations can restart without breaking customer service, payroll, or invoicing.”

  • Testing a sample may not cover full recovery.
  • Restore tests must include rights, dependencies, and imports.
  • A usable backup can still be too old for the business.

A 7-day checklist: who owns it and what you should observe

Day 1 — CEO or general manager: approve the list of 5 to 10 essential datasets. Observable result: a short, dated, approved list.

Day 2 — IT lead or managed service provider: identify the source backup and the test target. Result: documented restore path.

Day 3 — Business owner: define acceptance criteria. Result: everyone knows what must open, import, and recalculate.

  • Day 4 — IT: restore in an isolated environment. Result: an exploitable copy outside production.
  • Day 5 — Business team: check 10 real cases. Result: issues listed, not guessed.
  • Day 6 — IT + business: fix at least one priority gap. Result: an improved retest.
  • Day 7 — Management: decide the next test frequency. Result: a revalidation date on the calendar.