Ransomware-ready: backups that actually restore

When ransomware hits, the first question from the board is always the same: do we have backups? The honest answer is usually "yes, but". Yes, but they sit on the same domain the attacker now controls. Yes, but nobody has restored more than a single file in two years. Yes, but the backup console uses the same admin password as everything else.

Modern ransomware crews know this. Deleting or encrypting backups is now a standard step before they detonate, not an afterthought. A backup strategy that would have been fine against a failed disk does not survive a human who is actively looking for it.

Assume the attacker will look for your backups

Before you buy anything, map how someone with domain admin rights would reach your backups. In most environments we review, it takes one hop.

• Separate the identity. Backup administration should not use accounts from your main directory. A compromised domain admin should not be able to log into the backup console.
• Separate the network. The backup server should not be reachable from ordinary workstations over SMB or RDP.
• Make at least one copy immutable. Object lock on cloud storage, a hardened repository, or offline media. The point is simple: for a set period, nobody, including you, can delete it.

Restore time is the number that matters

Backup reports love to show success rates. The metric that decides how long you are offline is how fast you can rebuild the systems that the business needs first.

Write down your recovery order before you need it. Identity provider and directory first, because nothing else works without them. Then email and collaboration, finance and payroll, and the customer-facing systems that generate revenue. For each, note where the backup lives, who can restore it, and how long a full restore took the last time you tried.

If the answer to the last question is "we have never tried", that is your most urgent finding.

Practise a full restore, not a file restore

Restoring one spreadsheet proves the software works. It does not prove you can rebuild a business. Once or twice a year, pick a critical system and restore it into an isolated environment from the immutable copy, as if production were gone.

You will find things. Licence keys stored on the server you are restoring. Encryption keys for the backups kept in a password manager that itself needs restoring. A database that comes back but an application that cannot find it. Each of those is far cheaper to find on a Tuesday afternoon than during an incident.

Keep the clean room clean

During a real incident, restoring into the same compromised environment is how companies get hit twice. Plan for a clean build area: fresh credentials, patched images, and monitoring in place before data comes back. Check restored systems for the persistence you found during the investigation before they rejoin the network.

A short checklist for this quarter

1. Confirm one backup copy is immutable or offline, and that its retention outlasts how long an attacker might sit unnoticed.
2. Move backup administration to separate accounts with phishing-resistant MFA.
3. Write the recovery order for your top ten systems on one page, and store it somewhere that does not depend on those systems.
4. Run one full restore of a critical system and record how long it really took.

Backups are the one control that turns a ransomware incident from an existential crisis into a very bad week. They only do that if they are still there, and still usable, on the day you need them.