NIS2 incident reporting: rehearse the handoffs
The reporting clock is not your first problem. The first problem is discovering that only one person knows who can submit the report.
If you are responsible for security and incident response, a short rehearsal can expose that dependency without waiting for an actual incident. You need the responder, decision-maker, reporting lead and their deputies to understand how information moves between them.
The second Network and Information Security Directive, known as NIS2, sets staged reporting requirements for significant incidents through Article 23 of Directive (European Union) 2022/2555. National implementation and sector-specific rules still need checking.
Use this NIS2 incident reporting tabletop checklist to rehearse decisions, not to simulate a submission to an authority. A tabletop is a discussion-based exercise using an invented scenario. Nothing in the exercise below happened to a real organisation.
What matters this week, and what can wait
This week, confirm your reporting route, deputies and current national significance criteria. Rehearse the first handoff from a technical alert to an accountable significance assessment. Check whether the reporting lead can access the approved channel if ordinary sign-in or email is unavailable.
An elaborate simulation, new presentation slides and a comprehensive library of scenarios can safely wait. A working contact route and a clear deputy cannot. Neither can containment of a real incident or an applicable reporting duty.
Your useful result today is a one-page role sheet and a timed decision log showing where the handoff failed and who will fix it.
Know what starts the reporting process
Article 23(3) considers an incident significant where it has caused or is capable of causing severe operational disruption or financial loss for the entity, or considerable material or non-material damage to other people or organisations.
That is not a requirement to report every alert. It is also not permission to wait for complete certainty about the final damage. An initial assessment must be timely and based on the applicable criteria.
For the entities covered by Implementing Regulation 2024/2690, additional significance criteria apply. Its recital 31 explains awareness in terms of a reasonable degree of certainty, following an initial assessment, that a significant incident has occurred. Check the operative rules and your authority's guidance rather than applying one generic outage threshold to every sector.
Record detection, initial assessment and awareness of significance separately, including who knew what and when. A later management meeting should not be used to move the awareness point simply because that is when a senior person became available.
Verify the Article 23 clocks
The following is the Directive baseline for significant incidents. Confirm the law and reporting instructions that apply to your entity. The maximum deadlines are not targets: the early warning and incident notification must be made without undue delay.
| Stage | Directive baseline | Information to prepare |
|---|---|---|
| Early warning | Without undue delay and within 24 hours of becoming aware of the significant incident | Where applicable, suspected unlawful or malicious cause and likely cross-border impact |
| Incident notification | Without undue delay and within 72 hours of becoming aware | Update the warning; initial severity and impact assessment; indicators of compromise where available |
| Intermediate report | On request from the computer security incident response team or competent authority | Relevant status updates |
| Final report | No later than one month after submitting the incident notification | Detailed description, severity and impact, likely threat or root cause, mitigation and relevant cross-border impact |
| Ongoing incident | Progress report when the final report would otherwise be due | Final report within one month of handling the incident |
A computer security incident response team is a designated team that supports incident handling. “Indicators of compromise” means technical signs that can help identify suspicious or malicious activity, such as relevant file or network indicators.
For trust service providers, the Article 23 incident notification for significant incidents affecting their trust services is due without undue delay and within 24 hours, rather than 72 hours.
The 72-hour period is not added after the 24-hour warning period. Both run from awareness. The one-month final-report period runs from the incident notification, not from detection or the early warning. A calendar month is not a universal synonym for 30 days.
Keep other notification duties on the sheet
Article 23 also addresses informing affected service recipients in the relevant circumstances. Personal-data breach, contractual and sector-specific notifications may require separate decisions and timelines. Do not assume one submission satisfies every duty.
Give those questions to the appropriate legal, privacy or contract owner. Software cannot make legal determinations about significance, jurisdiction or who must be notified.
Confirm the national route, not just the country label
For Belgium, the Centre for Cybersecurity Belgium's reporting guidance describes an early warning within 24 hours, an incident report within 72 hours, the trust-service exception and a final report within one month after the notification report. Read its current notification guide for assessment and practical reporting instructions.
The Netherlands' National Cyber Security Centre describes reporting through the central MijnNCSC reporting point, with staged 24-hour and 72-hour reports and a final report within one month after notification. Its guidance also flags trust-service and sector-law exceptions.
These are checked examples, not a complete country-by-country legal comparison. A country name in an application does not establish the applicable jurisdiction or whether all national requirements have been implemented.
Start with the scope checker, the Belgium country page or the Netherlands country page, then verify the current official route for the actual entity and service. Keep the source and review date in your exercise pack.
Assign roles before starting the exercise
| Responsibility | Named role to assign | Deputy or fallback to test |
|---|---|---|
| Technical assessment and containment | Incident response lead | On-call responder |
| Significance assessment and escalation | Accountable security decision-maker with legal input | Authorised decision-maker outside normal hours |
| Preparation and submission | Reporting lead | Person able to use the reporting channel |
| Service and business impact | Operations or service owner | Duty operations lead |
| Recipient, privacy and contractual communication | Relevant communications, privacy and legal owners | Approved alternate contacts |
| Decision log and evidence preservation | Recorder | Alternate recorder using an available system |
Roles can be combined in a small team, but do not leave a responsibility implicit. Test authority as well as availability: a deputy who is reachable but cannot approve or submit has not removed the dependency.
Choose a secure alternative communication method if normal collaboration tools are affected. Keep credentials and sensitive incident records out of the exercise handout.
Run this fictional incident exercise
The following scenario, facts and timings are invented training material. They are not a client story or evidence of a real attack. Exercise minutes are facilitation prompts, not legal deadlines.
A fictitious service develops an unexplained outage. Responders find suspicious privileged activity, while the service owner reports disruption affecting important customer operations. It is not yet clear whether information was taken. The usual reporting approver is unavailable.
Exercise minute 0: receive the first alert
Ask who opens the incident record, who contacts the service owner and what evidence must be preserved. Record what is known, unknown and merely suspected. Keep technical containment moving while the reporting questions are assessed.
Exercise minute 15: assess significance
Give the team an update: the disruption continues and the activity may have affected more than one country. Ask which legal and sector criteria they apply, what additional information they need and when they will reassess.
If participants decide significance is established, record their reasoning and the awareness time used for the exercise. If they do not, record why, who owns the next assessment and what fact would change the decision. “Waiting for the director” is not a significance criterion.
Exercise minute 30: the approver remains unavailable
Ask the deputy to prepare an early-warning draft in an offline exercise document. Use known facts and label uncertainty. Do not open a real authority submission or send a test report unless that authority has an explicitly agreed exercise route.
Check who authorises the draft and how the reporting lead would obtain help if the normal channel failed. A document ready on a laptop is not the same as a submitted notification.
Exercise minute 45: impact information changes
Provide a second invented update: recovery is partial and the affected service list changes. Ask how the incident notification would update the early warning and how corrected facts are distinguished from earlier estimates.
Then discuss the one-month stage. If the incident is ongoing, who prepares the progress report and tracks the subsequent final report? Do not stop the exercise after the first warning.
Keep a timed decision log
Copy this table or use the blank exercise log and workbook. These are internal practice aids, not official notification forms.
| Timestamp and zone | Fact or decision | Basis and uncertainty | Owner and next action | Evidence or receipt |
|---|---|---|---|---|
| Record actual exercise time | Alert received | Source and what is still unknown | Assessment owner | Exercise reference |
| Record actual exercise time | Significance assessment | Criteria and rationale | Reassessment time or escalation | Decision reference |
| Record actual exercise time | Awareness point established | Facts supporting the conclusion | Reporting lead calculates deadlines | Reviewed calculation |
| Record actual exercise time | Warning or notification draft approved | Known facts and limitations | Submission owner and deputy | Exercise draft only |
| Record actual exercise time | Follow-up and closure planning | Remaining impact and open questions | Progress or final-report owner | Action references |
Use a consistent time zone and retain the underlying timestamp when systems differ. Record actual submission times and acknowledgements during a real incident. Never mark a report sent merely because the draft is approved.
Close the rehearsal with three corrective actions
Ask where the handoff depended on one person, where an important fact was missing and where the reporting route was uncertain. Give the three most useful fixes owners and due dates. Re-test the failed step after the fix.
GRCompliance's homepage lists an incident clock among preview features. Treat any application deadline display as an aid to coordination, not a verified national legal determination or evidence that an authority received a report. Confirm availability in the edition you are evaluating before relying on a workflow.
Try the live demo with fictional data only. The free open-source Core documents risks, controls and linked evidence; do not assume the incident features or automation shown elsewhere are included in every edition. No authority filing is automated or promised in this guide.
Frequently asked questions
Do all incidents need a NIS2 notification?
The Article 23 staged duty concerns significant incidents. Assess the applicable significance criteria promptly and record the reasoning. Other laws or contracts may create separate notification duties.
Does the 72-hour deadline start after the early warning?
No. The Directive's 24-hour and 72-hour clocks both run from awareness of the significant incident. The trust-service exception shortens the incident-notification period to 24 hours for the incidents it covers.
Is the final report due one month after detection?
No. The Directive sets it no later than one month after the incident notification. If the incident is ongoing at that point, provide a progress report and then a final report within one month of handling it.
Can an application decide whether we must report?
No. Software cannot make legal determinations. It can support records and coordination, but responsible people must assess the facts, applicable rules, reporting route and actual submission.
Sources
Reviewed 7 November 2026. Recheck national and sector guidance before relying on the exercise in operations.
- Directive 2022/2555, Article 23 and recitals 101–102.
- Implementing Regulation 2024/2690, Articles 1 and 3–14 and recital 31.
- Centre for Cybersecurity Belgium: notification instructions.
- Centre for Cybersecurity Belgium: notification guide, version 1.3.
- Netherlands National Cyber Security Centre: incident reporting duty.
- GRCompliance public incident reporting guide: existing screen names and product caveats, not a regulatory source.
- GRCompliance Core documentation: conservative edition boundaries and verified Core features.
Try the live demo
Open the public demo to see the product. Use fictional data only.