When a major ICT incident occurs at your organisation, DORA's Article 19 starts a clock you cannot stop. Twenty-four hours to submit an initial notification to your competent authority. Seventy-two hours to deliver a detailed interim report. One month to file a comprehensive final account. The organisations that will meet these deadlines are not the ones who respond fastest in the moment — they are the ones who built the evidence pipeline before the incident happened.
What Article 19 Actually Requires
DORA Article 19 applies to "major ICT-related incidents" as classified under Article 18. The classification thresholds are specific: incidents that cause significant operational disruption, affect a large number of clients or counterparts, involve data loss with potential for serious consequences, or trigger reputational damage that could undermine market confidence. Critically, any incident involving the compromise of privileged credentials or unauthorised access to critical systems is almost certainly a major incident under this framework.
The reporting cascade is three-stage. The initial notification — due within 24 hours of classification — must include a description of the incident, its impact, and initial containment measures taken. The interim report at 72 hours requires a detailed root cause analysis, the systems and data affected, and the remediation actions underway. The final report at one month must document the full timeline, permanent corrective measures, and lessons learned. Each report builds on the previous — you cannot produce the interim report without the evidence gathered for the initial notification.
One nuance that catches organisations unprepared: the 24-hour clock runs from the moment you classify the incident as major, not from the moment the incident began. Your classification process therefore becomes a legal exposure point. Delay classification to buy time, and regulators will treat that delay as a reporting failure. Your internal escalation criteria, classification decision authority, and timestamp discipline are all regulatory artefacts, not internal housekeeping.
Why Identity Events Are the Critical Evidence Layer
Every ICT incident investigated by a financial regulator traces through the identity layer. Which account initiated the anomalous activity? When did privilege escalation occur? Which systems were accessed between the initial compromise and containment? What authentication events preceded the breach? These are not optional context — they are the evidentiary foundation of every Article 19 report.
Privileged access logs, authentication event records, credential change histories, and session audit trails are what distinguishes a compliant incident report from a vague summary. Regulators under DORA have explicit authority to request raw evidence — not just the narrative account. If your identity events are not captured, timestamped, and retrievable within hours, your reporting obligation becomes impossible to meet accurately.
Under DORA Article 18, an incident involving unauthorised access to systems holding critical financial data, or the compromise of privileged credentials with the potential for systemic impact, must be classified as major. The classification decision must be documented with a timestamp — that timestamp starts the Article 19 reporting clock. Late classification is treated by regulators as a reporting failure, not a mitigation.
The Evidence Pipeline You Must Build
The evidence pipeline for Article 19 compliance has three layers. The first is capture: every authentication event, privilege use, credential change, and access grant or revocation must be logged with a tamper-evident timestamp. This means your SIEM or log aggregation platform must ingest events from your IdP, PAM solution, Active Directory, and cloud identity providers in real time — gaps in ingestion are gaps in your evidence chain.
The second layer is integrity. Log evidence submitted to regulators must demonstrate it has not been altered after the fact. Immutable log storage — whether through write-once object storage, log signing, or a dedicated SIEM with cryptographic integrity guarantees — is the technical control that makes your evidence admissible. Logs stored in mutable systems can be challenged; signed, immutable logs cannot.
The third layer is retrievability. During an incident, you need to extract a coherent timeline of identity events for a specific time window within hours, not days. If your logs are technically captured but practically inaccessible — scattered across systems, requiring manual correlation, or gated behind search interfaces that cannot handle the query load of an incident investigation — they will not be available when the 24-hour clock demands them. Retrieval time is a technical requirement, not a best-effort aspiration.
Building for the 24-Hour Clock
The organisations that meet the 24-hour deadline have done three things before the incident occurs. First, they have documented classification criteria — a written decision framework that specifies exactly which indicators trigger a major incident classification, who has authority to make that call, and how the decision is recorded. Remove ambiguity from the classification step and you remove the delay.
Second, they have pre-built report templates for each of the three DORA reporting stages. A blank template produced under pressure at 3am will miss fields; a pre-populated template with your organisation's standard information, awaiting only incident-specific data, will not. Third, they have rehearsed the process. A tabletop exercise that runs the classification-to-notification workflow — including extracting identity event evidence from your SIEM against the clock — will reveal gaps in your pipeline before a regulator does. The exercise is not optional if you want confidence in your actual capability.
The Cost of Getting It Wrong
DORA penalties for reporting failures are not discretionary warnings. Competent authorities under DORA have the power to impose fines of up to 1% of average daily worldwide turnover for each day of non-compliance, with no statutory cap on duration. For a mid-size financial institution with €500M annual turnover, a two-week reporting failure could reach €1M in fines before the incident is even resolved.
Enforcement precedents from 2025 have established that regulators will not accept "we did not have the logs" as a mitigating explanation — it is treated as a separate control failure compounding the original incident. Supervisory authorities have also made clear that organisations without demonstrable incident classification procedures face elevated scrutiny across their entire ICT risk management framework, not just the reporting obligation in isolation. The message is unambiguous: the evidence pipeline is infrastructure investment that must be in place, tested, and demonstrably operational before the first incident occurs.