Last updated: 2026-11-06
This page applies to both frameworks: to financial entities under the full framework of Articles 5 to 15 DORA and to entities under the simplified framework of Article 16, including, from 1 January 2027, the institutions under Section 1a(2a) of the German Banking Act (KWG) (here: KWG group) such as factoring and leasing firms. Which framework applies to you is covered on our page DORA applicability. This page covers the structure, backup and testing of business continuity, that is ICT contingency management or business continuity management (BCM) under DORA.
What does Article 11 DORA require?
An ICT business continuity policy that the management body approves, oversees and periodically reviews (Article 5(2)(e)), and plans based on it. The policy may be a dedicated policy or an integral part of the overall business continuity policy (Article 11(1)). The paragraphs at a glance:
| Article 11 | Obligation | Microenterprises | RTS (EU) 2024/1774 |
|---|---|---|---|
| (1) | ICT business continuity policy based on the identification under Article 8 | applies | Article 24 (content of the policy) |
| (2) | arrangements, plans and procedures: continuity of critical or important functions, quick response, containment, estimate of damage, communication and reporting | applies | Article 24(1)(b) |
| (3) | ICT response and recovery plans with independent internal audit review | plans yes, audit review no | Article 26 |
| (4) | implement, maintain and test business continuity plans, especially for outsourced critical or important functions | applies | Article 26(4) |
| (5) | business impact analysis (BIA) as part of the overall business continuity policy | applies | Article 24(1)(a)(i), Article 25(1), Article 26(1) |
| (6) | tests at least yearly and after substantive changes, testing of crisis communication plans, review with test results and audit recommendations | tests yes, without the obligation for cyber-attack and switchover scenarios | Article 25 |
| (7) | crisis management function | not required | - |
| (8) | records of activities before and during disruption events readily accessible | applies | - |
| (10) | report estimated annual costs and losses of major incidents on request | not required | - |
Paragraph 9 concerns only central securities depositories, paragraph 11 the guidelines of the European Supervisory Authorities on paragraph 10.
BIA and recovery objectives: where the plan comes from
From the business impact analysis (Article 11(5)) and the recovery time and recovery point objectives derived from it for each function (Article 12(6)). What both contain is shown with example values on our page ICT risk management. What matters for the plan: the policy states that critical or important functions must be running again within these objectives after a disruption (RTS Article 24(1)(b)(ii)). Which functions they are is set by your list of functions.
The BIA is also mandatory under the simplified framework: the management body approves it (RTS Article 28(2)(d)(i)), and the ICT business continuity plan sets planned recovery levels and timeframes (RTS Article 39(2)(d)).
Backup under Article 12: what a DORA backup must achieve
It must be able to restore systems and data with minimum downtime. Article 12 under the full framework:
| Article 12 | Obligation |
|---|---|
| (1) | backup policies and procedures with scope and minimum frequency based on the criticality of information or the confidentiality level of the data, plus documented restoration and recovery procedures |
| (2) | backup systems whose activation does not jeopardise security, availability, authenticity, integrity or confidentiality, with periodic testing of backup and restoration |
| (3) | restoration with own systems on ICT systems that are physically and logically segregated from the source system and protected from unauthorised access |
| (4) | redundant ICT capacities, for microenterprises see FAQ |
| (6) | recovery time and recovery point objectives per function, taking into account critical or important functions and market efficiency |
| (7) | checks and reconciliations during recovery so that data is consistent across systems |
Under the simplified framework, according to BaFin’s supervisory notice of 21 August 2025 (section 4.4), Article 12 does not apply, and a backup concept is no longer an explicit requirement. Backup itself remains mandatory: the plan sets scope and minimum frequency based on the criticality of the functions using the data (RTS Article 39(2)(g)), plus restoration and recovery measures (point (f)), tested at least yearly (RTS Article 40(1)). We recommend a segregated backup protected against access there too, because after a ransomware attack only a backup the attacker has not reached will help.
Which scenarios must plans and tests cover?
Under the full framework, a whole list. Under RTS Article 26(2), the ICT response and recovery plans take into account, among others, cyber-attacks, the failure or insolvency of a key ICT third-party service provider, the loss of premises or data centres, lack of staff, natural disasters, insider attacks and large-scale power outages. Testing uses severe but plausible scenarios that challenge the assumptions of the plans and show whether staff, service providers and systems respond adequately (RTS Article 25(2)). Entities other than microenterprises test cyber-attacks and switchovers to redundant capacity (Article 11(6)). Results are documented, and weaknesses are analysed, addressed and reported to the management body (RTS Article 25(5)).
Under the simplified framework, the RTS expressly names only the cyber-attack alongside severe business disruptions (RTS Article 39(1)). Testing takes place at least yearly for backup and restore or upon every major change of the plan (RTS Article 40(1)), and deficiencies go to the management body (paragraph 3). These tests are part of business continuity. The testing programme for ICT systems under Articles 24 and 25 is described on our page DORA resilience testing.
What is different under the Article 16 framework
The simplified framework has no separate ICT business continuity policy, no ICT response and recovery plans under Article 11(3), no test concept for IT contingency plans as in BAIT and VAIT (BaFin’s supervisory requirements for IT in banks and insurers), no crisis management function and no cost reporting under Article 11(10) as explicit requirements (supervisory notice of 21 August 2025, sections 5 to 5.3). Their content is brought together in an ICT business continuity plan under RTS Article 39, approved by the management body, with escalation plans for communication (point (i)). How this plan fits into the evidence for the whole framework is shown by the evidence matrix on our page DORA Article 16: the simplified framework.
MaRisk AT 7.3 and MaGo: one contingency management or two?
Sectoral requirements on contingency management continue to apply alongside DORA. For institutions under MaRisk (BaFin’s Minimum Requirements for Risk Management), AT 7.3 requires an emergency concept for critical or important functions. How it fits with DORA business continuity is shown on our page MaRisk and DORA. For insurers under Solvency II, chapter 14 of MaGo (BaFin’s minimum requirements for the system of governance of insurers) applies, see DORA for insurers.
Work product: outline of an ICT business continuity plan
Blackfort Technology’s own outline, not an official template. It assigns the references of both frameworks to each chapter. Entities under the full framework use it for policy and plans together, Article 16 entities for the single plan under RTS Article 39.
| Chapter | Content | Full framework | Article 16 framework |
|---|---|---|---|
| 1 Purpose and scope | objectives, scope with exclusions, period covered, link to general contingency planning | Article 11(1), RTS Article 24(1)(a)(i) to (iii) | RTS Article 39(1) |
| 2 Organisation | roles, deputies, escalation paths, resources, approval by the management body | Article 5(2)(e), RTS Article 24(1)(b)(i) | RTS Article 39(2)(a), (c) |
| 3 Functions and BIA | critical or important functions, impact over time, dependencies on processes, assets and service providers | Article 11(5) | RTS Article 28(2)(d)(i), Article 39(1) |
| 4 Recovery objectives | recovery time and recovery point per function, system objectives derived from them | Article 12(6), RTS Article 24(1)(b)(ii) | RTS Article 39(2)(d) |
| 5 Scenarios | scenario catalogue with reasons why a scenario is relevant or not | RTS Article 26(2) | RTS Article 39(1) (at least cyber-attack) |
| 6 Activation | trigger criteria, who decides, deactivation and return to normal operations | RTS Article 24(1)(a)(iv), Article 26(1)(a) | RTS Article 39(2)(e) |
| 7 Measures per function | immediate measures, emergency operation, recovery, partial recovery, alternatives | Article 11(2) and (3), RTS Article 26(1)(b) and (e), Article 26(3) | RTS Article 39(2)(f), (h) |
| 8 Backup | scope, minimum frequency, segregated restoration, integrity checks | Article 12(1) to (3) and (7) | RTS Article 39(2)(g) |
| 9 Service providers | dependencies, contacts, failure of a provider, contractual commitments | Article 11(4), RTS Article 26(4) | RTS Article 39(2)(d), (f) with final sentence |
| 10 Communication | internal and external communication, escalation, crisis team, reporting to BaFin | Article 11(2)(e) and (7), Article 14, RTS Article 24(1)(b)(vi) | RTS Article 39(2)(i) |
| 11 Records | log of decisions and activities during a disruption | Article 11(8) | no explicit requirement, recommended |
| 12 Tests | test plan, scenarios, records, deficiency report to the management body | Article 11(6), RTS Article 25 | RTS Article 40 |
| 13 Maintenance | updates after incidents, tests, new threats and major changes, audit | Article 11(3) and (6) | RTS Article 39(2)(j) |
Under both frameworks the plan must be documented and readily accessible in an emergency (RTS Article 26(1)(d) and Article 39(2)(b) respectively), including when the network and file storage are down.
Example: test record of a switchover exercise
Fictitious example, not a client. Muster-Kreditbank AG is the CRR credit institution from the example on our page ICT risk management. A data centre service provider runs its core banking system including payments at two sites. The recovery objectives for payments come from the BIA shown there.
| Exercise | Switchover of payments to the data centre’s secondary site, with crisis communication |
|---|---|
| Date, duration | 21 April 2026, 08:00-13:00, switchback on 22 April 2026, 06:00-07:30 |
| Basis | business continuity plan chapters 6, 7 and 10, Article 11(6), RTS Article 25 |
| Scenario | A cyber-attack takes down the systems at the data centre’s primary site. Payments are switched over to the redundant capacity at the secondary site. Assumption to verify: the secondary site is fully connected without any action by the bank. |
| Objectives under the plan | payments usable again after 4 hours at most, data loss of 15 minutes at most, customer information within 60 minutes of the decision to switch over |
| Sequence | 08:00 scenario triggered by the exercise lead 08:10 crisis team convenes 08:50 management board decides on the switchover 10:00 customer information on the website, 70 minutes after the decision 10:40 secondary site reports ready for operation 10:55 reconciliation of booking balances completed 11:20 payments released to the business unit |
| Result | Payments usable after 3 hours 20 minutes, last data state 12 minutes before the start of the scenario: objectives met. Outgoing payment files backed up for 25 minutes until the connection to the clearing service provider at the secondary site was enabled. Customer information 10 minutes late. Switchback the next day without findings. |
| Deficiencies | 1. Connection to the clearing service provider at the secondary site not enabled in advance, the plan’s assumption did not hold. 2. The person designated for the public and the media could not be reached, and the plan named no deputy. 3. The reconciliation under Article 12(7) checked only account balances, not the totals of the payment files. |
| Measures | On 1: set up the connection permanently and include it in the contract with the data centre as a test item, head of IT, by 30 June 2026. On 2: name a deputy and add them to the plan, management board, by 15 May 2026. On 3: add reconciliation of file totals to the recovery checklist, head of payments, by 31 May 2026. |
| Report to the management board | 28 April 2026, deficiencies and measures noted (RTS Article 25(5)), follow-up in the quarterly report on contingency management |
An institution under the Article 16 framework can use the same record. The RTS does not expressly require a switchover exercise there. What is mandatory is the yearly test of backup and restore (RTS Article 40(1)).
Three typical gaps
| Gap | Cause | Effect | Remedy |
|---|---|---|---|
| Restore tested only file by file | The restoration test recovers individual files, never a whole system with application and database. | Whether a function is back within its recovery time remains unproven. The test does not show what Article 12(2) and RTS Article 40(2) require. | At least once a year, a full restoration with time measurement and data reconciliation for each critical or important function. |
| Backup in the same administrative domain | Backup servers and storage are attached to the same directory service and the same administrator accounts as production. | An attacker who takes over production also encrypts or deletes the backups. The segregation under Article 12(3) is missing. | Physically and logically segregated backup, separate access, immutable copies, practise restoration on segregated systems. |
| Recovery objectives stricter than the provider’s commitments | The BIA sets 4 hours, the contract with the data centre commits to 24 hours. | The plan cannot be met in an emergency, and nobody notices. The dependency under RTS Article 39(2)(d) or Article 11(4) is not secured. | Compare the BIA objectives with the contractual values, renegotiate the gap or plan fallback procedures, and include the provider in the tests. |
How we help
Institutions of the KWG group moving from BAIT on 1 January 2027 build their ICT business continuity plan under RTS Article 39 in the transition from BAIT to Article 16, including an exercise. Other institutions under the simplified framework, such as small investment firms, small IORPs or insurance holding companies, start with the Article 16 gap analysis. For entities under the full framework, the DORA gap analysis shows where policy, plans, backup and testing stand against Articles 11 and 12.
Frequently asked questions
Does DORA set fixed recovery times?+
Do microenterprises need redundant ICT capacities?+
Does our IT service provider have to take part in the contingency tests?+
What has to be recorded during a disruption?+
Read more
- ICT risk management under DORA: framework and DOR strategy
- DORA Article 16: the simplified ICT risk management framework
- DORA resilience testing: testing programme, pentests and TLPT
- Classifying critical or important functions under DORA
- MaRisk 9th amendment and DORA: interfaces from AT 2.2 to AT 9
- VAIT and DORA for insurers: mapping, MaGo and transition plan
Sources
- Regulation (EU) 2022/2554 (DORA), Articles 5, 11, 12, 14, 16, 30, German version (retrieved 2026-11-06)
- Delegated Regulation (EU) 2024/1774 (RTS on ICT risk management), Articles 24 to 26, 28, 39, 40, German version (retrieved 2026-11-06)
- BaFin: supervisory notice of 21 August 2025 on implementing DORA with the simplified ICT risk management framework, sections 4.4 and 5 to 5.3, in German (retrieved 2026-11-06)
This content provides general technical and organisational information and does not constitute legal advice (no legal services within the meaning of the German RDG).