The right tool for group-level operational resilience is one that holds a single, consolidated view of critical services, ICT assets, third-party providers and continuity plans across every entity, while still producing entity-level outputs. Under DORA (Regulation (EU) 2022/2554), applicable since 17 January 2025 (Article 64), this means supporting the register of information at entity, sub-consolidated and consolidated level, incident classification and reporting, and tested ICT business continuity plans. Compare tools against these regulatory outputs rather than against feature lists.
Disclosure: this guide is published by ResiPlan, which sells a continuity and resilience platform for groups. The criteria below come from the regulatory texts, not from our product, and we do not rank tools: neither DORA nor NIS2 requires or certifies any particular software.
Key takeaways
- DORA sets outcomes, not technology: a documented ICT risk management framework, an ICT business continuity policy and tested plans, incident classification and reporting, a testing programme and a register of information.
- The register of information is the obligation that is explicitly multi-level: DORA Article 28(3) requires it at entity level, and at sub-consolidated and consolidated levels.
- Most other DORA obligations apply entity by entity: a group tool must consolidate without taking away each entity's own records.
- Non-financial or mixed groups also face NIS2 (Directive (EU) 2022/2555), applied through national law, entity by entity.
This article is about tooling for groups. For the obligations of DORA itself, pillar by pillar, read our complete DORA guide for 2026.
What does 'group-level' operational resilience actually require?
A group is a parent undertaking and its subsidiaries, often across several countries, with shared services (IT, procurement, a shared data centre) and ICT providers used by several entities at once. Regulators supervise each regulated entity, but disruption does not stop at legal boundaries: a failure at one shared provider can hit every subsidiary on the same day.
Two kinds of obligations follow:
- Obligations that apply to each entity. Under DORA, each financial entity has its own ICT risk management framework (Article 6), its own ICT business continuity policy and plans (Article 11), its own incident classification and reporting (Articles 18 and 19) and its own testing programme (Articles 24 and 25). Its management body remains responsible for ICT risk (Article 5).
- Obligations that consolidate. DORA Article 28(3) requires financial entities to "maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information" on all contractual arrangements for ICT services provided by ICT third-party service providers. The templates for each level are set by Implementing Regulation (EU) 2024/2956.
Groups outside the financial sector, or mixed groups with both financial and non-financial entities, also need to look at NIS2. Each essential or important entity must take the risk-management measures of Article 21, including business continuity, backup management, disaster recovery and crisis management (Article 21(2)(c)) and supply chain security (Article 21(2)(d)), and must notify significant incidents under Article 23. For financial entities, DORA applies as the sector-specific act (NIS2 Article 4). See DORA vs NIS2 and NIS2 for groups in the Netherlands and Belgium.
Which regulatory outputs must a group resilience tool produce?
| Output | Legal basis | Produced by entity, consolidated or both |
|---|---|---|
| ICT risk management framework, documented and reviewed at least once a year | DORA Art. 6, detailed by Delegated Regulation (EU) 2024/1774 | Each entity; a group can share policies and methods |
| ICT business continuity policy, ICT response and recovery plans, tested at least yearly | DORA Art. 11 (testing: Art. 11(6)); Delegated Regulation (EU) 2024/1774 | Each entity |
| Classification of ICT incidents and reports on major incidents | DORA Art. 18 and 19 | Each entity |
| Digital operational resilience testing programme | DORA Art. 24 and 25 (TLPT for identified entities: Art. 26) | Each entity |
| Register of information on ICT third-party arrangements | DORA Art. 28(3); templates of Implementing Regulation (EU) 2024/2956 | Both: entity, sub-consolidated and consolidated |
| NIS2 risk-management measures, including business continuity | NIS2 Art. 21, under national law | Each entity in scope |
| NIS2 significant incident notifications | NIS2 Art. 23 | Each entity in scope |
The register of information is where group tooling matters most. Our practical guide to the register of information and the register of information template go through the templates field by field.
How should you compare tools for a multi-entity group?
Use a neutral grid tied to the texts, and apply it to every candidate, including the tool you already have.
| Tool criterion | Why it matters at group level | Regulatory basis |
|---|---|---|
| Multi-level register of information | The register must exist for each entity and at sub-consolidated and consolidated levels | DORA Art. 28(3); Implementing Regulation (EU) 2024/2956 |
| Single reference list of ICT third-party providers | One provider often serves several subsidiaries; one record avoids duplicates and inconsistent data | DORA Art. 28; Implementing Regulation (EU) 2024/2956 |
| ICT continuity and recovery plans per entity, with a consolidated view | An ICT business continuity policy and ICT response and recovery plans are required | DORA Art. 11; Delegated Regulation (EU) 2024/1774 |
| Incident classification and reporting | Common classification criteria and short reporting deadlines | DORA Art. 18 and 19 |
| Test planning and follow-up | A digital operational resilience testing programme is required | DORA Art. 24 and 25 |
| Access rights per entity and audit trail | Shows governance and the responsibility of each management body | DORA Art. 5 |
| NIS2 coverage for non-financial entities | Mixed groups fall under more than one regime | NIS2 Art. 21 and 23 |
In a demo or trial, test these on your own data rather than on slides:
- Model your real group structure: entities, countries, shared services.
- Load one real critical or important function and its ICT dependencies.
- Record a provider used by two subsidiaries and check that it exists once, with both relationships.
- Simulate a disruption at that provider and check what each entity, and the head office, sees.
- Export the register of information for one entity and for the group, and check the output against the templates of Implementing Regulation (EU) 2024/2956.
- Check who can see and change what in each entity, and what the audit trail records.
Spreadsheets, GRC suites or dedicated continuity platforms?
DORA does not prescribe a tool. It requires results: a register, plans, tests, notifications, and evidence that the management body oversees them. Any of the three usual approaches can be compliant; they differ in how much effort it takes to stay compliant across a group.
| Approach | Consolidation effort | Traceability | Keeping it up to date |
|---|---|---|---|
| Spreadsheets | High: each entity's file has to be merged and reconciled by hand | Limited: versions and changes are hard to prove | Depends on discipline; shared providers drift between files |
| GRC suites | Depends on configuration; often built for broad risk and control scope | Usually strong (workflows, logs) | Good once configured; continuity content may need custom modelling |
| Dedicated continuity and resilience platforms | Built around entities, functions, dependencies and plans | Usually strong for plans, tests and incidents | Good for continuity data; check how they connect to your wider risk tooling |
Many groups combine approaches, for example a GRC suite for enterprise risk and controls and a continuity platform for business impact analysis, plans, exercises and crisis management. For a market overview, see our business continuity software comparison and our exercise software comparison.
How does resiplan.eu handle group-level continuity?
The ResiPlan business continuity platform has a group profile in which the head office sets the method and consolidates, while each entity keeps its own workspace, data and users:
- Consolidated dashboard: BIA coverage, plans, exercises and open actions, one line per entity, with Excel and PDF export.
- Group BIA methodology and campaigns: the head office defines one impact grid, locked or adaptable per entity, and launches BIA campaigns across several entities with follow-up and reminders.
- Shared suppliers: when several entities depend on the same critical supplier, the group sees which entities and processes rest on it.
- Group DORA register of information: each entity keeps its register (entered, derived or imported) and the head office consolidates them for filing with the competent authority.
- DORA incidents: classification under Delegated Regulation (EU) 2024/1772 and the reporting deadlines of Delegated Regulation (EU) 2025/301.
- Plans and exercises: continuity plans per entity and eight exercise types, from tabletop to full-scale.
- Access: data isolated per entity under its own rights, Microsoft Entra ID single sign-on and SCIM provisioning, unlimited users.
Business data is hosted in the EU. The group licence is quoted according to the number of entities and the onboarding scope: see ResiPlan for groups and subsidiaries, the pricing page, or book a demo based on your own group structure.
What should a group put in place first?
- Inventory critical or important functions, entity by entity, using one impact scale approved at group level.
- Identify the ICT third-party providers shared by several entities, and the functions that depend on them.
- Build the register of information for each entity, then at sub-consolidated and consolidated levels: our register of information guide explains how.
- Write or update the ICT business continuity policy and the response and recovery plans of each entity.
- Test: plan the yearly tests of continuity and recovery plans and the wider testing programme, and track what the tests reveal until it is fixed.
For the regulatory calendar, see our complete DORA guide for 2026 and our DORA timeline; to check where you stand, use the DORA readiness checklist.
Frequently asked questions
Does DORA require a specific software tool for operational resilience?
No. DORA (Regulation (EU) 2022/2554) sets obligations and outcomes: an ICT risk management framework, ICT continuity policy and plans, incident classification and reporting, a testing programme and a register of information. It does not require or certify any tool, and the financial entity and its management body remain responsible for compliance whatever tool they use.
Who maintains the DORA register of information in a group: each entity or the parent company?
Both levels exist. DORA Article 28(3) requires financial entities to maintain and update the register at entity level, and at sub-consolidated and consolidated levels. Implementing Regulation (EU) 2024/2956 sets the templates; check it and your competent authority's reporting instructions to confirm which group entity submits the consolidated register.
Can one tool cover both DORA and NIS2 obligations across a group?
It can, provided it keeps each entity's records separate and maps them to the obligations that apply to that entity: DORA for financial entities, NIS2 under national law for essential and important entities. The two regimes overlap on continuity, incidents and third parties, but their incident deadlines and authorities differ (DORA Article 19; NIS2 Article 23).
Are spreadsheets acceptable for a group-level register of information?
DORA does not ban spreadsheets. The register must follow the templates of Implementing Regulation (EU) 2024/2956 and exist at entity, sub-consolidated and consolidated levels. With spreadsheets, consolidating several entities, keeping shared providers consistent and proving who changed what is manual work and prone to errors.
What is the difference between a GRC suite and a business continuity platform?
A GRC (governance, risk and compliance) suite covers a broad scope of risks, controls, audits and policies. A business continuity platform focuses on what keeps critical functions running: business impact analysis, dependencies, continuity and recovery plans, exercises and crisis management. Under DORA, both can contribute evidence; what counts is that the required outputs exist for each entity and for the group.
Sources
- Regulation (EU) 2022/2554 (DORA), Articles 5, 6, 11, 18, 19, 24 to 26, 28 and 64, EUR-Lex
- Commission Delegated Regulation (EU) 2024/1774 (RTS on the ICT risk management framework), EUR-Lex
- Commission Delegated Regulation (EU) 2024/1772 (RTS on the classification of ICT-related incidents), EUR-Lex
- Commission Delegated Regulation (EU) 2025/301 (RTS on the content and time limits of incident reports), EUR-Lex
- Commission Implementing Regulation (EU) 2024/2956 (ITS on the register of information), EUR-Lex
- Directive (EU) 2022/2555 (NIS2), Articles 4, 21 and 23, EUR-Lex
- European Supervisory Authorities: EBA, DORA register of information reporting
- ISO 22301:2019, Business continuity management systems (cited by number; the text of the standard is not reproduced)
- ResiPlan: product and group licence as of 9 November 2026