NIS2 Directive

Incident handling here is the internal capability to detect, triage, contain, eradicate, recover from and learn from incidents. It is separate from the reporting duty in Article 23: reporting tells the authority what happened, handling is what the entity does about it. The capability needs defined severity levels, an escalation path that reaches decision makers out of hours, named responsibilities, and evidence that it functions rather than exists on paper. Post-incident review matters because it is the link back to Article 21(2)(f), where the effectiveness of the measures is assessed. The classification scheme deserves particular attention, because the same triage has to be able to recognise a significant incident under Article 23(3) and start the 24-hour clock.

What an assessor asks to see: The incident handling procedure with severity levels, roles and escalation paths; Incident records for a representative period showing detection, containment and recovery times; Evidence of out-of-hours coverage and of how escalation reaches decision makers; Post-incident review outputs and the actions they generated, with closure evidence. Where it usually falls short: A response plan that has never been exercised against a realistic scenario

This category asks the entity to be able to keep providing its services, or to restore them, when systems fail or are attacked. Backup management means backups that are taken, protected against the same event that takes out production, and demonstrably restorable, which is why restore testing rather than backup success rate is the evidence that counts. Disaster recovery means recovery objectives that were derived from what the service can actually tolerate, and infrastructure and procedure capable of meeting them. Crisis management is the decision-making layer above both: who declares a crisis, who can commit the organisation, how the entity communicates while under pressure. Because NIS2 is concerned with continuity of service to recipients, recovery objectives set purely from internal convenience are the usual weak point.

What an assessor asks to see: Business impact analysis deriving recovery time and recovery point objectives from service tolerance; Backup configuration showing isolation or immutability against destructive attack; Restore test results, dated, covering the systems that carry the essential service; The crisis management plan naming decision authority, activation criteria and communications routes. Where it usually falls short: Backups verified as completed but never restored end to end

Two duties travel together in this point. The first is that security is built into how systems are acquired, developed and maintained: security requirements set before purchase or build, secure development practice, change control, and maintenance that does not quietly reintroduce weakness. The second is vulnerability handling and disclosure, meaning the entity can receive a vulnerability report about its own products or systems, triage it, fix it on a timescale that reflects severity, and handle disclosure. A published route for a finder to reach the entity is the part most often missing, and its absence is visible from outside. Note that the coordinator role and the European vulnerability database in Article 12 belong to the CSIRTs and ENISA; what binds the entity is its own handling and disclosure capability.

What an assessor asks to see: Security requirements applied in procurement and in the development lifecycle, with gate evidence; Secure development practices in use, such as design review, code analysis and dependency scanning, with output; Change and maintenance control records for in-scope systems; A published contact route for vulnerability reports, and the triage procedure behind it. Where it usually falls short: Security requirements defined for new build only, leaving acquired and inherited systems untouched

The core reporting duty attaches to any incident with a significant impact on the provision of the entity's services. Article 23(3) fixes the threshold: an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Capable of causing matters, because it brings in near-miss and contained events that could have gone further. Notification goes to the CSIRT or, where the Member State so provides, the competent authority, without undue delay, and must carry whatever lets the recipient determine cross-border impact. Where appropriate the entity must also tell the recipients of its services about significant incidents likely to affect service delivery. The Directive states that notifying does not of itself increase the notifying entity's liability, which removes one common reason for delay.

What an assessor asks to see: The documented significance test, expressed against the Article 23(3) limbs including capable of causing; The determination record for each candidate incident, including reasoned decisions not to report; Notifications as submitted, with timestamps, and the identity of the receiving CSIRT or authority; Cross-border impact information captured and included in the notification. Where it usually falls short: Threshold applied only to realised impact, so contained incidents capable of severe disruption go unreported

The first stage of the layered reporting regime falls due without undue delay and in any event within 24 hours of becoming aware of the significant incident. The early warning is deliberately light: where applicable it indicates whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have cross-border impact. It is not a full assessment and waiting for one is the classic way to miss the deadline. Two operational points decide whether an entity can meet this. First, becoming aware has to be defined and evidenced, because the clock starts there and an entity that cannot say when it knew cannot show it reported in time. Second, submission has to be possible at any hour, since a Friday night detection has the same 24 hours as a Tuesday morning one. The CSIRT or authority is expected to respond within 24 hours where possible, so the channel is two-way.

What an assessor asks to see: The definition of becoming aware and the evidence trail that fixes that moment per incident; Submitted early warnings with timestamps, measured against the 24-hour limit; Out-of-hours submission capability, including named authorised submitters and their credentials; The judgement recorded on suspected unlawful or malicious cause and on cross-border impact. Where it usually falls short: Awareness treated as the moment of executive briefing rather than of qualified detection

Within 72 hours of becoming aware, the entity updates the early warning and provides an initial assessment of the significant incident covering its severity and impact, together with indicators of compromise where those are available. The 72 hours runs from awareness, not from the early warning, so the two clocks start together. Trust service providers are held to a shorter deadline: for significant incidents affecting the provision of their trust services they must notify within 24 hours. The practical demand here is investigative rather than administrative, since the entity needs enough forensic capability within three days to characterise severity and impact honestly and to extract indicators worth sharing. Producing indicators requires that the telemetry existed before the incident.

What an assessor asks to see: Submitted notifications with timestamps measured from the awareness moment; The initial severity and impact assessment as submitted, and the basis for it; Indicators of compromise shared, and the telemetry and tooling they were derived from; Where the entity is a trust service provider, evidence the shorter 24-hour deadline is built into the procedure. Where it usually falls short: 72 hours counted from the early warning rather than from awareness

One month after the 72-hour notification the entity owes a final report containing 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 where applicable the cross-border impact. If the incident is still ongoing when that month expires, the entity provides a progress report at that point and then a final report within one month of finishing its handling of the incident. Root cause is the demanding element: a report that names the immediate technical trigger without reaching the reason the condition existed does not meet the standard, and it is also the element that determines whether the entity learns anything. The mitigation section must distinguish what is already done from what is still in progress.

What an assessor asks to see: Final reports as submitted, with the date measured one month from the notification; Root cause analysis output, reaching the underlying condition rather than the immediate trigger; The mitigation record separating completed measures from ongoing ones, with owners and dates; Cross-border impact assessment where applicable. Where it usually falls short: Root cause given as the exploited vulnerability with no account of why it was exposed