Contents
- Records of all ICT-related incidents and significant cyber threats
Purpose of the Requirement
Article 17(2) DORA imposes a binding obligation on financial entities to ensure full lifecycle visibility of all ICT-related incidents and all significant cyber threats, in order to support:
- continuous monitoring of the entity’s ICT risk profile,
- effective incident handling and follow-up,
- structured root-cause analysis,
- identification of weaknesses in ICT systems and controls, and
- prevention of recurrence through corrective and preventive measures.
The requirement also forms a foundational component for compliance with detection (Article 10), classification and materiality assessment (Article 18), and supervisory reporting (Article 19).
Scope of Records
Financial entities must record all of the following:
Including but not limited to:
- cyber-attacks (malware, phishing, DDoS, ransomware, intrusions)
- ICT system failures, outages, degradation
- network disruptions or instability
- data integrity, confidentiality, or availability breaches
- service degradation or failure impacting critical or important functions
- authentication or access control failures
- failures of ICT third-party service providers
- cloud service disruptions
- operational errors with ICT impact
- anomalies that triggered incident response processes
Significant cyber threats
Including:
- threat intelligence indicators signalling imminent attacks
- external reports on vulnerabilities with direct relevance
- credible attack preparations
- early-stage compromise indicators (IOCs)
- alarms from detection tools suggesting hostile activity
- alerts from ICT third-party service providers
Only “significant” threats must be recorded, but all incidents must be recorded regardless of severity.
Mandatory Record-Keeping Obligations
Financial entities must:
Maintain a complete, structured, and tamper-resistant incident register
The register must capture at a minimum:
- Date/time of occurrence
- Date/time of detection
- Incident type and root cause
- Systems, services, or data affected
- Business functions impacted
- Third-party involvement
- Severity and classification (per Article 18)
- Actions taken (mitigation, containment, recovery)
- Escalation steps taken
- Communication and notifications (staff, customers, stakeholders, authorities)
- Final resolution and closure date
- Lessons learned and follow-up measures
- Assessment of recurrence risk
Records must be sufficient to enable supervisors to verify the entire incident lifecycle.
Procedures to Ensure Consistent and Integrated Monitoring, Handling and Follow-Up
Article 17(2) requires formalised procedures ensuring:
Consistent monitoring
Across all ICT layers, including:
- log data (Article 12 RTS RMF)
- anomaly detection mechanisms (Article 10 DORA; Article 23 RTS RMF)
- SOC, NOC, SIEM, EDR/XDR tools
- threat intelligence feeds
- third-party incident notifications
Monitoring must allow integrated visibility across the entire ICT environment.
Integrated incident handling
Procedures must ensure:
- centralised intake of all incidents (single entry point)
- uniform classification and severity assessment
- consistent triage rules
- coordinated actions across ICT, security, business, and third-party functions
- alignment with communication and crisis communication plans (Article 14)
- escalation to senior management (Article 17(3)(e))
Handling must be reproducible and aligned with incident taxonomies defined under Article 17(3)(b).
Mandatory follow-up of all incidents
The procedures must require:
- structured root-cause analysis for every incident
- identification of control weaknesses and architectural deficiencies
- documentation of mitigating and preventive measures
- verification of the effectiveness of corrective measures
- updating of risk assessments where relevant (Article 3 RTS RMF)
- feeding lessons learned into:
- detection mechanisms
- ICT BCP and response/recovery plans (Articles 11–12, 24–26)
- digital operational resilience testing (Article 24(5))
- ICT risk management framework reviews (Article 6(5))
Follow-up must prevent recurrence and strengthen digital operational resilience.
Requirements for Documentation and Retention
Records must:
- be complete, accurate, and contemporaneous
- be protected against tampering, deletion, or unauthorised modification
- be stored in a secure, auditable system
- support forensic analysis where needed
- remain accessible for supervisory inspection
DORA does not prescribe a fixed retention period here; retention must be adequate to support supervisory review and consistent with:
- logging retention rules (Article 12 RTS RMF)
- data protection and proportionality obligations
- ICT business continuity documentation needs
- audit trails required by Article 6(7) DORA
Integration with Other DORA Requirements
The incident record requirement supports and interacts with:
Article 10 – Detection Mechanisms
Records provide feedback loops for detection tuning and threshold calibration.
Article 18 – Classification / Materiality Assessment
Recorded data forms the basis for determining whether an incident is “major” and requires notification under Article 19.
Article 19 – Supervisory Reporting of Major Incidents
The incident register must enable extraction of:
- timelines
- impact analysis
- service criticality
- root causes
- containment measures
Article 11 – Response and Recovery
Incident records must document the lifecycle until recovery is complete.
ICT business continuity (Articles 24–26 RTS RMF)
Lessons learned must feed into updates of ICT BCP and ICT response/recovery plans.
Internal audit (Article 6(6))
The incident register is a primary audit object for verifying:
- completeness
- classification correctness
- escalation consistency
- adequacy of follow-up
- timeliness of mitigation