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

The week

On January 17, 2024, Europe’s three financial watchdogs, known together as the European Supervisory Authorities, published the first batch of final draft technical standards under the Digital Operational Resilience Act, or DORA. The three are the European Banking Authority (EBA), the insurance and pensions authority (EIOPA) and the securities and markets authority (ESMA). DORA is the EU law that makes banks, insurers, investment firms and other financial companies prove they can withstand, respond to and recover from technology disruption. It had entered into force in January 2023 and would apply from January 17, 2025, which gave firms a year to get ready once the detailed rules were known.

The reach of the law explains why the standards mattered so widely. DORA’s scope article lists twenty kinds of financial entity. Credit institutions, payment and e-money institutions, investment firms and crypto-asset service providers are on it. So are central securities depositories, central counterparties, trading venues, insurers and reinsurers, larger insurance intermediaries, occupational pension funds, fund managers, credit rating agencies and crowdfunding platforms. One set of incident rules would now cover a retail bank in Lisbon, a clearing house in Frankfurt and a pension fund in Rotterdam.

“Technical standards” are the detailed rulebook that sits beneath a law. The law says what must be achieved; the standards say exactly how, down to definitions and thresholds. DORA itself, adopted in December 2022, already named the criteria for judging an incident: clients and transactions affected, duration and downtime, geographical spread, data losses, the criticality of the services hit, and economic impact. It left the supervisors to say how each criterion should be measured and where the line falls.

The process behind the January texts was long and public. The supervisors had consulted on drafts from June 19 to September 11, 2023, and said they received more than 420 responses. They reported changes aimed at simplification, greater proportionality and sector-specific concerns. The final drafts then went to the European Commission, which would adopt them as binding regulations if it agreed.

This first batch covered four broad areas. It set out the ICT risk management framework (ICT simply means information and communication technology: the systems, networks and software a firm runs on), along with a simplified version for smaller entities. It covered the policy on ICT services that support critical or important functions, meaning the parts of the business whose failure would genuinely hurt customers or markets. It defined the register of information, a structured list of a firm’s technology suppliers and contracts. And it set the criteria for classifying ICT-related incidents and significant cyber threats.

The other three texts were linked to the fourth more closely than they looked. The supervisors said the register of information would be used to supervise compliance and to designate the critical technology providers that DORA would bring under direct EU oversight. The risk management standards required firms to know their assets and the functions they support. And the third-party policy standard asked firms to identify which providers support critical or important functions. Each of those inventories is also an input to incident classification.

That last item drew the most consequential line. The classification standard set out when an incident counts as “major,” and therefore must be reported to the supervisor: the line between a problem a bank handles internally and one it must disclose to the authorities. It also defined when a cyber threat is “significant,” which mattered for the voluntary threat notifications DORA allows. And it set out when a major incident at one firm is relevant to supervisors in other member states, and what they should share with each other.

The routing of reports had already been fixed in the law. A firm reports to its national competent authority. For the largest banks, the ones directly supervised by the European Central Bank, the national authority passes the report straight to the ECB. DORA’s incident chapter also extended to payment-related incidents at banks, payment institutions and e-money institutions, which had previously reported serious payment incidents under the EU payments directive. And DORA was written as the specialist law for finance alongside the EU’s general cybersecurity directive, NIS2, so financial firms would follow DORA’s incident rules first.

In a bank’s crisis room in the small hours, card payments are failing, the phones are lighting up, and someone has to decide whether this is a bad night or a reportable event that the regulator must hear about. For years in Europe, that call was largely a matter of judgment. In the week of January 15, 2024, it started to become a matter of arithmetic.

The texts were not yet final law. The drafts still needed adoption by the European Commission. A second batch of standards, including the content and timelines of incident reports, had gone out for consultation in December 2023 and was due by mid-2024. But the shape of the rule was now visible, and it changed what a crisis room would need to have at its fingertips.

Much of the attention that week went to the register of information, the supplier inventory. 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.

