DORA: how to classify an ICT incident step by step

Under DORA, I need to classify an ICT incident without delay, based on facts, and then check whether it reaches the major-incident threshold. In practice, I look at six criteria: affected customers and transactions, duration, reach within the EU, impact on data, effect on a critical or important function, and cost.

If I want to avoid a vague decision, I keep it simple:

• I collect evidence as soon as the incident is detected
• I compare every data point with my internal thresholds
• I include SaaS and third parties in the analysis
• I record the decision with the date, time, and decision-maker's name

In other words: no instinctive opinions. I start with measurements, such as 2 hours 15 minutes of unavailability, 2 EU countries affected, or an estimated loss of €80,000. Then I record, criterion by criterion, whether I am above, below, or uncertain.

Here is the key point at a glance:

Point to decide	What I check
Customer impact	Number of affected customers and transaction volume
Downtime	Time between detection and full recovery
EU reach	Number of Member States concerned
Data	Availability, integrity, confidentiality, and authenticity
Affected service	Link to a critical or important function
Cost	Direct and indirect losses and SLA clauses
Dependencies	SaaS, ICT providers, and tools outside the inventory

The simplest approach is to treat classification as a regulatory decision, with a timestamped file, evidence, assumptions, and any areas that remain uncertain.

The Digital Operational Resilience Act (DORA) - ICT-related incident management and reporting

Step 1: assess each DORA classification criterion

Measure every criterion and retain the evidence that supports it. These elements are used to decide how the incident should be classified. This is not just a technical checkpoint.

Customers, transactions, duration, and geographical reach

Start by quantifying the number of affected customers, as well as the volume or value of disrupted transactions. To support this, use transaction logs, the CRM, and support tickets.

Duration is measured from the detection of the incident to the full restoration of the service. Then compare this period with your internal unavailability thresholds. For geographical reach, identify how many EU Member States experienced a service interruption. Regional status reports and network traffic logs can be used to verify this.

Impact on data, critical services, and business consequences

Assess four data-related dimensions: availability, integrity, confidentiality, and authenticity. If personal data is involved, also record any risk of a personal-data breach.

Then check whether the incident concerns a critical or important function and measure its direct effect on the business. The simplest approach is to cross-reference the asset register with the business impact analysis, or BIA, to confirm the impact under the applicable rules.

Economic impact and direct or indirect costs

For the economic impact, clearly separate direct, indirect, and contractual costs. This point looks simple on paper, but in practice it is often where incident files become unclear.

Cost type	Concrete examples	Evidence source
Direct costs	Lost revenue, remediation costs	Invoices, timesheets
Contractual penalties	Triggered SLA clauses	Contracts, SLA penalty clauses
Indirect costs	Lost productivity, delayed billing, commercial impact	Financial reporting, business indicators

These measurements can then be compared with your internal DORA thresholds.

Step 2: apply a practical classification workflow

Collect the minimum evidence as soon as the incident is detected

As soon as an incident is identified, collect the information needed for classification. The simplest approach is one structured form for each DORA criterion.

The form should include: a timestamp in the format DD/MM/YYYY HH:MM (Paris time, estimated or confirmed), identifier, reporter, affected systems, whether a critical or important function is affected, SaaS and third parties involved, affected customers and transactions, countries concerned, impact on data - availability, integrity, confidentiality, and authenticity - as well as an initial financial range in euros, for example “< €10,000”, “€10,000-€100,000”, or “> €100,000”.

Each field directly supports a DORA materiality criterion.

These data points can then be compared with the internal thresholds.

Compare observed metrics with internal DORA thresholds

Once the form is complete, compare each metric with your internal threshold matrix aligned with the DORA RTS. The reference internal thresholds are: more than 10% of daily transactions or more than 100,000 customers affected, unavailability of more than 2 hours for services supporting a critical or important function, a geographical impact covering at least two EU Member States, and direct and indirect losses likely to exceed €100,000. [1][7]

DORA criterion	Observed metric	Internal threshold	Status
Affected customers	8,200 customers	≥ 10% of the base or ≥ 100,000	Uncertain
Duration of unavailability	2 hours 15 minutes	> 2 hours for services supporting a critical or important function	Above
Geographical reach	France, Germany	≥ 2 EU Member States	Above
Economic impact	~€80,000 (initial estimate)	> €100,000	Uncertain
Critical services affected	Not confirmed	Critical or important function affected	Uncertain

For each criterion, assign a simple, clear status:

• above the threshold
• below the threshold
• uncertain (if the data is still being collected)

Also record who performed the assessment and at what time.

From this point on, the classification decision is no longer vague. It becomes concrete, almost mechanical.

Decide the level and trigger escalation

The decision belongs to the incident manager, with the SOC, business, and compliance teams involved according to your governance model. [2][4][5][6] The incident is major if the major-incident thresholds are reached, or if several criteria point in the same direction. Otherwise, it remains minor or significant, depending on your internal thresholds. [8][3][7]

