NIS2 incident reporting process: deadlines and steps

What the NIS2 incident reporting process requires, step by step

An in-scope entity must report a significant incident on fixed deadlines. The sequence starts with an early warning within 24 hours of becoming aware of the significant incident, followed by a notification that updates that early warning and gives an initial assessment of severity and impact. A final report is due no later than one month after the notification, and if the incident is still ongoing at that point, the entity submits a progress report and then a final report within one month of handling the incident. Intermediate reports are required only when the national CSIRT or competent authority asks for them.

The timing and content of each step depend on the entity's own incident facts, on the national transposition law of its Member State, and on whether the incident has a cross-border impact. The early warning must indicate whether the incident is suspected of being caused by unlawful or malicious acts or could have cross-border impact, where that applies. Reports go to the national CSIRT or, where the Member State provides, the competent authority, which forwards them to the CSIRT. Before the first deadline starts running, the entity should confirm with its national authority which channel applies, what the submission format is, and how the national law adds to the EU baseline.

The organization owns the decisions and the report. Its management and incident leads decide whether an incident is significant, what goes into each filing, and who signs it off. An implementation partner can prepare the procedures, decision aids, reporting templates, logging and evidence trails that make the deadlines achievable, but only the entity files the report with its national CSIRT or competent authority. Outside help does not change who is accountable for meeting the 24-hour and 72-hour commitments. The NIS2 Directive text on EUR-Lex is the authoritative reference for these steps.

How to decide whether an incident is significant

Article 23(3) sets two routes to significance: severe operational disruption or financial loss for the entity, and effects on other people or organizations. The factors below turn that test into a decision you can record and defend, and each one should be checked before the 24-hour clock is assumed to have started.

Service impact and disruption

Ask whether the incident has caused, or can cause, severe operational disruption of the services you provide. Measure outage duration, the number of users or processes affected, and whether critical functions have failed over. Record the service, the observed and projected impact, and the time you first understood the scope. Assess potential impact too, not only current impact, because the test covers incidents that can cause these effects.

Financial exposure

Estimate whether the incident has caused, or can cause, severe financial loss to the entity. Include direct recovery costs, service credits, lost revenue and contractual penalties. Write down the figures used, the assumptions behind any projection, and who approved them. An early estimate is acceptable if it is labeled as provisional and revised as facts arrive.

Third-party effects

Determine whether other natural or legal persons, such as customers, business partners or the public, have been affected or can be affected through considerable material or non-material damage. Note the affected groups, the nature of the harm and whether they depend on your services for something critical. Record which groups you considered and why others were excluded, because this is the factor most often challenged later.

Data confidentiality and integrity

Check whether the incident compromised the confidentiality or integrity of systems, data or credentials, even if availability was unaffected. A tampered configuration or a stolen administrator credential can meet the test without visible downtime. Record what data or system classes were touched, how you established that, and whether the access is still ongoing. Where personal data is involved, the separate GDPR clock may also run, so flag it now.

Cross-border effects

Establish whether the incident could affect services or people in another Member State, or whether it may be part of a wider campaign. Cross-border impact is not itself a separate significance test, but it changes what the early warning must state and whom the authorities inform. Record the countries where your services or customers operate, and the evidence for or against spread.

Sector-specific criteria

Member States and Commission Implementing Regulation (EU) 2024/2690 may set further significance criteria for the sectors and entity types it covers, such as DNS, cloud, data center, managed service and online platform providers. Confirm with your national competent authority or CSIRT which criteria apply to your entity, and add them to your decision record alongside the Article 23(3) factors.

Where NIS2 incident reports go and who files them

Notifications go to the national CSIRT or, where the Member State provides for it, to the national competent authority, which forwards them to the CSIRT. Article 23 of NIS2 sets that routing, so the first decision for your organization is which of those two channels applies in each country where you are in scope. Before any incident, confirm with your national authority whether reports go directly to the CSIRT or through the competent authority, and record the answer in your incident response plan. Article 13(6) also requires Member States to simplify reporting through technical means. That points to a portal, a form or a secure channel, but the mechanics differ by country, so you must confirm the exact portal, form, submission channel, required fields and contact points locally. Do not rely on a guide, a vendor or a general EU summary for these details.

