Most incident plans in small and mid-sized companies are built around one picture. The files are still there, locked, and someone wants money for the key. The backup exists so you don't have to pay, and recovery means getting back in. That picture leaves out a second kind of attack, where nothing is locked because nothing is left.
Two attacks, two questions
Ransomware asks whether you can get back in. Erasure asks something harder: does the thing you would get back into still exist, and can you prove what was in it? In 2025, Microsoft described a group that, once inside a cloud environment, takes large volumes of data, destroys the data and its backups, and only then asks for payment.
What the law sees
Alberta's privacy law has words for this. Section 34 of PIPA requires organizations to protect personal information against risks that include disposal and destruction. The reporting duty in section 34.1 covers incidents involving the loss of personal information, or unauthorized access to it, where there is a real risk of significant harm. Whether erasure counts as a loss is a question for counsel. The practical problem is simpler: to assess that risk you need to know what was affected, and deleted logs take that answer with them.
Why the backup goes first
An attacker with authority to delete production data may also reach its backups. Microsoft's case shows why the backup's permissions matter as much as its existence.
Three things that survive
The first is a copy that can't be deleted from production. Canada's Cyber Centre says offline backups offer the most protection, and a cloud copy needs a retention policy and permissions that protect it from the compromised production identity. In the case Microsoft described, some resources survived because resource locks and immutability policies were already in place.
The second is a restore you have actually run. The Cyber Centre suggests testing backups on a regular schedule, monthly for example. NIST adds that you should verify a backup's integrity before you restore from it.
The third is evidence captured before the rebuild. The instinct is to wipe and start again. Capture appropriate system evidence before rebuilding, following the incident team's plan. The Cyber Centre recommends protecting collected logs from later modification.
The practical step is to ask for three documents. Where is the copy production can't delete? When did we last restore from it? And what is the written order between capturing evidence and rebuilding? This is not legal advice. Breach obligations depend on your jurisdiction, sector and facts, so get counsel.