Records of activities before and during disruption events when their ICT BCPs and ICT response and recovery plans are activated

Records of activities before and during disruption events when their ICT BCPs and ICT response and recovery plans are activated

Regulatory Purpose and Context in the ICT Risk Management Framework

Article 11(8) DORA obliges financial entities to maintain readily accessible records of all relevant activities before and during disruption events whenever:

  • the ICT Business Continuity Plans (ICT BCPs), or
  • the ICT Response and Recovery Plans (R&R Plans)

are activated.

This requirement ensures auditability, traceability and forensic readiness, supporting supervisory investigations, post-incident reviews, and the annual ICT risk management framework review under Article 6(5) DORA.

These records form a mandatory evidence base for:

  • business impact and harm assessment,
  • root-cause analysis,
  • audit verification (Article 6(6)–(7) DORA),
  • remediation planning,
  • ICT incident reporting (Article 19 DORA).

Scope of Required Records

The obligation concerns all relevant activities occurring:

  • before the disruption (pre-activation phase), and
  • during the disruption (active crisis/continuity phase),

whenever the ICT BCPs or ICT R&R plans are activated, irrespective of root cause (cyber-attack, system failure, third-party disruption, natural disaster, insider threat, etc.).

Records must cover critical and important functions in particular, but the scope applies to all activated plans.

Required Content Elements of the Records

Although Article 11(8) DORA is concise, its content requirements expand through interaction with the RTS RMF and DORA incident handling provisions.
The following elements must be recorded at minimum:

Pre-Activation Records (“Activities Before Disruption”)

  • anomaly detections, alerts and logs triggering the escalation (Article 10 DORA; Article 23 RTS RMF),
  • communications between detection, ICT operations, BCM and management body,
  • evidence supporting activation criteria (Article 24(1)(a)(iv) RTS RMF),
  • timeline and decision logs of when activation thresholds were met,
  • overview of impacted ICT systems, functions and interdependencies (Article 8 DORA),
  • changes in risk posture and deviation from normal operations.

Activation Decision Records

  • timestamp of activation of ICT BCPs and/or R&R plans,
  • decision-maker(s), roles, delegated authority,
  • documented rationale referencing the activation criteria.

Records of Activities During Disruption

  • operational steps taken in response and recovery (Article 26(1)(b) RTS RMF),
  • switchover or fallback measures (redundant facilities, backups, alternative channels),
  • communication and coordination actions (internal and external, Article 14(2) DORA),
  • involvement of third-party service providers (Article 26(2) and 26(4) RTS RMF),
  • security-related interventions (containment, isolation, mitigation),
  • manual workarounds deployed and their duration,
  • resource and staffing allocation during the crisis,
  • data integrity and availability assessments,
  • changes to RTO/RPO expectations or deviations.

Evidence and Logs

Records must be linked to:

  • system logs (Article 12 RTS RMF),
  • network logs (Article 13 RTS RMF),
  • anomalous activity records (Article 23(4) RTS RMF),
  • vulnerability or patch actions (Article 10 RTS RMF),
  • capacity/performance readings (Article 9 RTS RMF),
  • incident classification and root-cause log (Article 27 RTS RMF).

Documentation of Restoration

  • timestamps of recovery milestones,
  • systems reactivated,
  • recovery testing and validation steps ensuring return to normal operations (Article 26(1)(c)),
  • final confirmation of successful execution of the plans (Article 26(1)(f)).

Accessibility Requirements

Article 11(8) requires that all records are readily accessible, meaning:

  • immediately available to the crisis team during the event,
  • accessible for internal audit (Article 6(6) DORA),
  • accessible for supervisory review without delay (Article 6(3) DORA),
  • stored in an environment resilient to the disruption itself
    (remote backup locations, secure digital repositories, redundant storage).

This creates an operational expectation that continuity and recovery recordkeeping must not itself be reliant solely on affected systems.

Integration with Other Framework Components

The recordkeeping requirement is directly interlinked with:

  • ICT business continuity policy (Article 24 RTS RMF),
    – must define how records are created, maintained and protected.
  • ICT response and recovery plans (Article 26 RTS RMF),
    – must identify responsibility for documenting actions and events.
  • Incident management processes (Articles 17–20 DORA; Article 22 RTS RMF),
    – must align recordkeeping with root-cause analysis and post-incident obligations.
  • Annual ICT risk management framework review (Article 6(5) DORA),
    – uses these records as mandatory input to findings, assessments, and remediation plans.
  • Internal audit (Article 6(6)–(7) DORA),
    – relies on these records to verify adequacy and operating effectiveness.

Governance Responsibilities

  • The management body must approve, oversee and periodically review the integration of recordkeeping processes into ICT BCPs and R&R plans (Article 5(2)(e) DORA).
  • Roles and responsibilities must be documented in the ICT business continuity policy (Article 24(1)(b)(i) RTS RMF) and the ICT R&R plans (Article 26(1)(d)).
  • A formal process must ensure completeness, accuracy and timeliness of the records.

Article 11 (8) DORA

Article 11 DORA – Response and recovery