NIS2 has one clock a software company cannot outsource: the reporting of a significant incident, in Article 23, in three steps with three deadlines counted in hours and months from the moment the entity becomes aware. The CRA has its own clock for actively exploited vulnerabilities and the GDPR its 72 hours for a personal data breach, and the router article says which runs; this one is about the NIS2 clock itself, what each of its three reports contains, and when an incident is significant enough to start it, read against the catalogue StandardOS keeps of the Directive and the free page that computes the deadlines and writes the reports.
The three deadlines of Article 23(4)
Article 23(4) counts from awareness of a significant incident. Point (a): an early warning without undue delay and in any event within 24 hours, which, where applicable, says whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact. Point (b): an incident notification without undue delay and in any event within 72 hours, which updates the early warning and gives an initial assessment of the incident, including its severity and impact, and, where available, the indicators of compromise; a trust service provider gives that notification within 24 hours (Article 23(4), second subparagraph). Point (c): an intermediate report on relevant status updates, on the request of the CSIRT or the competent authority. Point (d): a final report not later than one month after the submission of the notification, with four contents: a detailed description of the incident including its severity and impact, the type of threat or root cause likely to have triggered it, the applied and ongoing mitigation measures, and, where applicable, the cross-border impact. Point (e): where the incident is still ongoing when the final report is due, a progress report then and the final report within one month of the handling of the incident. The recipient is the CSIRT or, where the member state so provides, the competent authority (Article 23(1)), and where appropriate the recipients of the services are told without undue delay of a significant incident likely to affect them. The free page names the CSIRT of the state from the CSIRTs Network's register, computes the three deadlines, and counts the month of the final report from the notification's own deadline until the submission time is entered.
What makes an incident significant
Article 23(3) of the Directive sets two conditions, either of which makes an incident significant: it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. For the digital providers, Implementing Regulation (EU) 2024/2690 goes further and says in numbers when those conditions are met. Article 3(1) lists seven general criteria, any one of which is enough: a direct financial loss exceeding EUR 500 000 or 5 % of the entity's total annual turnover in the preceding financial year, whichever is lower; the exfiltration of trade secrets; the death of a natural person; considerable damage to a natural person's health; a successful, suspectedly malicious and unauthorised access to network and information systems capable of causing severe operational disruption; recurring incidents that together meet the financial criterion (Article 4: at least twice within six months, the same apparent root cause); or one of the per-service criteria of Articles 5 to 14. For a cloud computing service provider Article 7 sets four: the service completely unavailable for more than 30 minutes; its availability limited for more than 5 % of its users in the Union or more than 1 million of them, whichever is smaller, for more than one hour; the integrity, confidentiality or authenticity of the data compromised as a result of a suspectedly malicious action; or such a compromise with an impact on more than 5 % or 1 million of the users in the Union, whichever is smaller. Article 10 sets the same four for managed and managed security service providers. Article 3(2) takes scheduled interruptions and planned maintenance out. So a SaaS outage of 31 minutes is a significant incident and starts the 24-hour clock; a planned maintenance window of two hours is not; a phishing email that reached one inbox is not, unless the account was used to reach the systems.
What each report says, and what it must not wait for
The early warning is two flags and a timestamp: malicious or not, cross-border or not, sent within 24 hours even where the answers are "not yet known". The notification is the first assessment: what happened, how severe, what is affected, with the indicators of compromise where the company has them; it is due within 72 hours and is not held back for the forensic report. The final report is the record: the description with severity and impact, the root cause or type of threat, the measures applied and still ongoing, and the cross-border impact where there is one, one month after the notification. None of the three waits for the incident to be over: Article 23(4)(e) is written for exactly the incident that is still open at the final report's deadline, and the progress report is its answer. A software company that reports late because it wanted the full picture has reported late; the Directive's design is that the picture is built in three steps.
Two clocks beside it
A software company that is a NIS2 entity is often a GDPR controller or processor as well, and the same incident that reaches the CSIRT within 24 hours reaches the supervisory authority within 72 where personal data are affected, on the GDPR breach clock, and the manufacturer of a product with digital elements reports an actively exploited vulnerability to ENISA's single reporting platform on the CRA's 24-hour, 72-hour and 14-day clock. The three clocks run from one moment of awareness with three different recipients and three different thresholds, which is why the one thing to fix in advance is the record that starts them: the incident logged with its timestamp, the systems affected, the data affected, and the products affected, so that each report is a rendering of the same record rather than a separate investigation.
What to do with it
Decide today which provider kind the company is under the Implementing Regulation and put its thresholds into the incident procedure as the test for "significant". Name the CSIRT of the state, or the competent authority where the transposing law chose it, with its portal and its contact, before the first incident. Run the free page once with a past incident to see the three reports it writes, then keep its link with the moment of awareness in it as the incident's first record. StandardOS opens the clock from the incident record and drafts the three reports from it; the scope tool says whether the company is an essential or important entity in the first place.