NIS2 Incident Reporting Timeline: 24 Hours, 72 Hours, and One Month

Under NIS2, a significant incident triggers a staged reporting process: an early warning within 24 hours of becoming aware of the incident, an incident notification within 72 hours of awareness, and a final report no later than one month after the incident notification. If the incident is still ongoing at that point, the entity submits a progress report and then a final report within one month after handling the incident.

The clock does not start because any security alert appeared. Article 23 applies when an essential or important entity becomes aware of a significant incident. That distinction matters: teams need a fast internal path from detection to significance assessment, because spending a day arguing about ownership can consume most of the first reporting window.

There is also one wording trap worth removing early. NIS2 says "one month," not "30 days." Those phrases are often treated as interchangeable in summaries, but they are not the same legal deadline.

Free guide

Build the reporting clock into the response plan before an incident

Use Q-Sec's NIS2 Incident Response Plan Template to structure escalation, the 24-hour and 72-hour stages, and reporting decisions, actions, and evidence.

Get the NIS2 Incident Response Plan

What is the NIS2 incident reporting timeline?

Article 23 uses a sequence rather than one all-purpose report. Each stage has a different job, so the information can become more complete as the investigation develops.

The baseline comes from Article 23(4) of the NIS2 Directive. The early warning and incident notification both run from awareness of the significant incident; the final report runs from the submission of the incident notification.

When does the NIS2 reporting clock start?

The Article 23 clock starts when the entity becomes aware of a significant incident. It does not run from the attacker's first action, the first log entry, or the moment a monitoring tool generated an alert.

That still leaves an operational question: when has the organization moved from "something suspicious happened" to "we are aware of a significant incident"? The Directive itself does not turn that into a universal minute-by-minute test for every sector.

For the entity categories covered by Commission Implementing Regulation (EU) 2024/2690, the Regulation gives a useful clarification. An entity is regarded as aware when, after an initial assessment, it has a reasonable degree of certainty that a significant incident has occurred. That wording applies to the categories covered by the Regulation and should not be presented as a blanket threshold for every NIS2 entity.

Operationally, the important part is speed and ownership. A security team needs to know who can classify the event, who decides whether Article 23 is triggered, and who can submit the notification. Otherwise, the legal clock can be lost inside an internal handoff.

What counts as a significant incident under NIS2?

NIS2 does not require every security event to be reported under Article 23. The incident must have a significant impact on the provision of the entity's services.

Article 23(3) says an incident is significant when one of the following conditions is met:

• It has caused or is capable of causing severe operational disruption of services or financial loss for the entity.
• It has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

The phrase "is capable of causing" matters. An organization does not always have to wait for the full damage to materialize before deciding that the incident is significant.

Some digital and ICT service providers have more detailed rules. Commission Implementing Regulation (EU) 2024/2690 sets specific significance criteria for DNS providers, TLD registries, cloud and data-center providers, content delivery networks, managed service and managed security service providers, online marketplaces, search engines, social-networking platforms, and trust service providers.

Those sector-specific criteria include concrete thresholds and incident types. They belong only to the entity categories named in the 2024/2690 implementing regulation, not to every organization covered by NIS2.

What must be sent within 24 hours?

The first NIS2 submission is an early warning, not a finished forensic report. Its purpose is to alert the CSIRT or competent authority quickly while the organization is still establishing the full picture.

Where applicable, the early warning should indicate whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact.

At this stage, the organization may still have open questions about root cause, affected systems, and full business impact. That is expected. The Directive deliberately separates the early warning from the later incident notification so reporting does not wait for perfect certainty.

The practical mistake to avoid is making the 24-hour submission carry the weight of the final report. If internal policy says "do not report until every field is complete," the policy is fighting the structure of Article 23.

What must be sent within 72 hours?

The 72-hour incident notification is the first fuller assessment. It updates the early warning and adds information the organization has established during the first phase of investigation.

Article 23 says the incident notification should include an initial assessment of the significant incident, including its severity and impact, plus indicators of compromise where they are available.

This is still not the final report. A root cause can remain provisional, containment can still be under way, and some affected assets or users may not yet be fully known. The submission should distinguish confirmed facts from working assessments rather than fill gaps with certainty the team does not have.

Is the 72-hour deadline different for trust service providers?

Yes. For a trust service provider reporting a significant incident that affects the provision of its trust services, Article 23(4) sets the incident-notification deadline at 24 hours rather than the standard 72 hours.

That is a specific exception. It should not be generalized to other NIS2 sectors.

What belongs in the one-month final report?

The final report closes the standard NIS2 reporting sequence once the organization has had enough time to investigate the incident properly. The deadline is no later than one month after the incident notification, not 30 days after awareness.

Article 23 requires the final report to cover the following information:

• A detailed description of the incident, including severity and impact.
• The type of threat or likely root cause that triggered it.
• Applied and ongoing mitigation measures.
• Cross-border impact where applicable.

If the incident is still ongoing when that final-report point arrives, the organization submits a progress report instead. The final report then follows within one month after the incident has been handled.

An intermediate report sits outside that fixed sequence. The CSIRT or competent authority can request one when it needs relevant status updates; Article 23 does not assign it an automatic universal deadline of its own.

Do affected customers or service recipients have to be notified too?

Sometimes. Article 23 separates reporting to authorities from communication to service recipients.

