OperationalResilience.help
The Continuity Desk - important services, kept running
Home / Line 06 - Incident management and reporting / Guide

Classifying an Incident by Impact

How to judge an ICT incident by its impact on services and customers, rather than by the size of the technical fault, and how to keep that judgement consistent.

Published 26 October 2026Checked against the regulation text on 26 October 2026European Union (financial entities in scope of DORA)

The short answer

Classifying by impact means judging an incident by what it did to services and to the people who use them, not by how complicated the fault was to fix. The incident team asks which services degraded or stopped, who could not use them, what those people could not do, and whether any workaround existed. The answers are then weighed against the classification criteria in the applicable standard. This approach keeps classification honest, because a technically simple fault with a wide service effect is treated seriously, while a technically complex fault with no service effect is not inflated.

How does an impact assessment begin?

An impact assessment begins with the service map, not with the fault log. The team identifies the service that customers or counterparties were trying to use, then traces how far the disruption spread through it. That trace may show that only one channel was affected, or that every channel failed at once, and the difference matters greatly. It may also show that the service itself kept running while a supporting function, such as client onboarding or statement production, stopped. In that case the impact is real but different in kind, and the classification should reflect that difference. Starting from the service also brings the service owner into the room early, which is where the knowledge of customer effect usually lives.

Which dimensions of impact should be considered?

Impact has more than one dimension, and a good assessment looks at several of them before deciding. One dimension is breadth, meaning how many clients, counterparties, or transactions were touched. Another is depth, meaning how completely the service stopped rather than slowed. A third is duration, meaning how long the effect lasted or is expected to last. A fourth is substitutability, meaning whether customers had another way to get the same outcome, such as a different channel or a manual process. A fifth is knock on effect, meaning whether the disruption spread to other services, other firms, or a market function. No dimension alone tells the whole story. A short, total outage of a core service can matter more than a long, partial degradation of a peripheral one, and the assessment should say why.

Do workarounds reduce the impact?

Workarounds change the customer experience, and so they change the impact, but they do not erase it. If customers can complete the same transaction through another channel with little delay, the harm is smaller than if they are left with no route at all. If the workaround is slow, confusing, or only available to some customers, the harm remains substantial, and the assessment should say so plainly. The same applies to partial recovery. A service that returns for some users but not others is still disrupted for the remainder, and the classification should reflect the position of those still affected rather than celebrating the partial return. Honesty about workarounds also helps the later report, because an authority will ask what customers actually experienced, not what the firm hoped they experienced.

How can different teams judge impact consistently?

Consistency comes from shared language and shared examples, not from a longer form. Teams judge impact more alike when they use the same service definitions, the same way of describing breadth and depth, and the same set of worked examples drawn from past incidents. A short guide with a few anonymised cases, showing why one incident was judged major and another was not, teaches more than a detailed scoring scheme that nobody remembers under pressure. Consistency also improves when classifications are reviewed together after incidents, so teams can see where their judgements diverged and agree on the reason. Over time, that review builds a common sense of what serious impact looks like for each service.

How should the impact judgement be recorded?

The record of an impact judgement should be short, timed, and specific. It should name the services affected, the groups affected, the nature of the effect, and the workaround position, in plain words that a reader who was not in the room can follow. It should also note what was unknown at the time, so a later reader does not mistake an early estimate for a final figure. As the incident develops, the record should be updated rather than rewritten, so the changing picture stays visible. That layered record is what turns a judgement made under pressure into evidence that can be examined later, and it is what allows the firm to learn whether its impact criteria are calibrated or drifting.

Primary sources on the record

Legal status: Regulation (EU) 2022/2554 in force; applies from 17 January 2025, with technical standards applying on the dates stated in each standard. Application position for this topic: Applies from 17 January 2025. Technical standards apply on their own stated dates.

Follow the service map

Line 06 - Incident management and reporting ICT Incident Classification and Reporting A plain guide to how DORA incident classification and reporting works: restoring the service, deciding what counts as major, and keeping a record that stands up later. Line 06 - Incident management and reporting Incident Reporting Phases Under DORA The phases of DORA incident reporting explained in order: what each phase is for, what it should contain, and how later phases correct or complete earlier ones. Line 06 - Incident management and reporting Reporting to Competent Authorities Who competent authorities are in DORA incident reporting, how a firm finds the right route, and what a report to an authority should and should not contain.