Govern ICT risk
Give the management body a clear framework, named ownership, current policies and enough information to direct and challenge the work.
DORA is not a filing project. It is an operating responsibility.
The Digital Operational Resilience Act has applied since 17 January 2025. It asks in-scope financial entities to govern ICT risk, handle and report major incidents, test resilience, and control ICT third-party risk as part of normal operations.
DORA in one minute
DORA is Regulation (EU) 2022/2554. It creates a common EU framework for the digital operational resilience of the financial sector. The management body remains accountable, while the work crosses risk, information security, operations, procurement, legal, compliance and the business.
Read the official regulation
Who needs to act
Start with the legal entity, its licence and the services it depends on.
DORA covers a broad range of EU financial entities, including banks, insurers, investment firms, payment and electronic-money institutions, fund managers, pension institutions, crypto-asset service providers and financial market infrastructures.
The regulation also creates an oversight framework for ICT third-party providers designated as critical. Proportionality, exclusions and the simplified ICT risk management framework can change what a particular entity must do. Scope therefore needs to be checked entity by entity, not inferred from a group label.
Five connected workstreams, one operating picture.
These workstreams are often owned by different teams. DORA makes the relationships between them the important part.
Manage incidents
Detect, record, classify and respond to ICT-related incidents, with the facts and decisions needed for major-incident reporting.
Test resilience
Run a risk-based testing programme, track findings and show that remediation changes the organisation's actual resilience.
Control ICT third parties
Understand dependencies, assess concentration and contract risk, maintain exit thinking and keep the Register of Information current.
Learn and share
Use incidents, tests and threat information to improve the framework. DORA also permits voluntary cyber-threat information-sharing arrangements.
Why implementation gets difficult
The knowledge exists. It rarely exists together.
The service owner knows which supplier matters. Procurement knows the contract. Information security knows the incident history. Risk knows the control. Finance knows the spend. Much of the explanation lives in meetings, email and documents that no one maintains as a shared operating record.
A more durable operating model
Connect the responsibility before automating the output.
A workable DORA model starts with shared records: legal entities, business functions, ICT services, assets, suppliers, contracts, risks, controls, incidents, tests, decisions and evidence. Each team can keep its own accountability without rebuilding the same facts for every request.
Ariadnah helps recover that organisational knowledge, give it named ownership, connect it across workflows, and carry it forward into registers and reporting. Specialists remain responsible for interpretation and judgement. The platform makes the underlying work visible and reusable.
Governance & policiesOwnership, requirements, approvals and durable policy knowledge.
Risk & controlObjectives, risks, controls, assessments, owners and evidence.
Incident managementFacts, classification, decisions, reporting and lessons learned.
Suppliers & contractsServices, arrangements, clauses, assessments and dependencies.
ICT assetsOwnership, criticality, dependencies, reviews and service context.
Register of InformationConnected source records carried into the required register structure.
Register of Information
The register is a management record first and a regulatory submission second.
Article 28 requires financial entities to maintain and update a register of information for contractual arrangements involving ICT services provided by third parties. The European Banking Authority explains that the register supports the entity's own third-party risk management, supervisory work and the designation of critical ICT third-party providers.
The hard part is not filling cells. It is preserving the relationships between entities, functions, services, suppliers, contracts, data locations and identifiers as they change. A register assembled only at reporting time quickly becomes a reconciliation exercise.
See our Register of Information approach →Go deeper where the work becomes specific.
Our field notes focus on the places where teams usually need to make an interpretation, preserve a relationship or repair the quality of the underlying data.
5 field notes
Register of Information
How the DORA register fits together, from identifiers and relationships to submission-ready data.
- Referential integrity
- The value of the DORA register of information: a helicopter view
- How to report intra-group ICT service providers in your register of information
- One Contract, How Many Countries?
- LEI requirements in the DORA register of information: what you need to know
4 field notes
Business Functions
How services, dependencies and financial data connect to the functions the organisation must keep running.
- Business functions in DORA; The cornerstone of your ICT Risk management
- How to Map ICT Services to Business Functions: A Complete Yet Proportionate Approach
- illustrative example: business functions of a venture capital fund manager
- Financial data in the DORA register: what to report and how to collect it
5 field notes
Contracts & Suppliers
How to classify ICT arrangements and preserve the supplier and contract knowledge behind the register.
- ICT suppliers in DORA – which contracts must be recorded?
- How to classify contracts under DORA: standalone, overarching, or associated?
- Understanding RT.03: mapping ICT contractual relationships under DORA
- DORA Supply-Chain Reporting: When Granularity Creates Noise
- The Risk You Didn’t Sign
3 field notes
Technical Foundations
The data quality, identifiers and technical relationships that determine whether DORA records remain usable.
- Why DORA requires you to track every software library in your application stack
- Navigating F identifiers in schema 06.01: how to avoid mapping chaos
- When non-EU service providers lack a LEI: the identifier workaround
6 field notes
Ecosystem & Practice
Practical lessons on proportionality, supervisory expectations and maintaining DORA after the first submission.
- How the Dutch Association of Insurers supports DORA implementation
- DORA for Microenterprises: Why size matters for your compliance journey
- DORA Asset Management: What regulators expect
- Why Excel isn’t enough for DORA reporting: key lessons from the ESA dry run
- Who Reads the Register?
- Our journey with the DORA register: challenges, solutions, and collaboration
DORA and NIS2
Related EU resilience rules, with a sector-specific boundary for finance.
For financial entities covered by both regimes, DORA is treated as the sector-specific Union legal act for the NIS2 provisions on cybersecurity risk management, incident reporting, supervision and enforcement identified by Article 4.
That does not make NIS2 irrelevant. National cybersecurity strategies and crisis-management structures continue to matter, and a group may contain entities or activities that are not covered by DORA. The right question is which legal entity and activity falls under which rule, not whether the group is simply “a DORA organisation” or “a NIS2 organisation”.
Read the European NIS2 guide →Short answers to the questions that usually come first.
What is DORA?
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, sets common requirements for how in-scope EU financial entities manage ICT risk, incidents, resilience testing and ICT third-party risk.
When did DORA start to apply?
DORA has applied since 17 January 2025. It is now an operating obligation, not a future implementation deadline.
Who is responsible for DORA?
The management body retains responsibility for the ICT risk management framework. Delivery usually spans risk, information security, operations, procurement, legal, compliance and the business owners of critical or important functions.
What is the DORA Register of Information?
It is the structured register of contractual arrangements for ICT services provided by third parties. It supports the organisation's third-party risk management, supervisory work and the designation of critical ICT third-party providers.
Does DORA replace NIS2 for financial entities?
For financial entities covered by DORA, DORA is the sector-specific Union act for the NIS2 cybersecurity risk-management, reporting, supervision and enforcement provisions identified in Article 4. Other NIS2 provisions and national context can still matter, so scope should be checked for each legal entity and activity.
Use the law and supervisory material as the final authority.
This guide is an operating overview, not legal advice. Applicability and proportionality depend on the entity, activity and jurisdiction.
- Regulation (EU) 2022/2554The official DORA text on EUR-Lex.
- ESMA DORA overviewLevel 1 legislation and the adopted technical standards by topic.
- EBA Register of Information resourcesReporting preparation, FAQs, templates and supporting material.
- Implementing Regulation (EU) 2024/2956The standard templates for the Register of Information.
- Commission guidance on NIS2 Article 4The official explanation of the DORA and NIS2 sector-specific boundary.
Bring the part of DORA that is consuming your team's time.
A discovery call can start with a live responsibility, such as a register that depends on repeated spreadsheet reconciliation, supplier knowledge spread across teams, or incident evidence that is difficult to reconstruct.
Book a Discovery Call →