Where appropriate, an entity should notify recipients of its services without undue delay when a significant incident is likely to adversely affect those services. Where applicable, entities must also communicate measures or remedies that recipients can take in response to a significant cyber threat and, where appropriate, inform them about the threat itself.

The Directive does not put those recipient communications on the same fixed 24-hour and 72-hour schedule used for the authority reporting stages. The trigger and timing are framed as "without undue delay."

This is one reason an incident communication plan should not be a copy of the regulatory form. Regulators, customers, partners, and employees can need different information at different points.

Who should own the reporting workflow inside the organization?

NIS2 tells the entity what must be reported and by when. It does not assign one universal corporate job title to every step. The internal workflow still needs named decision rights.

Before an incident, the organization should decide how the reporting path moves through these functions:

• Detection and investigation: who establishes what happened and how serious it is.
• Significance assessment: who decides whether Article 23 has been triggered.
• Legal and regulatory routing: who identifies the competent national reporting channel and any overlapping reporting regime.
• Executive escalation: who is informed when the incident affects business continuity, customers, or regulatory exposure.
• Submission authority: who can send the early warning and later reports without waiting for an unavailable executive.
• Evidence retention: who keeps the submitted versions, timestamps, source records, decisions, and later corrections.

The point is not to turn a security incident into a committee meeting. It is to remove the question "who is allowed to decide?" while the clock is already moving.

Read NIS2 Management Responsibility and Liability Under Article 20. See what management must approve and oversee and where operational delegation stops.

How should teams prepare for the NIS2 reporting clock?

A usable reporting process is built before the incident. The preparation work is mostly about decisions, access, and evidence rather than writing a perfect report in advance.

A practical sequence looks like this:

• Define the internal significance-assessment path and who can make the call.
• Map the competent authority or CSIRT and reporting portal for each relevant Member State and legal entity.
• Pre-assign owners for the early warning, incident notification, customer communication, and final report.
• Make sure technical teams can provide timestamps, impact information, indicators of compromise, and mitigation status quickly.
• Keep a record of what was known at each submission point so later updates do not rewrite the history of the incident.
• Test the workflow with a scenario where the facts are incomplete. That is closer to a real 24-hour window than a tabletop exercise where every answer is already printed in the script.

What if another EU law also requires incident reporting?

Do not assume that every overlapping EU regime means sending the same incident through two complete reporting tracks. NIS2 Article 4 contains a sector-specific rule: where another EU legal act imposes cybersecurity risk-management or incident-reporting requirements that are at least equivalent in effect, the corresponding NIS2 provisions do not apply to the entities covered by that sector-specific act.

The equivalence test is specific, and the sector-specific notifications need to be accessible to the NIS2 authorities in the way Article 4 requires. Financial entities under DORA are the obvious example, but the exact reporting route should be mapped from the entity's legal scope rather than guessed from the incident type.

Read DORA vs. NIS2: Obligations for Dual-Scope Entities. Use the dedicated comparison when published to determine which framework owns the reporting obligation.

Has the NIS2 reporting process changed in 2026?

The legal deadlines have not changed. The standard Article 23 sequence remains 24 hours, 72 hours, and one month.

What is changing is the reporting format. In May 2026, the NIS Cooperation Group agreed common incident-reporting templates intended to reduce differences between Member States. The European Commission said the next step is to adopt those templates through an implementing act so they become mandatory across the EU.

The Commission also refers to a proposed single-entry point for incident reporting under the Digital Omnibus. As of 24 August 2026, that work should be treated as a simplification initiative in progress, not as a replacement for the current Article 23 deadlines or the reporting channel required by national law. See the European Commission update on the common templates.

Final thoughts: Make the clock part of incident response, not an afterthought

The difficult part of NIS2 reporting is rarely remembering the numbers. It is reaching a defensible significance decision, collecting enough information for the next stage, and getting the submission out while the technical response is still moving.

A workable process keeps those jobs connected. Detection feeds classification. Classification triggers the reporting path. Each submission records what is known at that moment, and the later stages update the picture instead of pretending the first 24 hours produced a complete answer.

Frequently asked questions about the NIS2 reporting timeline

What is the NIS2 incident reporting deadline?

For a significant incident, the standard sequence is an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report no later than one month after the incident notification.

Does NIS2 require reporting within 24 hours?

Yes, for significant incidents. The first step is an early warning within 24 hours of awareness. It is not the same as the fuller 72-hour incident notification.

What must be reported within 72 hours under NIS2?

The incident notification updates the early warning and provides an initial assessment of severity and impact, plus indicators of compromise where available.

Is the final NIS2 report due in 30 days?

The Directive says no later than one month after the incident notification. "30 days" is a common shorthand, but it is not the legal wording.

When does the NIS2 reporting clock start?

The clock starts when the entity becomes aware of a significant incident. It does not automatically start from the first alert, first malicious action, or first log entry.

Do all cybersecurity incidents have to be reported under NIS2?

No. Article 23 reporting applies to significant incidents. The Directive defines significance by severe disruption or financial loss or considerable material or non-material damage to others.

What happens if the incident is still ongoing after one month?

At the point when the final report would be due, the entity provides a progress report. The final report is then due within one month after the incident has been handled.

Are trust service providers on the same 72-hour deadline?

Not for the incident notification affecting trust services. Article 23 sets that notification at no later than 24 hours after awareness of the significant incident.