ICT business continuity management

ICT business continuity management

Revised structure and contents of policies and plans

DORA introduces a new, layered ICT BCM architecture.

a) New central element: ICT business continuity policy

  • Art. 11(1) DORA: “ICT business continuity policy” as integral part of the overall business continuity policy.
  • Based on identification of critical/important functions and ICT assets under Art. 8 DORA (asset & function mapping).
  • BAIT/VAIT do not use this term; they speak more generally of “IT (business) contingency/continuity plans”.

Content of the ICT BCM policy (Art. 11(2) DORA; Art. 24 RTS RMF):

  • Documented policy with:
    • Response to all ICT-related incidents (damage limitation, resumption, prioritisation of recovery actions).
    • Activation criteria and containment measures, processes, technologies.
    • Preliminary impact, damage and loss estimation (aligned with PSD2 incident practice).
    • Communication and crisis management actions.

b) ICT business continuity plans (vs. BAIT/VAIT BC plans)

  • DORA replaces generic “IT contingency plans” with ICT business continuity plans (Art. 11(4) DORA).
  • Must be kept up to date and are tightly linked to:
    • Business impact analysis (BIA)
    • ICT risk assessment (Art. 3(1)(b) DORA; Art. 24 RTS RMF)
  • Outsourcing / ICT third parties must be integrated from design, update and testing onwards, especially for critical/important functions (Art. 25(2) RTS RMF).

c) ICT response and recovery plans (new naming, similar purpose)

  • Where BAIT/VAIT speak about restart / emergency operation / recovery plans,
    DORA introduces ICT response and recovery plans (Art. 11(3) & Art. 26 RTS RMF).
  • They define:
    • Technical and organisational steps for incident response,
    • Recovery of ICT services,
    • Prioritisation of systems, data and functions.

d) BIA, RTO/RPO and market-wide perspective

  • DORA requires a BIA + risk analysis as part of the ICT BCM framework (Art. 11(5) DORA; Art. 24 RTS RMF).
  • When defining RTO/RPO for each function, entities must not only consider whether it is critical/important, but also the overall impact on market efficiency (a new DORA aspect).

Expansion of mandatory scenarios

DORA significantly broadens the mandatory scenario set for ICT response and recovery plans.

Art. 26(2) RTS RMF and cross-references to Art. 24(1)(b)(i)(1) and Art. 25(2)(e) RTS RMF require that the following (non-exhaustive) scenarios be covered at least:

  • Climate & environment / physical
    • Climate change and environmental degradation
    • Natural disasters
    • Pandemics
    • Physical attacks, including intrusions and terrorist attacks
  • Insider attacks
  • Political and social instability, including:
    • Instability in the jurisdiction of ICT third-party providers
    • Instability in the location where data are stored/processed
  • Widespread power outages

BAIT/VAIT knew “classic” disaster and outage scenarios but did not explicitly list climate, insider, political instability and cross-border data-location risks in this detail.


Regular review of ICT business continuity management

DORA makes ICT BCM review and testing much more formal, frequent and board-centred.

a) Governance – role of the management body

  • Approval & periodic oversight of:
    • ICT business continuity policy
    • ICT response and recovery plans
      (Art. 5(2)(e) DORA; Art. 11(6) DORA)
  • In BAIT/VAIT, this explicit board-level obligation did not exist in this form.

b) Testing obligations

  • DORA requires periodic testing, at least annually, of:
    • ICT business continuity plans
    • ICT response and recovery plans
    • Crisis communication plans (explicitly new)
  • Testing must be repeated:
    • At least once a year, and
    • Whenever significant changes affect ICT systems that support critical/important functions (Art. 11(6)(a) DORA).

By contrast:

  • BAIT: annual testing of IT contingency plans, but no explicit ICT BCM policy / plan structure with crisis-comms testing.
  • VAIT: “regular” testing, less concretely tied to annual minimum and significant changes.

c) Link to ICT risk management framework

  • As noted in section 2.2 of the guidance, the entire ICT risk management framework, which includes ICT BCM, must be reviewed at least annually or on an event-driven basis (e.g. after major incidents or testing conclusions).

Strengthening of crisis management and communication

DORA embeds crisis management and communication deeply into ICT BCM.

a) Crisis management function

  • Art. 11(7) DORA: financial entities must establish a crisis management function.
  • Once ICT business continuity or ICT response & recovery plans are activated, this function:
    • Coordinates internal and external crisis communication,
    • Aligns with Art. 14 DORA (communication strategies for ICT incidents).

b) Communication strategies, policies and plans

  • ICT BCM must include communication and crisis-management actions to notify:
    • External stakeholders (customers, authorities, partners), and
    • Internal staff involved in response & recovery.
  • Art. 14 DORA and Art. 24(1)(a)(iv), (b)(vi) RTS RMF require:
    • Communication strategies and policies for ICT-related incidents,
    • Differentiation of target groups (staff, customers, media, public, supervisors),
    • Designation of at least one person responsible for public/media communication (from Section 2.3, Art. 14(3) DORA).

This goes beyond BAIT/VAIT, which do not prescribe a dedicated crisis management function or such detailed, structured crisis communication framework for ICT incidents.

Source: BaFin, Supervisory statement: Guidance notes on the implementation of DORA for ICT risk management and ICT third-party risk management

https://www.bafin.de/SharedDocs/Downloads/EN/Anlage/dl_2024_07_08_Aufsichtsmitteilung_Umsetzungshinweise_DORA_en.html