DORA incident reporting: from regulatory requirement to operational workflow

Incident reporting is a decision process, not a form-filling event

DORA brings ICT-related incident management and regulatory reporting into one governed operating problem. Article 17 requires financial entities to define, establish and implement an ICT-related incident management process. Articles 18 and 19 then connect classification to the decision to report a major ICT-related incident. The practical challenge is therefore not merely completing a template. Teams must establish what happened, when awareness began, which services and clients were affected, whether classification thresholds are met, who approved the conclusion and what information changed between the initial, intermediate and final reports.

A workable process should preserve those facts as a sequence. If the operational incident record, the classification worksheet and the regulatory submission live in unrelated files, reviewers are forced to reconstruct the decision under time pressure. A connected workflow keeps one incident identity while allowing the regulatory assessment, submission versions and human approvals to remain distinct records. That distinction matters: changing an impact estimate should update the reporting assessment without rewriting the original detection event or erasing the rationale used at an earlier stage.

Start with awareness, scope and a controlled incident record

The first operational control is a reliable point of entry. An incident may arrive from monitoring, a service desk, a third-party provider, a business team or a security process. The initial record should identify the source, detection time, awareness time, affected service, current owner and known impact. Awareness is especially important because regulatory time limits can depend on when the entity became aware of the incident, while classification may occur later. Store both values, including later corrections, rather than allowing one timestamp to overwrite the other.

• Create one stable incident identifier and retain the original source of notification.
• Record awareness, detection, escalation and classification timestamps separately.
• Link affected business services, ICT assets, providers and critical or important functions.
• Assign an operational owner and a separate authority for the regulatory reporting decision.
• Version material impact estimates instead of replacing earlier values without history.

Translate classification criteria into reviewable questions

Commission Delegated Regulation (EU) 2024/1772 specifies classification criteria and materiality thresholds for ICT-related incidents. An operating workflow should present the criteria as structured questions supported by current facts, not as a single unexplained major-or-not toggle. The assessment can bring together clients and financial counterparts affected, duration and service downtime, geographical spread, data losses, critical services affected and economic impact. Some facts may be unknown early in the response, so the model needs explicit unknown and pending-verification states rather than encouraging assumptions.

Classification should be repeatable as facts change. Each reassessment needs a timestamp, input values, resulting threshold evaluation and named reviewer. When an incident crosses a threshold after the initial response, the history should show when the new information became available and when the major-incident classification was recorded. This supports the reporting timeline and avoids a misleading final record that makes the classification appear obvious from the beginning.

Create a reporting clock that follows the decision

Commission Delegated Regulation (EU) 2025/301 specifies the content and time limits for the initial notification, intermediate report and final report. It provides that the initial notification is due as early as possible and, in any case, within four hours after classification as major and no later than 24 hours after awareness. The intermediate report is generally due within 72 hours of the initial notification, and the final report no later than one month after the intermediate or latest updated intermediate report. The regulation includes qualifications and specific provisions that teams must check against their circumstances.

A reporting clock should therefore be generated from controlled dates and the applicable rule, with the calculation visible to the reviewer. It should warn, escalate and record completion without silently deciding whether an exception applies. If a deadline cannot be met, the same workflow should capture the notification to the competent authority and the explanation for delay. Calendar reminders alone are not enough because they rarely preserve the calculation inputs, applicable exception, decision owner and submission receipt together.

Build one submission record with three controlled stages

Commission Implementing Regulation (EU) 2025/302 provides the standard forms, templates and procedures for reporting. Operationally, a useful approach is to maintain one regulatory reporting case linked to the incident, with separate initial, intermediate and final report versions. Common incident facts can be reused, but every submitted stage should be frozen with its submission time, approver, delivery channel and acknowledgement. Later corrections then become a new version rather than an invisible edit to what was already sent.

1. Initial notification: confirm the major classification, minimum available facts, reporting authority and approval.
2. Intermediate report: refresh impact, containment, recovery and other required information, including unchanged-status reporting where applicable.
3. Final report: complete root-cause, resolution, cost and recurrence information required by the applicable standard.
4. Closure review: reconcile submissions, incident actions, lessons learned and any remaining remediation.

Keep human authority visible

Automation can calculate elapsed time, identify missing fields and bring connected service or provider records into view. It should not make an unreviewed regulatory conclusion operational. A named person should approve the classification result and each report, with the authority to request more evidence, record uncertainty or reject a prepared submission. The audit trail should distinguish machine-generated suggestions, operational updates and human decisions. This makes accountability visible without pretending that a workflow engine can replace professional judgement.

An illustrative NeoGRC record path

Consider illustrative incident INC-204, affecting payment service SVC-017 and third-party provider TPR-006. A classification review CLS-204-03 evaluates current impact facts against the configured DORA criteria. The reviewer records a major-incident decision DEC-118, which opens reporting case RPT-041. Initial submission SUB-041-A is approved and retained with its receipt; intermediate submission SUB-041-B reuses verified facts but adds recovery status; final submission SUB-041-C links root-cause analysis RCA-019 and remediation action ACT-243. These identifiers are representative product data, not customer records.

The value of that path is not the number of linked objects. It is the ability to answer practical questions without reconstructing the history: which source requirement governed the decision, which facts were available, who classified the incident, when each deadline was calculated, what was sent, what changed and which actions remain open. That is the evidence a controlled incident-reporting workflow should produce as a natural consequence of doing the work.

Govern the workflow as regulatory material changes

The workflow itself needs ownership and version control. Classification criteria, report fields, competent-authority routes, calendars and approval roles should be treated as governed configuration with an effective date and change history. When an official source changes, the team can compare the new requirement with the active configuration, identify affected forms and rules, test the proposed version and require approval before deployment. Historical incidents should continue to display the configuration used at the time, rather than being reinterpreted silently through today’s settings.

Exercises should test the complete chain under realistic uncertainty. A tabletop that ends when an incident is classified misses report preparation, approval, submission, receipt, updated reporting and closure. Include late-arriving facts, unavailable decision-makers, third-party dependencies and a classification that changes. The outcome should be owned improvements to process, data, roles and configuration—not only meeting notes. Regular review is also needed when services, authorities or the entity’s regulatory scope changes.