Contents
- Restoration and recovery procedures and methods
Restoration and recovery procedures and methods
Regulatory Purpose and Integration into the ICT Risk Management Framework
Restoration and recovery procedures under Article 12(1)(b) DORA form the core operational mechanism through which a financial entity restores ICT systems and data with minimum downtime, limited disruption, and minimal loss. They constitute the executable part of the ICT response and recovery plans mandated under Article 11 DORA and must ensure that the entity can reliably return to normal or near-normal operations after ICT disruptions.
These procedures and methods must be:
- formally developed,
- fully documented,
- maintained within the ICT risk management framework (Article 6(1)),
- embedded in business continuity operations and ICT BCP (RTS RMF Article 24),
- and aligned with detection, incident handling, and business impact analysis (BIA).
Required Content of Restoration and Recovery Procedures
Restoration and recovery procedures must cover all critical and important functions and the ICT systems supporting them. They must provide a complete, auditable, and operationally executable instruction set.
Recovery Objectives and Dependencies
Procedures must explicitly map:
- recovery time objectives (RTOs),
- recovery point objectives (RPOs),
- dependencies between ICT systems, data stores, applications, infrastructure layers, and communication links.
This alignment is required under RTS RMF Article 24(1)(b).
Step-by-Step Restoration and Recovery Methods
Procedures must include:
- activation steps for recovery efforts,
- identification of the system to be restored (primary, backup, redundant, or alternative environment),
- instructions for retrieving and validating backup datasets,
- system rebuild or reinitialisation procedures,
- reloading of configuration baselines,
- verification of system integrity and authenticity,
- re-synchronisation of data where applicable,
- documented criteria for successful recovery completion.
Procedures must reflect the principle under Article 12: minimum downtime, limited disruption, minimal data loss.
Secure Activation of Backup Systems
Article 12(2) imposes a security requirement: activation of backup systems or restoration environments must not jeopardise:
- network security,
- information system security,
- data availability, authenticity, integrity or confidentiality.
This requires:
- isolation of backup environments,
- secure credentials and privileged access management,
- controlled restore pipelines,
- hardening of backup and recovery servers,
- integrity verification measures before reintegration.
Alignment with Response Processes (Article 11(2)(c))
Restoration and recovery procedures must be directly linked to the incident response mechanism required under Article 11(2)(c) DORA, ensuring:
- immediate activation following incident containment,
- tailored recovery paths based on the type of ICT-related incident,
- integration with crisis communication procedures,
- harmonisation with containment actions to avoid restoring compromised systems or reinfecting the environment.
Integration with ICT Third-Party Services
Where recovery relies on ICT third-party service providers, procedures must:
- document the provider’s role in recovery,
- identify contractual RTO/RPO commitments,
- define fallback or alternative procedures if the provider is impaired,
- ensure alignment with the policy on the use of ICT services supporting critical or important functions.
This requirement stems from Article 12 read in conjunction with Article 28 DORA and RTS RMF Article 26(4).
Required Technical and Organisational Measures
Restoration and recovery procedures must incorporate:
Technical Measures
- configuration baselines for restored systems,
- automated or semi-automated restoration workflows,
- forensic-ready restoration environments,
- system integrity checks (checksums, hashes, logs),
- anti-malware and security verification before reconnecting systems to the production network,
- resilient architecture enabling alternative restoration paths (cloud, on-prem, hybrid).
Organisational Measures
- clearly assigned roles and responsibilities,
- multi-person control for critical recovery steps,
- escalation paths and incident commander authority,
- communication processes for internal staff and external stakeholders (Article 14(2)),
- predefined approval workflow for restoring sensitive data or reactivating critical systems.
Testing Requirements
Under Article 12(2), periodic testing of restoration and recovery procedures is mandatory. This testing must:
- validate the end-to-end restoration capability,
- confirm the entity can meet required RTO/RPO,
- assess data integrity and confidentiality in restored systems,
- ensure restored environments are secure against cyber threats,
- test switchovers between primary and backup infrastructure.
Testing must align with ICT BCP testing obligations (RTS RMF Article 25), including:
- severe but plausible scenarios,
- scenarios involving failure of ICT third-party service providers,
- crisis communication testing,
- stress conditions for recovery systems.
Findings must feed into the ICT risk management framework review (Article 6(5)).
Governance and Oversight Responsibilities
In accordance with Article 5(2)(e) and Article 6 DORA, the management body must:
- approve restoration and recovery procedures,
- periodically review them,
- oversee their operational effectiveness,
- ensure adequate resources (human, financial, technical) are allocated for restoration capability.
Internal audit must independently review the procedures (Article 11(3)).