Direct answer
Encryption keys are part of the recovery system, not merely a security setting. Document which key encrypts each copy, who can retrieve it, what services it depends on and how rotation affects old recovery points. Use independent escrow and require a witnessed recovery test.
How to frame the decision
Operational confidence comes from repeatable evidence: logs, timestamps, restored-object counts and application checks. A successful backup job is an input to testing, not proof of recoverability.
For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.
How should recovery records survive identity compromise?
Keep the recovery inventory in a management domain that does not share the business system’s identity path, and distinguish inventory metadata from the secrets that must be reissued.
- Reissue every credential that can be reissued rather than restoring an assumed-clean value.
- Protect the recovery workbook in a separately managed service and test its version, retention and emergency access behavior.
- For catastrophic endpoint loss, keep an encrypted copy in another service or on encrypted removable media with a named physical retrieval path.
Decision table
The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.
| Factor | Practical guidance | Evidence to retain |
|---|---|---|
| Key ownership | Distinguish vendor-managed, customer-managed and application-level keys and their failure modes. | A key-to-copy inventory with responsible owners. |
| Escrow independence | Keep recovery material outside the same identity, cloud account and password path as production. | A retrieval test during simulated identity outage. |
| Historical access | Confirm rotations, revoked accounts and provider changes do not strand older recovery points. | A restore using a recovery point encrypted before key rotation. |
Validation procedure
Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.
- Collect machine-readable evidence rather than relying on a green dashboard.
- Translate the requirement into a pass/fail test for backup encryption key recovery and escrow.
- Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
- Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.
A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.
Common failure modes
These conditions can make a compliant-looking design unusable during an actual recovery.
- Keys are backed up inside the encrypted repository they unlock.
- One departed administrator is the only person who understands key recovery.
- Rotation removes access to recovery points still required by retention policy.
Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.
Evidence checklist
Keep this evidence with the recovery plan so that a reviewer can distinguish a documented capability from a reproduced result.
- Assign an owner and closure date to every failed assertion.
- A tested requirement exists for: Key ownership.
- A tested requirement exists for: Escrow independence.
- A tested requirement exists for: Historical access.
- Evidence includes a date, environment, operator and reproducible procedure.
- The exception path identifies who can accept residual risk.
Frequently asked questions
These answers state the decision in plain language and preserve the conditions that can change it.
Should recovery secrets be stored in Excel?
Do not use a workbook as a general secret vault. It can hold a controlled recovery inventory, while reissuable credentials should be regenerated and placed into the approved secret-management service through an audited process.
Is storing the recovery workbook in Box sufficient?
Only after version recovery, retention, identity separation and emergency access have been tested. In the cited design those checks had not been completed, so Box availability remained an explicit evidence gap.
When is an encrypted USB recovery copy appropriate?
Use it as a catastrophic fallback when remote endpoints and online management paths may all be unavailable. Its retrieval time, custody, update trigger and unlock path need a separate recovery objective.