That sounds like a compliance detail. In practice it changed how a bank runs a bad night. A judgment can be made by experienced people in a room. A formula can only be completed by people who have the numbers. And the numbers the formula asks for mostly live in systems that the incident team does not own.

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 sections below first set out where the legal line falls and why Europe chose a formula. They then take the three components in turn, make the business case for the data work, describe how to build and test it, and close on what it all adds up to.

Incidents, severity scales and the legal line

An “ICT incident” is any unplanned event that disrupts a firm’s technology or the services built on it. It could be a cyberattack, but far more often it is something mundane: a software update that goes wrong, a failed data center link, a supplier’s outage, a batch job that never finishes. A large bank has a steady stream of these. Nearly all are minor and are fixed by technical teams without anyone outside IT noticing.

“Classification” is the act of sorting those incidents by seriousness. Most organizations already do this with a severity scale, often numbered one to four, where severity one means all hands on deck. What DORA added was a legal line on top of that internal scale. Cross it, and the incident becomes “major,” with reporting duties to the supervisor and, under the later standards, a clock that starts ticking.

Where that line falls matters, because reporting a major incident brings more than paperwork. It invites supervisory attention, may lead to follow-up questions about the firm’s resilience, and becomes part of the regulator’s view of how well the firm is run. Under-reporting is a compliance failure. Over-reporting wastes scarce crisis time and erodes credibility. Getting the classification right, quickly, is a matter of regulatory standing and reputation as much as of technology.

Hospital triage offers a fair comparison. Emergency department nurses do not decide who is most urgent by gut feeling alone; they use defined vital signs, such as heart rate, blood pressure and oxygen levels, gathered by instruments. DORA asked banks to triage technology incidents in the same way. The catch is that the instruments have to be connected before the patient arrives.

Why Europe chose a formula

The case for a formula is comparability. Before DORA, a firm’s incident obligations depended on which national authority supervised it, which sector it was in and which regime applied. Payment incidents had one set of guidelines. The largest banks reported cyber incidents to the ECB under its own arrangements. Insurers and asset managers faced a patchwork of national expectations. A supervisor trying to see whether a cloud outage had hit ten firms or a hundred could not add up reports built on different definitions.

A common formula fixes that. If every financial entity in the EU applies the same thresholds, a report from a Dutch insurer and a report from an Italian bank mean the same thing. Supervisors can then aggregate them, spot a shared supplier behind several incidents, and alert other authorities. DORA requires the supervisors to publish an anonymized annual report on major incidents, and that report is only meaningful if the inputs are consistent.

The case against, and why it mostly fails

The strongest objection is that formulas are brittle. An experienced incident commander can tell that a small outage is the first sign of something serious, long before any counter crosses a threshold. A formula can also invite gaming: a team under pressure can be tempted to read the numbers in a way that keeps an incident just under the line.

Both concerns are real, and the standard answers them only in part. It keeps room for judgment in several places. Reputational impact turns on whether an incident has drawn media attention or repeated complaints. The “relevant clients” test asks the firm to decide in advance which clients and counterparts matter most to its business or to market efficiency. And nothing stops a firm from reporting voluntarily, or from treating an incident as serious internally while the counters catch up.

Gaming is better handled by evidence than by discretion. A formula leaves a trail. If every input to a classification decision is recorded with its source and time, a supervisor can later reconstruct whether the firm read its own numbers honestly. A pure judgment call leaves much less to examine. The formula therefore shifts the risk from a bad call to a bad record, and records are something a firm can build ahead of time.

The gate: critical services

Under the standard, an incident could only be major if it affected critical services. That condition sounds simple. In practice it ties incident classification to decisions made somewhere else in the bank, usually in business continuity, third-party risk and compliance.

The adopted text gives the gate three routes, and any one of them is enough. An incident passes if it affects ICT services or systems that support critical or important functions. It passes if it affects financial services that require authorization or registration, or that supervisors oversee. And it passes if it is a successful, malicious and unauthorized access to the firm’s systems. Each route draws on a different list held by a different team.

Route one: the critical or important functions list

Most banks held their list of critical or important functions in a business impact analysis, refreshed once a year, written in business language. A business impact analysis is a document that asks, for each business activity, “what happens if this stops, and how quickly does it hurt?” It speaks of things like “retail payments” or “mortgage servicing.” Incident tickets, by contrast, reference applications, hosts and cloud accounts: the technical names of specific software and servers.

