Enterprise Crypto Wallet Policy Template 2026

Purpose and Scope

This policy establishes the controls, responsibilities, and procedures for the custody and management of digital assets held by [Organisation Name] ("the Organisation"). It applies to all personnel with access to crypto wallets, private key material, hardware signing devices, or backup media containing key material.

In-scope assets:

• Cryptocurrency treasury reserves (Bitcoin, Ether, stablecoins, and other digital assets)
• Tokenised securities and on-chain financial instruments
• Signing keys for smart contract deployment and administration
• Private keys controlling validator or staking infrastructure
• [Other digital assets as applicable]

Out of scope: Digital assets held by third-party custodians on behalf of the Organisation are subject to the Organisation's Third-Party Risk Management Policy, not this policy.

Regulatory alignment: DORA Article 8 (asset identification), NIS2 Article 21(i) (asset management), SEC cyber rules (covered assets definition).

Hardware Wallet and Device Selection

All hardware signing devices used to store or sign transactions involving in-scope assets must meet the following minimum standards:

• Purchased directly from the manufacturer's official website or an authorised reseller — never secondhand or from third-party marketplaces
• Device box seal intact upon receipt; if seal is broken, the device must not be used and the purchase reported to the policy owner
• Firmware verified on first boot and updated to the latest version before use
• Device model listed in the Organisation's approved hardware inventory (see Appendix A)

Approved device models (2026):

The policy owner must approve any new device model before procurement. Device selection guidance: see CryoVault Hardware Wallet Comparison 2026.

Regulatory alignment: DORA Article 21 (supply chain security), NIS2 Article 21(d).

Key Management and Cryptographic Controls

Key generation: All private keys for in-scope assets must be generated on a hardware wallet device using its on-device entropy source. Keys must not be generated in software wallets or on general-purpose computers and then imported to hardware.

Seed phrase protection: Seed phrases (12 or 24-word recovery phrases) must be:

• Written on durable physical media (paper or metal backup plate) during device setup
• Never photographed, typed into any digital device, or stored in any electronic format
• Stored in a physically secured location with restricted access (e.g. locked safe, safety deposit box)
• Stored separately from the hardware device they correspond to

BIP39 passphrase (25th word): For wallets holding assets above [threshold: e.g. $100,000], a BIP39 passphrase must be enabled. The passphrase must be stored in a separate physically secured location from the seed phrase.

Approved cryptographic algorithms:

Regulatory alignment: DORA Article 9 (cryptography policy), NIS2 Article 21(h), ISO 27001 A.10. See also: Post-Quantum Migration Guide.

Transaction Signing Controls

Clear signing requirement: All transactions above [threshold: e.g. $10,000] must be verified on the hardware device screen before signing. Signers must confirm the recipient address, amount, and gas/fee on the device display — not only on the companion app or browser.

Blind signing prohibition: Signers must not approve transactions where the device screen shows only a contract hash or opaque calldata without a human-readable decoded view. If a dApp or protocol does not support clear signing on your approved device, the transaction requires escalation approval (see Section 5).

Multi-signature requirements:

For guidance on blind signing risk, see: Blind Signing Risk 2026.

Regulatory alignment: NIS2 Article 21(j) (MFA), DORA Article 9 (access controls).

Access Control and Authorised Personnel

Authorised signers: Only personnel listed in the Authorised Signer Register (Appendix B) may operate hardware wallets or access seed phrase storage locations. The register must be approved by [role: e.g. CFO / CISO] and reviewed quarterly.

Joiners / movers / leavers:

• Joining: New signers must complete hardware wallet security training and sign acknowledgement of this policy before access is granted
• Role change: If a signer's role changes such that signing access is no longer appropriate, access must be revoked within [e.g. 24 hours] of the role change
• Leaving: When an authorised signer leaves the organisation, their access must be revoked on their last day. If they had sole knowledge of any key material, the wallet must be swept to a new address and the seed phrase rotated before they depart

Physical access to seed phrases and backup media: Access to seed phrase storage locations must require two-person authorisation — no single individual should be able to access seed phrase backups alone.

Regulatory alignment: NIS2 Articles 21(i) and 21(j), DORA Article 9.

Backup, Cold Storage, and Recovery

Cold storage classification: Assets above [threshold: e.g. $500,000] must be held in cold storage (hardware wallet, air-gapped device, or institutional vault) rather than hot/warm wallets.

Backup procedure:

• Every hardware wallet in use must have its seed phrase backed up to a metal backup plate within [e.g. 24 hours] of wallet creation
• Backup storage location must be documented in the Asset Inventory (Appendix C) and physically separated from the device
• For assets above [threshold], a second backup copy must exist in a geographically separate location

Recovery testing: The ability to restore from seed phrase (or backup card for Tangem) must be tested at least annually. Test results must be documented with date, tester, outcome, and sign-off by the policy owner.

Target recovery metric: Time to Clean Restore (TTCR) for in-scope assets must not exceed [e.g. 4 hours] for operational assets and [e.g. 48 hours] for cold storage assets.

See: Enterprise Cold Storage Architecture Guide and TTCR metric guide.

Regulatory alignment: DORA Article 12 (backup), NIS2 Article 21(c) (backup management and disaster recovery).

Incident Response

Reportable events: The following events must be reported to the policy owner within [e.g. 1 hour] of discovery:

• Suspected or confirmed private key compromise
• Unauthorised transaction detected on any in-scope wallet
• Hardware device lost, stolen, or physically tampered with
• Seed phrase backup lost, stolen, or potentially exposed
• Insider access to key material outside normal procedures
• Cold storage integrity failure (backup unrestorable, hash mismatch)

Immediate response actions:

1. Suspend all outgoing transactions on affected wallets pending investigation
2. If key compromise is suspected, initiate sweep of remaining assets to a clean wallet
3. Document the incident, time of discovery, and actions taken
4. Notify [CISO / Legal / CFO] within [timeframe]
5. If the organisation is subject to NIS2 or DORA reporting, assess whether the incident meets the threshold for regulatory notification (24h NIS2 / 4h DORA initial notification)

Regulatory alignment: NIS2 Article 23 (incident reporting), DORA Article 19 (ICT-related incident reporting). See: NIS2 incident reporting, DORA incident reporting.

Training, Review, and Governance

Training: All authorised signers must complete annual training covering: hardware wallet setup and security, blind signing risk, seed phrase protection, and this policy's requirements. Training completion must be documented.

Annual review: This policy must be reviewed at least annually, and updated within [e.g. 30 days] of:

• A significant change to the Organisation's digital asset holdings
• A material change in applicable regulation (e.g. new NIS2/DORA guidance)
• A security incident involving in-scope assets
• Introduction of a new hardware device or signing method

Policy ownership and accountability: The [CISO / CFO / relevant executive] is accountable for this policy and must report on compliance status to the management body [quarterly / annually].

Regulatory alignment: DORA Article 5 (management body accountability), NIS2 Article 20 (governance and training).