Would your backups survive the same incident as your servers?

A successful backup notification tells you a copy was made. It does not tell you whether an attacker with access to your systems could delete that copy, whether it contains everything you need, or whether your team knows how to restore it.

Choose a business task you would need to recover: opening customer records, processing an order or retrieving essential documents. List the data, accounts, software and instructions behind it. That gives you something specific to test.

Who controls the backup copies?

Backup systems have two kinds of access to consider. The data plane stores the backup objects. The control plane governs retention, deletion and the jobs that create them. If the same production administrator can change both, a second storage location may still be vulnerable to the same account compromise. Check who can alter the copies and who can alter the rules that protect them.

Encryption keeps backup contents confidential, but an authorized identity may still be able to delete the encrypted files. Versioning keeps earlier copies, provided those versions cannot also be removed. Immutability adds retention restrictions. You may need all three, and you still need a restore test to find out whether the saved data forms a usable application.

Read the limits of immutable storage

Amazon S3 Object Lock is a concrete example. Its governance mode permits specially authorized exceptions; compliance mode prevents shortening retention or deleting a protected version through ordinary object operations, including by the account root user. AWS also documents account deletion as a limit to that protection. The feature applies to object versions, so bucket-level labels alone are insufficient evidence about a particular backup object.

AWS: Object Lock retention modes and limitations

The same questions apply whichever provider you use: which objects are protected, when does that protection end, who can override it, and what happens if the whole account becomes unavailable? Include the encryption keys in that review. An intact archive is little use if the recovery team cannot decrypt it.

Put a number on acceptable downtime and data loss

Two targets help make the tradeoffs concrete. The recovery point objective, or RPO, sets how much recent data the business can afford to lose. The recovery time objective, or RTO, sets how long restoring the required service should take. An order system with a four-hour RPO and a two-hour RTO needs to recover within two hours of the defined start, losing no more than four hours of order history.

For a simple nightly backup, an incident just before the next backup could leave nearly a day of changes outside the last completed copy. That would miss a four-hour RPO even if restoration were instant. Conversely, frequent copies can meet the data-loss target while a slow rebuild misses the availability target. Measure the complete workflow, including access, infrastructure, data restoration and application validation.

Check the application, not just the archive

A copied database file may be readable without representing a consistent application state. Use the database or application’s supported backup mechanism and include required logs, configuration and dependent object storage. In a recovery test, check expected record counts or selected known records, open attachments, and exercise a harmless transaction in an isolated destination.

Write down the backup identifier, recovery point, software version, required keys and configuration, start and finish times, and validation results. Include the gaps you found. Checksums are useful for confirming that a transfer preserved the archived bytes. They cannot tell you whether the data was already damaged or untrustworthy when the backup captured it.

Check what the backup is separated from

CISA’s ransomware guidance recommends offline, encrypted backups and regular testing. The practical question is whether the incident affecting your working systems can also reach or change your recovery copies. A permanently connected drive or a copy controlled by the same compromised administrator may not provide the separation you expect.

Ask the provider to show how retention and deletion protection apply to your actual backup objects. Keep the recovery credentials and encryption keys available through a protected process your authorized team can use during an outage.

Test a restore without interrupting work

• Choose a representative, low-risk sample and record the version you expect.

• Restore into a separate test destination, leaving working data intact.

• Use the written recovery instructions and record missing access or knowledge.

• Open the recovered files in the application that normally uses them.

• Record the full elapsed time, including finding instructions and approvals.

Restoring a file is a good first exercise. A full service may also need licenses, configuration, identity services and other dependencies. Bring the people responsible for those pieces into the larger recovery test.

Compare the test with what the business needs

Now compare the measured recovery time and backup frequency with your RTO and RPO. If the test missed either target, decide what must change and who owns the work. “We have backups” becomes a much more useful statement when you can explain what they will recover and how long it takes.

During an actual incident, coordinate restoration with the response lead. Putting clean data back into a compromised environment can expose it again. And even a successful restore cannot reverse the theft of information an attacker has already copied.

Read next: Write your incident response plan before you need it

Sources & further reading

CISA: StopRansomware Guide — prevention, response, and recovery

Technical review: September 8, 2026. This is Short Circuit LLC’s original guidance, with primary sources linked beside the relevant explanations. Examples are illustrative.