ICT Incident Classification and Reporting

Under DORA, incident management has two jobs at the same time. One is to restore the affected service as safely and quickly as the situation allows. The other is to keep a record that can be reported, examined, and learned from. Classification sits between those jobs. It decides whether an incident is major, which authority should be told, and in which phase of reporting the incident belongs. That decision is taken while the incident is running, not written up afterwards as paperwork. A report that is accurate about the failed technology but silent about the service, what stopped, for whom, and for how long, has missed the point.

Reporting without classification would treat every disruption alike, and that would help nobody. A brief glitch in an internal tool and a prolonged outage of a customer payment service are different events, even if the same kind of component failed in both. Classification sorts them by their effect on the service, so the response, the urgency, and the reporting route match the harm rather than the noise. It also protects the incident team from a common trap, which is to spend the first part of an incident arguing about labels while customers wait. A firm that has agreed its criteria in advance can apply them under pressure and revisit them later if the facts change. That early sorting is what makes the later report coherent, because each phase of the report then builds on a decision that was recorded at the time.

Restoration and record keeping can pull in opposite directions during a live incident. The people fixing the service want to act, try, and retry, while the record needs times, decisions, and reasons. DORA treats both as part of the same job, and the tension is managed by separating roles rather than by choosing one aim over the other. One group works the fault, another keeps the log, and a named decision maker bridges the two. The log is not a transcript of every keystroke. It is a timed account of what stopped, what was tried, what was decided, and who decided it. When the service returns, that account becomes the backbone of the report, and when the same fault recurs, it becomes the starting point for learning. A team that restores well but records poorly will struggle to explain itself later, however good the recovery felt at the time.

A useful report starts from the customer or counterparty experience, then works back to the technology. It names the service that stopped or degraded, the people affected, and the period involved, before it describes servers, networks, or code. That order matters because an authority reading the report needs to understand the consequence first and the cause second. It also matters inside the firm, because a service description forces a check that a purely technical description skips. If nobody can say which service was affected, the incident may have been handled as a technical fault when it was really a service outage. The report should also be honest about uncertainty. Early phases may describe what is known and what is still being checked, and later phases can correct or complete that picture without pretending the early account was final.

The recurring mistake is to treat classification as a form to complete once the incident is over. By then, the facts that mattered most, the moment the service degraded, the first signs that it was spreading, and the reasons for each escalation, are hard to reconstruct. Another mistake is to let the technology owner classify alone, without the service owner who understands the customer effect. A third is to write the report for an internal audience and forget that an authority, a board member, or a customer will read it with different questions in mind. Each of these mistakes has the same root, which is that incident work was organised around systems rather than services. Keeping the service at the centre, from the first alert to the final lesson, avoids most of them.

This pillar sets out the whole picture, and the supporting guides take one piece at a time. The guide on what counts as major explains the threshold idea, the guide on impact explains how to judge effect, and the guides on phases and authorities explain where reports go and in what order. Later guides cover logs, communication, third party causes, minor incidents, learning, severity, teams, timelines, and reporting to more than one authority. Read together, they describe a single process, from the first alert through restoration, reporting, and review. A firm can use them to check whether its own process covers each step, and to find the gaps where a step exists on paper but has no owner, no criterion, and no record.