Incident reporting deadlines

A manager's dashboard that gathers every outstanding regulatory notification deadline across your incidents into one countdown list.

When a security incident may also be a reportable event under law, the clock starts at detection. NIS2 (a European cybersecurity law) expects an early warning within 24 hours, a fuller notification within 72 hours and a final report within a month. GDPR (the European data-protection law) expects a personal-data breach to reach the supervisory authority within 72 hours. DORA (the European rules for financial-sector operational resilience) adds initial, intermediate and final reports for major ICT incidents. The Incident Reporting Dashboard at /incidents/reporting collects those obligations and counts each one down.

This screen tracks. It does not log incidents and it sends no notifications: you record the incident, decide whether it is significant and mark a notification as sent on the incident itself — see Incidents. Here you watch all of those clocks at once and step into whichever one needs attention.

Which reporting duties apply

Three European laws can put a legal clock on a security incident. Each applies to a different kind of event, and each has its own deadlines. Aegis works out the deadlines from the detection time you record on the incident, so enter Detected as accurately as you can — it is the moment your organisation became aware.

Law When it applies Deadlines How Aegis supports it
GDPR, Article 33 The incident is a personal-data breach: you set the data-breach flag on the incident. Notify the data protection authority within 72 hours. A GDPR deadline on the incident, an Article 33 draft for the authority of your country, and Record GDPR Notification to stamp when you notified.
NIS2, Article 23 Your organisation is an essential or important entity under NIS2 and the incident is significant: you mark it significant in the significance assessment. Early warning within 24 hours; incident notification within 72 hours (24 hours for a trust service provider whose trust services are affected); final report no later than one month after the incident notification. If the incident is still ongoing then, a progress report first and the final report within a month of handling it. The staged NIS2 deadlines on the incident, a draft for each stage, the national authority of each jurisdiction you report in, and the NIS2 Incident Notification workflow template.
DORA, Article 19 Your organisation is a financial entity under DORA and the incident is a major ICT-related incident. Initial notification, intermediate report and final report, on the deadlines that follow from the DORA classification. A DORA card on the incident naming the competent authority for your entity type, with the deadline of each report. See DORA.

One incident can trigger more than one law: a ransomware attack that exposes customer data at a hospital is a GDPR breach and, once judged significant, a NIS2 incident as well. Each duty then runs its own clock.

Aegis never notifies an authority for you

Aegis prepares drafts and counts the deadlines down. It never sends anything to an authority. You file the notification yourself — through the authority's own portal — and then record in Aegis that you filed it, with the reference the authority gave you. Whether an incident is reportable is always a decision for your organisation; the AI assessment is advice only.

Tell Aegis where you report

The authority, the national law and some deadlines depend on the country your organisation reports in and, in some countries, on your sector. Aegis does not assume a country. An Admin sets it once under Settings → Organization.

  1. Open Settings and select the Organization tab. The Jurisdiction & NIS2 Classification card loads with your stored values.
  2. Choose your EU Member State and your NIS2 Entity Type (Essential Entity, Important Entity or Not Applicable).
  3. Choose your NIS2 sector and, where it has them, your NIS2 subsector. The sector decides the sectoral duties Aegis shows on incidents, such as Z-CERT and the IGJ for Dutch healthcare.
  4. Under Incident-reporting jurisdictions, add every other member state your incidents are reported in. If Germany is one of them, choose the German Land of your establishment: the German data protection authority is the one of that Land.
  5. Fill in the Data Protection Officer card. The DPO is the contact point a GDPR notification must name; without one, the draft marks that field as missing.
  6. Select Save Organization Settings. The Resolved incident-reporting authorities list on the same tab shows, per country, which authority receives each kind of report.

Authorities and deadlines are modelled for Belgium, the Netherlands, Luxembourg, France and Germany. Another member state is saved but shown as not modelled: Aegis then shows no authority or deadline for it, and you determine them yourself. France has not yet transposed NIS2, so no French NIS2 deadline is computed. An incident without any configured country asks you to choose a Jurisdiction for this incident before it shows authorities.

