Who owns digital asset recovery within your financial institution?

When a financial institution loses access to cryptographic key material, the ability to recover their digital assets is only part of the challenge. The institution must also know who has the authority to initiate that recovery, which teams are responsible for carrying it out, what controls remain in force throughout the process, and who is accountable for the decisions made while access is being restored.

Responsibility will vary between institutions, but typically spans several functions. Product teams may define the continuity of the service and client experience, security teams may govern the infrastructure and controls protecting access to assets, while compliance and risk teams need to understand whether recovery arrangements satisfy the institution's regulatory obligations and can withstand subsequent scrutiny.

The complexity arises where those responsibilities meet. A recovery process can be technically sound while remaining operationally difficult to execute because an approval route is unclear, an authorised individual is unavailable, a third-party dependency has not been considered, or the teams involved have never tested the process together.

For regulated institutions within scope, these weaknesses are becoming increasingly difficult to overlook. The Digital Operational Resilience Act (Regulation (EU) 2022/2554), the Markets in Crypto-Assets Regulation (Regulation (EU) 2023/1114) and the FCA's operational resilience framework, introduced through PS21/3 and set out in SYSC 15A of the FCA Handbook, have placed greater emphasis on continuity, recovery, third-party dependencies and the ability of firms to demonstrate that critical services can continue through disruption.

A robust digital asset recovery operating model should therefore clearly allocate responsibilities, establish decision-making authority in advance, and regularly test the complete process under conditions that reflect the complexity of a real incident.

Why ownership becomes difficult during digital asset recovery

Institutional digital asset environments bring together cryptographic infrastructure, custody technology, approval policies, operational processes and regulatory controls, often across several internal teams and external providers. These arrangements provide multiple layers of protection, although they also create dependencies that become particularly significant when normal access is interrupted.

Consider a relatively straightforward scenario in which an institution can no longer access a wallet containing client assets. Security may understand how the key can be recovered, but the recovery process requires approval from two authorised executives. One of those executives is unavailable. Operations need to understand whether an alternative approval route exists. Compliance needs to determine whether the incident has reached an internal or regulatory reporting threshold. Product needs to manage the effect on clients and establish how long the service can remain unavailable before existing commitments are affected.

None of these responsibilities exists independently, and delays in one area can prevent progress elsewhere. This is where loosely defined shared ownership becomes difficult to manage. Each team may understand its own responsibilities while lacking clarity over who has authority to make the decisions connecting them.

The FCA's operational resilience framework has increased the importance of resolving these dependencies before disruption occurs. Under the rules introduced by PS21/3, firms within scope must identify their important business services, set impact tolerances for the maximum tolerable disruption, carry out mapping of the resources required to deliver those services and undertake scenario testing designed to demonstrate whether those tolerances can be maintained during severe but plausible disruption. The transition period for meeting those requirements ended on 31 March 2025, and the FCA has been clear that important business services, impact tolerances and mapping should be reviewed at least annually or following a material change to the business.

Where access to digital assets forms part of an important business service, recovery becomes part of that wider resilience framework.

The role of product teams

Product teams have an important role in defining how recovery should operate within the service itself, particularly where loss of access has a direct effect on clients.

Recovery arrangements are often established during the initial design of a custody or wallet infrastructure and subsequently receive less attention than the production environment. As the service develops, however, the assumptions upon which those arrangements were based can change considerably.

Assets under custody may increase. New client segments may be introduced. Approval structures may change. Employees named within key ceremonies or escalation procedures may move roles. New technology providers may become involved in the custody stack. A recovery process designed around the original architecture can consequently become increasingly detached from the service it is expected to protect.

The function responsible for service design, whether that is product or another team, should therefore consider recovery requirements throughout the lifecycle of the service, including how clients are authenticated, which parties can request recovery, how approvals are obtained, what happens outside normal operating hours and how communications are managed while access remains unavailable. The appropriate design will also vary considerably according to the client. A retail or wealth client may require an identity verification process supported through established customer service channels, whereas an institutional client may expect recovery to follow existing treasury controls involving multiple authorised parties, defined approval thresholds and segregation of duties.

Those differences become particularly important where the recovery process could ultimately restore control over substantial client assets. The same controls that make recovery accessible enough to be useful must also prevent the process from creating an alternative route through which an unauthorised party could obtain access.

The role of security teams

The security function will typically play a central role in assessing whether the recovery mechanism can operate under the circumstances for which it was designed without weakening the protections surrounding the institution's digital assets.

This creates a demanding architectural problem. Recovery infrastructure must remain available when normal access mechanisms have failed, yet the existence of that infrastructure creates another highly sensitive route through which control over assets may potentially be restored. Security teams therefore need to consider recovery as part of the wider custody architecture, including the systems, people, credentials and third parties upon which the process depends.

