The 3AM ransomware call ends one of two ways, and the difference is usually a checkbox nobody ticked.
The first way: the team restores from last night's backup, shrugs off a day of lost changes, and spends the week being smug about their air-gapped drives. The second way: the backups are right there, verified even, and the recovery stalls anyway — because the archive is encrypted, and the key is a question nobody can answer. Or worse: the backups were never encrypted, the attacker's second stage quietly exfiltrated the entire archive before detonating, and now "we survived the ransomware" comes with a breach notification attached.
Both failures live in the same blind spot: backup encryption is treated as a feature flag, not a policy. We just published a one-page checklist that treats it properly — and the short version is this:
Encrypt before it leaves your network, not at the destination. Client-side encryption means the storage provider never holds a readable copy, which turns "cloud account compromised" from a breach into a non-event. Server-side-only encryption quietly adds the provider's staff to your threat model. The order of operations goes in the runbook: encrypt, verify, upload.
The key must be reachable by a second path, and storable by no single path. Never inside the backup itself. Never in the same cloud account as the backup. Never only on the machine being backed up — that's the classic failure where the stolen disk image arrives with its own decryption key sitting next to it. A password-manager entry, a sealed offline copy with the break-glass kit, a second offline copy at a different location: that's the whole storage policy. If the key exists only in one admin's head, the backup dies with them.
If the key leaks, it's a credential, not a config file. The key to an archive of everything is roughly an admin credential for everything: rotate it, re-encrypt the archives, and check whether the old key was used after its leak window. But never rotate without a verified restore on the new key first — the most common rotation failure is destroying the ability to read history.
The restore test is the encryption test. Quarterly, on a machine that has never seen the key from cache: fresh VM, key typed by hand, archive decrypted, one file opened, checksum compared. Then the honest version — hand the documentation (not the keyboard) to someone who didn't write it. Where they stall is where your runbook is missing a step. Insurers increasingly ask this exact question on security questionnaires: are backups encrypted, and when was the last proven restore?
Old copies outlive the policy that made them. The plaintext dump from two migrations ago on a decommissioned NAS, the mail export on a laptop, the "temporary" DB copy for a demo — each is an unencrypted shadow copy. Full-disk encryption on every device that touches production data is the cheapest line in the whole checklist, and the decommission pass exists precisely so old copies die on schedule instead of haunting a closet.
The full one-pager — the inventory pass, the tool choices a new admin can recognize from file headers, the two-path key card, the cold-machine restore test, and the copies ledger — is free on our ops-notes site:
Backup Encryption Checklist for Small Teams →
It pairs with two neighbors: the backup restore test checklist (the quarterly proof your backups work at all) and the ransomware recovery checklist (what the 3AM call actually looks like). If you want the fill-in-the-blank versions, the Ops Starter Kit is $14, and the free one-page First 30 Minutes incident checklist is the place to start.
Running a small business or ops team? The Ops Starter Kit ($14) packs the checklists, templates, and runbooks from this article into ready-to-use form. Free First 30 Minutes incident response kit also available.
Top comments (0)