Digital Sovereignty Is Now a Board-Level Risk: What DORA and the ECB Mean for Crypto Accounting Software
A new KPMG analysis produced in collaboration with the European Central Bank frames digital sovereignty not as a niche compliance exercise but as a core strategic capability for regulated financial institutions. Published on 6 July 2026, the paper argues that banks and, by extension, any ECB-supervised entity, must be able to understand, control and, where necessary, unwind critical technology dependencies. For accounting firms advising financial clients, CFOs running crypto treasury functions, and any organisation relying on digital asset accounting software to meet its regulatory obligations, this framing has direct and immediate implications.
What KPMG and the ECB Actually Said
The analysis positions digital sovereignty as a risk-management discipline rather than a technology procurement preference. Europe's financial institutions rely heavily on a small number of global cloud, software and AI platforms to deliver core banking functions at scale. That concentration creates efficiencies, but it also creates single points of failure and exposure to geopolitical or legal developments that originate outside the EU's jurisdictional reach.
The paper is clear that digital sovereignty does not require institutions to internalise all technology or to avoid non-European providers. What it does require is that dependencies are visible, controlled and, crucially, reversible. An institution that cannot exit a critical third-party relationship without operational disruption has, in the paper's framing, already ceded sovereignty.
The regulatory baseline: DORA and the ECB cloud guide
The hard legal floor for EU-regulated banks sits in two instruments. First, the Digital Operational Resilience Act (DORA), which requires institutions to maintain credible exit plans for critical ICT third-party service providers. Second, the ECB's revised guide on cloud outsourcing, which sets supervisory expectations for concentration risk management in cloud procurement. Together, these instruments mean that digital sovereignty is not merely a strategic aspiration; it is already embedded in supervisory examination programmes.
Beyond those two anchors, KPMG identifies a wider policy architecture that is pushing in the same direction: the Digital Markets Act, Germany's revised competition law, the EU Tech Sovereignty Package, the proposed Cloud and AI Development Act, Chips Act 2.0, and the EU's Open-Source Strategy. None of these instruments individually creates a new obligation for every firm, but collectively they signal clear supervisory intent. Boards and audit committees that treat digital sovereignty as a future concern are, in the paper's words, already behind the curve.
Why Crypto Accounting Software Is Caught by This Analysis
Accounting firms and CFOs managing digital asset portfolios routinely rely on third-party platforms for transaction ingestion, ledger reconciliation, cost-basis calculation and regulatory reporting. Those platforms sit squarely in the category of critical ICT services the KPMG/ECB paper addresses. If a provider is embedded in the month-end close process, the audit trail, or the tax filing workflow, then a forced or unplanned exit from that provider carries exactly the operational and regulatory continuity risk the framework is designed to manage.
This is not a theoretical concern. The concentration of crypto bookkeeping software provision among a small number of vendors, many of which are headquartered outside the EU, means that the geopolitical exposure the paper describes, covering data residency, legal access requests, and contractual enforcement, applies directly to crypto finance functions.
Data residency and decision rights
The KPMG paper introduces a useful distinction between EU-based hosting and genuine sovereignty. Locating data within EU borders does not, on its own, satisfy the framework if the provider retains unilateral rights to move workloads, change encryption standards, alter data-access models, or terminate the contract on short notice. For firms using digital asset accounting software, the relevant questions are whether transaction-level data can be extracted in a portable format, whether the vendor's support model creates an operational dependency that cannot be unwound quickly, and whether the contractual terms give the client genuine audit and exit rights.
AI models and the new dependency layer
KPMG specifically highlights the rise of AI as a factor that deepens digital sovereignty risk. When AI models influence credit decisions, compliance alerts, or transaction classification, the institution needs to understand not only where the underlying data sits but also which model, trained on what data, is producing outputs that feed regulated processes. For crypto accounting and AML functions, where classification of on-chain activity is increasingly AI-assisted, this adds a new due-diligence layer that firms will need to document in their ICT risk registers under DORA.
The Seven-Area Action Framework
KPMG's paper outlines seven areas of action for institutions seeking a pragmatic path toward digital sovereignty. While the paper is directed at banks, the logic maps cleanly onto the governance challenges facing any regulated entity running material crypto finance operations.
Classification and placement logic
The first practical step is classification: mapping applications, data sets and processes by criticality, regulatory sensitivity, data confidentiality, substitutability and exit feasibility. For a CFO's office, this means categorising the crypto accounting software stack in the same way a bank would categorise its core banking system. Is the platform critical to the close process? Is transaction data held exclusively by the vendor? What is the realistic migration timeline if the relationship ends?
Classification then drives placement decisions. The paper argues that EU-based deployment may be appropriate for critical services but that it is not sufficient on its own. Control rights, support dependencies, encryption governance and portability must be assessed alongside geography.
Hardening existing infrastructure and open-source discipline
The paper recommends selective use of open-source tooling to reduce vendor lock-in, while noting a clear condition: open source only strengthens sovereignty if the institution has the internal capability to operate it securely across its full lifecycle. That means clear ownership, structured patch management, proactive vulnerability management and sufficient technical know-how to maintain and harden components over time. Firms that deploy open-source crypto bookkeeping tools without those operational capabilities may reduce licence dependency while simultaneously increasing operational and security risk.
Reclassification under geopolitical stress
The paper calls explicitly for institutions to analyse the new geopolitical risk landscape and reclassify assets accordingly. For accounting firms and CFOs, this means the ICT risk register for crypto finance infrastructure should not be a static document. It should be reviewed against live geopolitical developments, including sanctions regimes, data-localisation legislation in third countries, and changes in a vendor's ownership structure or jurisdiction.
Accounting and Audit Implications
The digital sovereignty framework intersects with financial reporting obligations in two ways that accounting professionals need to track.
Going-concern and continuity disclosures
Where a firm's ability to produce auditable financial records depends on a single third-party platform for which no credible exit plan exists, auditors and preparers face a disclosure question. DORA's exit-plan requirement is, at its core, a going-concern safeguard for operational processes. If that safeguard cannot be demonstrated, the absence of a workable contingency may need to be reflected in risk disclosures within financial statements, particularly for entities that hold or process material volumes of digital assets.
ICT risk register and ISAE 3402 / SOC 2 assurance
Audit firms providing assurance over crypto finance processes will increasingly need to assess the digital sovereignty posture of the digital asset accounting software used by their clients. DORA subcontracting requirements mean that the client's ICT third-party risk framework now extends to the software vendors that feed regulated reporting. Auditors should expect to see documented exit plans, data-portability evidence, and contractual audit rights as part of the control environment they are asked to attest to.
For a broader view of how supervisors are stress-testing the ICT and reporting infrastructure of European financial institutions, the EBA 2027 stress test covering IFRS 9 and the COREP/FINREP overhaul sits alongside the digital sovereignty agenda as part of the same supervisory push toward operational and financial resilience.
Practical Steps for Accounting Firms and CFOs
The KPMG paper's call to action translates into a short set of concrete priorities for finance and compliance professionals managing crypto-related technology dependencies.
Vendor due diligence: beyond the security questionnaire
Standard vendor security questionnaires capture cybersecurity posture but typically miss the sovereignty dimensions the paper identifies. A revised due-diligence template for crypto accounting software should add questions on: data portability formats and export APIs; contractual exit timelines and termination assistance obligations; the vendor's own dependency on sub-processors in non-EU jurisdictions; AI model governance where classification or alerting functions are AI-assisted; and the geographic scope of law enforcement or regulatory access rights the vendor is subject to.
Firms evaluating their AML tooling should also cross-reference our earlier analysis on blockchain analytics vendor evaluation for AML compliance, which covers related concentration and quality-of-output risks in the chain analytics layer.
Exit planning as a live document
DORA requires exit plans to be credible, not theoretical. For a crypto finance function, a credible exit plan means a documented, tested process for migrating historical transaction data, cost-basis records and audit trails to an alternative platform within a defined timeframe. That plan should be reviewed at least annually and stress-tested against realistic scenarios, including vendor insolvency, regulatory withdrawal of authorisation, and geopolitically-driven service suspension.
Board and audit committee reporting
The KPMG paper identifies digital sovereignty as a board-level concentration risk topic. For CFOs, this means the crypto finance technology stack should appear in the ICT risk section of board reporting, with sovereignty metrics sitting alongside the more familiar cybersecurity and business continuity indicators. Audit committees overseeing digital asset operations should ask management explicitly whether critical crypto accounting software relationships have documented exit plans that meet DORA standards.
The MiCA licensing enforcement already under way across the EU, illustrated most recently by MiCA licensing enforcement in Belgium, adds a further dimension: firms that lose access to a compliant CASP or accounting platform because of a regulatory or geopolitical event need to know, in advance, where they will go next.
What Happens Next
The KPMG paper is an advisory document, not a binding instrument. However, it carries significant weight as a co-production with the ECB's office, and its recommendations closely mirror the language of DORA's implementing technical standards and the ECB's supervisory priorities for 2026 and beyond. Institutions that treat this as a signal of forthcoming examination focus rather than a voluntary best-practice guide are reading the supervisory environment correctly.
For accounting firms and CFOs, the near-term calendar item is a review of the crypto accounting software and digital asset accounting software in use across the organisation against the classification and placement criteria the paper describes. That review should produce a documented output: a register of critical ICT dependencies, an assessment of sovereignty risk for each, and an exit plan where the risk is rated as material. Doing that work now, before it is requested by a supervisor or an external auditor, is precisely the kind of proactive governance the ECB is looking for.
Source: KPMG Digital Assets / ECB Office
Frequently Asked Questions
Does digital sovereignty apply to accounting firms, or only to banks?
The KPMG/ECB paper is directed at ECB-regulated banks, but the underlying risk logic applies to any organisation that relies on critical third-party technology for regulated financial processes. Accounting firms advising financial institutions, and CFOs running crypto treasury or reporting functions, are exposed to the same concentration and exit risks the paper describes. DORA itself has a broad scope that extends beyond banks to financial entities and their ICT service providers.
What does DORA require specifically for crypto accounting software?
DORA requires in-scope entities to identify critical ICT third-party service providers and maintain credible exit plans for each. If a crypto accounting or bookkeeping platform is embedded in critical reporting processes, it is likely to qualify as a critical ICT service. Firms must document the dependency, assess concentration risk, and maintain a tested exit plan that includes data portability and migration timelines.
Does hosting data in the EU satisfy the digital sovereignty requirement?
Not on its own. The KPMG paper explicitly states that EU-based operations do not guarantee sovereignty. What matters is whether the institution retains control rights over its data, whether it can extract and migrate data in a portable format, whether encryption is under the institution's control, and whether credible contractual exit options exist. Geography is one factor among several.
How should a CFO approach open-source crypto bookkeeping tools under this framework?
Open-source tooling can reduce vendor lock-in, but only if the organisation has the internal capability to operate it securely over its full lifecycle. The KPMG paper conditions the sovereignty benefit of open source on clear ownership, structured patch management, vulnerability management and sufficient operational know-how. A CFO considering open-source digital asset accounting software should assess whether those internal capabilities exist before treating open source as a sovereignty solution.
What should audit firms ask when reviewing a client's digital asset accounting software arrangements?
Auditors should request evidence of documented exit plans, data-portability testing, contractual audit rights and an assessment of the vendor's own sub-processor dependencies. Where AI models influence transaction classification or compliance alerting, auditors should also ask for AI model governance documentation. These items should be part of the IT general controls review for any engagement where crypto accounting software feeds the financial statements or regulatory reports being assured.