Name one person who holds the reporting authority and one deputy who can act if that person is unreachable. The reporting clock starts when the entity becomes aware of a significant incident, so a report that waits for one absent officer can miss the 24-hour early warning. Decide who has authority to submit the notification, who approves its content, and who can make the significance call on the entity's behalf. Give each of these people a way to submit that does not depend on a single mailbox or a single login. Test that the deputy has working access to the national channel, the required credentials or registration and the current contact details. Where your entity operates in several Member States, document the reporting channel for each one, and confirm with each national authority which entity is the right contact for cross-border incidents.

Treat the reporting contacts as a maintained record, not a one-time setup. Contact names, roles, credentials and national channels change, and a stale record is a common reason a report is late. Review the list on a set schedule and after any reorganization, supplier change or change in national rules. Keep a copy of the national submission instructions and the required information set somewhere the reporting officer can reach during an outage of your primary systems. Where an external provider, such as a managed security service, files reports on your behalf, confirm in writing who holds the legal responsibility, who has the portal access and how quickly the provider must escalate to your officers.

The reporting sequence from detection to final report

This sequence turns a detected security event into a documented chain of NIS2 reports, each with a defined output that an assessor or supervisor can check. It shows what must exist at each stage so the entity can meet the Article 23 deadlines and explain its decisions afterward.

Detect and record the moment of awareness
The security operations or IT team detects a possible incident through monitoring, a staff report, a supplier notice or a customer complaint, then logs it in the incident register with the time the entity first became aware of it. This timestamp matters most, because the 24-hour early warning clock starts when the entity becomes aware of a significant incident. The step is complete when the incident record shows a unique identifier, a detection source and a recorded awareness time that can be produced for a supervisor.
Decide whether the incident is significant
The incident commander applies the Article 23(3) test: whether the incident has caused or can cause severe operational disruption of services or financial loss, or has affected or can affect other persons through considerable material or non-material damage. The decision is taken by a named role, with the facts available at that time and the reasoning written down, even when the answer is no. The output is a signed significance assessment that an assessor can review, including any reassessment as facts change.
Submit the early warning within 24 hours
For a significant incident, the entity submits an early warning to the national CSIRT or competent authority without undue delay and in any event within 24 hours of becoming aware. The early warning states whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact, where applicable. The output is a dated submission receipt or channel record, held with the incident file, that shows the submission time against the awareness time.
Send the notification with an initial assessment
Within the notification, the entity updates the early warning where applicable and gives an initial assessment of the incident, covering its severity, its impact and, where available, indicators of compromise. The incident team confirms the technical facts with the owners of the affected systems before sending, and records any facts still unknown. The output is a notification copy and a version history that shows what was known at the time, so later reports can be compared against it.
Provide intermediate reports on request
Intermediate reports are not a fixed step in every case. The entity submits them only when the CSIRT or competent authority requests status updates, so the process should include a named contact who receives and tracks such requests. Each request is answered with a dated update that reflects the current state of containment, recovery and impact. The output is a request log and the update responses, which show the entity responded to the authority's questions in an orderly way.
File a progress report if the incident is ongoing
If the incident is still ongoing when the final report is due, the entity submits a progress report at that time. The report describes the work completed, the containment and mitigation measures in place, and the remaining steps, and it names what is still unknown. The output is a progress report on file with a date, plus the internal sign-off record, showing the entity did not let an open incident pass the deadline without a report.
Submit the final report within one month
The final report is due no later than one month after the incident notification, and it must describe the incident in detail. It covers severity and impact, the type of threat or likely root cause, the applied and ongoing mitigation measures, and any cross-border impact. The output is a final report with supporting evidence, reviewed by management and linked to the post-incident review, which an assessor can compare against the early warning and notification to check consistency.

What the 24-hour early warning must say

The early warning has two required indications. Under Article 23(4)(a) of NIS2, the early warning must be submitted without undue delay and within 24 hours of the entity becoming aware of a significant incident. Where applicable, it must indicate whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact. The wording leaves the first point open for incidents where no malicious cause is suspected, so the entity should record a clear answer in each case, whether that is a suspicion, no suspicion, or an unknown status that will be revisited. The early warning is not a full account of the incident. It is a first signal to the national CSIRT or competent authority, and the detailed assessment follows in the notification.

Because the early warning is short by design, the entity should prepare a standard template before any incident occurs. Useful fields include the time the entity decided the incident was significant, the affected services and systems, a suspected cause category (for example, malicious activity, technical failure, human error or unknown), an indication of possible cross-border impact, and the name and contact details of a person who can answer questions from the authority. Incident response leads should confirm with their national CSIRT or competent authority which submission channel and format they use, since the Member State determines the route. Practising the template in exercises helps the on-call team fill it in quickly under pressure.

