Your backup is not a backup until you have restored from it
Most organisations discover their recovery gaps during an incident. A restore test takes an afternoon and answers the question in advance.
Almost every organisation we assess has backups. A much smaller number have ever performed a full restore. The gap between those two states is where most recovery failures live.
The failures that only appear during a restore
Backup jobs report success while silently skipping locked files. Retention is shorter than the time it takes to notice a compromise. The backup system authenticates against the same directory as everything else, so an attacker who reaches the domain reaches the backups too. Recovery depends on a credential that left with someone.
None of these show up on a backup dashboard. They surface when somebody needs the data back.
What a restore test involves
Pick a representative system. Restore it to isolated infrastructure. Time the process end to end, including the parts that are not technical — locating credentials, deciding who authorises the restore, confirming the data is intact once it is back.
The output is two numbers you can give the business: how long recovery actually takes, and how much data you would lose. If those numbers differ from what the business assumes, that gap is the finding.
Immutability and separation
Ransomware groups target backup infrastructure first, because an organisation that can restore does not pay. Backups should be immutable for their retention period and should not be reachable using production credentials.