Self-hosted ledger resilience for DORA

DORA's Chapter III (Articles 17 to 23) requires financial entities to manage ICT-related incidents, classify them and report major incidents to the competent authority, so the entity needs a record of each incident from detection through closure. Under the Regulation, the incident process must capture when the event was detected, what systems and customer groups were affected, how severity was classified and what actions were taken. For a ledger, that means an incident record that names the affected ledger accounts or balance ranges, the transfer identifiers in flight, and the decision trail for any recovery or replay. Confirm the exact field list, initial notification timing and intermediate and final report content with your competent authority and your internal incident taxonomy, since the detailed technical standards define how the fields are populated.

Retain logs that let you reconstruct the sequence of events without relying on memory. For the ledger, keep request logs with idempotency keys, transfer and account identifiers, posting outcomes, rejections and errors, and the time each was received and committed. For the replica cluster, keep consensus and replica state changes, failover and view changes, and any node restarts or disk errors. For the surrounding stack, keep infrastructure and network logs, time synchronization records, authentication events for operators, and change records for deployments and configuration. Use a single clock source with documented synchronization, because incident timelines are unreliable otherwise. Set retention periods in your own policy, and confirm with your auditors and supervisor how long incident evidence must be kept. Test that logs can be exported off the affected cluster during an outage.

Link them by carrying a stable identifier from the customer-facing event through to the ledger and into the reconciliation output. In practice, each customer instruction should map to an idempotency key, which maps to the ledger transfer identifier, which maps to the account balance movement and then to the bank or processor reference. During an outage, the incident record should list the transfer identifiers that were pending, rejected, duplicated or uncertain, and the reconciliation run that later confirmed or corrected each one. The mapping is only as good as its design, so verify with your engineers that identifiers are generated before the write and retained in your data store, and that the reconciliation process reads the same identifiers. Ask your implementation partner to show this trace end to end in a test scenario before go-live.

The root cause record should explain what failed, why the failure was not prevented or detected sooner, what was done to restore service and what changes were made afterward. For a ledger, that usually includes the replica or network condition that triggered the event, the state of each replica at the time, whether any transfers were lost, duplicated or left pending, and how integrity was confirmed after recovery. The record should link to the change records for any recent deployment and to the recovery test results, if they exist. Keep the record factual and dated, and separate confirmed findings from hypotheses. Ask your competent authority how it expects the root cause to appear in final reports, and whether a preliminary analysis is acceptable at the earlier reporting stage.

Reporting follows a staged structure set by the regulatory technical standards and the supervisor's own procedures, typically an initial notification, one or more intermediate updates and a final report. The content usually covers the incident's classification, its impact on clients, transactions and data, the affected services and locations, the recovery status and any third-party involvement. For a self-hosted ledger, prepare a template in advance that pulls the transfer identifier ranges, affected account counts and time windows from your logs rather than from memory. Confirm with your competent authority which reporting channel, format and deadlines apply to your entity type, whether the incident also falls under NIS2 reporting if you are an essential or important entity, and how to handle incidents that span a third-party provider.

The financial entity remains responsible for its own incident reporting even when a provider operates the ledger, so the contract must give it timely access to the evidence it needs. Under DORA's ICT third-party risk chapter (Articles 28 to 44), the contractual arrangements should set out notification duties from the provider, the logs and records the provider must keep, how the entity can obtain them, and how data is returned on termination. The register of information (Article 28(3)) should identify the provider and the services supporting each critical or important function. Confirm with your legal and compliance teams which log formats, retention periods and export methods are in the contract, and test the export before an incident occurs.

A reasonable partner scope includes an incident evidence design, a logging and retention configuration for the ledger and its monitoring stack, a runbook for capturing transfer identifiers during an outage, a reporting template and a tested reconstruction exercise. DeployOpen plans, implements and documents self-hosted open-source platforms in the client's own infrastructure, and it prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or regulatory approvals. Ask any partner to define in the written scope which artifacts it will deliver, which of them the entity must approve, and what the entity must run after handover. Scope, deliverables and timelines are normally agreed in writing before work starts, so request those details in the quote rather than assuming them.