The practical risk is that a team waits for complete facts before filing. A response team that is still investigating often wants to confirm the root cause, the full scope and the data affected before reporting, and that delay can push the filing past 24 hours. The expected pattern is to file a first version on time, with the information that is known, marked as preliminary, and then update it in the notification stage, which gives an initial assessment of severity, impact and any available indicators of compromise. Management should make the decision to file an early warning on partial facts explicit in the response plan, so that the deadline does not depend on the incident team reaching certainty first.

Who does what in the reporting process

The entity owns the obligation. Its management body approves the response approach and carries accountability under the governance duties, while its incident commander or security lead decides whether an incident is significant and when the clock starts. Legal and communications staff judge notification duties toward customers and any overlap with personal data breach rules. The person authorized to file submits the early warning, notification and final report through the channel the national authority specifies.

Management body: approves the reporting procedure, sets escalation thresholds and receives status updates during significant incidents.
Incident commander or security lead: makes the significance decision, records the time of awareness and directs containment and reporting work.
Legal and communications: review notification content, decide on customer messages and coordinate with data protection duties where personal data is involved.
Authorized filer: holds the credentials and mandate to submit reports, and keeps a copy of each submission with its timestamp.
Supplier liaison: obtains the facts from managed providers and cloud operators that the report needs.

Before relying on this split, confirm with your national authority who may file, which channel applies and whether a named delegate is accepted.

Informing service recipients and other Member States

Four obligations run in parallel once a significant incident is confirmed: telling service recipients, giving the authority the facts it needs on cross-border impact, and the authorities passing information onward. Each one produces its own record, and the customer notice and the regulator report must be read together so they never contradict each other.

Notifying service recipients

Where a significant incident is likely to adversely affect the services your customers receive, you must notify those recipients without undue delay under Article 23(1). The decision to notify is yours, and it should be made against a documented test of which customers are affected and how. Keep the notice itself, the distribution list, and the timestamp of each send. The customer or service owner should own the message, with legal reviewing the wording.

Reporting cross-border impact facts

Your report must contain the information that lets the CSIRT or competent authority establish whether the incident has a cross-border impact. In practice this means recording which Member States your services, data or customers touch, and whether the incident affects them. Keep a service-to-country map current before an incident occurs so the answer is not reconstructed under pressure. The incident lead and the compliance owner should confirm the facts together.

Authority information sharing with other states

Where appropriate, the national body informs other affected Member States and ENISA. This happens on the authority's side, not yours, but it means the facts you submit will travel beyond the first recipient. Your reports should therefore be complete, consistent and free of internal shorthand. Ask your national authority during onboarding how it shares cross-border notifications, and record that answer in your reporting procedure.

Record of customer communications

Keep a dated log of every notice sent to service recipients, including who approved it, what it said about cause and impact, and the channel used. This record is your evidence that notification happened without undue delay. Customer notices and regulator reports can describe the same incident with different facts, so compare them before each new submission. The compliance lead owns the log, and the communications owner keeps the source copies.

Reporting now versus the proposed single-entry point

This table compares two ways to design NIS2 reporting channels and templates: building for today's Article 23 duties only, or also structuring the process so one submission could later feed other regimes. Read each row against your own reporting volume and the regimes that already apply to you. The main takeaway is that the single-entry point is still a proposal, so the safe default is to build for current obligations and keep the data model flexible.

