The Recovery
Governance Gap

Families are accustomed to documenting who owns an asset, who may act for an owner and what should happen after death or incapacity. Those questions are essential. For Bitcoin held in self-custody, they are not sufficient.

Legal authority and operational capability are different things. A successor may have an undisputed right to the asset while lacking the information, equipment or procedure required to access it safely. An executor may know that a wallet exists but not which backup is current. A family member may find recovery material but have no reliable way to distinguish it from an obsolete setup. A trusted adviser may understand the legal structure while being intentionally excluded from the cryptographic secrets.

This is the recovery governance gap: the space between having authority on paper and being able to restore a working, verified system without introducing avoidable risk.

Recovery is a system outcome

A backup is one component of recovery. It may preserve key material, wallet policy, configuration data or instructions. Recovery succeeds only when the necessary components can be assembled under realistic conditions.

That normally requires answers to several separate questions. Which material is authoritative? What wallet or policy is being restored? Which devices and software are compatible? How is a receiving address or wallet balance verified independently? What happens if one device, service provider or knowledgeable person is unavailable? Who may make a decision when evidence conflicts?

Treating recovery as a single document hides these dependencies. Treating it as a governed process makes them visible.

Four roles that families should name

One person may hold several roles during normal operation. Continuity planning begins by recognising that those roles can separate during illness, absence, conflict or succession.

1. Owner. The person or entity with authority over the asset and the right to determine its use.
2. Operator. The person capable of performing the technical steps required to inspect or transact with the setup.
3. Verifier. The person responsible for checking that devices, wallet policy, addresses and transaction details correspond to the intended system.
4. Recovery contact. The person who knows that a recovery procedure exists, when it may be invoked and how to start it without receiving secrets prematurely.

The names matter less than the distinction. If every function depends on the same individual, the arrangement has a human single point of failure. If several people share a role but no one knows whose evidence prevails, the arrangement can fail through ambiguity instead.

Separate secrets from instructions

A useful continuity plan does not place seed phrases, private keys, PINs, passphrases or recovery words into ordinary family records. It should instead describe the map around those secrets: what systems exist, where approved procedures are located, which roles are authorised, how current information is identified and which escalation path applies.

This separation allows a family to improve governance without unnecessarily increasing access to signing material. It also supports safer involvement by lawyers, trustees, executors or family-office staff who need to understand responsibilities but should not hold Bitcoin credentials.

Evidence needs a time dimension

Continuity records age. Devices are replaced, wallet software changes, signers move, policies are updated and service providers disappear. A procedure that was valid two years ago may now describe the wrong system.

Each important record should therefore carry an evidence state. Current means it was checked against the live setup within a defined period. Stale means it was once checked but has exceeded that period. Unknown means no reliable verification record exists. Unavailable means the evidence cannot presently be obtained.

These labels prevent an old document from producing false confidence. “Unknown” is a legitimate security state. It identifies work that remains to be done; it should never be silently converted into “verified.”

Test the procedure without exposing the asset

A recovery exercise does not have to begin with a live transfer of significant funds. Families can test whether participants can locate the procedure, identify the correct roles, assemble required non-secret information, recognise the wallet policy and explain how independent verification would occur. A controlled technical exercise can then use a designated test setup or a deliberately limited environment.

The aim is to test the path, not to maximise exposure. The exercise should reveal ambiguous instructions, hidden dependencies and decisions that still rely on the original architect.

A practical governance record

A concise recovery governance record can document:

• the systems covered and their purpose;
• the accountable owner, operator, verifier and recovery contact;
• the location and version of approved procedures;
• the evidence required before a recovered system is trusted;
• known dependencies on devices, software, nodes or service providers;
• the review interval and last test date;
• the escalation path for conflicting, stale or unavailable evidence.

It should not contain the secrets themselves. Its purpose is to make responsibility and verification possible while preserving the security boundaries of the underlying setup.

Continuity is demonstrated, not declared

A family cannot infer recovery readiness from the existence of a backup, a legal document or a technically sophisticated primary owner. Readiness is evidence that the right people can identify the system, follow the procedure, recognise uncertainty and restore a verified state when normal operation is no longer available.

Good governance does not remove self-custody from the owner. It makes the surrounding responsibilities explicit enough that self-custody can survive a transition.