For financial entities within scope of DORA, these considerations now sit within a broader regulatory framework governing ICT continuity and recovery. Article 11 requires relevant financial entities to put in place a comprehensive ICT business continuity policy and to implement associated ICT response and recovery plans, while Article 12 sets out the corresponding requirements for backup policies and procedures alongside restoration and recovery procedures and methods.

Within a digital asset environment, this places particular importance on the independence and resilience of the recovery capability. If the same infrastructure, location, provider or set of credentials supports both the production environment and the route used to recover it, a sufficiently severe incident could affect both simultaneously.

DORA makes a comparable point in the context of backup data. Article 12(3) requires that, where a financial entity restores backup data using its own systems, the systems used are physically and logically segregated from the source system and protected from unauthorised access or corruption. Although the provision is directed at backup-data restoration, the underlying principle can apply equally to the material and infrastructure supporting cryptographic recovery.

Security teams should therefore examine whether recovery material is appropriately separated from production infrastructure, whether access requires multiple authorised parties, whether critical components are distributed across suitable locations or providers, and whether the failure of a single system or organisation could prevent recovery altogether.

The same scrutiny should apply to people. An institution may have highly distributed technical infrastructure while remaining dependent upon a single engineer who understands the recovery procedure, a single executive whose approval is required, or a single relationship owner capable of escalating an incident with a critical provider. These dependencies can be difficult to identify through architecture diagrams alone, which is one reason realistic recovery exercises remain essential.

The role of compliance and risk teams

Compliance and risk teams have a different responsibility: establishing whether the institution can demonstrate that its recovery arrangements operate as intended and satisfy the requirements applying to the service.

For regulated firms, the existence of a recovery policy provides only part of that evidence. Applicable frameworks may require institutions to evidence how continuity and recovery arrangements have been mapped, governed and tested, including the dependencies upon which critical services rely.

The testing obligations are explicit. Article 11(6) of DORA requires financial entities within scope to test their ICT business continuity plans and ICT response and recovery plans for systems supporting all functions at least yearly, and again in the event of any substantive change to ICT systems supporting critical or important functions. Article 11(8) requires those entities to keep readily accessible records of activities before and during disruption events in which those plans are activated. Under the FCA framework, SYSC 15A.5.3R requires firms within scope to carry out scenario testing to assess their ability to remain within impact tolerance for each important business service during severe but plausible disruption.

Recovery exercises therefore produce evidence with value extending beyond the security function. Test results, recovery times, failed approvals, unavailable participants, deviations from documented procedures and remediation actions can all provide insight into whether the institution's governance operates effectively under pressure.

For compliance teams, this creates a practical set of requirements around documentation. Recovery tests and their results should be documented. CoinCover Certified can support this process by providing recovery testing and associated evidence, subject to the scope of the applicable service. Escalation and activation thresholds should be defined. The individuals authorised to approve recovery should be identifiable, together with suitable deputies. Dependencies on third parties should be documented and incorporated into relevant testing, while weaknesses identified during exercises should lead to recorded remediation and subsequent validation. Over time, these records provide an institution with an evidential history showing how its recovery capability has been tested and improved.

MiCA raises the importance of protecting access

For crypto-asset service providers offering custody and administration in the European Union, MiCA gives the protection of access particular significance.

Article 75(3) requires crypto-asset service providers providing custody and administration of crypto-assets on behalf of clients to establish a custody policy containing internal rules and procedures to ensure the safekeeping or control of clients' crypto-assets, or the means of access to those assets. The same provision requires that policy to minimise the risk of loss arising from fraud, cyber threats or negligence, and a summary must be made available to clients on request. Article 75(6) goes further, requiring providers to have procedures in place to return crypto-assets held on behalf of clients, or the means of access to them, as soon as possible and for facilitating the exercise of clients’ rights.

Article 75(8) then addresses liability. Custody providers are liable to their clients for the loss of any crypto-assets, or of the means of access to those crypto-assets, resulting from an incident attributable to them, with liability capped at the market value of the asset at the time the loss occurred. The provider is not liable where it proves that the incident occurred independently of the provision of the relevant service, including where the incident results from a problem inherent in the operation of a distributed ledger that the provider does not control.

For institutions providing custody services, the ability to preserve and restore access consequently forms part of the wider responsibility surrounding the safekeeping of client assets. An access incident can affect the operation of the custody service, the institution's relationship with its clients and the evidence required to demonstrate that appropriate safeguards were in place.

This increases the importance of bringing recovery arrangements into the institution's wider custody governance rather than maintaining them as a separate technical procedure.

Third-party dependencies can determine whether recovery succeeds

Few institutional digital asset services operate entirely within infrastructure controlled by a single organisation. Custody technology, cloud infrastructure, key-management systems and specialist security providers can all form part of the environment through which assets are protected and accessed.