Option	When it fits	Internal effort	What it risks
Build for current NIS2 duties only	Entity is covered by NIS2 and few other incident reporting regimes, or the regimes are already handled separately	Lower upfront effort: one set of templates for the early warning, notification, intermediate and final reports	Rework later if a single-entry point or new reporting rules are adopted, and possible duplication of fields across regimes
Build for current duties with a shared incident record	Entity also reports personal data breaches under GDPR or falls under DORA, so the same facts reach several authorities	Moderate effort: one incident record with fields mapped to each regime's content requirements, reviewed by legal and compliance	Mapping errors if fields are copied between templates without legal review, and extra maintenance when any regime changes
Design for a future single-entry point now	Entity expects heavy multi-regime reporting and has leadership appetite to invest ahead of a legal decision	Highest effort: exporting data in structured formats, supporting multiple submission routes, and tracking a moving target	Designing around a proposal that may change or not pass, and spending effort on channels that a national authority never adopts
Confirm national channels before choosing a design	Any entity, as a first step, to confirm how its Member State receives notifications and whether it uses a single or separate channels	Low effort: written confirmation from the national CSIRT or competent authority and a check of guidance	Building to the wrong channel or format if national rules differ from the EU-level description
Keep the 24-hour and 72-hour clocks independent of the design	Any entity, regardless of which option it selects	Low to moderate effort: the clocks, roles and decision points are defined before any channel is built	Deadlines missed while the team waits for a tool or a channel to be finalized
Status of the Digital Omnibus proposal	Before any design work that assumes a single-entry point	Confirm with counsel or the national authority whether the proposal has been amended or adopted	Relying on the proposal as current law, since the Commission describes it as a proposal that would not modify existing reporting obligations

What usually delays reporting in practice

Most late or contradictory NIS2 reports trace back to a handful of gaps in how the organization records time, decides significance and rehearses its process. Each card names one failure, the consequence it creates for the report, and the control that prevents it, using evidence a supervisor can inspect.

Detection time is not recorded

The 24-hour early warning clock starts when the entity becomes aware of a significant incident, so the time of awareness is the fact everything else depends on. If the first alert, ticket or call is not timestamped in a system that cannot be edited after the fact, the entity cannot prove when the clock started. Fix it by logging the first detection event in the ticketing or SIEM system with a fixed time source and by keeping the raw alert alongside the incident record.

Significance decided informally

Whether an incident is significant depends on severe operational disruption, financial loss or considerable damage to others, and the assessment has to be explained later. When the decision is made in a chat message or a hallway conversation, there is no record of who decided, when, or on what facts. Fix it by requiring a short, dated significance assessment for every security incident above a defined threshold, signed by the person with reporting authority and stored with the incident file.

Nobody knows the reporting channel

Notifications go to the national CSIRT or, where the Member State provides, the competent authority, and the channel differs by country. An on-call engineer who must search for the portal in the middle of an incident loses time that counts against the deadline. Fix it by recording the exact national channel, the contact route for out-of-hours reporting, the required format and a named backup submitter in the incident response plan, and by checking those details against the national transposition law.

Early warning waits for full facts

Teams often hold the early warning until they understand root cause, which the 24-hour notice does not require. The early warning only needs to say whether the incident is suspected of unlawful or malicious acts and whether it could have cross-border impact, with the fuller assessment following in the notification. Fix it by preparing a short early-warning template with those fields, and by writing down what is still unknown so the gaps are visible to the supervisor.

Customer notices and regulator reports conflict

Where significant incidents are likely to affect service provision, customers must be told without undue delay, and those messages often go out before the regulator filing is settled. When the customer notice says one thing about impact or cause and the CSIRT filing says another, the inconsistency is itself a finding. Fix it by keeping one incident fact sheet as the single source for every message, with version numbers and an approver for each release.

The process has never been rehearsed

A plan that has never been run usually fails at the first handoff: the on-call person does not have access to the portal, the approver is on leave, or the timestamps are not captured. Rehearsal turns these gaps into dated findings before a real incident. Fix it by running tabletop exercises that walk through the early warning and notification steps, recording the times achieved, and documenting the corrective actions with owners and due dates.

Questions buyers ask about NIS2 incident reporting

When does the 24-hour early warning clock start?

The clock starts when the entity becomes aware of a significant incident, and the early warning must be submitted without undue delay and in any event within 24 hours of that moment. Awareness is the point at which the organization has enough information to judge that the incident is significant, so the decision on significance is itself time-critical. Document who made the awareness decision, when, and on what basis, because a supervisor will ask for that timeline. Make sure the on-call escalation path lets a qualified person reach that judgment outside office hours. Confirm with your national CSIRT or competent authority how it expects the time of awareness to be recorded and whether it offers a template for the early warning.

Can we file an early warning before we have the full facts?

Yes. The early warning is designed as a first signal within 24 hours, and the notification that follows updates it with an initial assessment. The early warning indicates whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact, where applicable. Incomplete information is normal at this stage, so state what is known, what is unknown and when the next update will come. Waiting for complete facts is the failure mode to avoid, because the 24-hour deadline does not move while the investigation continues. Rehearse this minimum-content report in exercises so the team can produce it quickly.

