When something goes wrong, you restore.
When data is lost, you recover.
When systems fail, you roll back.
Backups are essential.
But after a cyber incident, they answer the wrong question.
The real question is not “Can we restore the data?”
It is:
“Can we prove the data is still true?”
Recovery is not the same as verification
After an incident, organisations rush to bring systems back online.
Backups do their job: files reappear, databases are restored, services resume.
But something critical is missing.
A backup can tell you:
• what data existed at a certain point in time,
• what version was restored,
• when the restore happened.
It cannot tell you:
• whether the data was already compromised before the backup,
• whether records were altered silently,
• whether the information can be trusted as evidence.
Recovery gives you continuity.
Verification gives you credibility.
The dangerous assumption behind backups
Most organisations operate under an implicit assumption:
“If it came from a backup, it must be correct.”
After an incident, that assumption becomes a liability.
Attackers don’t always delete data.
They modify it. Subtly. Selectively. Quietly.
A single altered field.
A changed timestamp.
A modified clause in a document.
Backups faithfully preserve all of it - including the compromise.
From a technical perspective, everything looks fine. From a legal, regulatory, or audit perspective, everything is questionable.
Auditors don’t ask for backups. They ask for proof.
When auditors, regulators, or legal teams step in, they are not interested in recovery success.
They ask different questions:
• How do you know this record wasn’t altered?
• Can you prove this document existed in this exact form at that time?
• What evidence do you have that this data is authentic?
“Because we restored it from backup” is not an answer. It’s an assumption - and assumptions don’t survive scrutiny.
Without verifiable proof:
• audits slow down or fail,
• compliance reports are challenged,
• legal positions weaken,
• decisions are delayed.
The problem isn’t storage. It’s trust.
Most security strategies are built around protecting storage:
• encrypt the database,
• harden access,
• replicate data,
• back it up.
All necessary. None sufficient.
Trust does not come from where data is stored.
It comes from whether its integrity can be independently verified.
After an incident, trust must be earned - not assumed.
And trust that depends on internal systems alone is fragile, especially when those systems were just compromised.
Proof must exist outside the blast radius
If the only evidence you have lives inside the same systems that were attacked, you don’t have evidence - you have uncertainty.
Real proof has three properties:
• Immutable: it cannot be changed retroactively
• Timestamped: it proves when something existed
• Independent: it survives even if internal systems fail
Without these properties, data may be recoverable - but it is not defensible.
Backups are necessary. They are not enough.
This is not an argument against backups.
It’s an argument against relying on them for something they were never designed to do.
Backups are about availability.
Proof is about integrity.
Continuity without credibility is fragile.
And in regulated, high-stakes environments, fragility is a risk organisations can’t afford.
In the next article, we’ll explore what it actually means to prove data integrity by design - and why verification must start at creation, not after an incident.
Because after a breach, the question is no longer whether you recovered the data - it’s whether anyone can trust it.
Erhalten Sie Einblicke zur Cyber-Resilienz per E-Mail
Praktische, auditfähige Hinweise zu Datenintegrität, Compliance und Kontinuität – sobald wir veröffentlichen.