At 2 a.m. the on-call engineer sees that a payments API gateway is failing. (An API, or application programming interface, is the interface through which one piece of software asks another for something; a gateway manages the traffic through those interfaces.) 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, or CMDB, 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. A CMDB is the organization’s master inventory of technology, listing every system and how they connect. The incident tool should display the critical-service tag automatically. Without that link, the gate becomes a debate on the bridge call, the emergency conference line where responders gather. That debate consumes hours that DORA’s later reporting timelines would leave no room for.

Route two: the licensed services list

The second route is wider than many firms first assumed. Almost everything a bank sells to customers is an authorized or supervised financial service. That means the gate filters out mainly internal systems, such as human resources tools or internal analytics that support no regulated activity. For most customer-facing outages, the gate will be passed.

The list that matters here belongs to legal and compliance: the scope of each entity’s license. In a group with several licensed entities, the same platform may serve a bank, a payment institution and an investment firm. The incident tool therefore needs to know which legal entities and which licensed services each component supports. Without that, a group cannot say which entity must report, or to which authority.

Route three: confirmed intrusions

The third route means a confirmed malicious intrusion passes the gate on its own. That changes the hand-off between the security operations center and the incident process. When analysts confirm that an attacker got in, the classification clock is effectively in play, even if no customer has noticed anything.

Many security teams treat containment and forensics as their own track, separate from service incident management. Under DORA the two have to meet early. A confirmed intrusion needs to be logged in the same incident record that drives classification, with the time of confirmation captured. Otherwise the firm may later find it classified an intrusion hours after the security team knew about it.

Shared infrastructure

The gate also has a design consequence. Shared infrastructure, such as identity, DNS, network edge and logging, supports many services at once. Identity systems check who is allowed in; DNS is the internet’s address book, translating names into locations; the network edge is where the bank meets the outside world; logging records what happened. 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. Ironically, the most foundational systems are the easiest to miss, because they belong to everyone and therefore to no one in particular.

A practical rule helps. Any component that supports more than one critical service should be tagged with all of them, and treated as critical in its own right. That makes the map larger, but it removes the most dangerous blind spot.

The counters: impact thresholds

Once past the gate, the standard required a further test. An incident was major if it involved a successful, malicious and unauthorized access to the firm’s systems that could lead to data losses. It was also major if it met two or more of the other materiality thresholds. Those covered clients, financial counterparts and transactions affected; reputational impact; duration and service downtime; geographical spread across member states; data losses more broadly; and economic impact. Each threshold is a number or condition above which that criterion counts as met.

The figures in the text the Commission adopted are specific. The client threshold is met when more than 10 percent of a service’s clients, or more than 100,000 of them, are affected. It is also met when more than 30 percent of the financial counterparts using a service are affected, or more than 10 percent of a service’s average daily transactions, by number or by value. Duration counts above 24 hours. Downtime counts when a service supporting a critical or important function is down for more than two hours. Geographical spread counts when two or more member states are hit. Economic impact counts once costs and losses exceed, or are likely to exceed, 100,000 euros.

Every one of these numbers is held in a system outside security operations. Client and transaction counts live in core banking, card processing and payments platforms. A core banking system is the central ledger that holds accounts and balances and records every deposit, withdrawal and transfer. 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.

Not all counters are equally hard

The thresholds bite differently depending on the size and shape of the firm. For a large cross-border group, two of them are close to automatic. A serious outage at a group that operates in several member states will usually hit more than one country. And once overtime, consultants, supplier fees and customer redress are added up, 100,000 euros is not a high bar for a large bank. For such a group, almost any significant incident on a critical service is likely to be major.

A small national firm faces a different arithmetic. Geographical spread rarely applies, and costs may stay under the line. Its incidents turn on the relative tests: 10 percent of a service’s clients or transactions, or two hours of downtime. That makes good baseline data more important for small firms, because they must know what a normal day looks like to say what share of it was lost.

