Define what a successful drill proves
An owner can often restore their own test data while silently filling in missing steps from memory. A family member does not have that context. The drill’s purpose is to discover the missing instructions while the owner is available to improve them.
Separate three outcomes: the backup is technically usable, the intended person can follow the handoff, and that person has authority to act in a real event. A practice session can provide evidence about the first two. It does not create legal authority or guarantee future recovery.
The checklist and pass criteria below are our suggested rehearsal method, not a certification or an industry standard. You do not need to buy a service to use them.
Prepare a harmless practice package
Download the printable recovery-drill worksheet. Save or print it before the session. It deliberately contains no fields for seed words or passwords.
Choose an owner, a recipient, and optionally an observer. The owner prepares the material; the recipient follows only the written instructions; the observer records confusing language. Agree that anyone can pause immediately.
Prepare:
- A fictional asset inventory, clearly marked as practice.
- Harmless encrypted instructions, such as “Practice complete: locate instruction card R-01.”
- The required export and a trusted saved decryptor if testing an encrypted file.
- A separate route to the practice recovery phrase.
- A separate practice wallet if you want to rehearse wallet identification; it need not hold funds.
- A privately recorded expected result and a list of actions outside the drill, including transfers and resetting production devices.
Do not introduce actual wallet seeds, private keys, or production recovery phrases into this exercise. A rehearsal using only fictional material cannot validate the real backup; arrange any real backup check separately through the wallet manufacturer’s documented process.
Run the five checkpoints
| Checkpoint | Recipient task | Pass evidence | A gap worth recording |
|---|---|---|---|
| Discover | Find the starting document from the agreed trigger | Finds the current instruction version | Owner has to reveal the folder or filename |
| Retrieve | Obtain each practice item through the documented route | Finds export, tool, and separate phrase | A required file is behind the owner’s unavailable login |
| Open | Decrypt or read the practice instructions | Exact expected practice message appears | Missing metadata, wrong file, or ambiguous field labels |
| Identify | Explain which wallet and recovery method the instructions describe | Matches the expected practice wallet or clearly identifies the documented route | Confuses device PIN with wallet passphrase |
| Stop | Respond to a simulated missing factor or suspicious request | Pauses and uses the verified help route | Would send secrets to an unknown website or helper |
Let the recipient narrate what they think each step means. Record prompts the owner supplies. If the owner says “that part is obvious,” it belongs in the next version of the instructions.
For an optional practice-wallet restoration, follow the exact vendor procedure on appropriate equipment and confirm a known address. Avoid interpreting an empty balance as either success or failure: a no-funds practice wallet is expected to be empty, and wallet identity needs a different check.
Test saved-copy recovery without the network
If you use PingVaults, the saved-copy path needs the standalone decryptor, exported metadata containing ciphertext and decryption parameters, and the separate recovery values. The offline recovery guide explains the two modes.
For this checkpoint, save the files first, disconnect the network, open the saved HTML, and use the exported metadata. Avoid the TxID retrieval option during the offline test because that path contacts a gateway. Confirm that the harmless expected text appears on the recipient’s actual browser and operating system.
Record the test date, tool version or saved-file reference, and result. The browser cryptographic primitive is described by the W3C Web Crypto standard; a standard’s existence does not establish that your particular files, inputs, and device will work together. The rehearsal supplies that narrower evidence.
Use the verification page and published source snapshot to understand the available checks. A passing self-test is not an independent audit of the full service.
Rehearse failure before handling value
Introduce one fictional problem at a time. This turns vague advice into an observable decision.
The owner’s email is unavailable. Can the recipient still reach the saved instructions? If not, record the dependency and assign a fix. Do not improvise access to someone else’s account during the drill.
Two versions of the export are present. Can the recipient identify the current one from dates and version notes? If the answer relies on guessing, improve the naming and replacement procedure.
The primary helper cannot be reached. Is an alternate already documented and verifiable? “Search online for help” is too broad for a person handling recovery materials.
A recovery page asks for seed words. The recipient should stop and compare the request with the approved vendor procedure. A surprising form should not become legitimate merely because a search result or message linked to it.
The reminder email does not arrive. Record contact reachability and notification delivery as separate checks. This guide does not ask you to shorten a production inactivity schedule or send a real emergency notification just to test the plan.
Score the instructions and assign fixes
Use three outcomes for each checkpoint: passed without help, completed with help, or blocked. Avoid a single percentage that hides a critical failure. Four passes do not compensate for a missing phrase at the fifth step.
A useful record is specific: “Recipient found the JSON but assumed it was the decryptor; rename both files and add a screenshot-free, numbered instruction sheet.” An unhelpful record says “needs more training.” Change the instructions or dependency first, then repeat the affected checkpoint.
Record only the stage, issue, responsible person, and next review. Do not photograph screens containing secrets or paste sensitive values into the worksheet. If a practice file is retained, label it clearly so it cannot be mistaken for the real package later.
When to repeat the drill
Repeat relevant checkpoints when the wallet, backup standard, passphrase, encryption phrase, contact, device, browser, or storage location changes. Review the contact’s willingness and ability to participate as well as their email address.
A model-specific backup check is a separate maintenance action. Trezor’s Safe 5 guide describes checking whether a supplied backup matches the device’s backup. That does not test the full family handoff. Preserve both kinds of evidence without confusing them.
Common drill questions
Must we make a real transaction?
No. Discovery, opening instructions, wallet identification, and stop decisions can be rehearsed without moving value. Any later transaction has a different purpose and requires its own authorization and preparation.
What if the recipient cannot finish?
Treat that as a useful finding. Record the exact blocked step, simplify the instruction or fix the dependency, and repeat. Do not solve it by giving the recipient every secret at once.
Does a successful drill mean the plan is finished?
It means the tested scenario worked under the recorded conditions. Maintain current documents, independent backups, and the relevant inheritance arrangements so those conditions remain realistic.