Flag a significant incident

  1. Open the incident and select Assess Significance in the AI Analysis panel. The NIS2 Significance Assessment wizard opens.
  2. Read Automatic Checks: severity, the data-breach flag, affected systems and a high-risk incident type. If your organisation is an entity type bound by Implementing Regulation (EU) 2024/2690, the wizard also lists that Regulation's criteria; tick every one the incident meets or can meet — one is enough.
  3. Run the AI assessment for a second opinion, or select Skip to Decision.
  4. Choose Mark as Significant or Not Significant, write the justification, and tick the trust-services box if the incident affects trust services you provide. Select Confirm.

Marking an incident significant starts the NIS2 deadlines and shows the NIS2 Significant Incident — Reporting Required alert with its stages. You can reopen the assessment later with Review Significance Decision to revise or withdraw the decision. Record whether you will report at all under Reporting Decision, so an auditor can see who decided and why.

Work the deadlines on the incident

The Regulatory Notifications section of the incident holds one card per duty and per country: GDPR Art. 33 — Personal data breach notification, NIS2 Art. 23 — Significant incident report and DORA Art. 19 — Major ICT-related incident report. Each card names the authority, links its primary sources and shows every stage with Due … or Overdue by ….

  1. Select Generate draft on the stage that is due. Aegis fills in what the law asks for from the incident and your organisation profile; review it and complete the fields marked as missing.
  2. File the report through the authority's portal.
  3. Select Mark as filed and enter the reference number the authority assigned. The stage then reads Filed, and Acknowledged once the authority's acknowledgement is recorded.

NIS2 expects the stages in order. Filing a later stage first is allowed, but the card tells you which earlier stage is still not marked as filed. The dashboard on this page collects every open deadline across all incidents.

Let a workflow create the NIS2 tasks

A Manager or Admin can start a workflow from the NIS2 Incident Notification template under Workflows. It runs when an incident is marked significant: it confirms the incident owner, creates three tasks under Roadmap → Action items — the 24-hour early warning, the 72-hour notification and the one-month final report — due on the incident's own NIS2 deadlines, and e-mails the owner for each. See Workflows.

Belgium

The Netherlands

Who uses it

The route checks the INCIDENT_READ permission, then confirms the role is Manager or Admin; if either check fails you are redirected to the incident list rather than shown an error. The data also requires the Incidents module to be active for your organisation.

What's on this screen

The dashboard fills the main area to the right of the left menu. At the top, the heading Incident Reporting Dashboard sits above the sub-line Regulatory reporting obligations — NIS2 and GDPR deadline tracking, with a Back to Incidents link on the far right.

Below the heading are four summary cards, each a large number over a label: Overdue (red), Due within 24h (orange), On Track (green) and Total Active (blue). In the demonstration tenant captured below they read 3, 0, 0 and 3 — three obligations, all of them already past their date.

Under the cards is a row labelled Framework: with three buttons — All, NIS2 and GDPR — the selected one filled in indigo. Then comes the Active Deadlines panel: a table with the columns INCIDENT, FRAMEWORK, STAGE, DEADLINE and STATUS, plus an unlabelled final column holding a View link on every row. The incident name and the View link both open that incident's detail page.

In the capture the three rows all belong to one seeded incident, Vendor Audit Finding - 2026-02-07, and show its three NIS2 stages — Early Warning (24h), Incident Notification (72h) and Final Report (1 month) — each with a red overdue age such as 199 days 6 hours ago and a red Overdue chip. That is demonstration data, not a real backlog.

Nothing else is on the page: no export, no bulk action and no way to record a notification from here. A Completed Notifications panel appears below the table once at least one obligation has been fulfilled; there are none in this capture, so the page ends at the table.