The main cost drivers are replica count and sizing, the number of sites, the integrations that feed the ledger, the scope of resilience and recovery testing, and the depth of ICT third-party contract review. Infrastructure is recurring: compute, storage, network links and backup capacity for each replica and site. One-time work includes architecture, deployment, integration, runbooks and the first recovery test. Recurring work includes patching, monitoring, periodic recovery exercises and evidence refresh. A written quote should separate these lines, list the sites and replicas in scope, and state which tests are included and how many rounds of each. DeployOpen does not publish prices, so the quote follows from the agreed scope.

Duration depends on scope, not on a fixed template. The variables are how many sites and replicas the entity runs, how many upstream payment and core banking systems must integrate, how mature the existing change and incident processes are, and whether the register of information and exit plans already exist. No timeline figure applies to every entity, so ask the implementation partner to break the schedule into phases with named deliverables and entry and exit criteria for each. Check whether the plan includes time for the recovery test, the evidence pack and the review by the entity's risk and legal teams, since those steps often set the critical path.

Many entities have the engineering skills to operate a ledger, but DORA adds obligations that go beyond engineering. The team needs to classify the ledger's function as supporting a critical or important function, maintain the ICT risk framework, define incident classification, run tested recovery and exit exercises, and produce evidence that a competent authority can review. A useful self-check is whether the team can name the owner of each control, reproduce a site-loss recovery on a schedule, and show the records from the last incident without reconstructing them from memory. Gaps in any of these areas are where an external partner typically adds the most value, either as a fixed-scope engagement or as an ongoing retainer.

Each function has a distinct role. Risk owns the ICT risk framework, the classification of the ledger as supporting a critical or important function, and the risk acceptance for residual gaps. Legal reviews ICT service contracts against the requirements for service location, data processing location, advance notice of changes, and data return on insolvency or termination. Operations owns the recovery runbooks, the on-call model, the change process and the incident timeline. Each team should name a single accountable person and agree on what evidence it will sign off. Ask the partner to list these inputs in the quote so that internal review time is planned, not discovered during the assessment.

A vendor-managed ledger shifts infrastructure work to the provider but does not shift the entity's obligations. The entity still needs a register of information on all contractual arrangements for ICT services, documented and tested exit strategies for services that support critical or important functions, and contract terms covering location, notice and data return. Costs come from contract review, due diligence on the provider's resilience, ongoing monitoring of the provider and the exit planning itself. Ask any provider for the evidence it can share on its own recovery testing, sub-outsourcing chain and data location, and include the cost of reviewing that material in your internal estimate.

No. DORA does not set up a certification scheme. Competent authorities supervise compliance using their powers under Article 50, and the only authority-issued attestation the Regulation provides for is that a threat-led penetration test met the requirements under Article 26(7). Any vendor or consultant that offers a DORA certificate for a platform should be asked to explain what it covers and who issued it. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and the entity's supervisor make those judgments.

A useful quote lists the following in writing:

• The sites, replicas and environments in scope, and the topology diagram they refer to
• Each integration with payment, core banking and accounting systems, with the interface and data flows
• The recovery and failover tests included, how many rounds, and who witnesses them
• The incident evidence pack, including the records produced and how they are retained
• Assumptions about the entity's existing ICT risk, change and third-party processes
• Client inputs and review cycles for risk, legal and operations
• What is one-time, what recurs, and what support or testing retainer applies after go-live

DeployOpen engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the exclusions as well as the inclusions.

Testing scope depends on whether the ledger supports a critical or important function, how the entity has classified its ICT systems, and whether the entity is subject to threat-led penetration testing. Chapter IV of DORA covers digital operational resilience testing, and the ECB states that the core requirements of DORA TLPT and TIBER-EU are identical. Scope should be agreed against the entity's own classification and documented test plan. Ask the partner to show how each test maps to a requirement, what the test environment mirrors from production, and what remediation timing is assumed. Testing costs rise with the number of systems in scope and the number of rounds required to close findings.