How to use this checklist
This review asks one question in twenty-two ways: if the machines holding your key material disappeared this afternoon, could you get them back, and how do you know. It runs quarterly because the answer decays. People leave, schedules drift, a service is migrated and its state stops being captured, and none of that generates an alert.
Book it as a working session rather than a form-filling exercise. The central item is the drill, and the drill takes most of a day the first time. Everything above it exists to make the drill possible and everything below it exists to keep the drill honest. If you are short of time, do the drill and let the paperwork follow; a signed checklist with no restore behind it is worth nothing at all.
Where the numbers come from
Locations, owners, thresholds and protecting keys come from the recovery inventory, which is the one document this review will not proceed without. Treat it as source code: reviewed, versioned, and stored somewhere that does not depend on the systems it describes.
File-level evidence is read from the running authority and from the backup target. Look at the issuance database, the revocation list and the timers on the host that produces the backups, and read the retention and replication settings from the storage service rather than from the automation that was supposed to configure them.
Three items are attestations because no command can answer them. Whether the drill was run by someone other than the author, whether each protecting passphrase can be recovered without the system under restore, and whether the restore path is free of circular dependencies are answered by a person who has traced the path and signed their name to it.
Access this needs
Read access to the recovery inventory, read access to the backup storage and its configuration, shell access on the authority host to read the issuance database and timers, and the ability to query the seal status of the secret manager. The drill itself needs more: an isolated environment, the shares or passphrases, and the agreement of every share holder. Schedule that part; do not attempt it by borrowing credentials on the day.
What the review produces
A dated recovery statement: the inventory as it stands, the result of the drill with its elapsed time, the gap against the recovery target, and every finding with an owner. It is signed by the person who ran the restore, not only by the person who scheduled it. A copy is stored with the recovery inventory itself, offline, because a recovery statement that only exists in the wiki you are trying to restore is a recovery statement you will not read.
Sign-off
- Reviewer: ________________ Date: ___________
- Platform owner: ___________ Date: ___________
- Security owner: ___________ Date: ___________
Every critical item must pass. A failing critical item means that recovery is currently a hypothesis, and the honest way to report that upward is as an outstanding outage risk with a number attached rather than as a checklist row. Record the date, the reviewer, and the disposition of every item that did not pass.