NIS2 Incident Reporting: The 24 Hour, 72 Hour and One Month Clocks

Illustration for: NIS2 Incident Reporting: The 24 Hour, 72 Hour and One Month Clocks

NIS2 replaces the original NIS Directive across the EU and brings sharper teeth, wider scope, and three specific incident reporting deadlines. There is an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month of that notification. If your organisation is in scope, or supplies someone who is, these clocks need to be built into your incident process now, because they are far too short to design a response around mid-incident.

Who NIS2 applies to

NIS2 (Directive (EU) 2022/2555) applies to organisations operating in the EU across a much broader set of sectors than its predecessor. Entities are classed as either essential or important.

• Essential entities include energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure (DNS, cloud, data centres, trust services), public administration and space.
• Important entities include postal services, waste management, chemicals, food production and distribution, manufacturing of medical devices and other critical products, digital providers such as online marketplaces and search engines, and research organisations.

Broadly, entities with 50 or more staff or over 10 million euros turnover in a listed sector are captured, with some captured regardless of size, DNS providers being the obvious example. Both classes face the same reporting deadlines, and the difference lies mainly in supervision intensity and penalty ceilings, which reach 10 million euros or 2 per cent of global turnover for essential entities. Management bodies carry personal accountability for compliance, which has done wonders for board attention.

The UK position needs stating carefully, because it trips people up. NIS2 is EU law and does not apply in the UK. The UK still runs the NIS Regulations 2018, and the government’s Cyber Security and Resilience Bill is intended to update them along broadly similar lines. But a UK organisation is not necessarily off the hook, and it is worth separating the two ways it reaches you. If you provide in-scope services within the EU, establishment rules can bring you directly within NIS2 in your own right. If you merely supply an EU essential or important entity, that alone does not make you a regulated entity, but your customer’s own supply chain duties will arrive as contract clauses instead. Many UK firms will meet NIS2 obligations contractually well before UK law changes. Do not assume Brexit removed the problem.

What counts as a significant incident

The reporting duty attaches to significant incidents. NIS2 defines these as incidents that have caused, or are capable of causing, severe operational disruption to services or financial loss for the entity, or that have affected or can affect other natural or legal persons by causing considerable material or non-material damage. An implementing regulation adds specific thresholds for digital infrastructure and digital providers, including complete service unavailability beyond set durations, and events such as compromise of data integrity or confidentiality, or repeated related incidents within six months.

Two points come out of practice. First, “capable of causing” means you cannot wait for impact to fully materialise before the clock starts, so a ransomware detonation contained within an hour may still qualify if it could have taken out the service. Second, near-threshold judgement calls at 2am go badly without pre-agreed criteria. Write your own significance thresholds, mapped to your services, and have counsel and your CISO agree them in daylight.

Reporting is the visible end of a wider duty

The clocks get the attention, but NIS2 does not treat reporting as a standalone obligation. Article 21 requires every in-scope entity to run cyber security risk management measures, and your significance thresholds should fall out of that work rather than be invented for the reporting form. In practice that means a structured and repeatable risk management framework covering technical, operational and organisational risks, with a defined assessment methodology behind it. The methodology identifies the threats, vulnerabilities and potential impacts to your network and information systems, evaluates and prioritises risks by likelihood and business impact, and flags the areas that need treatment or stronger controls. Run properly, it also gives management the evidence to make treatment decisions that line up with business objectives and regulatory requirements, which matters under a directive that holds management bodies personally accountable. If you already know which services would hurt most and how, the 2am significance call becomes a lookup rather than a debate.

Cycle diagram of a risk management framework identifying threats, evaluating impact, prioritising and treating risks, feeding NIS2 significance thresholds and the reporting clocks

Significance thresholds and reporting readiness both fall out of the same risk cycle. If the framework is running, the 2am call is already half made.

The three clocks

