Accountability should sit with both security and asset owners, because crypto custody is part identity assurance and part transfer governance. Security teams need the verification, endpoint, and monitoring controls, while the business side must define who can approve transfers, recovery steps, and wallet changes under abnormal conditions.
Who should own crypto custody workflows when value can move quickly?
Accountability should not sit in one team alone. In practice, the people closest to the assets must own transfer policy and exception handling, while security owns the control environment that makes those decisions safe. That split matters because custody failures usually come from weak approval rules, poor recovery design, or controls that are technically present but not operationally enforced.
Why crypto custody is both an identity problem and a transfer-governance problem
Crypto custody workflows combine two different control questions: who is allowed to act, and under what conditions value may leave a wallet or custodian. The first is about assurance, authentication, and approval authority. The second is about business rules, reconciliation, and operational guardrails. If either side is vague, a team can have strong technical controls yet still be unable to answer who may approve a transfer, rotate a wallet, or trigger recovery after an abnormal event.
That is why accountability needs to span both security and asset ownership. Security can verify the endpoint, validate the signer, monitor abnormal behaviour, and harden the workflow. Asset owners, treasury, or the relevant business function must define the decision rights, tolerance for delay, and what counts as an emergency exception. For a broader control baseline, teams can anchor those duties in ISO/IEC 27001:2022 Information Security Management and the supporting access and authentication controls it points to.
What “accountable” means in a custody workflow
Accountability means someone can explain, prove, and defend the decision path for a transfer, not just the signature event. That includes ownership of approval thresholds, separation of duties, emergency overrides, wallet recovery, key replacement, and post-event review. A custody process becomes fragile when one team owns the tools, another owns the funds, and nobody owns the full chain from request to settlement.
At the control level, the most useful model is to assign one primary business owner for the asset movement policy and one technical owner for the security controls that make the policy enforceable. The business owner decides who may approve, when a transfer requires escalation, and how abnormal conditions are handled. The security owner verifies that the identities, devices, and monitoring paths are actually enforcing those rules. NIST guidance on key management is especially relevant where custody depends on signing material and recovery procedures, and teams should align operational handling with NIST SP 800-57 Key Management.
Risk and Threat Considerations
Custody workflows fail when approval authority, signer control, and recovery responsibility are split across teams without a clear owner. That creates a gap where an attacker, a rushed operator, or a confused recovery process can move value faster than the organisation can verify intent. The risk grows when individual or small-team custody concentrates value but leaves transfer exceptions informal.
Failure mechanism: Ambiguous ownership leads to weak approval discipline, overbroad access, or emergency actions that bypass normal verification. In practice, the failure is often not theft by itself, but an approval path that is easy to misuse and hard to audit.
Impact: Unauthorised transfers, delayed recovery, disputed authorisation, and incomplete incident reconstruction can all follow. If custody is concentrated in a few people, a single compromised account or mistaken approval can produce outsized loss.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access control | Custody workflows depend on who may approve or execute transfers. |
| A.8.5 — Secure authentication | Transfer approval relies on proving the signer and operator are legitimate. | |
| Recommendation — Define and enforce access rules for custody approvals and recovery actions. Require strong authentication for custody approvals and wallet changes. | ||
| NIST SP 800-57 | 3.2 — Key lifetimes and cryptoperiods | Custody depends on signing material and rotation or recovery discipline. |
| Recommendation — Set rotation, expiry, and recovery rules for custody keys and signing material. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Custody workflows rely on lifecycle control of authenticators and signing secrets. |
| AC-6 — Least Privilege | Transfer authority should be limited to the minimum set of trusted approvers. | |
| Recommendation — Manage issuance, rotation, and revocation for custody authenticators. Restrict custody approval and recovery permissions to least privilege. | ||
Practitioner Guidance
What to prioritise: Define one accountable business owner for transfer policy and one accountable security owner for control enforcement. If those names are not explicit, the workflow will drift into “shared” responsibility, which usually means no one can make fast exception decisions when value is at risk.
What to verify: Test the full path for normal transfers, emergency holds, wallet recovery, and key replacement. The control should show who approved, which identity signed, what device or environment was used, and how the event was reviewed after the fact.
Common mistake: Treating custody as a wallet or tooling problem only. The approval model, escalation rules, and recovery authority are part of the control design, not just the operational runbook.
Practitioner takeaway: Crypto custody is safest when the business owns the decision rights and security owns the enforcement, because accountability only works when both halves of the workflow can be audited end to end.
Related resources from NHI Mgmt Group
- What do high volumes of small-value P2P transfers tell security and compliance teams about crypto use in a market?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?