Sector matters too. A card issuer or payment institution has transaction counts by the second. An insurer or a fund manager has far fewer real-time transactions, so its incidents more often turn on downtime, data and cost. A central counterparty or trading venue serves a small number of large counterparts, so the 30 percent counterpart test can be met by a single outage of a member-facing system. Each firm should work out in advance which two thresholds are most likely to trigger for each critical service, and make sure the data for those two is the most reliable.

Measuring time and cost the way the rule does

The standard is precise about clocks. Duration runs from when the incident occurred until it is resolved. If the start cannot be determined, it runs from detection. If the firm later finds evidence in logs that it began earlier, the clock moves back to the logged start. Downtime runs from when a service becomes fully or partially unavailable to users until normal service is restored. If a backlog of delayed transactions remains, downtime runs until that delayed work is completed.

Those rules have operational consequences. Monitoring must record the start of partial degradation, such as slow logins or a share of failed payments, and not wait for a total outage. Batch backlogs must be tracked to completion. And the incident record should hold three separate timestamps: occurrence, detection and classification. Supervisors will look at the gaps between them.

Cost is defined just as carefully. The economic test counts gross costs and losses, without subtracting insurance or other recoveries. It includes funds lost, replacement of hardware or software, staff overtime and extra hires, contractual penalties, customer redress, forgone revenue, communications and advisers. It excludes ordinary maintenance, improvements made after the incident and insurance premiums. A finance contact who knows these categories can produce a defensible estimate in an hour. One who does not will produce a number that has to be redone.

A practical design

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. A query is simply a saved question to a database, such as a count of customers whose card payments failed between 1 a.m. and 3 a.m. Writing and testing it in calm conditions means nobody has to improvise it in a crisis. Second, service-level monitoring that records the start and end of downtime from the client’s point of view, not the infrastructure’s. A server can be technically “up” while customers still cannot log in; what counts is the customer’s experience. 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.

Two more inputs round out the worksheet. Reputational impact needs a feed from the contact center and complaints teams, and from whoever watches media and social channels. The standard treats repeated complaints from different clients, or coverage in the media, as enough on their own. And the “relevant clients” test needs a short list, agreed in advance, of clients and counterparts whose disruption is material by itself. A major corporate client or a market infrastructure might be on it.

The trade-off is between speed and accuracy. Early estimates will be wrong. The standard allowed for that: where actual counts cannot be determined, firms may estimate them from comparable reference periods, such as the same hour on a normal day. 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.

One outage, two nights

Take a mid-sized lender operating in several EU countries. One evening its mobile app stops processing transfers. The engineer on call sees errors on a payments API gateway. The night can go two ways.

In the unprepared version, the engineer escalates to a duty manager, who convenes a bridge call. Someone asks whether payments count as critical; the business continuity lead is asleep and the list is in a document nobody on the call can find. Someone else asks how many customers are affected; the payments team can find out, but needs to write a new database query first. Finance is not on the call. Ninety minutes later the team is still debating whether this is “major,” and the incident itself has barely been diagnosed.

In the prepared version, the incident tool shows that the gateway is tagged to the retail payments critical service. The gate is passed in seconds. The payments team runs its standard query and reports affected clients and failed transactions by country. Monitoring shows when customers first saw failures. A finance contact fills in a rough cost estimate. The incident manager completes the worksheet, records the time and source of each input, and makes the call. The engineers, meanwhile, have been left alone to fix the problem.

The outage, the people and the law are the same in both. The difference lies entirely in what was wired up beforehand.

The memory: recurring incidents

The third component was the least discussed and the most novel. The standard treated recurring incidents with the same apparent root cause as a single incident if, taken together, they met the major-incident criteria. In the adopted text, that applies when the incidents occurred at least twice within six months. Firms must assess recurrence monthly as well as in the moment. Microenterprises and firms under the simplified regime are excused from this part.

This targets a familiar pattern. A batch job fails every few weeks. (A batch job is a scheduled task that processes a large pile of work in one go, often overnight, such as posting interest or settling the day’s card transactions.) 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. Incident management is about restoring service fast; problem management is about finding and fixing the underlying cause so it does not happen again. The two disciplines speak different rhythms, one measured in minutes, the other in weeks.

