Content library
DORA simplified RMF
Article 39: Components of the ICT business continuity plan

Requirement description

1. The financial entities referred to in Article 16(1) of Regulation (EU) 2022/2554 shall develop their ICT business continuity plans considering the results of the analysis of their exposures to and potential impact of severe business disruptions and scenarios to which their ICT assets supporting critical or important functions might be exposed, including a cyber-attack scenario.

2. The ICT business continuity plans referred to in paragraph 1 shall:

(a) be approved by the management body of the financial entity;

(b) be documented and readily accessible in the event of an emergency or crisis;

(c) allocate sufficient resources for their execution;

(d) establish planned recovery levels and timeframes for the recovery and resumption of functions and key internal and external dependencies, including ICT third-party service providers;

(e) identify the conditions that may prompt the activation of the ICT business continuity plans and what actions are to be taken to ensure the availability, continuity, and recovery of the financial entities’ ICT assets supporting critical or important functions;

(f) identify the restoration and recovery measures for critical or important business functions, supporting processes, information assets, and their interdependencies to avoid adverse effects on the functioning of the financial entities;

(g) identify backup procedures and measures that specify the scope of the data that are subject to the backup, and the minimum frequency of the backup, based on the criticality of the function using those data;

(h) consider alternative options where recovery may not be feasible in the short term because of costs, risks, logistics, or unforeseen circumstances;

(i) specify the internal and external communication arrangements, including escalation plans;

(j) be updated in line with lessons learned from incidents, tests, new risks, and threats identified, changed recovery objectives, major changes to the financial entity’s organisation, and to the ICT assets supporting critical or business functions.

For the purposes of point (f), the measures referred to in that point shall provide for the mitigation of failures of critical third-party providers.

How to fill the requirement

DORA simplified RMF

Article 39: Components of the ICT business continuity plan

Task name
Priority
Status
Theme
Policy
Other requirements
Creating and documenting continuity plans
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Risk management and leadership
Continuity management
40
requirements

Examples of other requirements this task affects

Članak 30.1.c: Kontinuitet poslovanja
NIS2 Croatia
2.7: Varautuminen häiriötilanteisiin
TiHL tietoturvavaatimukset
9.10 §: Varmuuskopiointi ja jatkuvuuden hallinta
Kyberturvallisuuslaki
5.2.8: IT service continuity planning
TISAX
1.6.3: Crisis preparedness
TISAX
See all related requirements and other information from tasks own page.
Go to >
Creating and documenting continuity plans
1. Task description

Sometimes an unexpected event, such as a fire, flood, or equipment failure, can cause downtime. In order to be able to continue operations as quickly and smoothly as possible, continuity planning is carried out, i.e. planning the operations in advance for these exceptional situations.

Each continuity plan shall contain at least the following information:

  • Event for which the plan has been made
  • Goal for recovery time
  • Responsible persons and related stakeholders and contact information
  • Planned immediate actions
  • Planned recovery steps
Developing and executing a recovery plan
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Incident management
Incident management and response
2
requirements

Examples of other requirements this task affects

4.3.4: Launch recovery plan during or after the incident
NSM ICT-SP
Article 39: Components of the ICT business continuity plan
DORA simplified RMF
See all related requirements and other information from tasks own page.
Go to >
Developing and executing a recovery plan
1. Task description

The organization should have a defined and well-documented recovery plan. The recovery plan should be able to be initiated during or after an incident. Recovery actions and measures will vary from incident to incident, for example, the type of incident can affect the actions taken. These actions could include:

  • Reactivating redundant resources lost or damaged during the incident
  • Reinstalling hardware and software on affected components
  • Restoring configuration settings, including any necessary adjustments
  • Restoring services halted during the incident

The organization should adopt a 'build back better' mindset when rebuilding ICT systems. This means that systems should be rebuilt to a better state than they were before the incident.

Regular testing and review of continuity plans
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Risk management and leadership
Continuity management
37
requirements

Examples of other requirements this task affects

