Encrypt the backup, keep the key restorable

An unencrypted backup is the second prize in a breach: the attacker who already popped one machine now gets a complete, portable copy of your customers, your credentials, and your history, taken without touching the production system at all. But the over-corrected version fails too — the team that encrypts everything, stores the key in the same vault as the backup, and loses both on the same Tuesday. A backup encryption checklist has to prevent both failures at once: the copy must be unreadable to a thief and readable to you, on a clean machine, a year from now. It is the security half of the discipline you already practice in the backup restore test.

1. First, inventory what the backup actually contains

You cannot protect what you have not named. One pass through the backup job and write down: database dumps, user uploads, the .env/config exports (which are themselves a key ring — treat them like the keys they contain), full-disk images, and any export that includes personal data. If the backup contains production credentials, encryption is not optional; it is the difference between a stolen archive and a stolen business.
Classify each item: public, internal, or regulated. Most small teams end up encrypting everything anyway, because the classification exercise reveals that the "harmless" files (logs, dumps, mail exports) quietly hold PII. That is fine — uniform encryption is simpler than a policy with exceptions. The classification still earns its keep in one place: the incident answer to "what was in the stolen archive?" should be a fact you can read off the breach first-24-hours worksheet, not a guess.
Find the copies, not just the job. The encryption is only as good as the worst copy: the rsync to a spare drive in the office, the laptop's Time Machine, the "temporary" export on someone's desktop that never got deleted. The asset inventory pass that covers machines should cover backup destinations too — every location where a copy rests is a location the policy applies to.

2. Encrypt at rest, with a tool that outlives the person who set it up

Use what your stack already trusts. For file/directory backups, the boring choices are the right ones: a modern backup tool with native encryption (restic, borg with a repo key), or a container format like age/GPG wrapped around the archive before upload. For whole drives and laptops, built-in full-disk encryption (FileVault, LUKS, BitLocker) covers the device itself. Do not invent a scheme — the scheme must be something a new admin can recognize from its file headers.
Encrypt before it leaves your network, not at the destination. Client-side (or at least "before upload") encryption means the storage provider never holds a readable copy — which is what turns "cloud account compromised" from a breach into a non-event. If the backup tool offers server-side encryption only, the provider holds the key or the key-derivation, and your threat model quietly includes their staff. Write the order of operations in the runbook: encrypt, verify, then upload.
One config flag is not a policy — it is a line item with an owner. The checklist line is: backup job X writes encrypted archives with method M, verified on date D, by person P. An unowned flag drifts; the next tool migration (the classic moment backups silently turn plaintext) re-introduces the gap unless someone's checklist asks. The annual review is where the drift gets caught if nobody notices sooner.

3. Where the key lives — and the one place it must never live

The rule in one sentence: 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 (the classic failure: attacker exfiltrates the disk image with its own decryption key sitting next to it). A password manager entry, an offline copy in a sealed envelope with the break-glass kit, and a second offline copy at a different physical location: that is the whole storage policy.
Escrow it like it matters, because it does. If the key exists only in one admin's head or one admin's laptop, the backup dies with them — same failure as an undocumented password manager. The checklist line: at least two people (or the owner + the documented emergency kit) can produce the key without the first person's involvement. For teams of one, "two people" is you plus the sealed offline copy — and the test in section 5 is what proves it.
If the key leaks, treat it like a credential, not like a config file. The key to an encrypted backup of everything is roughly equal to an admin credential for everything, so the response is the key-leak runbook: revoke (rotate the key, re-encrypt the archives), assess exposure window, and check whether the old key was used after its leak. Rotate on a schedule too — but never rotate without a verified restore on the new key first (see section 5), because the most common rotation failure is destroying the ability to read history.

4. The restore test is the encryption test

Encrypting is one command; proving you can decrypt is the checklist. Quarterly (alongside the regular restore test), run the restore on a machine that has never seen the key from cache: fresh VM or a colleague's laptop, key entered by hand, archive decrypted, one file opened, checksum compared. If the restore only works on the admin's own machine with saved state everywhere, you do not have a backup — you have a memory.
The new-hire test is the honest version. Hand the documentation — not the keyboard — to someone who did not write it, and ask them to restore one file. Where they stall is where the runbook is missing a step. This is the same logic as the incident first-30 runbook's tabletop: the rehearsal is cheap, the real 2AM version is not, and a backup you cannot restore mid-incident turns a ransomware event from "inconvenient" into "unrecoverable."
Log the test result next to the archive. A one-line ledger — date, archive version, machine used, who ran it, checksum match yes/no — is what makes the claim auditable (by you, by an insurer's security questionnaire, by the post-incident review). The insurance requirements checklist increasingly asks exactly this question: are backups encrypted, and when was the last proven restore?

5. Retention, deletion, and the copies you forgot you made

Old copies outlive the policy that created them. The encrypted archive on the current storage is fine; the plaintext dump from two migrations ago on a decommissioned NAS is not. Every backup location gets an owner and an expiry: the same disposition logic as the vendor offboarding pass, applied to your own storage. When you retire a location, decommission it deliberately — wipe, then verify the wipe.
Laptops and phones are backup locations too. The mail export on the laptop, the sync client's local cache, the "I'll just copy the DB for the demo" folder: each is an unencrypted shadow copy. The lost laptop runbook is much shorter when the disk itself is encrypted and the shadow copies were never made. Full-disk encryption on every device that touches production data is the cheapest line in this entire checklist.
Deletion is part of encryption hygiene. When a key rotates, the old-key archives are either re-encrypted or destroyed on a schedule — not left readable forever by a key you have already treated as burned. The same review that checks who still has access should ask: which keys can still open which archives, and should they?

6. The one-page template

Header: backup job name, what it contains (three bullets max), destination(s), encryption method + version, last verified-restore date.
Key card: where the key is stored (two paths), who holds it (two people or owner + sealed kit), rotation date, and the leak-runbook link.
Test card: the quarterly restore-from-cold steps, the new-hire test schedule, and the result ledger location.
Copies line: every location where a copy rests — including laptops and old drives — each with an owner and an expiry.

Small-team honesty note: encryption is the part of backups that feels like extra work right up until it is the only part that mattered. If your team is one person and one NAS, this page still applies — it is three commands, a sealed envelope with the key, and a calendar reminder that says "restore one file from the encrypted backup on a clean machine." That is the entire difference between a backup and a liability.