Meeting the requirement means that root cause becomes a structured field, not free text, so that tickets can be grouped. If one engineer writes “vendor API slow” and another writes “timeout at payment processor,” no computer will spot that they are the same problem. A drop-down list of agreed causes, tied to the component in the CMDB, makes the pattern visible. 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.

Choosing the grain of a root cause

The hardest design choice is granularity. If root-cause categories are too broad, such as “software defect” or “third party,” unrelated incidents get grouped and the monthly sum crosses thresholds that no single cause deserves. If categories are too narrow, every incident gets a unique cause and recurrence never shows. A workable grain combines the component from the CMDB with a short list of failure modes, such as capacity, configuration change, expired certificate, dependency failure or data error.

Adding up is less obvious than it sounds. Two outages of the same service may affect largely the same customers, so a simple sum overstates the number of distinct clients hit. Downtime is easier, since minutes can be added. The standard asks whether incidents “collectively” meet the criteria without spelling out every counting rule. A firm should choose a method, write it down, apply it consistently, and be ready to explain it to its supervisor.

What the monthly review produces

The monthly review should leave an artifact an examiner can read: the list of root-cause groups with two or more incidents in the past six months, the summed counters for each, the comparison against each threshold, and the decision. Most months the answer will be that nothing crosses the line. The record of having asked is the evidence. When a group does cross, the review should trigger the major-incident report. It should also push the root cause up the remediation queue, since a cause that recurs enough to become reportable is one the business has paid for repeatedly.

Suppliers matter most here. DORA requires contracts with technology providers to include assistance during incidents related to their service, either at no additional cost or at a cost set in advance. Banks negotiating or renewing contracts in 2024 had a reason to make that assistance concrete: incident start and end times, affected components, and the provider’s root-cause finding, delivered fast enough to feed classification.

Data a well-run bank wants anyway

The figures a bank must gather to classify an incident are the figures its own crisis team needs to run one.

Knowing which customers are affected lets the bank tell them, quickly and accurately, which protects trust and reduces complaint volumes. Knowing the cost while the incident runs helps leaders decide whether to pay for emergency supplier support or invoke a fallback. Knowing which critical service is touched tells the communications team what to say to the press. Spotting recurring problems early prevents a string of small embarrassments from becoming a headline.

DORA itself makes some of these uses mandatory. When a major incident affects the financial interests of clients, the firm must inform those clients without undue delay. The law also requires that major incidents be reported to senior management and the management body, with an explanation of impact, response and the further controls needed. Both duties draw on the same numbers as classification. A firm that can count affected clients for the regulator can also tell the board, and the clients, who was hurt.

There is also a money question in how the work is funded. The changes described here are not large technology programs. They are modest: a new field in an inventory, a handful of tested queries, a name on a rota, a monthly meeting. Their cost is mostly coordination across teams that do not normally plan together, which is precisely why they tend not to get done without leadership attention.

Where the cost argument is weaker

For smaller firms, the economics look different. A small payment institution or fund manager may run most of its technology through a handful of providers and have no CMDB worth the name. For such a firm, building internal impact queries may be less practical than requiring its providers to supply the counts. DORA’s proportionality principle and the simplified framework for some smaller entities recognize this. The obligation to classify still applies, but the means of feeding it can be lighter. A mapped list of services, a provider contract that delivers impact data, and a worksheet that is filled in and kept may be enough.

Large groups face the opposite problem. Their data exists, but in dozens of systems across several countries, owned by teams that report to different executives. Their cost is integration and governance, and the risk is that the classification logic is rebuilt separately in each entity. A single group-wide worksheet, applied entity by entity, avoids inconsistent answers to the same outage.

Plumbing before policy

Good preparation has a recognizable shape. Every critical service is mapped to the applications and shared components that support it, and the mapping is checked whenever either list changes. The incident tool shows the mapping without anyone having to look it up. Impact queries exist for each critical service, have named business owners, and have been run in an exercise. Finance has a cost template and a person on call. Root causes are recorded from a controlled list, and someone sums related incidents every month. Supplier contracts require enough incident detail to support all of this.

