What Counts as a Major ICT Incident

A major ICT incident under DORA is an incident whose effect on the firm, its services, or its customers crosses the classification criteria set in the applicable technical standard. The test is about consequence, not about how dramatic the technical failure looked. A small fault that stops a widely used service can be major, while a large fault in a contained system that affects nobody outside the firm may not be. Classification therefore asks what stopped, for whom, and how seriously, and it records the answer while the incident is still running so the reporting route follows from it.

The criteria in the applicable standard look at several kinds of effect together, rather than relying on a single measure. Duration matters, because a brief interruption and a prolonged outage are different experiences for customers. The number and type of clients or transactions affected matters, because it shows the breadth of the harm. The nature of the service matters too, since an outage in a payment service or a trading service carries different consequences from an outage in an internal reporting tool. Reputational and financial effect can also form part of the picture, where the standard provides for them. No single factor decides the matter on its own. A firm weighs them together, and where the picture is mixed, it should record why the balance fell one way rather than the other.

Borderline cases are where classification discipline matters most. An incident that starts small can grow, and an incident that looks severe at first can turn out to be contained. The classification should therefore be treated as a live judgement, revisited as facts change, with each revision timed and reasoned in the log. A firm that classifies once and never revisits the decision risks reporting too little, or reporting an incident as major when later facts show it was not. Neither error is comfortable, but the second is easier to explain than the first, because an authority can see that the firm acted on the information it had and corrected the record. The discipline is not to get every borderline call right in hindsight, but to show that each call was reasoned, recorded, and reviewed.

Technology fails in many ways, and the same failure can have very different consequences depending on where it lands. A database error in a back office system that staff can work around is a different event from the same error in a customer facing service with no workaround. Classification that starts from the component will miss that distinction, and it will also miss the question an authority will ask first, which is what happened to the service. Starting from the service forces the incident team to find out who was affected, what they could not do, and whether an alternative channel existed. Those answers, rather than the name of the failed component, are what make an incident major.

The evidence for a classification decision does not need to be elaborate, but it does need to exist. A short entry that names the criteria considered, the facts known at the time, and the person who decided is usually enough, provided it is written during the incident rather than reconstructed later. Where a criterion depends on numbers, such as clients affected or transactions delayed, the log should show the source of the figure and any uncertainty around it. Where a criterion depends on judgement, such as the seriousness of the service effect, the log should show the reasoning in plain words. That record protects the firm in two ways. It lets a later reviewer follow the decision, and it lets the firm itself learn whether its criteria are working or need adjustment.

A change of classification is not a failure, and it should not be hidden. Incidents evolve, and a firm that updates its view when new facts arrive is doing the job properly. What matters is that the change is visible, with the earlier view preserved and the new view explained. The reporting route may change as a result, and the firm should follow the route that matches the current classification rather than the route it started with. Over time, a pattern of changes in one direction can also teach the firm something about its own criteria. If incidents are repeatedly upgraded late, the early assessment may be too optimistic, and if they are repeatedly downgraded, it may be too cautious. Either pattern is worth a review.