DORA RTS - Incident Reporting (2025/301)

⚠️ WARNING: Deadlines are MAXIMUMS and NON-NEGOTIABLE

Failure to meet deadlines constitutes a DORA violation subject to penalties of up to 2% of annual worldwide turnover.

⏰ T+4 Hours: Initial Report

Deadline: Maximum 4 hours after classifying the incident as "major"

Objective: Alert the supervisor that a major incident is ongoing

Minimum mandatory content:

✅ Date and time of detection
✅ Nature of incident (outage, cyberattack, failure, etc.)
✅ Current status (ongoing, contained, resolved)
✅ Affected services/systems
✅ Preliminary estimate of number of impacted clients
✅ Geographic extent
✅ Classification according to RTS 2024/1772 criteria
✅ Immediate actions taken
✅ 24/7 contact point

⚠️ Information NOT required at this stage:

Detailed root cause (often unknown at T+4h)
Precise quantification of economic losses
Complete remediation plan

💡 Tip: Prepare a pre-filled template with static information (entity identification, contacts, etc.) to save time during emergency notification.

⏰ T+72 Hours: Interim Report

Deadline: Maximum 72 hours (3 days) after initial detection

Objective: Provide a detailed update on the situation and impact

Mandatory content:

✅ Update of all initial report elements
✅ Quantified impact:
- Exact number of affected clients/users
- Precise duration of interruption
- Failed or lost transactions
✅ Preliminary analysis:
- Probable causes (if identified)
- Attack vector (if cyber incident)
- Failed systems and components
✅ Remediation status:
- Corrective measures applied
- Services restored (partially or fully)
- Estimated timeline for complete resolution
✅ Economic estimate:
- Incident response costs
- Revenue losses
- Fraud or direct financial losses
✅ Indication if incident also notified to other authorities (GDPR DPA, CERT, etc.)

💡 Important note: If the incident is not resolved at T+72h, the interim report must include an action plan with expected timeline.

⏰ T+1 Month: Final Report

Deadline: Maximum 1 month (30 calendar days) after initial detection

Objective: Provide comprehensive post-incident analysis and preventive measures

Mandatory content:

✅ Complete Root Cause Analysis (RCA):
- Detailed timeline of events
- Technical root cause identified
- Control failures that allowed the incident
- Investigation methodology used
✅ Final quantified impact:
- Total costs (IT, consultants, customer compensation, fines)
- Definitive revenue losses
- Total number of affected clients/transactions
✅ Immediate corrective actions:
- Corrections already applied
- Security patches deployed
- Configurations modified
✅ Medium/long-term remediation plan:
- Control improvements
- Planned technology investments
- Staff training
- Process reviews
- Timeline with deadlines
✅ Lessons learned:
- What worked well
- What needs improvement
- Recommendations to prevent recurrence
✅ Confirmation that the incident is closed

Section 1: Entity Identification

Field	Description	Mandatory?
Full legal name	Official corporate name	YES
LEI Code	Legal Entity Identifier (20 characters)	YES
Entity type	Bank, insurance, PSP, investment, etc.	YES
Country of registration	EU Member State of primary authorization	YES
Supervisory authority	Name of competent supervisor	YES
Incident contact point	Name, role, email, 24/7 phone	YES

Section 2: Incident Characteristics

Field	Description	Required T+4h	Required T+72h	Required T+1 month
Detection date/time	Precise timestamp (UTC)	✅	✅	✅
Start date/time	When incident actually began (may be before detection)	Estimated	✅	✅
Incident type	• Cyberattack (specify: ransomware, DDoS, phishing...) • System failure • Human error • Natural disaster • Third-party provider failure	✅	✅	✅
Classification	RTS 2024/1772 criteria triggered (check all applicable)	✅	✅	✅
Affected systems	List of impacted applications, servers, networks	Partial	✅	✅
Impacted business functions	Payments, trading, customer service, etc.	✅	✅	✅
Status	Ongoing / Contained / Resolved	✅	✅	✅

Section 3: Quantified Impact

Metric	Calculation Method	T+4h	T+72h	T+1 month
Number of clients	Count all clients/users unable to access the service	Estimated	Precise	Final
Interruption duration	Total time (cumulative if multiple outages) in hours	Ongoing	Current	Total
Affected transactions	Number of failed/lost/delayed transactions	Estimated	Precise	Final
Economic losses	Direct costs: consultants, overtime, compensation Revenue losses: uncollected fees	Not required	Estimated	Final
Compromised data	Type of data (sensitive/non-sensitive) Number of affected individuals Type of compromise (confidentiality/integrity/availability)	If known	✅	✅
Geographic extent	Affected countries/regions, closed sites	✅	✅	✅

Section 4: Response Actions

At T+4h (Initial Report):

Immediate actions taken (system isolation, BCP activation, etc.)
Teams mobilized
External expertise engaged (if applicable)

