DORA,
from five pillars to proof.

DORA compliance: turn service dependencies into operational decisions

A payment service can have a recovery procedure and still fail when its identity provider becomes unavailable. The practical challenge under DORA is to show how governance, technology, suppliers and recovery arrangements work together. Start with the financial service that must remain available, then trace the decisions and evidence supporting it.

This guide focuses on the operating model: who owns the risk, which dependencies matter, how to test recovery and what to retain for supervision. A completed policy is a starting point, not proof that a service can withstand disruption.

Who needs to act

Article 2 of Regulation (EU) 2022/2554 covers numerous categories of financial entities, including credit institutions, payment institutions, investment firms, insurers and certain crypto-asset service providers. Scope follows the entity's regulated status, not simply its use of financial software.

Exclusions and specific regimes matter. Some smaller entities are excluded; others fall under the simplified ICT risk-management framework in Article 16. Proportionality under Article 4 affects implementation but is not a general exemption for small organisations. Record the legal basis for your assessment before selecting controls.

ICT suppliers face contractual requirements from financial customers. Providers designated as critical are also subject to a dedicated European oversight framework. Supplying a bank does not automatically make every technology company a designated critical provider.

Requirements that need operational evidence

Under Article 5, the management body defines, approves and oversees the ICT risk-management framework and remains responsible for its implementation. Give management decisions clear inputs: service exposure, unresolved weaknesses, investment choices and accepted residual risks.

The framework in Articles 6–16 connects identification, protection, detection, response, recovery and learning. For each important service, retain evidence of dependencies, access controls, backups, restoration tests and improvements after incidents. Recovery objectives should reflect business impact rather than a default value copied between systems.

Supplier governance must extend beyond procurement approval. Articles 28–30 address ICT third-party risk and contractual arrangements, with additional provisions for services supporting critical or important functions. Review service descriptions, data locations, assistance during incidents, access and audit arrangements, termination provisions and exit planning as applicable.

A useful evidence pack includes:

• A named service owner and a justified criticality assessment.
• An architecture view showing internal and external dependencies.
• Test results, defects, corrective actions and retest decisions.
• Approved contracts and an assessment of concentration risk.
• Management decisions explaining unresolved or accepted exposure.

Article 45 permits qualifying information-sharing arrangements. Participation is not a blanket obligation to share sensitive information with other firms.

Timeline and reporting clocks

DORA has applied since 17 January 2025. By November 2026, implementation should be treated as ongoing operation, not preparation for a future commencement date.

Article 24 requires entities other than microenterprises to conduct appropriate tests at least yearly on ICT systems and applications supporting critical or important functions. Advanced threat-led penetration testing under Article 26 applies to identified entities, generally at least every three years; the competent authority can adjust that frequency. It is not a universal testing requirement for every supplier or financial entity.

For major ICT-related incidents, Article 5 of Delegated Regulation (EU) 2025/301 sets specific reporting clocks:

• Initial notification as early as possible, within four hours of major classification and ordinarily no later than 24 hours after awareness.
• If classification as major occurs after those 24 hours, notification within four hours of classification.
• An intermediate report within 72 hours of the initial notification.
• A final report within one month of the intermediate report or latest updated intermediate report.

Build the procedure around the applicable rules, including updates and relevant exceptions. Do not confuse these clocks with a personal data breach notification assessment under GDPR.

Sanctions and business stakes

Article 50 requires Member States to establish administrative penalties and remedial measures. There is no single DORA fine ceiling that can safely be quoted for every financial entity across the EU. Identify the national enforcement regime and relevant competent authority for your organisation.

Supervisory requests, remediation orders and public notices can create substantial management work. Operational consequences may arrive sooner: interrupted services, failed reconciliations, unavailable customer channels or an exit plan that cannot be executed. Compliance priorities should therefore follow service impact, not just the ease of collecting documents.

A step-by-step implementation path

1. Confirm the legal perimeter. Identify regulated entities, applicable exclusions, simplified regimes and supervisory contacts. Distinguish group policy from each entity's responsibilities. Keep the rationale available for legal review.

2. Select the services that matter most. Work with business owners to assess critical or important functions. Map applications, infrastructure, people and suppliers supporting them. Validate the map through a real service walkthrough.

3. Assess gaps against actual operation. Compare requirements with current controls, not policy titles. Sample access reviews, backup restoration evidence and incident records. Separate missing documentation from missing capability so remediation addresses the right problem.

4. Repair supplier and recovery weaknesses. Prioritise dependencies with high service impact, limited substitutability or unclear contractual rights. Assign owners for negotiations and exit exercises. Test whether data, configurations and operational knowledge can actually be recovered or transferred.

5. Exercise incident decisions. Simulate a supplier outage and require participants to classify the incident, identify reporting triggers and obtain approval. Record awareness and classification timestamps. Ensure deputies can act when the usual decision-maker is unavailable.

6. Establish recurring review. Schedule tests, evidence refreshes and management reviews. Track findings through correction and retesting. Reassess dependencies when services, contracts or architecture change rather than waiting for the next annual exercise.

How Domyno supports the work

Domyno combines a SaaS platform with a dedicated human expert: agents prepare work and a human validates it. This supports a controlled preparation process while keeping regulatory decisions with the responsible organisation.

Use risk analysis to structure assessments with EBIOS RM or ISO 27005. Third-party management provides a place to organise supplier work alongside your operational priorities. Neither replaces testing the service or negotiating the required contract.

The controls and compliance module brings one control library, evidence and action plans across more than 28 frameworks. Shared security work can support several obligations while requirement-specific evidence remains identifiable. Documentation versions help preserve the decisions behind each review.

Domyno offers more than 300 connectors, including on-premises Active Directory, and can be hosted in any cloud, any region or on premises. Deployment flexibility does not remove the need to assess your own dependencies and contractual safeguards.

Official references

Consult DORA on EUR-Lex and the incident reporting deadlines when validating your procedures.

To discuss a practical operating model for your financial services and supporting suppliers, request a Domyno demo.