The ICT Incident Was Just Classified as Major. What Must Reach the DORA Reporting Owner?
Build a DORA major ICT incident handoff around awareness, classification, reporting clocks, affected services and evidence ownership instead of forwarding an outage summary.
Signals to watch
- A regulated financial entity says an ICT incident has been classified as major, but the awareness and classification timestamps are not recorded together
- Customer impact, service disruption and geographic reach appear in separate operational threads while nobody owns the regulatory report
- A draft notification exists, but its competent authority, next reporting event or supporting evidence owner remains unresolved
Once an EU financial entity has classified an ICT-related incident as major, the useful handoff is not a forwarded outage summary. It is a dated record that joins four things: when the entity became aware, when and by whom the major classification was made, when the initial notification is due, and who owns each missing fact for the next report. Without those stamps, a service provider cannot tell whether the discussion needs evidence recovery, report production or ordinary incident-response support.
This matters to an ICT incident-reporting or regulatory-response provider’s business-development lead watching authorised banking, insurance, payments and incident-response Telegram groups. A line such as “major incident, regulator update needed” deserves inspection only when it points to a regulated entity, an actual classification event and an unresolved reporting job. If the lead sees it a day late, the first notification may already have been filed with placeholders and the people who know the client impact may have moved to recovery work.
Definition: the reporting event begins with the entity’s classification
The Digital Operational Resilience Act (DORA) is Regulation (EU) 2022/2554. Articles 17–20 require financial entities to manage, classify and report major ICT-related incidents. An ICT-related incident is not automatically “major” because customers are angry, a status page is red or an engineer uses a critical severity label. The regulated financial entity makes the classification using the legal criteria.
Delegated Regulation (EU) 2024/1772 supplies the detailed criteria and materiality thresholds. They cover matters such as affected clients and transactions, duration and service downtime, geographical spread, data losses, criticality of services affected and economic impact. The exact evidence depends on the event. A public message rarely contains enough to apply every threshold.
Why the distinction matters: the reporting clocks are tied to awareness and classification, not to the time the first person posted in a group. An external provider must recover the entity’s own records before promising that a notice is on time.
Start with four stamps, not four paragraphs
The handoff can fit on one page. Give each stamp a time, source and human owner.
Stamp 1 — awareness
Record when the financial entity became aware of the incident, not merely when monitoring emitted its first alert. Keep the source: incident ticket, on-call acknowledgement, service desk record or another authorised system. If several business units learned at different times, preserve the disagreement instead of choosing the earliest chat timestamp by guesswork.
Stamp 2 — major classification
Record the exact time the entity classified the incident as major, the role that approved it and the criteria then supported. A later reclassification does not erase the earlier record. The handoff should show which facts were known at classification and which arrived later.
Stamp 3 — initial-notification deadline
Implementing Regulation (EU) 2025/302 sets the standard forms and reporting time limits. The initial notification is to be submitted as early as possible, within four hours from classification as major and no later than 24 hours from awareness of the incident. The two caps must be read together.
Write the calculation openly:
Awareness: 07:40 CET. Major classification: 15:10 CET. Four-hour classification limit: 19:10 CET. Twenty-four-hour awareness limit: 07:40 CET next day. Operational initial-notification deadline: 19:10 CET, subject to the entity’s confirmed reporting route.
This is an illustrative calculation, not a real incident. It shows why “tomorrow morning” can be wrong even when the 24-hour point has not arrived.
Stamp 4 — evidence ownership
Name the people or functions that can support each required field: incident command for chronology, service operations for downtime, customer operations for affected clients, data protection or security for data impact, finance for direct and indirect cost estimates, and regulatory affairs for the competent-authority route. A name is better than “engineering”; a named role is better than an empty cell.
The next clocks change the work
The same implementing regulation requires an intermediate report within 72 hours after the initial notification, even if recovery is incomplete. A final report follows within one month after the intermediate report or, where relevant, the latest updated intermediate report. The exact form also allows information to mature across reports.
That sequence is why a provider should not spend the first call polishing prose. The first useful question is: which required fields have a source, which are estimates, and which have no owner? The intermediate report needs the incident’s development, impact and mitigation picture; the final report needs root cause, resolution and fuller impact information. A missing source today can become a repeated contradiction later.
For example, an operations channel might say:
“Payments stable again. About 40 mins. Compliance called it major around 3. Client count still with support.”
The fragment is deliberately incomplete and does not represent a customer. It suggests recovery, a rough duration, a classification event and one missing impact measure. It does not identify the regulated entity, awareness time, competent authority, affected payment services, transaction count, geographical spread, data loss, cost or report status.
The provider can ask for the classification record and current reporting receipt. It cannot announce that a legal deadline was missed or that the event meets a particular threshold based on this fragment.
Build an evidence queue for the report owner
Use one row per fact, not one row per team:
| Report fact | Current evidence | Unknown | Owner | Needed for |
|---|---|---|---|---|
| Awareness time | Incident ticket acknowledgement | Whether an earlier business alert was accepted | Incident commander | Initial notification |
| Classification | Dated classification decision | Criteria later revised | Regulatory incident owner | Initial notification |
| Affected clients | Support export in progress | Final unique-client count | Customer operations | Intermediate report |
| Service downtime | Monitoring and recovery marker | Partial degradation window | Service owner | Intermediate report |
| Root cause | Investigation open | Contributing control failure | Technical lead | Final report |
This queue is the article’s original contribution. It makes missing evidence visible without turning an unknown into a fact. It also gives the service provider a bounded commercial scope: evidence recovery, form preparation, timeline reconciliation or report-quality review.
TOP Prospect can surface and group fragments from Telegram groups a user deliberately connects and is authorised to access, keeping original text, source, time, summary, ranking reason and cross-group support for human review. It cannot classify an incident, access internal incident systems, determine the competent authority, submit a report or contact the author. The pricing page describes the discovery product. For a different DORA evidence problem, see the register-of-information remediation project; if a forwarded requirement has lost its official source, use the official-source ladder.
Key facts
- DORA Articles 17–20 cover management, classification and reporting of ICT-related incidents by financial entities.
- Delegated Regulation (EU) 2024/1772 provides the detailed classification criteria and materiality thresholds.
- Implementing Regulation (EU) 2025/302 requires the initial notification as early as possible, within four hours after major classification and no later than 24 hours after awareness.
- The intermediate report is due within 72 hours after the initial notification.
- The final report is due within one month after the intermediate report or latest updated intermediate report.
- A group message can reveal a handoff gap; it cannot establish classification, authority or compliance.
FAQ
Does every serious outage become a DORA major ICT-related incident?
No. The financial entity must classify the incident under DORA and the applicable classification criteria. Severity language in a group message does not make the legal determination.
What are the main DORA reporting clocks?
Under Implementing Regulation (EU) 2025/302, the initial notification is due as early as possible, within four hours after classification as major and no later than 24 hours after awareness; an intermediate report follows within 72 hours after the initial notification, and a final report follows within one month after the intermediate report or latest updated intermediate report.
Can the incident-response provider choose the competent authority?
No. The regulated financial entity must confirm the reporting route that applies to it. A service provider can help preserve and format evidence but should not infer the authority from the incident alone.
What is the minimum useful handoff?
Record awareness time, major-classification time and owner, the resulting initial-notification deadline, affected services and clients, the competent-authority route, evidence owners and the next report event.
The handoff is complete enough for a scoping decision when every clock has a source and every missing fact has a named owner. It does not need a finished root-cause report on day one.
Frequently asked questions
Does every serious outage become a DORA major ICT-related incident?
No. The financial entity must classify the incident under DORA and the applicable classification criteria. Severity language in a group message does not make the legal determination.
What are the main DORA reporting clocks?
Under Implementing Regulation (EU) 2025/302, the initial notification is due as early as possible, within four hours after classification as major and no later than 24 hours after awareness; an intermediate report follows within 72 hours after the initial notification, and a final report follows within one month after the intermediate report or latest updated intermediate report.
Can the incident-response provider choose the competent authority?
No. The regulated financial entity must confirm the reporting route that applies to it. A service provider can help preserve and format evidence but should not infer the authority from the incident alone.
What is the minimum useful handoff?
Record awareness time, major-classification time and owner, the resulting initial-notification deadline, affected services and clients, the competent-authority route, evidence owners and the next report event.
Sources and further reading
- Regulation (EU) 2022/2554, Articles 17–20, official text, accessed 15 August 2026
- Commission Delegated Regulation (EU) 2024/1772, classification criteria for ICT-related incidents, accessed 15 August 2026
- Commission Implementing Regulation (EU) 2025/302, standard forms, templates and reporting time limits, accessed 15 August 2026
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.