Članak 30.1.c: Kontinuitet poslovanja
NIS2 Croatia
9.10 §: Varmuuskopiointi ja jatkuvuuden hallinta
Kyberturvallisuuslaki
5.2.8: IT service continuity planning
TISAX
30 § 3.3°: La continuité et la gestion des crises
NIS2 Belgium
4.1.6: Test and rehearse the plans regularly so that they are established
NSM ICT-SP
See all related requirements and other information from tasks own page.
Go to >
Regular testing and review of continuity plans
1. Task description

The organization should regularly, at least annually, test and review its information security continuity plans to ensure that they are valid and effective in adverse situations.

Testing of continuity plans shall involve, as appropriate, stakeholders critical to each plan. The organisation should identify and document the necessary contacts with suppliers and partners.

In addition, the adequacy of continuity plans and associated management mechanisms should be reassessed in the event of significant changes in operations.

Continuity of critical tasks in exceptional situations
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Risk management and leadership
Continuity management
5
requirements

Examples of other requirements this task affects

VAR-05: Henkilöstön saatavuus ja varajärjestelyt
Julkri
Article 11: Response and recovery
DORA
2.7: Varautuminen häiriötilanteisiin
TiHL tietoturvavaatimukset
1.6.3: Crisis preparedness
TISAX
Article 39: Components of the ICT business continuity plan
DORA simplified RMF
See all related requirements and other information from tasks own page.
Go to >
Continuity of critical tasks in exceptional situations
1. Task description

The organization has identified the tasks that are critical for the continuity of its operations. Alternative courses of action for specific exceptional situations and staff availability and contingency arrangements have been planned and prepared for the continuation of critical tasks.

To implement the continuation plans, the plan owners, their alternates and other persons required to implement the plan have been identified. In addition, their ability to carry out their tasks under normal circumstances has been ensured.

Identifying critical IT partners
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Partner management
Supplier security
3
requirements

Examples of other requirements this task affects

THIRD-PARTIES-1: Identify and Prioritize Third Parties
C2M2
1.2.4: Definition of responsibilities with service providers
TISAX
Article 39: Components of the ICT business continuity plan
DORA simplified RMF
See all related requirements and other information from tasks own page.
Go to >
Identifying critical IT partners
1. Task description

The organization must identify critical IT partners. A critical partner (internal or external) refers to a partner without whom the operation is interrupted.

Ensuring coverage of critical scenarios and aspects in continuity plans
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Risk management and leadership
Continuity management
2
requirements

Examples of other requirements this task affects

5.2.8: IT service continuity planning
TISAX
Article 39: Components of the ICT business continuity plan
DORA simplified RMF
See all related requirements and other information from tasks own page.
Go to >
Ensuring coverage of critical scenarios and aspects in continuity plans
1. Task description

The organisation should include the following topics into their continuity planning:

  • Plans for (D)DoS attacks
  • Plans for succesful ransomware attacks and other sabotage
  • System failures
  • Natural disasters

Continuity planning should take into account alternate communication options for situations primary communication means aren't operational. There should also be alternative options for storage, power and network strategies.

Defining a backup strategy
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Technical cyber security
Backups
15
requirements

Examples of other requirements this task affects

12.3.1: Information backup
ISO 27001
12.3: Backup
ISO 27001
TEK-20: Varmuuskopiointi
Julkri
8.13: Information backup
ISO 27001
A1.2: Recovery of infrastructure according to objectives
SOC 2
See all related requirements and other information from tasks own page.
Go to >
Defining a backup strategy
1. Task description

With adequate backups, all important data and programs can be restored after a disaster or media failure. To determine your backup strategy, it is important to map / decide on at least the following:

  • What systems are on our responsibility to back up?
  • How critical is each data asset and how often, based on this, they need to be backed up and to what extent (partial or complete copy)?
  • Where are backups stored and how are they protected?
  • How long will backups need to be retained?
  • What system is used for doing the back up?
  • How backup media is destroyed reliably
Defining the organization's continuity strategy
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Risk management and leadership
Continuity management
8
requirements

Examples of other requirements this task affects

VAR-03: Jatkuvuussuunnitelmat
Julkri
24: Jatkuvuudenhallinnan kuvaus
Digiturvan kokonaiskuvapalvelu
Article 11: Response and recovery
DORA
5.2.8: IT service continuity planning
TISAX
28.(1): Kiberriska pārvaldības un nepārtrauktības plāni
NIS2 Latvia
See all related requirements and other information from tasks own page.
Go to >
Defining the organization's continuity strategy
1. Task description