The first two deadlines run from when you become aware of the significant incident. The third does not, and this is the detail most often misread, because the final report is due within one month of the 72 hour notification rather than one month from awareness. All reports go to your national CSIRT or competent authority.

• Early warning, within 24 hours. A short flag, not an analysis. It must indicate whether the incident is suspected to be caused by unlawful or malicious action, and whether it could have cross-border impact. It exists so the authority can warn others and offer help. You are not expected to have root cause, you are expected to have picked up the phone.
• Incident notification, within 72 hours. An update to the early warning with an initial assessment of the incident, covering its severity and impact, and indicators of compromise where available. This is the substantive notification, and it lands while you are still likely to be in active response.
• Final report, within one month of the notification. A detailed account giving a description of the incident, its severity and impact, the threat type or root cause likely to have triggered it, mitigation measures applied and ongoing, and cross-border impact where relevant. If the incident is still running at the one-month mark, you provide a progress report and the final report within a month of resolution.

Timeline of the three NIS2 reporting clocks showing the 24 hour early warning and 72 hour incident notification measured from awareness, and the final report measured from the 72 hour notification

The early warning and the notification both run from awareness. The final report is the exception, because its month runs from the 72 hour notification, which can put the deadline several days later than a plain reading suggests.

Authorities can also request intermediate status updates at any point, and where the public interest requires it you may be directed to inform the public. Separately, if the incident involves personal data, the UK or EU GDPR’s 72 hour clock to the data protection authority runs in parallel as its own obligation with its own content requirements. One incident can easily mean two regulators and, for regulated sectors like financial services under DORA, a third.

Swimlane diagram of one incident feeding parallel reporting clocks for NIS2, GDPR and DORA regulators

One incident can mean two or three regulators, and their clocks run in parallel, not in sequence.

Why 24 hours is harder than it sounds

Seventy-two hours is familiar territory from GDPR. Twenty-four is not, and it compresses several steps that most organisations have never timed, running from detection to escalation, escalation to significance decision, decision to drafting, drafting to legal sign-off, and sign-off to submission through whatever portal the authority runs. In exercises I have run, the legal review step alone eats half a day when nobody pre-agreed what may be said. If your incident process needs a committee to approve external communications, the 24 hour clock is already lost.

Stacked bar showing an unprepared 24 hours consumed by escalation, significance, drafting and legal sign off overrunning the deadline, with a prepared response finishing in ten hours

Without pre agreed wording the legal review alone can eat half a day, while preparation brings the early warning comfortably inside 24 hours.

The fix is preparation, and none of it is clever.

• Decide who owns the clock. One named role, with a deputy, has authority to declare significance and submit the early warning without further approval.
• Pre-draft the templates. The early warning fields are known, so build a form that can be completed in 20 minutes. Do the same for the 72 hour notification and the final report.
• Build a decision tree. Detection type in, significance verdict out, with the ambiguous cases routed to a fast conversation rather than an open-ended debate. Include the parallel question of whether GDPR, DORA or sector regulators are also triggered. Then put the tree inside your business continuity and incident response documentation, because a decision aid nobody can find at 2am is decoration.
• Know your authority. Which member state, which CSIRT, which portal, what credentials. If you operate in several member states, map which establishment reports where, before the incident.
• Rehearse against the clock. Run a tabletop where the scenario starts at 16:40 on a Friday and the early warning is due before Saturday teatime. Measure where the time goes. The real product of the exercise is the list of residual gaps it surfaces, so turn each one into an action with an owner, not a lesson observed.

What to do this quarter

Confirm scope first. Are you an essential or important entity in any EU member state, and do any customer contracts pass NIS2 obligations to you? Then write your significance criteria, name the clock owner, and draft the three templates. Finish with a timed exercise. An organisation that has rehearsed the 24 hour report once will submit a competent one under pressure. An organisation reading the directive for the first time during an incident will not, and the final report will have to explain why.

NIS2 regulatory reporting countdown clocks in RaptorGRC

Regulatory reporting clocks in RaptorGRC.