DORA Incident Reporting: The Evidence Behind the 4-Hour, 72-Hour, and One-Month Deadlines
The reporting cascade runs on a clock, and the evidence it asks for has to exist before the clock starts, not get assembled after. Here is what audit-grade availability data looks like, and why screenshots and chat logs do not qualify.
It is 02:40. A check against your payments API fails from Frankfurt. Thirty seconds later two more probes, one in North America and one in Asia, agree that it is down. The incident is real, and under DORA the clock is now a legal object. If this gets classified as a major incident, you owe your competent authority an initial notification within four hours, a fuller intermediate report within 72 hours, and a final report within one month.
The hard part is not writing those reports. The hard part is that each one asks for facts that had to be true, and recorded, at 02:40. You cannot go back and measure when the outage started. Either the record exists or it does not.
This is a practical guide to the availability half of that record: what the cascade asks for, why screenshots and Slack threads do not count as evidence, and what audit-grade uptime data actually looks like. It is not legal advice. Classification and the reporting process itself stay your responsibility, and you should read the regulation and its technical standards for the exact fields and thresholds.
The three deadlines
DORA has applied since January 17, 2025. For major ICT-related incidents it sets a reporting cascade:
| Report | Due | What it is |
|---|---|---|
| Initial notification | within 4 hours of classifying the incident as major | that it happened, and the basics |
| Intermediate report | within 72 hours | what you now know, with updated status |
| Final report | within one month | root cause, full timeline, remediation |
The four-hour clock is worth reading twice. It does not start when the incident starts. It starts when you classify it as major, against criteria like the number of clients affected, duration, geographic spread, and data loss. So two timestamps matter before you have written a word: when the incident began, and when you knew enough to classify it. Both are measurements, not opinions.
What the report actually asks for
Strip the forms down and the availability-related fields come back to a few blunt questions:
- When was the incident detected, and when did it actually begin?
- How long were services unavailable?
- Which services, and how many clients or transactions, were affected?
- What was the geographic spread?
- When was service restored, and how do you know?
Every one of those is a data question before it is a narrative question. “How long were services unavailable” has a correct answer to the second, and a regulator reading your final report a month later can compare it against your own status page. If the two disagree, that is a finding.
Why screenshots and chat logs are not evidence
Most teams, asked to prove an outage after the fact, reach for a screenshot of a dashboard and a scroll back through Slack. Both feel like evidence. Neither holds.
A screenshot has no verifiable provenance. It shows a number at the moment someone pressed a key, not a continuous record, and nothing in the image ties it to a clock you can trust. A chat thread is a reconstruction: it captures when people talked about the incident, not when the incident happened. Human recollection drifts, messages get edited, and the first “hey, is prod down?” usually lands minutes after the first failed request.
An auditor is not being difficult when they decline these. They are asking a fair question: where did this timestamp come from, and could it have been changed? If the answer is “someone remembered” or “someone cropped a dashboard,” you do not have a record. You have a story.
What audit-grade availability data looks like
Evidence for the availability part of a DORA report has a few properties you can check.
Timestamps from the system, not from a person
Detection and recovery times come out of the monitoring itself, recorded as they happen, not typed in afterward. A timestamp is only worth as much as the clock behind it.
Confirmation, not a single opinion
A single probe failing can mean the target is down, or that one network path is flaky. Perstat opens an incident only when a quorum of regions agrees, so the recorded start is the quorum confirmation, not the first failed check. In a report that distinction is the difference between “our service was down” and “one route to our service was briefly unhappy.”
Exclusions that are curated and visible
SLA math often involves excluded windows, announced maintenance for example. Audit-grade means those exclusions carry their real boundaries and their announcement timestamp, and an exclusion with no matching announced window is not accepted. The point is not to flatter the number. The point is that anyone can see exactly what was excluded and why.
One record, not four
The same data that feeds your SLA report feeds your status page and your incident timeline, so the public story and the audit story cannot quietly drift apart.
Here is a concrete shape, taken from Perstat’s sample SLA report for a demo service over one quarter:
- 91 days, 131,040 minutes, 1,572,480 checks across six regions.
- One confirmed incident: a check fails at 02:40:42 from eu-fra; quorum confirms at 02:41:12 when na-ewr and as-sgp agree; recovery is confirmed across regions at 02:48:24.
- The SLA window is 02:41:12 to 02:48:24, confirmation to confirmed recovery, 7 minutes 12 seconds. The 30 seconds before confirmation stay visible in the record, not silently stretched or shrunk.
- Gross availability 99.925%, and 99.994% after the one curated, announced maintenance exclusion.
You can recompute every one of those numbers. That is the test.
Working backward from the report
The useful exercise is to take a report field and ask where its answer lives before an incident, not after:
| Report needs | Evidence source |
|---|---|
| Time of detection | monitoring timestamp, recorded live |
| Time the incident began | quorum-confirmed start across regions |
| Duration of unavailability | window from confirmation to confirmed recovery |
| Was it us or a single route | multi-region confirmation |
| Planned downtime excluded correctly | announced maintenance window with real boundaries |
| Restoration confirmed | recovery agreed across regions, not one probe |
If a row has no source today, that is the gap to close before your next audit, not during your next incident.
Where a monitoring tool fits, and where it does not
Be clear about the boundary. A monitoring product does not make you DORA-ready, and no tool should claim to. Classification, the register of ICT third parties, the reporting workflow, and the legal judgment all stay with you. What a tool can do is produce the availability evidence the framework keeps asking for: real detection and recovery times, confirmed across regions, with exclusions you can defend and a record you did not have to assemble by hand at 02:40.
Perstat is built for that half of the problem. It runs HTTP, TCP, and DNS checks down to 10-second intervals from probe regions on six continents, with an EU control plane and a German company behind it. When the auditor asks how long you were down, the answer is already on the record.
You can walk the whole flow, incident timeline to exported report, in the product tour, no signup required. When you are ready, start monitoring free.