The organization must maintain a top-level strategy for continuity planning. The strategy should include at least:

  • Guidelines for defining continuity planning recovery time objectives and the adverse events requiring continuity plans
  • Management commitment to continuity planning and improvement
  • Description of the organization's risk appetite

In order to develop a strategy, it may be necessary to make use of general good practices, such as ISO 22300.

Communication to stakeholders on continuity plans
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Risk management and leadership
Continuity management
18
requirements

Examples of other requirements this task affects

Članak 30.1.c: Kontinuitet poslovanja
NIS2 Croatia
9.10 §: Varmuuskopiointi ja jatkuvuuden hallinta
Kyberturvallisuuslaki
30 § 3.3°: La continuité et la gestion des crises
NIS2 Belgium
RC.CO-2: Reputation is repaired after an incident.
CyberFundamentals
14.5.4): Veiklos tęstinumą
NIS2 Lithuania
See all related requirements and other information from tasks own page.
Go to >
Communication to stakeholders on continuity plans
1. Task description

The organization shall have procedures in place to communicate effectively with stakeholders and other participants during continuity plans and survival procedures.

Communication plans related to continuity plans shall include:

  • Responsible persons, related stakeholders and other necessary contact information
  • Clear criteria for the situation where continuity communication will be implemented
  • A clear description of the staff implementing the continuity communication in each situation and the recipients to whom the communication will be sent
  • References to the templates and tools to be used
Communicating recovery measures to stakeholders
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Risk management and leadership
Continuity management
6
requirements

Examples of other requirements this task affects

RC.CO-3: Recovery actions
NIST
Article 14: Communication
DORA
RC.CO-3: Recovery activities are communicated to internal and external stakeholders as well as executive and management teams
CyberFundamentals
4.2.3: Inform relevant stakeholders
NSM ICT-SP
RC.CO-03: Recovery activities and progress communication to stakeholders
NIST 2.0
See all related requirements and other information from tasks own page.
Go to >
Communicating recovery measures to stakeholders
1. Task description

Organizational recovery measures must be communicated as planned to critical individuals and management within the organization. Recovery measures must also be communicated to external stakeholders.

Continuous improvement of continuation plans
Critical
High
Normal
Low
Fully done
Mostly done
Partly done
Not done
Risk management and leadership
Continuity management
10
requirements

Examples of other requirements this task affects

CC7.5: Recovery from security incidents
SOC 2
Article 11: Response and recovery
DORA
RS.IM-2: Response and Recovery strategies are updated.
CyberFundamentals
RS.IM-1: Response plans incorporate lessons learned.
CyberFundamentals
RC.IM-1: Recovery plans incorporate lessons learned.
CyberFundamentals
See all related requirements and other information from tasks own page.
Go to >
Continuous improvement of continuation plans
1. Task description

The organization regularly develops its continuity plans by analyzing the testing of the plans, training and their actual use in real situations.

Tasks included in the policy

Task name
Priority
Status
Theme
Policy
Other requirements
No items found.

Never duplicate effort. Do it once - improve compliance across frameworks.

Reach multi-framework compliance in the simplest possible way
Security frameworks tend to share the same core requirements - like risk management, backup, malware, personnel awareness or access management.
Cyberday maps all frameworks’ requirements into shared tasks - one single plan that improves all frameworks’ compliance.
Do it once - we automatically apply it to all current and future frameworks.
Get to know Cyberday
Start your free trial
Cyberday is your all-in-one solution for building a secure and compliant organization. Whether you're setting up a cyber security plan, evaluating policies, implementing tasks, or generating automated reports, Cyberday simplifies the entire process.
With AI-driven insights and a user-friendly interface, it's easier than ever to stay ahead of compliance requirements and focus on continuous improvement.
Clear framework compliance plans
Activate relevant frameworks and turn them into actionable policies tailored to your needs.
Credible reports to proof your compliance
Use guided tasks to ensure secure implementations and create professional reports with just a few clicks.
AI-powered improvement suggestions
Focus on the most impactful improvements in your compliance with help from Cyberday AI.