Owners and sequence

Each input needs one owner. Business continuity owns the list of critical or important functions. Compliance owns the list of licensed services and the relationship with the supervisor. Technology owns the CMDB mapping and the monitoring. Each business line owns its impact queries. Finance owns the cost template. Third-party risk owns the supplier clauses. The incident manager owns the classification decision itself, using all of the above.

The order of work follows the dependencies. The service lists come first, because nothing else can be mapped without them. Mapping comes next, starting with the components that support the most critical services. Impact queries and monitoring follow, service by service. Cost templates and the recurrence review can run in parallel. Contract changes take longest, since they wait for renewal dates, so they should start early even though they finish last.

Keep two scales, not one

One tempting shortcut is to rewrite the internal severity scale so that severity one simply means “major under DORA.” That merges two different questions. The internal scale answers how many people to wake and how fast to restore service. The regulatory classification answers whether to tell the supervisor. An internal security incident with no customer impact may need maximum response and still not be major. A slow-burning outage of a minor service in several countries may cross the legal line without ever feeling urgent. A better design keeps the operational scale and adds the regulatory classification as a separate field, calculated from the worksheet and reviewed at set points during the incident.

So do the failures:

• Policy without plumbing. A beautifully written severity matrix that nobody can complete in the middle of the night because the inputs do not exist.
• Mapping only the obvious. Customer-facing applications get tagged; shared infrastructure such as identity, DNS and logging does not, so the biggest outages are the hardest to classify.
• Waiting for certainty. Teams hold off classifying until counts are precise, and miss the window. Rough, documented estimates are better than perfect late ones.
• Free-text root causes. Every ticket describes the cause differently, so recurrence is invisible.
• Silent suppliers. A provider’s outage hits the bank, but the contract gives no right to the detail needed to classify or group it.
• An annual business impact analysis that never meets the CMDB. Two lists describing the same estate in different words, drifting apart every month.
• Security on a separate track. A confirmed intrusion is handled by the security team for hours before anyone opens the incident record that drives classification.

Evidence a supervisor will ask for

When supervisors review incident handling, they tend to ask for documents more than for explanations. Firms should expect requests for the classification methodology, the mapping of services to systems, records of exercises, and, for each reported incident, the worksheet with its inputs and timestamps. For incidents that were not reported, they may ask how the firm decided they fell below the line. The recurrence reviews, month by month, round out the file. Each of these artifacts is cheap to produce if it is a by-product of the process and expensive to reconstruct afterward.

How a board can test the plumbing

A board member or executive does not need to understand the systems in detail to test readiness. These questions tend to reveal quickly whether the plumbing exists:

1. If our main payments service failed tonight, how long would it take to confirm that it supports a critical or important function? Who would confirm it, and where would they look?
2. Are shared systems such as identity, DNS and logging mapped to the critical services they support?
3. For each critical service, do we have a tested query that tells us how many clients and transactions are affected in a given time window? When was it last run in an exercise?
4. Is root cause a structured field in our incident records? Who adds up related minor incidents each month, and what did the last review find?
5. Do our key supplier contracts give us the incident detail we need to classify and group their outages?

Three smaller checks follow from them: whether downtime is measured from the customer’s side or the server’s, whether finance has someone on the rota with a cost template, and whether each rough estimate is recorded with how it was made.

Measures that show progress

Boards also benefit from a few numbers tracked over time. The most telling is time to classify: the minutes between detection and a recorded classification decision, measured in exercises and in real incidents. Others follow from the design. One is the share of critical services with a tested impact query. Another is the share of shared components mapped to the services they support. A third is the share of incidents closed with a structured root cause. A fourth is whether each monthly recurrence review happened on schedule. Each can be measured without new tooling, and each points to a specific owner when it slips.

An exercise is the best test of all. A tabletop in which the incident team must classify a realistic outage against a running clock, with business, finance and compliance on the call, shows within an hour whether the inputs arrive. The most useful exercises use a shared component, such as identity or DNS, and a supplier-caused failure, because those are where the gaps hide.

From severity matrix to data plumbing

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. Incident classification has become a data problem that crosses business continuity, technology, the business lines, finance and procurement, and no single one of those teams can solve it alone.