Open the dashboard

  1. In the left menu, open the SECURITY INCIDENTS group and choose Reporting (or type /incidents/reporting straight into the address bar). The dashboard loads with the four summary cards, the framework buttons and the Active Deadlines table.
  2. Note that the separate REPORTING group further down the menu is for cross-module reports and board packs — this deadline view does not live there. See Reports for that group.
  3. Select the help ? in the top bar to open the in-app guidance for the screen you are on.
  4. Check the name in the top-right corner. Only a Manager or an Admin sees this page; a Viewer or Contributor has no Reporting entry in the menu and is returned to /incidents if they type the address.
The Incident Reporting Dashboard — summary cards, framework filter and the Active Deadlines table — /incidents/reporting.
The Incident Reporting Dashboard — summary cards, framework filter and the Active Deadlines table — /incidents/reporting.

Read the summary cards

The four cards answer the first question: how bad is it right now?

Card What the count means
Overdue Obligations whose date has passed with no notification recorded. Work these first.
Due within 24h Obligations falling due in the next 24 hours.
On Track Everything else — not overdue and more than 24 hours away.
Total Active Every outstanding obligation combined — the sum of the other three cards.

One incident can contribute several rows and several counts: an incident that is both a NIS2 significant incident and a GDPR breach produces a deadline for each framework and each stage — which is why one seeded incident fills all three rows above.

The cards and the row chips use different bands

The cards split into overdue, within 24 hours and everything else. The STATUS chip in each row is finer: Overdue, Urgent (within 24 hours), Due Soon (within 72 hours) and On Track (more than 72 hours away). A deadline two days out therefore counts towards the green On Track card while its row reads Due Soon. Read the row when you plan the work.

Filter by framework

  1. Select NIS2 to narrow the table to NIS2 obligations, or GDPR for the 72-hour authority notifications that follow a personal-data breach. The button you choose fills in indigo and the table redraws immediately.
  2. Select All to return to the combined view. If the chosen framework has no outstanding obligations, the panel shows a short "no deadlines" line in place of the table rather than an empty grid.

The filter changes the two tables only — the summary cards always count every active obligation. Only NIS2 and GDPR have buttons. DORA stages for major ICT incidents appear under All but cannot be isolated here; use DORA for that module's own view.

Work an overdue deadline

  1. Read the STATUS column and start at the top. The table is sorted by urgency, so the most pressing obligation is always the first row.
  2. Read STAGE and DEADLINE together to see which notification is due and by how far it is ahead or behind — for example Early Warning (24h) and 199 days 6 hours ago.
  3. Select the incident name, or the View link at the end of the row, to open that incident's detail page in the same tab.
  4. On the incident, record what actually happened: use the GDPR notification action for a data breach, or the NIS2 significance assessment and its stage actions for a NIS2 obligation. See Incidents for both flows.
  5. Return to the dashboard. Once a notification is recorded against the incident, that row leaves Active Deadlines and reappears under Completed Notifications.

Review completed notifications

The Completed Notifications panel is only rendered when at least one obligation has been fulfilled for the current framework filter, which is why it is absent from the capture above. When it is there, the header reads Completed Notifications followed by the count in brackets; select it to expand the panel. Each row lists the incident, the framework, the stage, Sent At, Sent To (a dash when no recipient was recorded) and a status of On Time or Late. Rows are ordered most recent first. This is the record to reach for when an auditor asks what was reported, to whom and when.

The deadline banner follows you around

Urgent deadlines are announced on every page

When an obligation is overdue or within 24 hours, Managers and Admins see a coloured banner at the top of every Aegis page, not only this one. It names the most urgent obligation and offers links to the affected incident and back to this dashboard. Dismissing it hides it for 30 minutes in that browser tab; it returns while the deadline is still open. Viewers and Contributors never see it.

The AI assist

This dashboard does no AI work of its own — it counts deadlines that already exist. The AI step happens earlier, on the incident: when you assess whether an incident is a NIS2 significant incident, Aegis can offer a likely-significant verdict with its reasoning and a confidence score. A person reviews that suggestion and decides. Recording the decision as significant is what creates the NIS2 deadlines you then see here. The AI never marks an incident significant on its own, and it never sends a notification.

Tips and limits

Where this connects