DORA: A Practical Guide for the Financial Sector

DORA: a practical guide for the financial sector in November 2026

DORA is no longer a future compliance deadline. The Digital Operational Resilience Act, Regulation EU 2022/2554, has applied since 17 January 2025. Financial entities now need to demonstrate that their ICT risk management, incident reporting, resilience testing and third-party oversight work in practice.

The useful question is no longer “Have we written a DORA policy?” It is “Can we maintain an important financial service during disruption, explain our dependencies and produce reliable evidence?”

This guide retains that operational focus: establish scope, connect the five main areas of DORA and turn compliance into repeatable work rather than an annual document exercise.

Establish which obligations apply

Article 2 lists the financial entities within scope, including credit institutions, payment institutions, investment firms, insurance undertakings and several other financial-market participants. Exemptions and proportionality provisions matter; not every financial business faces an identical framework.

Map the legal entities, regulated activities and competent authorities in your group. Check whether the full or simplified ICT risk-management framework applies. Document the reasoning rather than assuming that a small team or outsourced infrastructure removes the obligations.

ICT suppliers require a separate analysis. Providing cloud or software services does not automatically make a supplier a designated critical ICT third-party provider. DORA establishes an EU oversight framework for providers designated as critical, while financial entities remain responsible for their own compliance when using external services.

For relevant financial entities, DORA also acts as sector-specific Union law in relation to NIS2 under Article 1(2). Coordinate the assessment rather than building duplicate reporting processes without examining the legal interaction.

The technical standards are operational requirements

Do not manage DORA from the base regulation alone. Adopted regulatory technical standards, or RTS, specify requirements; implementing technical standards, or ITS, standardise formats and procedures.

Key references include:

• Regulation 2024/1774: ICT risk-management tools, methods, processes and policies, including the simplified framework.
• Regulation 2024/1772: classification criteria and materiality thresholds for ICT incidents.
• Regulation 2024/2956: ITS templates for the register of information.
• Regulation 2025/301: incident-reporting content and deadlines.
• Regulation 2025/302: ITS reporting forms, templates and procedures.

These are adopted acts, not merely consultation drafts. Use the official register templates and the applicable authority's submission instructions. This list is a starting point, not an exhaustive catalogue: maintain a legal inventory of the standards relevant to your activities.

1. Make ICT risk management accountable

Under Article 5, the management body defines, approves, oversees and is responsible for implementing arrangements related to the ICT risk-management framework. Security cannot be delegated entirely to IT or a provider.

Connect business services to applications, infrastructure, information assets, people and suppliers. Identify critical or important functions and explain how their supporting dependencies are protected and recovered.

Useful evidence includes approved policies, risk decisions, access reviews, vulnerability remediation, backup tests and management follow-up. A control should have an owner, an expected result and a way to verify effectiveness. Exceptions need expiry dates and an escalation route.

2. Rehearse incident classification and reporting

A statement that “DORA requires notification within four hours of detection” is misleading. Under the incident-reporting RTS, Regulation 2025/301, the general initial-notification rule is as early as possible, within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it.

Where classification as major occurs more than 24 hours after awareness, the RTS provides for notification within four hours of classification. Specific provisions and permitted timing adjustments must be checked for the entity concerned.

The intermediate report is generally due within 72 hours of the initial notification. The final report is due within one month after the intermediate report or latest updated intermediate report. Reporting is therefore a sequence, not one message.

Record awareness and classification times separately. Prepare the required templates, deputies and evidence sources before an incident. Exercise decisions under uncertainty: the team must escalate without waiting for a complete forensic conclusion.

3. Test resilience, then close the findings

DORA requires a risk-based digital operational resilience testing programme. Tests should examine realistic failures, including unavailable services, compromised access and interrupted provider dependencies.

Record the scenario, scope, result, remediation owner and retest. An exercise report with unresolved actions is not evidence that the weakness has disappeared.

Advanced threat-led penetration testing, or TLPT, is not a universal obligation for every financial entity. Article 26 establishes it for entities identified under the applicable criteria, generally at least every three years, subject to the authority's permitted adjustments. Confirm applicability rather than treating an ordinary penetration test as equivalent.

4. Treat the register of information as a maintained dataset

Article 28(3) requires financial entities to maintain and update a register covering contractual arrangements for ICT services provided by third parties. It is not limited to arrangements supporting critical or important functions, although those must be distinguished.

Build the relationships between:

• The financial entity receiving the service.
• The contractual arrangement and ICT service.
• The provider and relevant subcontracting information.
• The supported function and its criticality assessment.
• The identifiers and other data required by the templates.

Use controlled identifiers, reconcile contracts with procurement and finance records, and test consistency across the templates. A supplier spreadsheet with inconsistent names is not a reliable register.

Maintain information at the relevant entity and group levels. Distinguish the obligation to keep the register current from annual reporting and requests for the full register. Confirm the submission calendar and technical requirements with the competent authority; do not assume one permanent EU-wide upload date.

Article 30 also sets contractual requirements, with additional provisions for services supporting critical or important functions. Review service descriptions, data access and recovery, incident assistance, audit rights and exit arrangements. A signed addendum is useful only if the organisation can exercise the rights it contains.

5. Share information within a controlled framework

Article 45 permits information-sharing arrangements subject to conditions. It does not impose universal membership of a threat-sharing community. Decide which exchanges help your organisation, who approves participation and how confidential or personal information will be protected.

A practical improvement sequence

1. Confirm scope: entities, authorities, exemptions and framework applicability.
2. Map dependencies: important functions, assets, providers and contracts.
3. Validate the register: ownership, identifiers, completeness and template consistency.
4. Test reporting: classification decisions, clocks, templates and deputies.
5. Exercise recovery: realistic disruption, restoration and provider cooperation.
6. Close weaknesses: accountable actions, retests and management review.

Avoid importing NIS2's headline penalty percentages into DORA. The regulation provides supervisory and enforcement powers, while relevant national arrangements also matter. Operational evidence is more useful than an unsupported universal fine figure.

Coordinate the work without outsourcing accountability

Domyno combines a cyber-governance SaaS platform with a dedicated human expert; agents prepare work and a human validates it. Its third-party management module and controls and compliance module can support organised supplier reviews, evidence and action plans.

The platform supports governance; legal interpretation, regulatory submissions and management accountability still require appropriate human oversight. To discuss your operational priorities, request a demo.