Asset Management | Handling ICT incidents under DORA: a response plan for asset managers

Under DORA, an ICT incident at an asset manager is no longer solely an IT matter. It requires a coordinated response also involving legal, compliance, senior management and Finanstilsynet. We have written before on measures asset managers can take to prevent ICT incidents in the first place (i.e. here). However, some incidents cannot be prevented, as the European Supervisory Authorities (ESAs) have just concluded in their first annual report on major ICT-related incidents under DORA. When an incident does occur, the response must be swift.

This newsletter turns to the practical side of handling an ICT incident: what constitutes an ICT incident, when it must be reported, and how to prepare a structured response plan that keeps a firm compliant and prepared.

ICT-related incidents in 2025

The ESAs’ first annual report on major ICT incidents under DORA records 3,383 incidents across the EU in 2025. Three points stand out for asset managers:

Asset managers are in scope: most of the 3,383 incidents involved credit, payments and insurance firms, but close to 100 were attributed to asset managers.
Third-party providers are the key exposure: close to a third of all major incidents started with a provider.
Low harm so far, but rising risk: most incidents caused little harm, with no or only minor client disruption and roughly half costing nothing material. The threat level is still assessed as high and rising (see our recent newsletter on the 2026 Risk and Vulnerability Report here).

What is a “major incident”?

DORA defines an ICT-related incident as a single unplanned event, or a series of linked events, that compromises your network and information systems. It must adversely affect the availability, authenticity, integrity or confidentiality of data, or any payment-related services you provide. Major incidents will need to be reported to Finanstilsynet.

An incident is major only if it clears both steps of the test as laid out in DORA delegated regulation, which we have summarized for you in the below:

Step 1

Did the incident affect critical or important services?

If it has not, the incident is not major.

Step 2

Does the incident involve a successful, malicious and unauthorised access that could cause data loss, or does it meet at least two of the materiality thresholds below?

Clients, financial counterparts and transactions affected	met where the incident affects more than 10% of clients using the service, more than 100,000 clients, more than 30% of financial counterparts, or more than 10% of the daily average number or value of transactions.
Reputational impact	met where any of the client or counterpart thresholds above is reached.
Duration and service downtime	met where the incident lasts more than 24 hours, or downtime of ICT services supporting critical or important functions exceeds 2 hours.
Geographical spread	met where the incident has an impact in two or more EU Member States.
Data losses	any adverse impact on availability, authenticity, integrity or confidentiality of data affecting your business objectives or regulatory compliance, including any successful malicious unauthorised access.
Economic impact	met where actual or estimated costs and losses exceed EUR 100,000.

According to the ESAs’ report, duration and downtime, and clients and transactions affected, were the two materiality threshold criteria that most often tipped incidents over the line in 2025.

How to prepare?

Map your critical or important functions. Criticality cannot be judged under pressure if it has not been mapped in calm conditions. In most cases, this is already covered by the “register of information” (ROI) as reported to supervisory authorities. In Norway, Finanstilsynet has just required the first round of annual ROI reports.
Put in place an incident response plan. Involve the relevant functions and ensure they are familiar with the plan. Rehearse it against a realistic scenario.
Keep the documentation at hand. Should an incident occur, matters move quickly, so keep the response plan and relevant contacts at hand, as well as the incident reporting templates.
Review ICT third-party service provider contracts. Ensure they incorporate mandatory DORA clauses, such as incident support obligations and performance standards. Consider whether it is appropriate and proportionate to send comments to the service provider, and in any event document your assessment.
Document your assessments. Record the reasoning behind each classification and assessment as you make it, so that these evaluations are sufficiently documented to withstand any post-event scrutiny by Finanstilsynet.

Response plan

Handling an ICT incident effectively means moving through a set sequence under time pressure, and that sequence has to be designed in calm conditions, not in the midst of an incident.

We have prepared a template DORA response plan for asset managers that runs from the first sign of an incident through to the final report. In outline, it works through the following stages:

Detect and log the incident as soon as you become aware of it.
Contain, respond and recover, activating your business continuity arrangements where they are needed.
Escalate internally and brief senior management and the management body.
Classify the incident against DORA’s two-step test for a major incident.
Report to Finanstilsynet on the initial, intermediate and final deadlines.
Notify affected clients where their financial interests are at stake.
Reassess and, where the picture changes, reclassify, including where reporting is outsourced.

The DORA reporting deadlines

Once an incident is classified as major, three deadlines run in sequence, measured from classification (initial) and from each preceding report (intermediate, final).

Deadline	Report	Details
Within 4 hours	Initial notification	Within 4 hours of classifying the incident as major, and no later than 24 hours after you became aware of it.
Within 72 hours	Intermediate report	Within 72 hours of the initial notification, with fuller detail on impact and status.
Within 1 month	Final report	Within one month of the last intermediate report, once root-cause analysis is complete.

If a minor incident later crosses a threshold, reclassify it as major and the four-hour clock starts at that point, not retrospectively from detection. If in doubt, escalate to Compliance and the management body and treat as major until proven otherwise.

BAHR comments

Asset managers are less exposed than credit, payments or insurance firms. But the ESA report confirms that major ICT incidents reach them too. Under DORA, the focus is no longer only on preventing incidents, but on being ready for the ones you cannot prevent. When one occurs, everything runs to a strict timetable, so the work should be done in advance rather than on the day itself.

Close to a third of major incidents originated with a third-party provider, and asset managers outsource more than most. That underlines the importance of maintaining the register of information (in any case, this is to be reported to Finanstilsynet annually and upon request) and the review of your ICT service provider contracts, beginning with the providers behind your critical or important functions. Such reviews can be AI-supported, so they need not place a significant burden on time or budget.