Recovery processes often inherit those dependencies, and both DORA and the FCA's operational resilience framework [KD7] address third-party dependency risk. Article 11(4) of DORA requires financial entities within scope to put in place, maintain and periodically test ICT business continuity plans with particular regard to critical or important functions outsourced or contracted through arrangements with ICT third-party service providers. The FCA's scenario testing rules in SYSC 15A identify the unavailability of third-party services critical to the delivery of an important business service as one of the scenarios firms should consider, as set out in PS21/3.

Where a third party holds recovery material or participates in the recovery procedure, institutions should understand precisely how that relationship operates during disruption. This includes where relevant material is held, who is authorised to access it, which jurisdictions are involved, what happens if the provider experiences its own operational or cyber incident, and whether the institution retains a viable route to recovery if the provider becomes unavailable.

The last of these questions is particularly important. A provider may strengthen resilience during many types of incident while simultaneously becoming a critical dependency during others. If both normal operations and recovery ultimately depend upon the continued availability of the same organisation, the institution should understand the circumstances in which that dependency could become a single point of failure.

Testing provider failure as part of a recovery exercise can expose these weaknesses before they affect client assets.

Establishing clear responsibilities before an incident

Effective recovery requires each material decision to have an established owner before an incident begins.

A practical responsibility matrix can provide that structure by recording which function defines the requirement, which individual has authority to approve recovery, who executes the relevant procedures and which teams need to be consulted or informed.

The value of the matrix depends upon its specificity. Naming "security" as the recovery owner may establish departmental responsibility, but it does not determine who can authorise a sensitive action at two o'clock in the morning.

Each critical responsibility should be assigned to a clearly defined role, with current authorised individuals, appropriate deputies and an escalation route identified in the operating procedure.

Testing the complete digital asset recovery process

The weaknesses within a recovery framework often become visible only when the process is exercised under realistic conditions.

A technical test may demonstrate that backup material can be restored, although it may reveal little about whether the institution can make the decisions required to use it during an actual incident. A testing programme should therefore include scoped exercises covering the people, procedures and dependencies surrounding the technical mechanism as well as the mechanism itself.

A realistic scenario might remove a key decision-maker from the exercise, delay an approval, make a third-party provider temporarily unavailable or provide participants with incomplete information concerning the cause of the access failure. This is close to the FCA's own framing. The scenarios identified in PS21/3 include the corruption, deletion or manipulation of critical data, the unavailability of facilities or key people, the unavailability of critical third-party services, disruption to other market participants and the loss or reduced provision of the technology underpinning an important business service.

The purpose is to understand how the operating model performs when the assumptions built into the documented procedure no longer hold. During the exercise, institutions can assess how quickly the incident is recognised and escalated, whether the appropriate decision-makers can be reached, whether participants follow the documented procedure, how long approvals take, whether communications remain coherent and whether recovery can remain within relevant service and impact tolerances.

The review following the exercise is equally important. Delays, workarounds, unavailable documentation and unexpected dependencies should be recorded and assigned for remediation, with subsequent testing used to establish whether the weakness has genuinely been addressed. This turns recovery testing into an ongoing process through which the institution's operating model develops alongside changes in technology, regulation, personnel and the custody service itself.

Building long-term digital asset recovery readiness

As financial institutions expand their digital asset activities, recovery arrangements will need to develop alongside the infrastructure they protect.

Changes to wallet architecture, key-management technology, custody providers, client types, approval policies and regulatory requirements can all alter the assumptions upon which an existing recovery process depends. A procedure that was effective when originally designed may therefore become less reliable over time unless it is periodically reviewed and exercised.

Institutions can strengthen recovery capability by incorporating recovery into their wider operational resilience and risk-management frameworks, bringing together the teams responsible for the service, the infrastructure protecting it, and the governance surrounding it.

The allocation will vary by institution, but often follows a similar pattern. Product, or the equivalent service-design function, may establish how recovery should operate for the client and the service. Security may oversee how access can be restored without undermining the controls protecting client assets. Compliance and risk may establish how the institution demonstrates that those arrangements satisfy its obligations and continue to operate as intended. Operations may provide the practical capability required to execute the process when an incident occurs. 

When an institution knows who can initiate recovery, who has authority to approve it, who can execute it, which third parties are required and how the process performs when one of those dependencies becomes unavailable, recovery becomes considerably more predictable and measurable.

How CoinCover can help

For institutions reviewing their existing approach, the CoinCover Recovery Playbook for Institutions provides a structured framework for identifying recovery risks, defining escalation procedures and testing recovery processes under realistic conditions.

CoinCover's protection solutions for financial institutions also provide further information on building digital asset protection and recovery capabilities around existing institutional custody and governance models.

This article is provided for general information only and does not constitute legal, regulatory or compliance advice. Regulatory requirements vary according to a firm’s activities, authorisations and jurisdiction. Responsibility for determining and meeting applicable obligations remains with the regulated entity. CoinCover provides technical and operational solutions that may support firms’ recovery and resilience arrangements.