If your organisation is subject to DORA and you’re wondering how to navigate the regulation’s stringent reporting requirements, you’re in the right place.
When you think of DORA reporting requirements, you might immediately skip to the “ICT-Related Incidents Management, Classification and Reporting” pillar. But, there are actually reporting requirements you need to be aware of in the other pillars of DORA, too.
We break them down below.
DORA Reporting Requirements for Financial Entities
We’ve laid out the reporting obligations, timelines, and report recipients in a table here:
Below, we provide more details on the reporting obligations set out by DORA for covered financial entities, broken down by DORA pillars.
Under the ‘ICT risk management’ pillar, financial entities need to…
Produce ICT risk management framework review reports
This report should reflect the findings from regular reviews of your “sound, comprehensive, and well-documented ICT risk management framework.”
→ Delivered to: The competent authority upon request.
Report on ICT incident costs and losses
Report an estimation of aggregated annual costs and losses caused by major ICT-related incidents.
→ Delivered to: The competent authority upon request.
Share ICT resilience and incident insights
Senior ICT staff must report yearly insights from digital resilience testing, real-life incidents (e.g., cyber-attacks), and business continuity challenges. These findings, which should continuously inform updates to the ICT risk management framework, should be accompanied by actionable recommendations.
→ Delivered to: The management body at least yearly.
Under the ‘ICT-related incident management, classification and reporting’ pillar, financial entities need to…
Report major ICT-related incidents (to senior management)
Report at least major ICT-related incidents, explaining the impact, response and additional controls that need to be established as a result of these incidents.
→ Delivered to: Senior management.
Classify and access ICT incident impact
Classify ICT-related incidents and determine their impact based on the following criteria:
- Number and/or relevance of clients or financial counterparts affected and, where applicable, the amount or number of transactions affected by the ICT-related incident and whether the ICT-related incident has caused reputational impact;
- Duration of the ICT-related incident, including the service downtime;
- Geographical spread with regard to the areas affected by the ICT-related incident, particularly if it affects more than two Member States;
- Data losses that the ICT-related incident entails, in relation to availability, authenticity, integrity or confidentiality of data;
- Criticality of the services affected, including the financial entity’s transactions and operations;
- Economic impact, in particular direct and indirect costs and losses, of the ICT-related incident in both absolute and relative terms.
→ Delivered to: Primarily for internal use, but also helps with reporting major incidents to the relevant competent authority (as described below).
Report major incidents (to the relevant competent authority)
Submit several reports (initial, intermediate, and final - more information on this below) in the event of a major ICT-related incident.
General information that must be provided in all reports includes the following:
- Type of report (initial, intermediate, or final).
- Name, LEI code, and what kind of entity it is authorised or registered as (e.g., credit institution, payment institution, etc.)
- Name and identification code of the entity submitting the report for the financial entity.
- Names and LEI codes of all financial entities covered in the aggregated report, where applicable.
- Contact details of the contact persons responsible for communicating with the competent authority.
- Identification of the parent undertaking of the group, where applicable.
- Reporting currency.
Initial report
The initial report must include at least the following information about the incident:
- Incident reference code.
- Date and time of detection and classification of the incident.
- Description of the incident.
- Classification criteria that triggered the incident report.
- Member States impacted by the incident, where applicable.
- How the incident was discovered.
- Origin of the incident, where available;
- Whether a business continuity plan has been activated.
- Reclassification of the incident from major to non-major, where applicable.
- Other information, where available.
Timeline: As early as possible, within 4 hours from when the incident is classified as major, but no later than 24 hours from when you become aware of the incident.
Intermediate report
The intermediate report must include at least the following information about the incident:
- Incident reference code provided by the competent authority, where applicable.
- Date and time of occurrence of the incident.
- Date and time when regular activities have been restored, where applicable.
- Classification criteria that triggered the incident report.
- Incident type.
- Threats and techniques used by the threat actor, where applicable.
- Affected functional areas and business processes.
- Affected infrastructure components supporting business processes.
- Impact on the financial interest of clients.
- Information about reporting to other authorities.
- Temporary actions/measures taken or planned to be taken to recover from the incident.
- Indicators of compromise, where applicable.
Timeline: No later than 72 hours from the submission of the initial report, even if there were no changes in the incident’s status or handling. When regular activities recover, another report needs to be submitted without undue delay and show what recovery and final actions were taken.
Final report
The final report must include the following information about the incident:
- Root causes of the incident.
- Dates and times when the incident was resolved and the root cause addressed.
- Information on the incident resolution.
- Information relevant for resolution authorities, where applicable.
- Information about direct and indirect costs and losses stemming from the incident and information about financial recoveries.
- Information about recurring incidents, where applicable.
Timeline: No later than one month after you submitted the latest updated intermediate report.
→ All reports to be delivered to: Relevant competent authority.
Report significant cyber threats (voluntary)
Financial entities can report significant cyber threats to the financial system, service users, or clients if they want to.
Reports should contain the following information:
- General information about the reporting entity.
- Date and time of detection of the significant cyber threat and any other relevant timestamps related to the threat.
- Description of the significant cyber threat.
- Information about the potential impact of the cyber threat on the financial entity, its clients and/or financial counterparts.
- Classification criteria that would have triggered a major incident report if the cyber threat had materialised.
- Status of the cyber threat and any changes in the threat activity.
- Actions taken by the financial entity to prevent the materialisation of the significant cyber threat, where applicable.
- Information about notification of the cyber threat to other financial entities or authorities.
- Information on indicators of compromise, where applicable.
- Other relevant information, where available.
→ Delivered to: Relevant competent authorities.
Under the ‘Managing of ICT third-party risk’ pillar, financial entities need to…
Maintain ICT contractual registers
Maintain an up-to-date register of all contracts with ICT third-party service providers at entity, sub-consolidated, and consolidated levels.
→ Delivered to: Competent authorities upon request, either in full or in specified sections, along with any additional information needed for effective supervision. A template is available here.
*Worth noting: During the 2024 Dry Run exercise on reporting the registers of information under the Digital Operational Resilience Act (DORA), 10,000 TPPs were identified, and 25,000 contractual arrangements were reported. Just 6.5% of submitted registers passed all data quality checks. On the other hand, 50% failed fewer than 5 out of 116 data quality checks. So, while initial submissions show promise, significant improvements are necessary to meet the 2025 requirements.
Under the ‘Information sharing arrangements’ pillar, financial entities need to…
Notify of participation in information-sharing arrangements
Upon validation of membership and of membership cessation.
→ Delivered to: Competent authorities.
DORA Reporting Requirements for Critical Third-Party Providers (CTPP)
For critical third-party providers (CTPP) and third-party providers that want to be designated as such, all reporting requirements fall under the DORA pillar of ‘Managing of ICT third-party risk.’
Again, we summarise these requirements in a table here and explain each requirement in more detail below.
Submit a reasoned statement
The statement should include any relevant information for the purposes of the assessment.
→ Delivered to: The Lead Overseer within 6 weeks from the date of the notification.
→ Follow up: Within 6 weeks from the date of the notification. The Lead Overseer will consider the statement and may request additional information, which the CTPP will need to submit within 30 calendar days.
Inform financial entity clients about the designation
This is to ensure financial entities are aware of the CTPP designation and its implications for oversight and compliance under DORA.
→ Delivered to: All financial entities that use the services of the designated provider.
Notify of management structure changes (for subsidiaries)
CTPPs that establish a subsidiary in the EU within 12 months of their designation must notify the Lead Overseer of any changes to the subsidiary’s management structure.
→ Delivered to: The Lead Overseer overseeing the CTPP.
Submit a reasoned statement addressing impact of oversight plan on customers not subject to DORA
Upon receiving the draft oversight plan, the CTPP can submit a reasoned statement that:
1) Provides evidence of the plan’s expected impact on non-regulated customers.
2) Proposes solutions to reduce or mitigate any risks identified.
→ Delivered to: The Lead Overseer responsible for the oversight plan within 15 calendar days of receiving the draft oversight plan.
Provide subcontracting information
Provide details about their subcontracting arrangements related to services provided to financial entities.
→ Delivered to: The Lead Overseer. A template is referred to in Article 41(1), point (b).
Submit a reasoned statement addressing impact of oversight plan on customers not subject to DORA
The Lead Overseer must allow CTPPs to submit:
- Evidence showing how oversight activities may affect customers outside the scope of DORA.
- Potential solutions to mitigate potential risks to those customers.
→ Delivered to: The Lead Overseer within 30 calendar days of request from the Lead Overseer.
Supply information the Lead Overseer requires to enable it to carry out its duties
Representatives of the CTPPs, including lawyers authorised to act, shall supply all information requested by the Lead Overseer to enable it to fulfil its oversight duties.
The information requested can include:
- Relevant business or operational documents.
- Contracts.
- Policies documentation.
- ICT security audit reports.
- ICT-related incident reports.
- Any information relating to parties to whom the critical ICT third-party service provider has outsourced operational functions or activities.
→ Delivered to: The Lead Overseer, upon request.
Respond to Lead Overseer recommendations
Respond to recommendations issued by the Lead Overseer, saying that they will either:
- Follow the recommendations.
- Provide a reasoned explanation for not following recommendations.
→ Delivered to: The Lead Overseer within 60 calendar days of receiving the recommendations issued by the Lead Overseer.
Submit a reasoned application for CTPP designation (voluntary)
ICT Third-Party Providers (TPPs) that wish to be designated as Critical Third-Party Providers (CTPPs) must submit a reasoned application.
→ Delivered to: The appropriate authority (EBA, ESMA, or EIOPA). The respective authority, through the Joint Committee, will evaluate the application and decide on the designation.
Need Help Complying with DORA? SECFORCE Can Help
SECFORCE is a consultancy firm specialising in DORA, with vast experience assisting financial institutions and businesses in managing compliance processes, including those required under DORA.
Contact us for support with your DORA compliance journey.
