Commission Delegated Regulation (EU) 2025/301
Digital Operational Resilience Act (DORA)
Objective: This RTS defines the precise content and timelines for notification of major ICT incidents to supervisory authorities, as well as the voluntary notification process for significant cyber threats.
Key Principle: Fast, progressive and structured notification in 3 stages:
Incident Reporting Flow: each clock starts from the previous step
All three reports go to your competent authority, which forwards the details to the ESAs and the ECB where relevant (DORA Article 19(6)). Times are maxima set by Delegated Regulation (EU) 2025/301, Article 5: earlier is always permitted.
Article 8(1) of RTS 2024/1772 is a gate followed by a count. Answer Q1 first: without critical services affected, the incident is not major. With them, Q2 alone can make it major; otherwise two or more YES answers in Q3 to Q8 are needed.
Failure to meet deadlines constitutes a DORA violation subject to administrative penalties set by national law under Article 50.
Deadline: as early as possible, within 4 hours of classifying the incident as "major", and no later than 24 hours after the financial entity became aware of the incident (Article 5(1)(a)). An incident classified as major later than that is notified within 4 hours of its classification (Article 5(2)).
Objective: Alert the supervisor that a major incident is ongoing
Minimum mandatory content:
⚠ Information NOT required at this stage:
Tip: Prepare a pre-filled template with static information (entity identification, contacts, etc.) to save time during emergency notification.
Deadline: at the latest 72 hours after the submission of the initial notification, even if the status or handling of the incident has not changed. Submit an updated intermediate report without undue delay whenever the status changes, and in any case when regular activities have been recovered (Article 5(1)(b)).
Objective: Provide a detailed update on the situation and impact
Mandatory content:
Important note: If the incident is not resolved when the intermediate report is due, include an action plan with the expected timeline, and file updated intermediate reports as the situation evolves.
Deadline: no later than one month after the submission of the intermediate report or, where you filed updates, after the latest updated intermediate report (Article 5(1)(c)).
If a deadline cannot be met: inform the competent authority before it expires and explain why (Article 5(3)). A deadline falling on a weekend or bank holiday moves to noon of the next working day, except for the initial notification and the intermediate report of credit institutions, central counterparties, trading venues and entities that are essential or important under NIS2 (Article 5(4) and (5)).
Objective: Provide comprehensive post-incident analysis and preventive measures
Mandatory content:
| 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 |
| Field | Description | Initial notification | Intermediate report | Final report |
|---|---|---|---|---|
| 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 | ✓ | ✓ | ✓ |
| Metric | Calculation Method | Initial notification | Intermediate report | Final report |
|---|---|---|---|---|
| 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 | ✓ | ✓ | ✓ |
In the initial notification:
In the intermediate report:
In the final report:
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.
| 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.
| 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.
DORA sets no EU-wide maximum fine for financial entities: Article 50 leaves administrative penalties to national law, so the amount depends on the Member State. The only turnover-based percentage in the Regulation applies to designated critical ICT third-party providers (periodic penalty payments capped at 1% of average daily worldwide turnover, Article 35).
Source: Regulation (EU) 2022/2554 (DORA), Article 50: administrative penalties · Article 35: periodic penalty payments for CTPPs · Article 52: criminal penalties
DORA does not grade incident-reporting breaches or attach an amount to each one. It requires every Member State to give its competent authority at least these powers:
These penalties and measures can also be applied, under national law, to members of the management body and other individuals responsible for the breach (Art. 50(5)).
⚠ Note: When setting the type and level of a penalty, the competent authority takes into account whether the breach was intentional or negligent, its materiality, gravity and duration, the degree of responsibility, financial strength, profits gained or losses avoided, losses caused to third parties, the level of cooperation and previous breaches (Art. 51(2)). For amounts, read the national law that implements Article 50 in your Member State.
| Timing | Actions | Responsible |
|---|---|---|
| From awareness of the incident |
• Detect and confirm incident • Activate crisis cell • Assess preliminary impact • Classify incident (major or not) as soon as the facts allow |
SOC / CERT CISO |
| Within 4h of classification (and no later than 24h after awareness) |
• Fill initial report template • Validate with Legal/Compliance • Submit on supervisor portal • Inform Executive Management |
Compliance CEO |
| After the initial notification |
• Continue remediation • Collect impact metrics • Prepare preliminary analysis |
IT / CISO Risk Management |
| Within 72h of submitting the initial notification |
• Submit intermediate report • Include all quantified impacts • Update it when regular activities are recovered |
Compliance |
| Until the final report |
• Finalize RCA (Root Cause Analysis) • Define remediation plan • Calculate total costs |
IT / Risk / Finance |
| Within 1 month of the latest intermediate report |
• Submit final report • Close incident • Archive documentation |
Compliance Archives |
Our experts can guide your institution through DORA compliance, from gap analysis to full implementation.
Workbooks, playbooks and certifications built for EU financial entities. Add several to your cart: volume discounts apply automatically.
Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.