A Bitcoin key management policy is the written rulebook for who controls a company's private keys, who can approve a transaction, and what happens when something goes wrong. It turns custody technology into enforceable corporate controls. Without one, even a well-designed custody setup depends on the habits of a few individuals.
Why a separate policy is needed
The Bitcoin treasury policy sets the strategy: why the company holds Bitcoin, how much, and who has authority to buy or sell. The key management policy sits underneath it and answers a narrower question: how is that authority actually exercised over the keys?
This matters because Bitcoin transactions are final. A payment made in error cannot be recalled. The control environment has to work before money moves, not after.
Whether the company uses a third-party custodian, self-custody or a multisig shared-control model, it needs a key management policy. With a custodian, the policy governs who can instruct the custodian and how. With self-custody, it governs the keys themselves.
The core elements of a Bitcoin key management policy
1. Roles and responsibilities
Define each role by function, not by name, and record current holders in a separate register.
- Initiator: proposes a transaction.
- Approvers: authorise it, up to defined limits.
- Key holders: control signing devices or platform credentials.
- Policy owner: maintains the document, usually the CFO or treasurer.
- Independent reviewer: internal audit or a non-executive, who tests compliance.
No person should hold incompatible roles, such as initiating and approving the same transaction.
2. Signing quorums
State how many approvals are required for each type of movement. Quorums can scale with value and destination.
| Movement type | Example quorum | Notes |
|---|---|---|
| Between the company's own wallets | 2 approvers | Destination on pre-approved whitelist |
| To a pre-approved counterparty | 2 approvers including CFO | Within delegated limits |
| To a new address or above limit | 3 approvers including a director | New address verified out of band |
The figures above are illustrative. Each company should set its own thresholds in line with its delegation of authority.
3. Dual control
Every movement of funds should require at least two people acting independently. Dual control applies to creating and approving transactions, changing whitelists, adding or removing users, and changing quorums themselves.
4. Address whitelisting and verification
Destination addresses should be added to a whitelist through a separate, approved process. Each signer should verify the address on a trusted device screen and, for new counterparties, confirm it through a second channel such as a call to a known number. Never rely on an address received only by email or chat.
5. Key generation and storage
Record how keys are created (for example, in a documented ceremony with witnesses), where each key and backup is stored, and what physical and logical access controls apply. Keys and backups should be geographically separated, and no single location should hold enough material to meet the quorum.
6. Recovery and succession
Describe exactly how the company regains access if a key, device or key holder is lost. Include departures, illness, death and the failure of a third-party key provider.
Practical tip: rehearse recovery at least once a year with a small test amount, and minute the result. An untested recovery plan is a hope, not a control.
7. Changes to people and providers
When a key holder leaves, their key or access should be rotated promptly, and the register updated. When a custodian or key provider changes, treat it as a formal project with board visibility.
Evidence, audit and assurance
Auditors will want to see that the policy is followed, not just that it exists. Plan the evidence from day one:
- Ceremony records for key generation and rotation.
- Logs of every proposed, approved and rejected transaction.
- Access registers showing who holds which role and key.
- Periodic reconciliations of book balances to blockchain addresses.
- Results of recovery tests.
Where a third-party custodian or key provider is involved, obtain its SOC 1 Type II and SOC 2 Type II reports. Pay particular attention to "complementary user entity controls", which are the controls the provider expects you to operate. They often overlap with your key management policy. Our audit readiness checklist covers the wider picture.
Linking the policy to segregation, insurance and insolvency
A key management policy works best when it reflects the legal and commercial structure around the keys.
- Segregation: the policy should name the specific wallets or accounts it governs, so holdings stay identifiable as the company's own.
- Bankruptcy remoteness: where outside parties hold keys, the policy should reference the contracts that confirm they hold keys as agents, not owners. Take legal advice on enforceability.
- Insurance: some policies require particular storage or signing practices as conditions of cover. Make sure the key management policy meets them.
Common gaps we see
- Quorums defined on paper but not enforced in the platform or wallet settings.
- One person holding both a key and the authority to change whitelists.
- Backups stored in the same building as the primary keys.
- No procedure for a key holder's sudden unavailability.
- A policy last reviewed when the holding was a fraction of its current size.
How The Bitcoin World helps
We draft and review key management and signing policies alongside the wider 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. See also our guide to corporate Bitcoin custody.