A recovery plan that restores a wallet dashboard may still leave an institution unable to settle an obligation. The keys might be available while an approval device, identity service, policy database or vendor coordination service remains offline. Digital asset disaster recovery should therefore define a business outcome: authorised people can determine the correct balances, approve the intended transaction and move the right assets without relaxing essential controls. A successful backup restore is one step toward that outcome.
Define the service that must recover
Begin with a map of critical activities. Client withdrawals, collateral delivery, treasury payments and record production may require different recovery times. Identify the applications, people and external services each activity needs. This follows the structure of NIST contingency planning guidance, which connects business impact analysis, recovery strategies, testing and plan maintenance. The guidance is a general planning framework, not a certification of a wallet provider.
Set recovery targets for business services rather than for individual servers. Restoring a signing service quickly is insufficient if the transaction queue cannot be trusted. Likewise, rebuilding history after a long delay can make a functioning wallet unsafe to use. Define how much missing operational data is acceptable, and distinguish a service being technically online from it being approved to resume external settlement.
Recovery authority is financial authority
Key backups contain, or help restore, the ability to move assets. Their distribution is therefore part of the authority model. Identify who can access backup material, what quorum is needed and whether the emergency process creates a single point of control. The answer should cover employee departures, lost devices and an unavailable provider. A plan that depends on the same building, administrator or identity service as production may fail under the same incident.
NIST key-management guidance addresses protection of cryptographic material and its lifecycle, including backup and recovery considerations. Applied to wallets, the practical question is whether recovery preserves the intended separation of duties. Our account of institutional key-management designs explains why restoring an HSM, recovering MPC participation and replacing a multisig signer are distinct procedures.
Prove the last known good state
After a disruption, the institution needs to know which instructions were merely approved, which were broadcast and which settled. Reconstructing that state requires more than a list of balances. Retain transaction identifiers, network and asset identifiers, approval records and the connection to the underlying business instruction. Reconcile these against independent network observations and provider records before replaying any queue. Otherwise recovery can turn a missing acknowledgement into a duplicate payment.
Use an explicit restart gate. Operations should resolve pending and uncertain transactions, confirm destination and policy configurations, check spending permissions and verify access by the restored signer set. Finance should understand any reconciliation breaks. A system can return a green health status while holding stale permissions or an incomplete ledger. The restart decision should therefore be owned jointly by people responsible for the technology and for the assets.
Run a drill that includes friction
A useful exercise removes a dependency rather than simply asking a vendor to demonstrate normal service. Assume a named approver is unavailable, a production device is lost or the main platform cannot coordinate a signature. On test infrastructure, restore the required material, reconstruct the transaction state and complete a harmless operation through the recovery workflow. Record elapsed time, missing information, unexpected privileges and the people needed to finish.
The drill should end with a revised plan and evidence that weaknesses were addressed. Check that recovery materials remain usable after software changes, signer changes and vendor migrations. Our operational due-diligence guide puts continuity within the broader manager review. For recovery specifically, the strongest evidence is a dated exercise showing who restored authority, what records they trusted and why operations judged it safe to resume.
Choose evidence that survives the outage
Keep a recovery copy of the information needed to recognise a legitimate instruction: approved counterparties, entity-to-wallet mappings, current signer responsibilities and escalation contacts. Protect that material against unauthorised alteration and verify its freshness during each drill. A team restoring access should not have to ask an unverified messenger for the destination of an urgent payment. The exercise should also test communication between operations and counterparties, using established contact routes. Recovery is safer when the people rebuilding the service have trustworthy records of what they are allowed to do.