Reporting to Competent Authorities

Under DORA, a major ICT incident is reported to the firm's competent authority, meaning the supervisory authority responsible for that firm under the applicable financial services framework. The report follows the route and format set in the applicable technical standard, and it moves through the reporting phases described in the companion guide. The purpose is supervisory, which is different from telling customers or informing the board. The authority needs to understand the service effect, the response, and the cause, so it can judge the wider risk and, where needed, coordinate with other authorities.

The competent authority is determined by the firm's authorisation and sector, not by where the incident happened or which system failed. A bank, an insurer, and an investment firm may therefore report through different routes even when they suffer similar incidents, because their supervisors differ. A firm with activities in more than one sector or more than one member state needs to map its reporting routes in advance, rather than working them out during an incident. That map should name the authority for each regulated entity, the channel to use, and the person inside the firm who owns the submission. An incident is a poor time to discover that the map is out of date.

An authority needs a service centred account, not a technology diary. It needs to know which services were affected, who was affected, how long the effect lasted, what the firm did to restore the service, and what the firm believes caused the incident. It also needs to know what remains uncertain and what the firm is doing to resolve that uncertainty. That last point matters, because a report that hides uncertainty forces the authority to guess, and guessing leads to questions that a candid report would have answered. The report should be written so that a reader who knows the sector but not the firm's systems can follow it without a glossary of internal product names.

The formal report is the core of the supervisory conversation, but it is rarely the whole of it. An authority may ask follow up questions, request further information, or discuss the incident with the firm directly, and the firm should be ready for that dialogue. The log kept during the incident becomes valuable here, because it lets the firm answer follow up questions from a record rather than from memory. The firm should also expect that its report may be shared, under the arrangements DORA provides, with other authorities that have a legitimate interest, which is why accuracy and restraint both matter. A report should contain what the authority needs and no more, and it should avoid speculation that could mislead a reader who lacks the firm's context.

Ownership of the report to an authority should sit with a named role, not with a committee or a general mailbox. That person coordinates the incident log, the service owner's account of the effect, and the technical account of the cause, and checks that the three agree before submission. The role also owns the timetable, making sure each phase goes out through the right route and that corrections are sent when earlier information proves wrong. Without a named owner, reporting tends to drift, with the incident team assuming the compliance team has sent it and the compliance team assuming the incident team has drafted it. A single owner, supported by the incident team, prevents that gap.

Preparation for authority reporting is mostly unglamorous. It means keeping the route map current, keeping contact details tested, and rehearsing the first phase of a report with a realistic scenario. A rehearsal reveals practical problems that a policy cannot, such as a reporting channel that needs a login nobody holds, or a template that asks for information the incident log does not capture. It also reveals whether the firm's language for describing service effect is clear enough for an outside reader. Firms that rehearse find these problems in a calm room. Firms that do not find them during a real incident, when every minute spent on administration is a minute taken from restoration.