Verify the integrity of backups and restoration assets before use
Restoring from a corrupted or compromised backup is one of the worst outcomes during incident recovery: it can re-introduce malware, restore a broken state, or cause data loss that compounds the original incident. Before any backup or restore asset is used, its integrity must be confirmed through cryptographic verification or a test restore. This control is especially important in ransomware scenarios, where attackers often target backup systems specifically. Catching a bad backup before restoration saves significant time and prevents making the situation worse.
Implementation steps
- 1
Identify the candidate backups for each system to be restored
Pull the backup catalog for each affected system and identify the most recent clean backup, based on the incident timeline. Backups created after the suspected intrusion start date should be treated as potentially compromised and should not be used without additional scrutiny.
veeamaws-backupazure-backupcommvault - 2
Verify backup integrity using checksums or a test restore
For each candidate backup, run a checksum or hash verification against the stored manifest. Where possible, perform a test restore to an isolated environment to confirm the backup is readable and produces the expected state. Document the result of each verification check.
veeamaws-backupazure-backupcommvaultrestic - 3
Confirm backups pre-date the intrusion and are free of indicators of compromise
Cross-reference the backup timestamps against the incident timeline established by the IR team. For high-risk incidents, run a malware scan or forensic check on the restored files before bringing them into production. Document the approved backup snapshot that will be used for each system.
crowdstrikesentinel-onedefenderveeam
Evidence required
Backup integrity verification records
Documented results showing that checksums, hashes, or test restores were completed for each backup used in recovery.
- · Veeam or Commvault verification job logs with pass or fail status
- · Checksum comparison report from the backup tool
- · Test restore completion log in an isolated environment
Backup selection rationale
A record showing which backup snapshot was selected for each system and why it was considered clean relative to the incident timeline.
- · Incident ticket note listing selected backup date and reason
- · Backup catalog screenshot with selected restore point highlighted
- · IR team sign-off confirming the backup pre-dates the intrusion window
Malware scan or forensic clearance
For incidents involving malware, evidence that restored files were scanned or reviewed before being placed back into production.
- · EDR scan report on restored data with no findings
- · Forensic analyst sign-off on restored snapshot
- · Antivirus scan log from isolated restore environment
Related controls
Execute the recovery plan once the incident response process initiates recovery
Incident Recovery Plan Execution
Select, scope, prioritize, and perform recovery actions
Incident Recovery Plan Execution
Re-establish critical mission functions and cybersecurity services
Incident Recovery Plan Execution
The integrity of restored assets is verified, the asset is deemed secure, and normal operating status is confirmed
Incident Recovery Plan Execution