This is necessary and important. It is not sufficient. A system restored to operational status is not a system restored to operational integrity unless the data it operates on is also intact, consistent, and trustworthy. The recovery that brings systems online with corrupted, manipulated, or incomplete data has restored availability while creating a different and potentially more serious problem: an operational state that appears normal and is not.
What Data Integrity Means in Recovery
Data integrity in a recovery context means that the data the restored system operates on accurately reflects the actual state of the business processes and transactions it supports. A financial system restored from backup is available. If the backup contains fraudulently altered transaction records that were modified before the incident was detected, the restored system processes those fraudulent records as if they were legitimate. The system is available. The data is corrupted. The operational problem the availability recovery was supposed to solve has been replaced by a data integrity problem that may be harder to detect and more damaging to address.
This scenario is not theoretical. Ransomware attacks have increasingly included a data corruption or manipulation phase designed to ensure that backups contain compromised data. The attacker's goal is to make recovery more difficult by compromising the backup data that the recovery depends on, or by making the organization uncertain whether the backup data is trustworthy. An organization whose recovery planning does not include data integrity verification cannot confirm that the data it is recovering from is the data it believes it is recovering from.
A recovery plan that restores systems to availability using data whose integrity has not been verified is a plan that may restore a corrupted operational state. Availability recovery and data integrity recovery are different recovery objectives that require different planning.
Where Recovery Planning Stops Short
Backup Strategies That Don't Verify Integrity Before Recovery
Backup verification programs typically confirm that backups complete successfully and that backup files are restorable to a functioning system state. They verify availability of the backup data. They do not typically verify that the backup data accurately represents the business state it is supposed to capture. A backup of a database table that was modified by an attacker before the backup ran captures the modified state. The backup completed successfully. The backup data is restorable. The data is corrupted.
Recovery Time Objectives That Don't Include Integrity Verification Time
RTO definitions describe the time to restore operational availability. They do not typically include the time required to verify data integrity before declaring recovery complete. An organization whose RTO is four hours and whose data integrity verification process takes six hours after availability is restored has an actual recovery time of ten hours that its planning does not reflect. The mismatch between the availability RTO and the integrity verification timeline produces pressure to skip or abbreviate integrity verification in order to meet the stated RTO.
Recovery Testing That Tests Availability, Not Integrity
Business continuity testing exercises typically assess whether systems can be restored to operational status within the RTO. They assess availability recovery. They do not typically include a data integrity verification component that confirms the restored data accurately represents the pre-incident operational state. The testing confirms that the recovery procedure works for the scenario it tests. If the scenario does not include a data integrity challenge, the test does not assess whether the recovery procedure can address one.
Building Data Integrity Into Recovery Planning
Recovery planning that accounts for data integrity requires addressing three gaps that most recovery plans do not currently address.
Known-good backup validation. Maintaining a capability to identify the most recent backup state that can be verified as uncompromised by the incident — not simply the most recent backup — requires either immutable backup storage that prevents modification after backup, cryptographic integrity verification of backup data against records created at backup time, or both. Without a known-good backup state, recovery from a data manipulation attack may restore from compromised data.
Integrity verification as a recovery phase. Defining data integrity verification as an explicit phase of the recovery procedure, with defined verification methods, defined acceptance criteria, and a defined timeline, makes integrity verification a required step rather than an optional post-recovery activity. The RTO should reflect the full recovery time including the integrity verification phase.
Recovery testing that includes data integrity scenarios. Business continuity exercises that include a data integrity challenge — tabletop scenarios in which backup data has been modified, recovery testing in which participants must identify the last known-good backup state — validate the recovery procedure against a realistic attack scenario rather than against an availability-only failure scenario.
Restore availability. Then verify the data. Recovery is complete when both are confirmed.
Include data integrity verification in the recovery RTO. Test recovery against scenarios that include data integrity challenges. The ransomware actor who corrupted your backup is betting that your recovery plan does not cover this.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.