The shift also changes how groups with operations outside the EU should think about their incident processes. American banking rules took a different route. Since 2022, US banking organizations have had to notify their federal regulator within 36 hours of a computer-security incident that has materially disrupted, or is reasonably likely to materially disrupt, their operations. Federally insured credit unions have had a 72-hour notification rule since September 2023. Public companies, from December 2023, must disclose material cybersecurity incidents on Form 8-K within four business days of deciding they are material. All three turn on judgment about materiality or disruption, not on a fixed formula.

A group subject to both kinds of regime does not need two incident processes. It needs one set of inputs, gathered fast and recorded well, feeding several legal tests. The European formula is the most demanding of these tests on data. A group that can satisfy it will usually have what it needs to make, and defend, the judgment calls the American rules require. Organizations with EU-regulated entities should confirm with counsel which entities and services fall in scope.

With hindsight

The rule landed much as drafted. The Commission adopted the classification standard on March 13, 2024, as Delegated Regulation (EU) 2024/1772, published in the Official Journal that June. A delegated regulation is a binding piece of EU law that fills in the detail of a parent law, so the draft had now become an obligation rather than a proposal.

The adopted text kept the structure described here. Critical services remained the gate, reachable through critical functions, supervised services or a malicious intrusion. A successful malicious intrusion that could lead to data losses, or meeting two other thresholds, remained the test. The thresholds were concrete: 10 percent or 100,000 clients, two hours of downtime for critical services, two or more member states, and 100,000 euros in costs, among others. Recurring incidents were still counted together, assessed monthly over a six-month window. Anyone who had started building the plumbing in early 2024 had not wasted their effort.

Then came the clock. The second batch of standards, published in July 2024, set the reporting timetable. The Commission adopted the reporting standard that October, and it was published in February 2025 as Delegated Regulation (EU) 2025/301. An initial notification is due within four hours of classifying an incident as major, and no later than 24 hours after the firm becomes aware of it. An intermediate report follows within 72 hours of the initial notification, and a final report within a month of the last intermediate one. DORA applied from January 17, 2025, as scheduled.

The details of the timetable rewarded the prepared. If a firm classifies an incident as major only after the 24-hour mark, it still has four hours from classification to notify. That softens the outer limit, but it also means a supervisor can see exactly how long classification took. The reporting standard also allows reports that fall due on a weekend or bank holiday to be filed by noon on the next working day. That relief does not apply to initial notifications and intermediate reports from credit institutions, central counterparties, trading venues and firms that count as essential or important entities under NIS2. Banks got no weekend grace on the first two reports.

The clock made the classification step decisive, because a notification can only be timely if the decision to classify is fast. Four hours sounds generous until you remember that it starts only once the firm has made the call, and the outer limit of 24 hours runs from the moment it knew something was wrong. A firm that dithers over classification eats into that outer window.

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.

Events in the meantime showed why shared components mattered. On July 19, 2024, a faulty update from the security vendor CrowdStrike crashed Windows machines around the world, disrupting banks, airlines, hospitals and broadcasters at once. DORA did not yet apply, but the outage was the kind of event the gate and counters were built for: one supplier, one cause, many services and many countries. Firms that had mapped endpoint software to the services it supported could say quickly which services were hit. Others spent the day finding out.

The supplier side of DORA also moved. The registers of information were collected by supervisors in 2025, and the ESAs began designating critical ICT third-party providers for direct EU oversight that year, with the list to be published and updated annually. Both rested on the same kind of data discipline as incident classification: knowing which provider supports which service.

The pattern reaches beyond Europe and beyond banking. Regulators increasingly define serious incidents by measurable impact rather than by how worried the firm felt. Under NIS2, an implementing regulation adopted in October 2024 set impact thresholds for when incidents at cloud, data center, managed service and other digital providers count as significant. Wherever that happens, the advantage goes to organizations that can answer basic questions about who was affected, for how long and at what cost, while the problem is still unfolding. That capability is built in uneventful months, through unglamorous work on inventories, queries and rotas, and it cannot be bought on the night.