Building a third-party risk management framework for NIS2 and DORA
As a rule, you do not struggle to detect incidents. You struggle to classify them consistently.
A ransomware incident is assessed as high severity. A similar incident a few months later receives a different classification. The technology may be similar, but the decision-making process is not. That becomes a problem under the Digital Operational Resilience Act (DORA).
DORA compliance requirements go beyond incident response. Financial institutions must be able to assess ICT-related incidents, determine their severity, evaluate reporting obligations, and maintain records supporting those decisions. In practice, this is where many teams encounter difficulties: incident response procedures exist and monitoring tools are in place, but applying the same classification criteria every time — and documenting the rationale — is the hard part.
What you’ll learn:
- What DORA compliance requirements mean for ICT incident classification
- Why similar incidents often receive different severity ratings
- What factors should be considered when assessing incident impact
- How DORA approaches severity determination and reporting decisions
- Common incident classification mistakes and how to avoid them
- Questions auditors may ask about your classification process
DORA Incident Classification Matrix
A ready-to-use methodology, severity assessment framework, decision worksheet, audit evidence record, and implementation guidance.
Download the free toolkitWhat DORA requires from financial institutions
Imagine an auditor asks a simple question: why was this incident classified as high severity? Not what happened. Not how it was contained. Why was that severity level assigned? Could your team explain the decision, and would everyone give the same answer?
The Digital Operational Resilience Act requires financial institutions to assess ICT-related incidents, determine their impact, evaluate whether reporting obligations apply, and maintain records supporting those decisions. For additional context, see the official text of Regulation (EU) 2022/2554 (DORA).
The regulation does not provide a magic scoring formula or a one-size-fits-all matrix. What it does expect is a process that is consistent, documented, and defensible. Incident classification is only one part of DORA readiness. If you’re also reviewing resilience testing requirements, see our guide on DORA penetration testing (TLPT), which explains when threat-led testing applies and how organizations typically prepare for it.
What factors should be considered when assessing incident impact?
When teams disagree on incident severity, the disagreement usually starts with impact assessment. One person focuses on the affected system, another on the number of users, someone else on the financial consequences. The problem is not that any of them are wrong — it is that they are looking at different parts of the same incident.
| Assessment area | Questions to consider |
|---|---|
| Customers | Who was affected and how many customers experienced disruption? |
| Services | Were critical or customer-facing services unavailable or degraded? |
| Operations | Did business activities stop, slow down, or require manual workarounds? |
| Data | Was sensitive information exposed, altered, or at risk? |
| Financial impact | Did the incident create measurable losses or recovery costs? |
| Third parties | Were suppliers, cloud providers, or outsourced services involved? |
No single factor automatically determines severity. A short outage may affect only one system but disrupt a critical customer service. A supplier incident may originate outside your organization but still have a significant operational impact. This is why incident classification works best when teams assess incidents from multiple perspectives before making a reporting or severity decision.
How DORA approaches severity determination and reporting decisions
This is the point where many teams look for a scoring system. DORA does not provide one. Instead, organizations are expected to assess the overall impact of the incident and apply their classification criteria consistently.
| Severity indicator | Typical characteristics |
|---|---|
| Low impact | Limited disruption, minimal operational impact, few customers affected |
| Moderate impact | Noticeable service degradation, multiple teams involved, measurable recovery effort |
| High impact | Critical services disrupted, significant customer impact, major operational or financial consequences |
The important part is not the label itself — it is being able to explain how the decision was reached. If an incident is classified as high severity, teams should be able to show what impact was assessed, what evidence was reviewed, and why that classification was appropriate at the time. A simple rule of thumb: if another analyst reviews the same incident six months later, they should be able to understand how the classification and reporting decisions were made without reconstructing the investigation from scratch.
Looking for a practical classification framework?
The DORA Incident Classification Matrix gives you a ready-to-use methodology, severity assessment framework, decision worksheet, and audit documentation templates.
Download the toolkitCommon incident classification mistakes
Most classification mistakes do not happen because teams ignore the process. They happen because people are making decisions with limited information and under time pressure. Here are the issues we see most often:
- Focusing on technical severity instead of business impact. A sophisticated attack does not automatically mean high business impact — and a relatively simple incident can significantly disrupt customers, services, or operations.
- Classifying incidents too early. The first few hours of an investigation rarely provide the full picture. Initial classifications should be reviewed as new information becomes available.
- Applying different criteria across teams. Security, IT operations, risk, and compliance may look at the same incident through different lenses. Without shared assessment criteria, consistency becomes difficult.
- Failing to document the rationale. “We discussed it and agreed” is rarely enough during an audit. Record what was assessed, what evidence was reviewed, and why a particular severity level was assigned.
- Overlooking third-party impact. Supplier incidents, cloud outages, and outsourced service disruptions are easy to underestimate. The incident may originate outside your organization while still affecting customers, services, or regulatory obligations.
DORA compliance checklist: 10 questions to ask before an audit
Auditors and internal reviewers are rarely interested in whether an incident occurred. They want to understand how decisions were made. Before your next audit or supervisory review, consider the following:
- Can you demonstrate a documented incident classification process?
- Are severity criteria applied consistently across teams?
- Are classification decisions reviewed when new information becomes available?
- Can you explain why previous incidents received their classifications?
- Is the impact assessment documented for each incident?
- Are customer, operational, financial, and third-party impacts considered during assessments?
- Are reporting obligations evaluated using documented criteria?
- Can you demonstrate why a reporting decision was made or not made?
- Is the classification rationale recorded for every significant incident?
- Can supporting evidence be located quickly during an audit or review?
Need an independent review of your incident classification process?
Q-Sec works with financial institutions to assess incident response procedures, classification practices, reporting workflows, and operational resilience requirements under DORA.
Talk to a Q-Sec expertFAQ
What are the DORA compliance requirements for incident classification?
DORA requires financial institutions to assess ICT-related incidents, determine their severity, evaluate reporting obligations, and maintain documentation supporting those decisions.
Does DORA provide a classification matrix?
No. DORA defines expectations and reporting requirements but does not prescribe a single classification matrix. Organizations are expected to establish their own documented and consistent assessment process.
What is a major ICT incident under DORA?
A major ICT incident is an event that significantly affects customers, critical services, business operations, or financial stability and may trigger regulatory reporting obligations.
What should be included in an ICT incident classification process?
A classification process should define assessment criteria, severity levels, reporting considerations, documentation requirements, ownership, and evidence retention practices.
How can organizations prepare for DORA audits?
Start with documented procedures, consistent classification criteria, recorded decision rationale, and accessible supporting evidence. Auditors typically want to understand how classification and reporting decisions were made.
Tags:
