As we explained in a previous blog post, most of the work involved in DORA incident reporting happens well before an incident occurs.
For this blog post, we talked to SECFORCE’s DORA Head of Consulting Services, Nikos Vassakis, to see what steps organisations should take to prepare for DORA incident reporting.
1. Perform and/or use an in-depth and accurate BIA
➤ What: Identify critical functions and impacts of disruption with a BIA.
➤ Why: Prioritise what matters most for reporting and recovery.
➤ How: Using quantitative and qualitative data, determine how severe disruptions could affect critical functions, processes, and third-party dependencies.
A Business Impact Analysis (BIA) will provide the information that will drive the definitions of criticality, classification and impact thresholds. This is a fundamental DORA incident reporting step that gives you a basic idea of what parts of your environment are critical.
This is actually a mandated action for DORA compliance anyway. According to DORA Article 11:
“As part of the overall business continuity policy, financial entities shall conduct a business impact analysis (BIA) of their exposures to severe business disruptions. Under the BIA, financial entities shall assess the potential impact of severe business disruptions by means of quantitative and qualitative criteria, using internal and external data and scenario analysis, as appropriate. The BIA shall consider the criticality of identified and mapped business functions, support processes, third-party dependencies and information assets, and their interdependencies. Financial entities shall ensure that ICT assets and ICT services are designed and used in full alignment with the BIA, in particular with regard to adequately ensuring the redundancy of all critical components.”
2. Define critical services and significant threats
➤ What: Make a list of critical services and major risks.
➤ Why: Know what to monitor for DORA-related incidents.
➤ How: Use your BIA and take into account all dependencies.
Use the Business Impact Analysis (BIA) and guidance from the ESAs and Central Authorities to identify critical services and their main risks.
Review all dependencies, including their geographic locations, relevant authorities and regulations, third parties and providers, and industry partners.
Remember, threats can be environmental, societal, or political, not just security-related.
It's essential to have a clear understanding of which systems, processes, and assets are truly critical to your operations.
A well-executed BIA helps you identify and prioritise the components of your environment that, if disrupted, would have the most significant impact - financially, operationally, and reputationally.
Without a BIA, you're essentially flying blind during a crisis, risking missteps in prioritisation and resource allocation.
3. Define ICT incidents
➤ What: Establish exactly what counts as an ICT incident in your environment.
➤ Why: Helps enable clear, consistent reporting.
➤ How: Align your standards with DORA’s standards.
What actually is an ICT incident?
Is it: (a) A server going offline? (b) A cloud provider failing (c) A data breach? (d) All of the answers?
The answer is potentially (d), but it depends on the affected systems. A server going offline might not be critical to operations (HR system) but a data breach of the same system might be critical.
Either way, DORA incident reporting requires you to have a clear definition of what an ICT incident is and how it can be triggered and managed.
Note: Service disruptions are considered incidents and can also be major, even though not triggered by a security threat or actor.
4. Define major and minor incidents
➤ What: Create a clear definition of what is a major incident vs a minor incident.
➤ Why: Avoid over or under-reporting incidents. We explain why in our previous blog post.
➤ How: Tailor definitions to DORA and your business size.
You only need to report on major incidents. So, you need to clearly define what a major incident means in your context.
Again, there is no universal definition of a major incident, but it should include, at a minimum, the requirements and thresholds defined by DORA.
5. Calculate and agree on incident classification thresholds
➤ What: Set clear impact thresholds for incident classification.
➤ Why: Trigger the right reporting and escalation at the right time.
➤ How: Create thresholds that take into account factors like geographical spread, past incidents and supplier impacts.
DORA reporting depends on accurate data definitions.
Each organisation should adjust the thresholds that trigger an incident and classify it as "major" based on its size, industry, and regulatory needs. You don't want to be figuring these things out during or immediately after an incident.
SECFORCE DORA incident reporting tip: Take into account your complete asset inventory and overall operational efficiency when figuring out these thresholds.
6. Define triggers for incident initiation
➤ What: List the conditions for when and how incident reporting happens.
➤ Why: Allows you to act quickly and consistently, and enables automation.
➤ How: Document triggers, reporting paths, and escalation criteria.
When exactly should an incident be reported?
Map clear conditions and requirements for reporting an incident under DORA.
Define:
- What qualifies as an incident.
- What information is needed to define an event as an incident.
- How to report an incident.
- Who can report an incident.
- Whether automated monitoring and response solutions exist.
- How to escalate an incident to major.
7. Define and assign roles and responsibilities for incident handling and management
➤ What: Map out who handles what during an incident.
➤ Why: It is fundamentally important for DORA compliance to have clear points of contact.
➤ How: Create a RACI matrix (or another kind of responsibility chart) and train teams.
Major incidents are rarely isolated to a particular department or within a single team’s responsibility.
A major incident will probably require different incident management functions and personnel across a range of teams and verticals. Think about cross-functional responses and assign roles for incident handling and management.
We advise making sure there is still enough independence and oversight in assigned responsibilities to maintain flexibility.
SECFORCE DORA incident reporting tip: Keep chains of command simple and as flat as possible during incident response.
8. Assign and maintain clear ownership of all assets and processes
➤ What: Tie every asset and process to a clear owner.
➤ Why: Avoid unknown risks and outcomes.
➤ How: Maintain a documented, updated ownership registry.
Every asset, policy, or procedure, including risks, controls, and standards, must have a designated owner.
Their roles and responsibilities should be clearly defined and documented.
9. Create and maintain an incident handling policy and procedure
➤ What: Formalise how incidents are managed end-to-end.
➤ Why: Prove compliance and enable consistent action under stress.
➤ How: Write, review, and train on detailed but practical procedures.
Policies need to be made and tested.
These will be very specific to your organisation, but as a rule, incident management policies must include proper data classification, logging, monitoring, and access control.
Your procedures also have to function smoothly.
For example: The process for defining and measuring incidents can’t be broken, disruptive, or dependent on unreliable resources. Otherwise, there's no point in having a process in the first place.
10. Align your incident handling processes with DORA criteria and guidance
➤ What: Make sure your processes meet DORA’s reporting rules.
➤ Why: Avoid compliance gaps and reporting errors.
➤ How: Cross-check workflows against DORA templates and guidelines.
Whatever your existing incident handling processes look like, now’s the time to review them in light of DORA’s incident reporting requirements.
This way, you won’t have to scramble to gather data during an incident or when a report is needed.
Make sure that your reports are based on reliable, accurate, documented, and approved processes and datasets.
11. Maintain an accurate and detailed asset inventory
➤ What: Track all digital, physical, and human assets.
➤ Why: Supports quick, complete, and accurate incident reporting.
➤ How: Use automated tools and regular audits.
Keep an accurate and complete inventory of all assets that touch core business functions, including digital, physical, and human resources.
SECFORCE DORA incident reporting tip: Include all the details and classifications you can in your inventory. You can always narrow down your taxonomy in the future.
Also, don’t neglect people.
Log the people who manage the systems you depend on so that when an incident happens, it will be very easy to make sure actions happen and the right people know to take action
12. Classify all assets, not just data, and integrate threshold measurements
➤ What: Assign criticality levels and tracking metrics to assets.
➤ Why: Identify how asset failures impact reporting thresholds.
➤ How: Tie classifications into risk, monitoring, and reporting systems.
Threshold measurement classifications show you when a certain limit or condition will be considered to have been reached for a particular asset, i.e., when a certain percentage of failed transactions indicates that a system has stopped your suppliers.
To figure out these thresholds, you need to first determine how critical each asset is and then estimate the potential impact (to your organisation and your suppliers) of an incident involving it.
Then, you can categorise incidents according to their severity and the risk they pose.
13. Use DORA’s templates for non-critical incident reporting
➤ What: Use DORA templates as a standard tool.
➤ Why: Make DORA-compliant reporting a “normal,” everyday act.
➤ How: Build templates aligned with DORA requirements and train teams.
There are pre-existing DORA reporting templates for critical incidents.
You can find them from page 30 here.
SECFORCE DORA incident reporting tip: Why not start using these templates (or at least the 24-hour and 72-hour templates) to report a percentage of normal, non-critical or major incidents internally? This has the obvious benefit of training your team and processes to be DORA-compliant.
14. Create scenarios and perform tabletop tests at least annually
➤ What: Simulate incidents to test plans and roles.
➤ Why: Reveals weaknesses and builds response readiness.
➤ How: Run realistic exercises based on BIA and threat scenarios.
This is the ultimate DORA incident reporting tip: Test your reporting capabilities on a regular (at least annual) basis.
Once all aspects of an incident have been identified and documented using the chosen sources, each organisation should test its major incident response plan at least once a year.
By using the Business Impact Analysis (BIA) and relevant risk assessments to guide testing, you can accurately simulate incidents that would lead to a DORA incident report and improve your incident management processes.
15. Maintain up-to-date connections with relevant authorities and ESAs
➤ What: Keep regulator contacts, procedures, and requirements current.
➤ Why: Prevent delays or mistakes in critical reporting moments.
➤ How: Subscribe to updates, and verify contacts regularly.
Personal and reporting chains change.
Make it a regular (at least annual) task to check that your current connections with the relevant authorities are still up to date and accurate, e.g., do you have the right email addresses? Are those people still in the same jobs?
Need Help Preparing for DORA Incident Reporting?
Getting DORA-ready isn't just about checking a box. It’s about building processes you can trust when things go wrong.
SECFORCE helps financial entities design practical, audit-ready DORA incident reporting processes tailored to their environment.
Talk to our DORA consultants today to find out where you stand and what you need to strengthen before the deadlines hit.
Contact us now.
