Bitcoin succession planning is how an organisation makes sure it can always access and move its Bitcoin, even if key holders leave, fall ill or die, devices fail, sites become unavailable or a provider stops operating. Because Bitcoin cannot be recovered through a bank or a court order to a third party, continuity has to be designed in advance. A plan that has never been rehearsed should be treated as untested, not as a control.
Why continuity is different for Bitcoin
With bank deposits, a company that loses its signatories can usually appoint new ones and regain access through the bank. With Bitcoin, the private keys are the access. If the required keys or credentials are lost, the coins can become permanently unspendable.
The opposite risk also matters. A plan that makes recovery too easy can hand an attacker, or a single insider, a route to the funds. Good succession planning balances resilience against security.
The four areas a plan must cover
People
- Who holds each key, credential or approval right?
- Who replaces each person, and how quickly can they be onboarded?
- What happens if two key holders are unavailable at the same time, for example because they travel together?
Technology
- Which devices, hardware modules or software hold key material?
- Where are backups, and what is needed to restore from them?
- Will the software and hardware still be supported in five or ten years?
Providers
- Which outside parties hold keys, shares or platform access?
- What happens to the company's access if a provider is acquired, loses a licence or fails?
- This links directly to the custody exit plan.
Documentation
- Is there a current wallet configuration record, so a multisig wallet can be rebuilt with compatible software?
- Are instructions written so that a competent successor, not the original architect, could follow them?
- Are the documents stored securely, separately from the keys they describe?
Scenarios to plan for
| Scenario | Main risk | Typical response |
|---|---|---|
| Key holder resigns | Former employee retains access | Rotate key or revoke credentials promptly |
| Key holder dies or is incapacitated | Quorum cannot be met | Use backup key or recovery key under defined procedure |
| Site becomes inaccessible | Keys or backups unreachable | Restore from geographically separate backup |
| Device failure or obsolescence | Key cannot be used | Restore to new device from verified backup |
| Provider ceases operation | Access through provider lost | Execute exit plan; use company-held keys if available |
| Coercion of a key holder | Forced transfer | Quorum, time delays and duress procedures |
Each scenario should name who decides, who acts, and what evidence is kept.
Building a Bitcoin succession planning framework
Map dependencies
Start with a single table showing every key, credential and approval right, who holds it, where its backup sits, and how it would be replaced. Any blank cell is a gap.
Set triggers
Define what starts the plan: notice of resignation, a key holder being unreachable for a set period, a provider incident. Clear triggers avoid hesitation in a crisis.
Separate knowledge from access
No single document should contain enough to move funds. Instructions can be held in one place, key material in another and authority to act with a named committee. Some organisations hold sealed recovery materials with a lawyer or independent key agent, released only under documented conditions.
Align with the wider policy
Succession procedures belong in, or alongside, the key management and signing policy, and the board should approve material changes. If a provider holds keys, its continuity commitments should be in the contract.
Practical tip: once a year, run a recovery test with a small amount, carried out by people who did not design the setup, using only the written instructions. Note every point where they had to ask a question. Each one is a gap to fix.
Testing and evidence
Auditors and boards will want proof that continuity works. Useful evidence includes:
- Minutes of recovery rehearsals, with dates, participants and results.
- Records of key rotations after staff changes.
- A dated register of key holders, approved by the policy owner.
- Confirmation from providers of their own business continuity testing, often found in SOC 2 Type II reports.
Our audit readiness checklist covers how this fits the wider audit file.
Governance links
Continuity planning touches the other custody controls:
- Segregation: the plan should identify exactly which wallets and accounts it covers.
- Bankruptcy remoteness: if a provider fails, legal ownership determines whether recovery is even possible. See bankruptcy remoteness.
- Insurance: some policies require documented continuity procedures as a condition of cover.
- Dual control: recovery itself should require more than one person to act.
Who owns the plan
Continuity planning needs a clear owner, usually the CFO or treasurer, with an independent reviewer such as internal audit or a non-executive director. The owner keeps the plan current; the reviewer checks it is followed. For family-controlled or closely held organisations, where one founder may hold most of the knowledge, this separation matters even more.
Common gaps
- The person who set up custody is the only one who understands it.
- Backups are stored in the same building as the primary keys.
- Former employees still appear on provider access lists.
- Recovery instructions rely on software versions no longer available.
- The plan has never been tested with real, if small, transactions.
How The Bitcoin World helps
We help organisations design and document continuity and succession arrangements as part of their custody architecture, and prepare the board papers that approve them. We do not hold keys or client assets. Custody and execution are carried out by licensed third-party institutions.