At T+72h (Interim Report):

Complete timeline of remediation actions
Services restored (detailed list)
Conservatory measures applied
Estimate of complete resolution date

At T+1 month (Final Report):

Root cause identified and documented
Immediate corrections applied (patches, configs, etc.)
Long-term remediation plan with timeline
Budget allocated to improvements
Monitoring indicators defined

Principle: In addition to the obligation to notify major incidents, financial entities MAY voluntarily notify significant cyber threats they detect, even if no incident has (yet) occurred.

What is a "significant cyber threat"?

Advanced intrusion attempts: APT (Advanced Persistent Threats), sophisticated vulnerability scans
Targeted phishing campaigns: Spear-phishing attacks specifically targeting the entity or sector
Critical vulnerabilities discovered: Zero-days affecting critical systems
Threat intelligence: Credible information about an imminent attack
Indicators of Compromise (IOCs): Detection of malware, C2 servers, malicious IPs

Why notify voluntarily?

✅ Alert other entities in the sector
✅ Enable authorities to coordinate collective response
✅ Contribute to financial sector resilience
✅ Demonstrate proactive posture

Content of voluntary notification:

Information	Description
Threat type	Malware, phishing, DDoS, intrusion, vulnerability, etc.
Technical indicators	• Malicious file hashes (MD5, SHA256) • Source IP addresses • C2 (Command & Control) domains • Malicious URLs • Attack patterns
Attack vector	Email, web, API, VPN, supply chain, etc.
Targeted systems	Targeted applications, OS, network equipment
Sophistication level	Low / Medium / High / APT
Defensive actions taken	Blocks, isolations, patches, enhanced monitoring

⏰ Voluntary notification timeline:

No strict deadline imposed, but notification recommended as soon as possible to maximize the usefulness of the information for the sector.

💡 Best practice: Notify within 24h of threat detection, even if analysis is not complete.

Notification Portals by Supervisor

Country/Supervisor	Portal	Format
France - ACPR	ROSA Portal (Operational Security and Activity Reporting)	XML per ITS 2025/302 schema
Germany - BaFin	BaFin MaCo Portal	XML per ITS 2025/302 schema
Spain - Banco de España	Portal de Supervisión	XML per ITS 2025/302 schema
Italy - Banca d'Italia	Portale INFOSTAT	XML per ITS 2025/302 schema
ECB (significant institutions)	ECB IMAS Portal	XML per ITS 2025/302 schema

💡 Standardized format: All supervisors accept the XML format defined in ITS 2025/302, ensuring interoperability.

Authentication: Qualified electronic certificates (eIDAS) required to submit reports.

Acknowledgment of receipt: The portal automatically generates an acknowledgment with unique incident number to retain.

Types of Violations and Potential Penalties

Violation	Severity	Penalty Type
Non-notification of major incident	VERY SEVERE	• Fine up to 2% worldwide turnover • Public disclosure of penalty • Mandatory corrective measures
Notification beyond deadline (delay >24h)	SEVERE	• Fine up to 1% worldwide turnover • Official warning
Incomplete or inaccurate information	MODERATE	• Fine up to 0.5% worldwide turnover • Obligation to submit corrected report • Supervised audit
Intentional misclassification	VERY SEVERE	• Fine up to 2% worldwide turnover • Individual sanctions on managers • In-depth audit

⚠️ Note: Penalties are proportionate to the severity, duration, and recurrence of the violation, as well as the degree of cooperation with authorities.

Preparation (BEFORE any incident)

☐ Create account on supervisor's portal
☐ Obtain eIDAS certificates
☐ Prepare pre-filled templates
☐ Document internal escalation procedure
☐ Identify 24/7 contact points
☐ Train IT and legal teams
☐ Test the process via tabletop exercise

During a Major Incident

Timing	Actions	Responsible
T+0 to T+2h	• Detect and confirm incident • Activate crisis cell • Assess preliminary impact • Classify incident (major/minor)	SOC / CERT CISO
T+2h to T+4h	• Fill initial report template • Validate with Legal/Compliance • Submit on supervisor portal • Inform Executive Management	Compliance CEO
T+4h to T+72h	• Continue remediation • Collect impact metrics • Prepare preliminary analysis	IT / CISO Risk Management
T+72h	• Submit interim report • Include all quantified impacts	Compliance
T+72h to T+1 month	• Finalize RCA (Root Cause Analysis) • Define remediation plan • Calculate total costs	IT / Risk / Finance
T+1 month	• Submit final report • Close incident • Archive documentation	Compliance Archives

ITS 2025/302: Standardized XML templates for notification
RTS 2024/1772: Incident classification criteria
DORA Article 19: Legal basis for reporting
ESAs Guidelines: Best practice examples by sector

📢 RTS on Incident Reporting

📋 Executive Summary

⏱️ The 3 Reporting Timelines (Article 5)