What happens if the incident is still ongoing when the final report is due?

The entity submits a progress report at the time the final report falls due, and then a final report within one month of handling the incident. The final report must describe the incident in detail, including severity, impact, the type of threat or likely root cause, and the mitigation measures applied and still ongoing. Plan for this from the start by keeping a running incident log with timestamps, decisions and evidence, so the progress report and later final report can be written from records rather than memory. Intermediate reports are required only when the CSIRT or competent authority requests them, so keep the status log ready for that request.

Can a managed SOC file the NIS2 reports for us?

A managed SOC can prepare, draft and transmit reports on the entity's behalf if the contract and the internal process allow it, but the obligation remains with the entity. The entity must still decide that an incident is significant, approve what is sent and be able to answer follow-up questions from the authority. Define in writing which steps the provider performs, which decisions stay with named internal roles, how after-hours escalation works and how the provider's evidence is handed over. Ask the provider to show how it times its alerts against the 24-hour and 72-hour points and what it records. Confirm with your national CSIRT whether delegated submission is accepted and through which channel.

What does the reporting process need from our internal team?

It needs named people who can make decisions under time pressure, not only people who can operate tools. At minimum, the entity needs a decision owner for significance, a person responsible for drafting and submitting reports, a technical lead who can describe the incident and its containment, and a contact who can speak for legal, privacy and communications. Those people need access to logs and asset inventories, a way to reach the management body, and authority to approve external statements. Time spent by these people on exercises and post-incident reviews is recurring effort, and the amount depends on the size of the organization and the number of services in scope. Confirm the internal effort with your advisers before committing budget.

Can we run NIS2 incident reporting in-house, and what does an implementation partner add?

Many organizations run reporting in-house, provided the people, roles, templates, logs and channels exist and have been tested. The entity owns its incident response, its reporting decisions and its compliance. An implementation partner such as DeployOpen can help prepare the systems that support this work, including logging, alerting, case management and self-hosted tooling that keeps incident records inside the client's own infrastructure, and can document the process and run exercises against it. The partner does not file reports on the entity's behalf unless the written scope says so, and it does not issue any compliance certificate. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope.

Does an auditor certify our NIS2 incident reporting process?

No. NIS2 does not create a certificate of compliance, so no auditor can issue one for the reporting process. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. An independent assessor may be engaged to test controls, and its report is evidence for the entity, not a NIS2 certificate. Any firm offering a NIS2 certificate should be asked to explain what legal basis it claims. Keep records of the process, exercises and reports ready for supervisors, because that record is what an authority will examine.

What should we confirm with our national CSIRT before an incident happens?

Confirm the reporting channel, the required format, and whether notifications go directly to the national CSIRT or through the competent authority that forwards them. Ask whether the Member State offers a technical reporting tool, what the early warning must contain in practice, how the authority wants cross-border impact described, and how updates are submitted. Also confirm whether delegated submission by a provider is accepted, what contact details must be registered, and who to call outside office hours. Write the answers into the response plan and test them in an exercise, because national rules, forms and channels differ by Member State and by sector.

How DeployOpen prepares NIS2 incident reporting

DeployOpen works on the NIS2 reporting process from detection to final report by preparing the systems, runbooks and evidence an entity needs to meet each deadline. The organization keeps ownership of its reporting decisions, and DeployOpen delivers the technical and documentary groundwork inside the client's own infrastructure.

How we scope

Engagements are fixed-scope, with the reporting stages, systems and teams agreed in writing before work starts.
The written scope names which incident types, detection sources and reporting channels are covered by the work.
Scope records who inside the organization owns each decision, including significance and the sign-off for each report.

How we build

We configure logging and alerting so detection feeds a triage path that can start the 24-hour clock quickly.
We prepare report templates that map to the early warning, notification, intermediate and final report contents.
We test the workflow with simulated incidents so gaps in timing, roles and evidence surface before a real event.

How we hand over

Deliverables include runbooks, escalation contacts, report templates and an evidence register for each reporting stage.
Each deliverable is documented so internal staff can operate and update the reporting process after handover.
We confirm with your legal and national competent authority contacts which reporting channel and format apply to you.

How we support

Ongoing support, upgrades and continuous testing of the reporting workflow are available as a retainer.
Retainers can cover periodic tabletop exercises that rehearse the early warning and notification deadlines.
Independent auditors and authorities assess compliance; DeployOpen prepares systems and evidence for those reviews.