After an incident, the question that dominates the crisis room is almost always the same: "when are we back up and running?" It is a legitimate question, and most organisations have invested seriously in being able to answer it: frequent backups, replicas in other regions, tested recovery procedures. There is, however, a second question that usually arrives later, often in the voice of an auditor or a regulator: "how do you know the data you restored is correct?"
Recovering data and verifying its integrity are different operations with different goals. Treating them as the same thing is one of the most common ways for an organisation to put back into production exactly the problem it was trying to get rid of.
What a successful restore proves, and what it does not
When a backup tool reports that a restore completed successfully, it is normally stating three things: the copy was read without errors, the data was written to the destination and, in many cases, the copy's checksums match those calculated when the backup was taken. This guarantees that the copy came back as it was stored.
It does not guarantee that what was stored was correct. If the data was already altered, corrupted or incomplete when the copy was made, the restore faithfully reproduces that state. The backup checksum protects against degradation of the copy; it says nothing about the integrity of the content against the reality it is supposed to represent.
A successful restore proves that the copy came back. It does not prove that the copy was right.
How compromised data ends up in backups
Attacker dwell time
In many attacks, the initial intrusion happens well before the moment the impact becomes visible. During that period the attacker can alter data, create accounts, install persistence mechanisms or prepare encryption. Every backup taken in that interval captures the already-compromised environment.
Silent changes
Not all tampering is spectacular. A change to a supplier's IBAN, a clinical record or a configuration parameter can go unnoticed for weeks. If nobody has an independent reference for the correct state, the altered version becomes, by default, the "true" version.
Logical corruption and application errors
A badly executed migration, a bug in a synchronisation routine or a partial write failure can corrupt data consistently and replicate the corruption. The backup copies the error just as effectively as it copies correct data.
Insider threats
A user with legitimate access can modify records and, in some cases, also the copies or logs that would allow the modification to be detected. Without a reference out of their reach, detection depends on luck.
What to check before you trust a restore
The list below does not replace a recovery plan, but it identifies the checks that distinguish "we recovered" from "we recovered data we can trust".
- Is there an independent reference for the correct state? Without a record of the known-good state, stored out of reach of whoever compromised the environment, there is nothing to compare against. That reference must pre-date the incident and be verifiable.
- Does the fingerprint of what was restored match the reference? Calculate the cryptographic fingerprints of the restored files or records and compare them with the ones that were sealed. An exact match is the only strong proof that the content has not changed.
- What is the last provably clean point? Instead of restoring the most recent copy by default, identify the most recent point in time whose state matches the reference. That is the defensible recovery point.
- Is everything there? Check completeness: missing files, removed rows or periods with no records. A copy that is intact but incomplete is still a problem.
- Does the application accept the data? Run consistency checks at the application and database level, including referential integrity and critical business rules.
- Is the restored environment free of the attack vector? Confirm that restored accounts, credentials, scheduled tasks and configurations do not reintroduce the attacker's access.
- Can you demonstrate all of this to a third party? Document each check with a timestamp and a result. Evidence of the recovery process is itself a requirement under frameworks such as DORA and NIS2.
Selective recovery: restoring only what changed
A practical consequence of having a verifiable reference is that recovery stops being an all-or-nothing operation. If you can identify precisely which files, versions or table rows diverge from the sealed state, recovery can be segmented: you restore only what was affected, down to a single file version or a single row. This reduces downtime, limits the loss of legitimate data created after the last backup and makes the result easier to audit.
What regulators expect
DORA devotes Article 12 to backup, restoration and recovery policies and procedures, and requires financial entities to test those procedures periodically. NIS2 includes, among the minimum measures in Article 21, business continuity, notably backup management and disaster recovery. In both cases the expectation goes beyond having backups: organisations are expected to be able to recover in a controlled way and to demonstrate that they did.
An organisation that can show, with independent evidence, that restored data matches a verified state is in a very different position from one that can only show that the restore job finished without errors.
How ROOTKey helps
ROOTKey adds to your recovery process the piece that is usually missing: the independent reference. Every asset receives a unique fingerprint, sealed on an independent public registry, and continuous monitoring compares your data against that registry, alerting on any modification.
When recovery is needed, it uses only the state that matches the sealed record. Automated recovery points let you know with certainty that the data is clean before you restore, and recovery jobs can be full or segmented, down to a single file version or table row. No guesswork, just clean data, independently verified. Learn more in Data Recovery.