Major incident, by formula: DORA’s first standards moved the call from judgment to data

The week

On January 17, 2024, the three European Supervisory Authorities (the EBA, EIOPA and ESMA) published the first batch of final draft technical standards under the Digital Operational Resilience Act. DORA had entered into force in January 2023 and would apply from January 17, 2025. The batch covered the ICT risk management framework and its simplified version for smaller entities, the policy on ICT services supporting critical or important functions, and the register of information. It also set the criteria for classifying ICT-related incidents and significant cyber threats. The classification standard set out when an incident counts as major, and therefore must be reported to the supervisor. The drafts still needed adoption by the European Commission. A second batch, including the content and timelines of incident reports, was due by mid-2024.

Much of the attention that week went to the register of information, which other articles in this series cover. The classification standard deserved as much. It replaced a judgment call with a formula. A major incident would no longer be whatever the bank’s crisis team felt was serious. It would be an incident that met defined conditions across clients, transactions, downtime, geography, data and cost. The formula has three components: a gate that decides whether an incident can be major at all, a set of counters that measure its impact, and a memory that adds up small incidents over time. Each one puts a different demand on systems that incident teams rarely own.

The gate: critical services

Under the draft standard, an incident could only be major if it affected critical services. That condition sounds simple. In practice it ties incident classification to a decision made somewhere else in the bank, usually in business continuity or third-party risk: which services support critical or important functions.

Most banks held that list in a business impact analysis, refreshed once a year, written in business language. Incident tickets, by contrast, reference applications, hosts and cloud accounts. At 2 a.m. the on-call engineer sees that a payments API gateway is failing. Whether that gateway supports a critical service is a fact that lives in a different document, maintained by a different team, and often expressed at a different level of detail.

The fix is mechanical but rarely done. The configuration management database needs a field that marks each application and shared component with the critical services it supports, sourced from the business impact analysis and reconciled when either changes. The incident tool should display it automatically. Without that link, the gate becomes a debate on the bridge call, and the debate consumes the hours that DORA’s later reporting timelines would leave no room for.

The gate also has a design consequence. Shared infrastructure, such as identity, DNS, network edge and logging, supports many services at once. If those components are not mapped, a single outage in them can be misclassified as minor because no one can say which critical service it touched.

The counters: impact thresholds

Once past the gate, the draft required a further test. An incident was major if it involved data losses or if it met two or more of the other criteria. Those criteria covered clients, financial counterparts and transactions affected; reputational impact; duration and service downtime; geographical spread across member states; and economic impact. Each had a materiality threshold. In the text the Commission later adopted, for example, the client threshold is met when more than 10 percent of a service’s clients, or more than 100,000 of them, are affected. Downtime counts when a service supporting a critical or important function is down for more than two hours.

Every one of these numbers sits in a system outside security operations. Client and transaction counts live in core banking, card processing and payments platforms. Downtime is measured by service monitoring, if the service has a defined availability target at all. Geographical spread depends on knowing which legal entities and member states a service serves. Economic impact needs finance to estimate direct costs, remediation and lost revenue while the incident is still running.

A practical design has three parts. First, pre-built queries against core systems that return affected client and transaction counts for a given service and time window, owned by the business line and tested in exercises. Second, service-level monitoring that records the start and end of downtime from the client’s point of view, not the infrastructure’s. Third, a named finance contact on the incident rota with a simple cost template. The classification then becomes a worksheet the incident manager completes from feeds, with a time stamp for each input.

The trade-off is between speed and accuracy. Early estimates will be wrong. The standard allowed for that by basing classification on what the entity knew, with later reports updated as facts emerged. Firms that waited for precise counts before classifying would be late. Firms that classified on rough counts needed a record of how each estimate was made.

The memory: recurring incidents

The third component was the least discussed and the most novel. The draft treated recurring incidents with the same apparent root cause as a single incident if, taken together, they met the major-incident criteria. Firms would have to assess recurrence on a regular cycle, not only in the moment.

This targets a familiar pattern. A batch job fails every few weeks. A third-party API times out on busy days. Each event is minor and closed within its own ticket. Together they may affect enough clients and transactions to cross the thresholds. Few incident processes looked across tickets this way, because problem management, where root causes are tracked, usually sits apart from incident response and reports to a different manager.

Meeting the requirement means that root cause becomes a structured field, not free text, so that tickets can be grouped. It also means a monthly review in which problem management sums the counters across related incidents and asks whether the total crosses a threshold. The most likely source of recurring incidents is a third-party service, so contracts need to give the bank enough incident detail from providers to assign a root cause in the first place.

Taken together, the three components shift the work. Policy documents and severity matrices were the easy part. The harder work was the data plumbing: mapping components to critical services, pre-building impact queries, and structuring root causes so that small events could be added up. Organizations with EU-regulated entities should confirm with counsel which entities and services fall in scope.

With hindsight

The Commission adopted the classification standard on March 13, 2024, as Delegated Regulation (EU) 2024/1772, published in the Official Journal that June. The adopted text kept the structure described here: critical services as the gate, data losses or two other thresholds as the test, and recurring incidents counted together, assessed monthly over a six-month window. The second batch of standards, published in July 2024, set the reporting clock, with an initial notification due within hours of classifying an incident as major. DORA applied from January 17, 2025, as scheduled. The clock made the classification step decisive, because a notification can only be timely if the decision to classify is fast. A firm with critical-service mapping and impact counts wired into its incident tools can make that decision in minutes. A firm without them has to assemble the inputs on a bridge call while the reporting clock runs.