Backup is the control with the widest gap between how organisations rate themselves and what they can actually show. Almost everyone backs up. Far fewer can demonstrate that a restore succeeds at the required scope and within the required time. That gap is why assessors work the subject backwards: they start at recovery and reason back towards the backup.
The restore test is the control
A backup is a state. A recovery is a process. Everything that can go wrong between the two only becomes visible in the process: unreadable media, incomplete backup sets, missing system state, unknown dependencies between applications, no credentials for the recovery environment, an encrypted backup set with no available key. The success message from the backup job says nothing about any of these.
A test worth the name is therefore different from pulling a sample file back. At minimum it should record which system was restored in full, how long that took, what data state was reached, what deviations occurred, and who signed off on the result. Those five items are the evidence an audit expects, and they are also the only reliable basis for checking your own recovery objectives.
Backup and recovery, side by side
| Trait | Backup | Recovery |
|---|---|---|
| Subject | a state: the copy | a process: bringing it back |
| Runs | planned, usually automated | triggered, usually under time pressure |
| Measures | scope, frequency, retention | time to operational readiness and data state reached |
| Fails through | missing scope, aborted runs | sequence, missing access, unknown dependencies |
| Produces as evidence | a run log | a test record with duration, data state, deviations and sign-off |
| Evidential value in an audit | proves that something was written | proves that something comes back; that is the actual control |
The last row is the whole point of the table: a run log proves a file exists, not that an operation can be restored.
What testing turns up
Three findings repeat regardless of size or sector.
Sequence. Systems cannot be restored in arbitrary order. Directory services, name resolution and time sources are routinely overlooked, because backup planning treats them as ordinary systems while recovery makes them a precondition for everything else.
Access. The credentials for the recovery environment live in the system that is currently unavailable. The same is true of the key to an encrypted backup set. Both belong in a separate, independently protected store.
Coverage. You back up what was in the plan. What has arrived since (new applications, outsourced services, data held in cloud services) often is not. Reconciling backup coverage against the inventory of systems is therefore a step of its own, not a by-product.
Protecting the backup itself
Backup sets are a preferred target precisely because destroying them prevents recovery. What works is a copy separated from the production network and from production credentials, together with protection against modification and premature deletion. Role separation matters just as much: whoever holds administrative rights in the production system should not be able to delete backup sets. That separation is simultaneously an access control checkpoint, which is why the two subjects are usually audited together.
What the law actually asks for
Art. 32 GDPR expressly requires the ability to restore the availability of and access to personal data in a timely manner after an incident, and a process for regularly testing and evaluating the effectiveness of the measures. Taken together, those two are the clearest basis for the proposition that an untested backup does not meet the requirement.
For organisations in scope in Germany, the catalogue of measures in § 30 Abs. 2 Satz 2 BSIG (the German BSI Act, which implements NIS2 in Germany) names, in Nr. 3, maintaining operations, including backup management and recovery after an emergency, together with crisis management. The statutory wording puts backup and recovery expressly side by side and files both under the continuity of operations rather than under data storage. That framing is worth borrowing even where the statute does not bind you: a German customer running supplier due diligence will read your backup arrangements as a continuity control, and will expect restore evidence rather than job logs.
The clearest testing duty of all sits in Regulation (EU) 2022/2554 (DORA). Its Article 12, headed "Backup policies and procedures, restoration and recovery procedures and methods", separates the two sides of the topic in its title alone:
- Paragraph 1(a) requires documented backup policies and procedures that set the scope of data to be backed up and the minimum backup frequency, based on the criticality of the data or the confidentiality level: the scope has to be justified, not merely decided.
- Paragraph 1(b) separately requires restoration and recovery procedures and methods.
- Paragraph 2 ends with the sentence that matters here: the backup, restoration and recovery procedures and methods shall be regularly tested. Testing is therefore an express statutory duty, not merely good practice.
- Paragraph 3 requires that where an entity's own systems are used to restore backed-up data, the recovery environment must be physically and logically segregated from the source IT system, and itself protected against unauthorised access.
- Paragraph 6 ties recovery time and recovery point objectives to whether a function is critical or important: targets follow business significance, not the technology.
These provisions apply directly only to financial entities within DORA's scope. Outside the financial sector, they remain the most precise available statement of what an assessor means by a defensible backup and recovery regime: a benchmark to hold yourself to, not a duty that reaches you automatically.
The target values for recovery time and tolerable data loss do not come from the technology. They come from the business impact analysis. There are no generally applicable benchmarks; backup planning is the implementation of objectives set on the business side, and it is measured against them.
What assessors ask
Expect: which systems and data sets are backed up, and what that selection is derived from? When was a full restore last performed, and how long did it take? Where is the copy that is separated from the production network? Who can delete backup sets? Where are the keys and emergency credentials held? And finally: what was the outcome of the last test, and what followed from it?
The last question often decides the finding. A test that surfaces deviations and leads to documented improvements reads better in an audit than one that succeeds without exception: the latter invites the suspicion that it was scoped narrowly enough to succeed.
Restore evidence worth keeping
Useful evidence comprises the backup concept with coverage and responsibilities; a reconciliation of backup coverage against the inventory of systems; logs of backup runs including the failed ones; the documented result of the last restore test with duration and data state reached; tracking of the deviations it found; proof that a copy is held separately; and the rule governing where keys and emergency access are deposited.
The test is the evidence
The distinction between backup and recovery has a practical consequence for evidence: proof that a backup works is not a success log from the backup run but the result of a restore. In Rizzqo that is exactly the form in which a requirement gets closed.
The requirement appears on the object whose category it concerns, meaning the system or service in question. The owner answers it, attaches the restore test result and finalises the answer under a name and a timestamp; until then it counts as a gap, even when already marked fulfilled. How strict the target has to be follows from the inherited protection needs of the primary assets the system carries. And because the backup environment is an object in its own right, it stands out when production and backup hang on the same provider or site.