Under NIS2, reporting a significant cyber incident happens in stages, not in a single submission. There are at least three: an early warning within 24 hours of becoming aware of the incident, an incident notification within 72 hours, and a final report no later than one month after that notification. The first is short. The other two ask for facts that do not exist yet when the first is sent.
Suppose an electricity and district heating supplier operating in two EU member states confirms at 11:20 on a Friday that ransomware has reached its billing and customer portal systems. The early warning goes to the national authority at 10:00 on Saturday. The incident lead’s relief lasts about a minute, because the next submission is due at 11:20 on Monday and it needs an assessment of severity and impact and, where available, indicators of compromise.
Each of those facts sits with someone who is busy with the incident itself. Who is working out how many customers are affected? Who is recording which systems were isolated, and when? Has anyone been asked to keep the indicators of compromise in one place, or are they scattered through a chat channel?
Settling NIS2 incident reporting roles and responsibilities before an incident is what closes that gap. Each fact in the report becomes a task inside the response, with a named owner and a time it is due.
A regulatory report is assembled during the response, from facts the response produces. If nobody is assigned to capture a fact while it’s fresh, somebody reconstructs it later from memory.
NIS2 Incident Reporting Roles And Responsibilities Give Every Fact An Owner
NIS2 incident reporting roles and responsibilities are the allocation of each fact a national authority will ask for to a named role, as an assigned task during the incident with a deadline tied to the reporting clock and a visible status. Those facts include the time the organisation became aware, the severity, the impact on services, the likely cause and the measures taken.
The directive does not prescribe these roles. It sets the deadlines and the content, and each organisation decides who supplies what. The practical difficulty is that the person who submits the report is rarely the person who knows the facts in it. Compliance or legal owns the submission, while security, operations, the service owners and communications own the content. A task list is the link between the two, and it has to exist while the incident is still running.
What Does NIS2 Incident Reporting Require Between The Early Warning And Full Notification?
Between the early warning and the incident notification, an organisation has to turn a short alert into an initial assessment. Article 23 of the NIS2 Directive, Directive (EU) 2022/2555, sets out what each stage contains, and the European Commission’s NIS2 Directive page explains which sectors are in scope.
NIS2 is a directive, so national law in each member state sets the authority, the portal and the template. What follows is the text of the directive, given as orientation and not as legal advice, and the exact process should be confirmed with the national CSIRT or competent authority before anyone relies on it. The stages in Article 23 are:
- Early warning, without undue delay and in any event within 24 hours of becoming aware of the significant incident. Where applicable it says whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have a cross-border impact.
- Incident notification, within 72 hours of becoming aware. It updates the early warning and gives an initial assessment of the incident, including its severity and impact and, where available, the indicators of compromise.
- Intermediate report, when the CSIRT or competent authority asks for a status update.
- Final report, not later than one month after the incident notification was submitted. It covers a detailed description of the incident including its severity and impact, the type of threat or root cause likely to have triggered it, the mitigation measures applied and ongoing, and any cross-border impact.
Two details in that text catch teams out. Both of the first clocks run from the moment the organisation became aware, so sending the early warning does not buy a fresh 72 hours. And if the incident is still running when the final report falls due, the directive asks for a progress report at that point and a final report within one month of the incident being handled.
The supplier in the scenario reports in two member states. That is two sets of submissions from one set of facts, and yesterday’s post on reporting one incident to regulators in several countries covers who coordinates them.
Different Rules, The Same Staged Report
A fast first notice followed by a fuller report is becoming the usual shape of cyber reporting rules outside the EU as well, though several of the newer regimes are not yet in force. As at October 2026:
- United Kingdom. The Cyber Security and Resilience Bill is at report stage in the House of Lords, so it isn’t law yet. The government’s incident reporting factsheet proposes an initial notification within 24 hours and a full report within 72 hours (DSIT 2026).
- United States. CIRCIA sets a 72-hour reporting requirement for covered entities, but CISA’s CIRCIA page says reporting will not be required until the final rule takes effect.
- Canada. Bill C-8 received Royal Assent on 15 June 2026. The Act as passed requires designated operators to report cyber security incidents within a period set by regulations, not to exceed 72 hours.
- Saudi Arabia. For financial firms, SAMA’s Cyber Security Framework asks for a formal incident report once operations have resumed, including root-cause analysis, corrective activities and impact.
- EU financial services. DORA has three stages of its own, covered in the post on DORA major incident reporting timelines.
Requirements vary by sector, entity and country, so check each obligation against the primary text. The rules differ and the problem underneath them is the same one: someone has to gather the facts, and someone has to own each action that produces them.
Who Owns Each Part Of An Incident Report To A Regulator?
Each part of an incident report to a regulator is owned by whoever produces the underlying fact during the response, and the submission itself is owned by compliance or legal. In most organisations that comes to six roles. The table maps the NIS2 content onto them, using the supplier in the scenario.
Part of the report | Fact needed | Owner | When the fact exists |
Time of becoming aware | When the incident was confirmed as significant, and by whom | Incident lead | At confirmation: Friday, 11:20 |
Suspected cause and indicators of compromise | Evidence of the attack, preserved in one list | Security lead | From the first hours, then added to |
Severity and impact | Services affected, customers affected, duration | Service owners | Changes through the weekend |
Mitigation measures | What was isolated, restored or changed, with times | IT operations lead | As each action is completed |
Notice to service recipients | Who was told, what they were told and when | Communications lead | As each message goes out |
Submission | Approved text, sent to the right authority on time | Compliance or legal | At each deadline |
The Incident Lead Owns The Clock And The Task List
The incident lead owns two things the report cannot do without: the time the organisation became aware, and the list of reporting tasks. The awareness time fixes every deadline that follows. So it is recorded once, with the name of the person who made the call.
At the supplier, the incident lead raises the reporting tasks at 10:05 on Saturday, five minutes after the early warning. Each task names an owner and a time. The first reads: “Impact assessment for the incident notification. Owner: head of customer operations. Due: Sunday 18:00. Needed: number of customers unable to use the portal, by country, and whether billing runs are affected.”
Security Owns The Cause, Service Owners Own The Impact
The security lead owns the facts about cause: whether the incident looks malicious, the indicators of compromise, and later the type of threat or root cause. These facts appear early and are easy to lose. Analysts paste file hashes into a chat channel at 02:00, and by Monday nobody is sure which list is current.
Service owners own severity and impact. At the supplier that means the head of customer operations for the portal and billing, and the head of network operations for supply itself, which was not affected but which the authority will ask about. Impact is the fact that changes most, so its task carries a refresh time as well as a due time.
Operations And Communications Own What Was Done And What Was Said
The IT operations lead owns the record of mitigation: what was isolated, what was restored, what was changed, and when. The final report asks for measures applied and ongoing. A list written a month later from change tickets and recollection tends to miss the things that were agreed by phone on Friday night.
The communications lead owns the record of who was told. NIS2 expects entities, where appropriate, to notify the recipients of their services without undue delay about significant incidents likely to affect those services. An authority may ask what customers were told and when, so each message is logged as it goes out.
Compliance Owns The Submission, And Depends On Everyone Else
Compliance or legal owns the submission: the decision that the incident is reportable, the approved wording and the act of sending it. But compliance cannot produce the content, and on a weekend it may not know who can.
So the compliance lead is the main user of the task list. At 09:00 on Monday, with the incident notification due at 11:20, the useful view is a short one: five tasks complete, one overdue, and the name of the person holding the overdue one. The earlier post on tracking critical actions during an incident covers how completion is confirmed in general. For reporting, a task is only done when the fact is written down in a form the report can use.
A Report Written After The Incident Is Written From Memory
The common belief is that the report gets written once the incident is over, when people have time. It’s half right. The final report under NIS2 isn’t due until a month after the incident notification, and nobody should pull engineers off containment to draft prose.
But the facts in the report are produced during the response, mostly in the first hours and days. If they are not captured then, the author of the final report interviews six tired people three weeks later and gets six slightly different timelines. The National Cyber Security Centre’s guidance on cyber incident response processes advises keeping a careful record of the response, the decisions made and the actions taken, and says this is especially true where evidence of the response may have to be presented to a regulatory body.
Preparation for this is thin. Only 32% of UK businesses have guidance on when to report a cyber breach or attack externally (DSIT 2025). Knowing when to report is the first step, and knowing who supplies each fact is the next.
Seven Reporting Tasks To Raise When The Early Warning Goes
The reporting tasks can be written before any incident and raised the moment the early warning is sent. Seven of them cover the NIS2 content. Each carries an owner and a due time set back from the regulatory deadline, which leaves room for review.
- Record the time of becoming aware and who confirmed it. Owner: incident lead. Due: immediately.
- Open one list for indicators of compromise and keep it current. Owner: security lead. Due: first version within 12 hours, then updated.
- Assess severity and impact by service and by country. Owner: service owners. Due: 18 hours before the incident notification, and refreshed before the final report.
- Log every mitigation measure with its time. Owner: IT operations lead. Due: continuous, reviewed daily.
- Log every message to customers and other service recipients. Owner: communications lead. Due: as each one is sent.
- Confirm which authorities must be told and whether other reports apply, such as a personal data breach report. Owner: compliance or legal. Due: within 24 hours.
- Draft, approve and submit the incident notification, then set the date for the final report. Owner: compliance or legal. Due: four hours before the deadline.
The times are illustrative and should be set against the organisation’s own obligations. An overdue task then becomes visible to the incident lead while there is still time to act on it.
Where Task Manager Fits In The Reporting Work
Most organisations could raise these seven tasks today, by email or in a spreadsheet. The trouble starts afterwards. Disconnected emails, spreadsheets and manual documentation leave someone reconstructing events once the incident has passed, which is the outcome the tasks were meant to prevent.
Crises Control is an operational incident coordination platform, and Task Manager, its incident task management software, is the module that applies here. Task Manager extends Incident Manager by turning coordinated response plans into assigned, tracked and completed actions. An organisation can put its reporting tasks in the response plan next to the technical ones, so they are assigned when the plan is activated.
Each task goes to a named owner or team, who can accept it and update its status from any device. Escalation rules for overdue or unclaimed tasks are configurable and run in stages, for example notifying a supervisor, then reassigning the task, then alerting the incident manager. Workflow dependencies mean a task only unlocks when the tasks it relies on are complete, so the submission can be made to wait for the impact assessment.
Task Manager records task ownership, acceptance times, status changes, escalation activity and completion updates, and those records form part of the operational incident record. The compliance management software page describes how that record supports governance, audit and compliance review, and the incident reporting software page covers the audit trail.
The software does not decide whether an incident is significant. It does not write the report, and it does not submit anything to an authority. Those remain decisions and actions for the organisation’s own people, and the platform’s role is to show who owns each task and whether it has been done.
A Month To Write It, Hours To Capture It
Go back to the supplier at 09:00 on Monday. The incident isn’t over, and the portal is still down in one country. But the compliance lead has an awareness time with a name against it, one list of indicators, an impact figure refreshed on Sunday evening and a log of what customers were told. The incident notification goes at 10:40. The final report is a month away, and most of what it needs has already been written down by the people who did the work. That record is the difference between a response that was under control and one the organisation can also prove.
Frequently Asked Questions
What are the roles and responsibilities for incident reporting under NIS2?
NIS2 incident reporting roles and responsibilities divide the report between the people who produce its facts and the people who submit it. The directive sets the deadlines and the content, and does not prescribe the roles, so each organisation allocates them. In practice each fact becomes an assigned task with a named owner, a due time and a visible status.
What has to be done between an early warning and a full incident notification under NIS2?
Between the early warning and the incident notification, the organisation has to produce an initial assessment of the incident, including its severity and impact and, where available, indicators of compromise. Under Article 23 of the NIS2 Directive the incident notification is due within 72 hours of becoming aware of the significant incident, which is the same starting point as the early warning. National law sets the authority and the template.
Who owns each part of an incident report to a regulator?
Each part is owned by the role that produces the fact. The incident lead owns the awareness time, the security lead owns cause and indicators of compromise, service owners own impact, IT operations owns mitigation measures and communications owns the record of who was told. Compliance or legal owns the decision to report and the submission itself.
Is the final incident report written after the incident is over?
The final report is usually drafted later, but the facts in it are captured during the response. Under NIS2 the final report is due not later than one month after the incident notification was submitted. Agreeing NIS2 incident reporting roles and responsibilities in advance means each fact is recorded as it happens, and the author works from records made at the time.
Can incident task management software submit a report to a regulator?
No. Incident task management software such as Task Manager from Crises Control assigns, tracks and escalates the tasks that produce the content of the report, and records who did what and when. Deciding whether an incident is reportable, approving the wording and submitting it remain the responsibility of the organisation.
This article was drafted with AI assistance and reviewed by the Crises Control team. Featured image: AI-generated.
