Review 2024 preparation from a 2026 perspective
The title locates the decision before January 2025; it does not suggest this article was published in 2024. This retrospective analysis is written from 2026. DORA, the European regulation on digital operational resilience in the financial sector, has applied since 17 January 2025. Exact roles, scope and obligations require assessment for each entity. This article addresses programme work: turning resilience requirements into usable responsibilities, dependencies and tests.
In 2024, the danger was not simply a missing policy. An organisation could hold application inventories, contracts and backups while remaining unable to explain how long a business service could be unavailable or who would authorise recovery. Useful preparation started with the service delivered and worked back through its systems and providers. In 2026, the same approach remains relevant to assessing arrangements already established.
Illustrative scenario: five available applications, one stopped service
The scenario, people and numbers are teaching examples, not claimed CYTIZEN client results. Anne, a payments service owner, needs to assess recovery after an identity-provider interruption. Technical dashboards are green: databases, networks and software remain available. Operators nevertheless cannot sign in, while pending instructions continue to accumulate.
Julien, the programme coordinator, brings together business, operations, security and the provider. The exercise uses a locally agreed objective to restore limited processing within two hours. The technical plan provides for restoration in ninety minutes. It says nothing about restoring access, checking pending transactions or authorising service resumption.
The first exercise is therefore not successful merely when the database is restored. Anne wants to see an authorised transaction, its record and its reconciliation. The programme redesigns the test around service recovery. The two-hour tolerance is a scenario assumption, not a universal DORA threshold or a rule applicable to every payment activity.
Map a critical service
Assign a business owner and describe the service's outcome. Map the applications, data, teams, suppliers and shared dependencies needed to deliver it. Include often overlooked services: identity, certificates, connectivity, monitoring and communication channels. The boundary is broader than the main contract because failure points can sit in a dependency shared by several providers.
| Scenario element | Operational question | Expected evidence |
|---|---|---|
| Payment authorisation | Who decides on partial recovery? | Business-approved mandate and conditions |
| Identity | Do operators have controlled emergency access? | Tested access, logs and removal procedure |
| Transaction queue | How is an already executed transaction recognised? | Demonstrated reconciliation and duplicate handling |
| External provider | Which contact can act outside ordinary hours? | Exercised escalation with observed timings |
| Communication | Who informs users and relevant bodies? | Prepared message and available independent channel |
The map should not become an unmaintainable diagram of the whole estate. Start with a sensitive journey, show dependencies that can stop it and name accountable people. Detailed architecture can remain in its own records. The programme view should expose the decisions and relationships on which recovery depends.
Do not confuse backups, technical recovery and business outcome
Technical recovery time describes when a component can operate. Tolerable data loss concerns what must be retrieved or reconstructed. Service recovery also requires access, procedures, checks and business authorisation. These concepts are related, but none replaces the others.
In the exercise, the database is restored at 10:20. Access returns at 10:45. Reconciliation takes forty minutes and the first controlled transaction completes at 11:30. If interruption began at 09:00, service recovery took two and a half hours even though database restoration took eighty minutes. The report retains both measures instead of choosing whichever meets the target.
Define the clock's start and end, exclusions and evidence of success in advance. If the business accepts limited recovery, specify permitted operations, supported volume and additional checks. Partial recovery without known boundaries can create another error at the point where the organisation is trying to contain an incident.
Prepare an exercise that can expose failure
The test has a scenario, facilitator, observers, criteria and a person authorised to stop it. Participants receive information available at the simulated moment rather than the complete solution. Here, the facilitator introduces identity unavailability, then an absent provider contact and a discrepancy in the transaction queue. Observers record who decides and on which facts.
A tabletop rehearsal can expose gaps without touching production. A technical restoration test supplies different evidence. An end-to-end demonstration then connects the elements within an authorised environment and process. No single exercise proves every capability. The programme combines them according to risk and security constraints.
The evidence record contains the timeline, actions, decisions, checks and gaps. Every gap needs an owner, a date and proof of closure. Improve procedure is insufficient. Verify emergency access with two authorised operators and document its removal after the exercise is observable and can be retested.
Define when rehearsal results are transferable to the actual service. Different data volumes, provider availability or permissions may alter recovery. Keep assumptions visible and avoid describing an exercise on a simplified environment as proof of every production condition. The limitation can itself generate a further test or a temporary operating restriction.
Providers: a contract is not demonstrated capability
Procurement gathers relevant commitments and rights. IT checks their correspondence with actual dependencies. The business describes the consequence of interruption. Legal reviews provisions applicable to the contract and entity's role. Programme leadership coordinates gaps without replacing those professional assessments.
In the scenario, the contract promises a one-hour response, but the team uses an ordinary support address. The exercise reveals that urgent escalation requires another number and reference. Closure is not achieved by copying the contract. Update the procedure, test escalation and confirm that the provider recognises the request.
Also examine concentrated dependencies. Two suppliers may use the same identity service or technical region. Having two contracts does not automatically provide independent fallback. The programme must explain which scenario is covered and which remains without an alternative. A dependency accepted for a limited scope should be revisited before the business expands the affected service.
A compact evidence record that can be maintained
For each service, assemble a scope record, dependency map, locally approved objectives, required procedures, contract references, exercises and gap register. Every item has a version and owner. References should retrieve current evidence without copying every file into multiple repositories.
A review examines three separate rates: critical services with approved ownership and dependencies; planned scenarios actually exercised; important gaps closed with retesting. In an illustrative portfolio of ten services, eight approved maps, six completed exercises and four retests should not become 80% ready. Denominators and the criticality of the two unmapped services matter more than an aggregate score.
A provider, architecture or business-process change triggers updates to affected evidence. A complete record in January may be obsolete in June. Maintenance ownership belongs to the service after programme closure, with information access and an appropriate review schedule. The handover should identify who receives supplier notices and which changes require an exercise rather than a document update alone.
The decision the sponsor actually needs to make
The scenario review concludes that the local recovery objective has not been demonstrated. It keeps the existing fallback arrangement and requires corrections to access and reconciliation. Anne approves the business journey; operations owns the technical test; the supplier must resolve escalation. A retest is required before another dependency is authorised. This expresses a choice and responsibilities rather than merely a red status.
A sponsor may temporarily accept risk within their authority and the applicable framework. They need its consequence, compensating measures and review date. Compliance should not replace that explanation. An internal decision does not erase a legal obligation or the responsibilities of competent governing bodies.
The decision record should also distinguish accepted residual risk from work still missing. If nobody can explain the affected transactions, the uncertainty is not yet a quantified risk accepted by management. Request the missing facts, limit the scope where appropriate and make the next decision explicit. This helps prevent programme deadlines from turning unknown dependencies into assumed readiness.
Adapt evidence to the financial function
For payments, recovery includes integrity, duplicates and transaction state, rather than application access alone. For insurance, claims handling needs case data and appropriate permissions; any manual mode must preserve checks and traceability. For a technology provider, distinguish commitments to the customer from requirements actually applicable to the provider's role and any relevant designation.
DORA should not be presented as a regulation imposing exactly the same arrangement on every industrial business. Other organisations may borrow the service-and-test approach, but their regulatory framework needs separate assessment. Similar operating methods do not make legal scope identical.
Sources, method and limitations
Primary sources consulted on 4 October 2026: EIOPA overview of DORA; EBA on digital operational resilience; ACPR DORA framework. The regulation referenced by these authorities is the legal source; this article analyses operational preparation.
The scenario's targets, volumes and times are illustrative, not regulatory minima. The method follows a service to its business outcome, links dependencies to owners and examines gaps through testing. Exact obligations, required tests and contractual responsibilities require competent assessment of the entity and service. This article supplies neither a certified legal opinion nor a compliance certificate.