Cyber incident recovery: are you really prepared?

Traditional disaster recovery planning assumes a failure: hardware dies, a data centre loses power, a region goes offline. Cyber recovery assumes an adversary — one who had time to look around, and who understands that your ability to recover is what stands between them and payment.

Why the difference matters

A hardware failure does not target your backups. A ransomware operator does, and will often spend longer preparing that than encrypting anything. Backups deleted, retention shortened, backup credentials harvested, replication used to propagate the damage — these are routine steps, not sophisticated ones.

A plan that assumes clean, available backups is planning for the wrong event.

Questions worth answering in advance

Who has the authority to disconnect a production system, and can they be reached outside working hours? What is the actual restore time for the systems the business needs first, measured rather than estimated? When were your backups last restored, as opposed to last taken? If your identity provider is compromised, how do responders authenticate to the tools they need?

The last one is worth dwelling on. A great deal of incident response tooling authenticates through the same directory the attacker now controls.

What makes backups survivable

Copies that cannot be altered or deleted within their retention period, held where compromise of the production environment does not grant access, and periodically restored to prove they work. Immutability and separation matter more than frequency; a daily backup an attacker can delete is worth less than a weekly one they cannot.

Order of restoration

Restoring alphabetically or by ticket order wastes the first day. Recovery sequence should follow business dependency: identity and network services before applications, applications before reporting. That sequence is worth writing down while nobody is under pressure, because it will not be worked out calmly during an incident.

Exercises, not documents

A plan that has never been executed is a hypothesis. A tabletop exercise with the people who would actually be involved surfaces the gaps that matter — the contact who left, the runbook referring to a decommissioned system, the assumption that someone else holds the vendor contract. Those are cheap to find in a rehearsal and expensive to find at three in the morning.