If new evidence changes whether a threshold has been crossed, reclassify without delay. Record the time and the decision-maker's name each time.

The analysis must then account for SaaS dependencies in the overall impact.

Step 3: include SaaS dependencies and document the decision

Map SaaS and third-party dependencies in the impact analysis

Once the DORA criteria have been quantified, check whether a SaaS application or provider increased the actual impact. Classification must not stop at the service visible on the surface. It must also account for the dependencies that keep it running: SaaS, IAM, collaboration tools, payment, support, and outsourced monitoring. If one of these links fails, customer-side workflows, reporting, or operations may deteriorate, even if the incident initially appears limited. [10]

Shadow IT adds another blind spot. An application absent from the catalogue may still support a very real business process. Its absence from the inventory does not change the impact in the field. In other words, the assessment must start from what actually happened, not simply from the application's registration status. [9][11][12]

For every SaaS service involved, ask four simple questions:

• What failed?
• Which processes stopped or degraded?
• Which other services depend on it?
• What evidence shows the actual business impact?

Also add a point of context: is the service internal, outsourced, or integrated into a third-party chain? And what exactly is its role: critical, supporting, or non-critical service?

Use Avanoo to improve SaaS visibility in DORA classification

When dependency mapping is reliable, the decision is often faster. Avanoo helps identify unrecorded usage, map SaaS dependencies, and connect affected data flows to the incident, including when some tools do not appear in the official inventory.

Build a clear classification file with comparison tables

The classification decision must be written, structured, and defensible in an audit. In plain terms, it needs to leave a clear record, not a collection of scattered notes. The file should include an incident summary, a timestamped timeline, affected functions, a criterion-by-criterion assessment, evidence sources, assumptions, remaining areas of uncertainty, and the final decision with its reasoning. Also state who decided, who approved, and at what time. [13]

You can formalise all of this in an evidence table.

Table 1 - observed metrics and evidence

DORA criterion	Observed value	Internal threshold	Evidence source	Assessment
Duration of unavailability	to be completed	Internal threshold for a critical service	System logs	-
Affected customers	to be completed	Internal threshold for affected customers	SSO / IdP logs	-
Geographical reach	to be completed	Impact across several EU Member States	Regional server logs	-
Impact on data	to be completed	Integrity or confidentiality affected	DLP alerts	-
SaaS service criticality	to be completed	Critical or important function	Asset register / BIA	-
Economic impact	to be completed	Internal euro threshold	Initial financial estimate	-

Table 2 - internal level and escalation

Internal severity level	Required escalation
Low	Technical team
Medium	IT manager / CISO
High / Major	Crisis team + management

Conclusion: a simple method for consistent DORA classification

Classifying an ICT incident under DORA requires a decision supported by measurable facts. Each criterion must be examined separately, with evidence to support it.

The same logic applies to SaaS dependencies and third-party providers. If a SaaS or third-party service supports a business process or critical service, it must be included in the impact analysis. In short, if you do not have a clear view of these dependencies, your classification may start from the wrong assumptions.

In practice, the method rests on four simple actions.

Key points to remember

• Collect evidence early, as soon as the incident is detected
• Test each DORA criterion against your internal thresholds
• Include SaaS and third-party providers in the impact analysis
• Formalise the decision in a timestamped file

This framework helps produce a consistent, traceable, and defensible decision. It also puts IT, security, compliance, finance, and procurement on the same page.

FAQs

::: faq

When is an ICT incident major under DORA?

Under DORA, an ICT incident is classified as major if it exceeds at least two criteria. These may include the number of affected customers, the duration of the outage, geographical reach, data loss, service criticality, or economic impact.

It can also be classified as major in two other specific cases. First, if there is unauthorised malicious access to critical systems. Second, if recurring minor incidents linked to the same cause occur at least twice within a six-month period. :::

::: faq

How do you classify an incident when data is incomplete?

With incomplete information, classify the DORA incident cautiously, but without delay. As soon as it is detected, appoint a team to take charge and start the analysis immediately. The key point is simple: the initial four-hour notification deadline starts when the incident is classified as major.

To move forward in the right conditions, rely on:

• standardised reporting templates;
• a map of critical dependencies.

If some criteria are not yet settled, document every action taken and update the classification as soon as more precise data becomes available. :::

::: faq

Why include SaaS and Shadow IT in the analysis?

Including SaaS and Shadow IT is essential for DORA compliance. Why? Because they are often the source of the largest blind spots in the information system.

Without an overall view, it becomes difficult to keep the ICT provider register up to date and, as a result, assess supply-chain risks.

The problem is straightforward: an unlisted tool can create security weaknesses, poorly governed data processing, and much more complicated incident management. When an incident has to be notified, every unclear area becomes a constraint.

Detecting and documenting these tools makes it possible to map each critical service more accurately. You are no longer working blindly. You are using concrete data to support digital resilience. :::