NIS2 Ransomware Reporting: Why the 24-Hour Clock Starts at Suspicion and Encryption Alone Can Be Significant

Three hours into a ransomware event, nobody in the room knows what the incident cost. The finance director cannot tell you whether losses will pass EUR 500,000. The forensics lead cannot tell you whether data left the building. And yet the NIS2 clock has been running since the moment someone read the ransom note.

Most reporting guides open with the financial threshold — the one number you cannot calculate while the incident is live. NIS2 does not ask you to calculate it. Ransomware reaches the significance threshold through a different door entirely, and knowing which door changes what you file and when.

ENISA analysed 4,875 incidents between 1 July 2024 and 30 June 2025 and identified ransomware as the most impactful threat in the EU. Of those incidents, 53.7% concerned entities that qualify as essential under NIS2 [4]. This is the scenario the reporting regime was built around.

Does This Apply to You? Two Different Significance Tests

Before anything else: which rulebook governs your incident depends on what kind of entity you are. Two separate tests exist, and most articles collapse them into one.

Your entity type	Which significance test governs	Where the detail lives
Essential or important entity in any sector (energy, health, transport, water, manufacturing, food, public administration, chemicals, postal, waste, research)	Article 23(3) of the Directive — the two-limb test	Directive (EU) 2022/2555, Article 23 [1]
DNS providers, TLD registries, cloud providers, data centre operators, CDN providers, MSPs, MSSPs, online marketplaces, search engines, social platforms, trust service providers	Article 23(3) plus the binding quantified criteria in Implementing Regulation (EU) 2024/2690	CIR 2024/2690, Articles 1, 3 and 5–14 [3]
Out of scope entirely (below the size thresholds and not specifically designated)	No NIS2 reporting duty — but GDPR, sector rules and contracts may still bite	National transposition law

The distinction matters more than it looks. CIR 2024/2690 formally binds only the eleven digital-provider categories listed in its Article 1 [3]. If you are a hospital or a water utility, its numbers are a useful interpretive benchmark and nothing more — your legal test is the Directive’s own wording. Treating the CIR Annex as a binding checklist for a non-digital sector is one of the most common errors in circulation.

Why Encryption Alone Can Make a Ransomware Incident Significant

For an in-scope digital provider, ransomware clears the bar on contact. Article 3(1) of CIR 2024/2690 lists several independent criteria, and any one of them is enough. Point (e) covers a successful, suspectedly malicious and unauthorised access to network and information systems that is capable of causing severe operational disruption [3]. Successful encryption of production systems satisfies every element of that sentence — the access happened, it was malicious, it was unauthorised, and it is plainly capable of severe disruption. No euro figure is required.

Everyone else works from Article 23(3), which treats an incident as significant where it has caused or is capable of causing severe operational disruption of the services or financial loss, or where it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage [1]. Either limb alone is enough.

Read the verb tense. “Is capable of causing” is prospective, not retrospective. It asks what the incident could do, not what it happened to do before your team contained it. That is why the common instinct — we restored from backup in six hours, so there was no severe disruption, so nothing to report — is a misreading. A fast restore is evidence of good business continuity practice; it does not retroactively strip an encryption event of its capability. The reasoning that gets you to “not significant” has to be about the incident’s potential, and it has to be written down before you rely on it.

The financial threshold sits inside this picture as a sufficient condition, not a necessary one. Where it applies, CIR Article 3(1)(a) sets direct financial loss above EUR 500,000 or 5% of total annual turnover, whichever is lower [3]. Note the comparator: lower, not higher. For a EUR 4M-turnover managed service provider the operative figure is EUR 200,000, not EUR 500,000. Crossing it makes an incident significant — but failing to cross it proves nothing, because points (b) through (e) are still open. Our guide to the Article 23(3) two-limb test works through the general thresholds in more detail.

One edge case worth flagging: if attackers retain a foothold and re-encrypt weeks later, CIR Article 4 aggregates incidents that are individually below threshold into a single significant incident where they occur at least twice within six months, share the same apparent root cause, and collectively meet the financial criterion [3]. Incomplete eviction is a reporting problem as well as a security one.

The 24-Hour Clock Starts at Suspicion, Not Confirmation

Article 23(4)(a) requires an early warning without undue delay and in any event within 24 hours of becoming aware of the significant incident [2]. Awareness, not confirmation. The clock does not wait for your incident response retainer to arrive, for the forensic image to complete, or for the executive committee to convene on Monday morning.

The operative text settles the argument on its own terms. The early warning has to indicate whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have cross-border impact [2]. A provision built around suspicion cannot sensibly require certainty before it fires. For ransomware the first flag is answered before you open the form: an extortion note is, by definition, a suspected malicious act.

Article 23(1) removes the remaining hesitation directly: the mere act of notification shall not subject the notifying entity to increased liability [1]. Filing an early warning that later turns out to describe a contained, non-significant event costs you nothing legally. Missing the window on an event that turns out to be significant is itself an infringement of Article 23.

In practice a compliant early warning is short. Entity identifier, time of detection, systems affected as currently understood, suspected malicious act (yes), cross-border impact (known, suspected or not yet assessed). Anything you do not know yet is answered “under investigation” — that is what the 72-hour update exists to correct.

The Three Filings — and the Deadline Most Teams Get Wrong

Filing	Deadline	What it must contain
Early warning — Art. 23(4)(a)	Within 24 hours of becoming aware	Whether the incident is suspected to be caused by unlawful or malicious acts; whether it could have cross-border impact
Incident notification — Art. 23(4)(b)	Within 72 hours of becoming aware	Update the early warning; initial assessment of severity and impact; indicators of compromise where available
Intermediate report — Art. 23(4)(c)	On request of the CSIRT or competent authority	Relevant status updates
Final report — Art. 23(4)(d)	Within one month of submitting the 72-hour notification	Detailed description including severity and impact; type of threat or likely root cause; applied and ongoing mitigation measures; cross-border impact where applicable
Progress report — Art. 23(4)(e)	At the point the final report would otherwise be due, if the incident is still ongoing	Progress to date, with the final report due within one month of completing your handling of the incident

The deadline teams miscalculate is the last one in the main sequence. Article 23(4)(d) sets the final report at not later than one month after the submission of the incident notification under point (b) [2]. The month runs from your 72-hour filing, not from the attack. If you notified on day three, the final report is due on day 33 — and if you notified early, on day one, you have shortened your own final-report window by two days. That is a scheduling detail worth putting in the runbook rather than rediscovering at day 28. Our step-by-step Article 23 notification walkthrough and the broader NIS2 incident reporting guide cover the generic mechanics for non-ransomware events.

Filing Three Reports When Your Evidence Is Encrypted

The reporting regime assumes you can reach your own records. Ransomware is the one incident class where that assumption fails.

The 72-hour notification asks for indicators of compromise where available [2]. That qualifier is doing real work. If your SIEM sits on the encrypted domain, the IOCs are genuinely unavailable and saying so is a complete answer — provided you say it rather than leaving the field blank. Regulators read an empty field as an omission and a stated limitation as an assessment.

Three practical consequences follow, and they belong in the plan rather than the incident:

• Keep the filing inputs off the domain. Entity registration details, CSIRT portal credentials, competent authority contacts and the notification forms themselves need to exist somewhere the attacker did not reach — printed, or on an independently authenticated service. A notification template stored on the file server you cannot open is not a control.
• Image before you restore. Article 23(4)(d)(ii) requires the type of threat or likely root cause in the final report [1]. Rebuilding from backup without preserving forensic copies destroys the evidence that answers it, and the answer is due 30 days later.
• Fix the out-of-band contact route first. Article 23 also expects entities, where appropriate, to inform recipients of their services about incidents likely to affect service provision, and to tell them about measures or remedies available in response to a significant cyber threat [1][2]. If customer contact data lives only in the encrypted CRM, that duty is unfulfillable. Our incident communication plan guide covers the escalation and disclosure side in depth.

One asset you do get for free: under Article 23(5) the CSIRT or competent authority must respond to your early warning within 24 hours with initial feedback and, on request, guidance or operational advice on mitigation — and where the incident is suspected to be criminal in nature, guidance on reporting it to law enforcement [2]. During a ransomware event that is a live technical channel, not a formality. Ask for it.

Ransom Payment: What NIS2 Makes You Say, and What It Does Not

NIS2 contains no field asking whether you paid — there is no ransom-disclosure obligation anywhere in Article 23. That is narrower reassurance than it first appears. The final report must set out applied and ongoing mitigation measures and the likely root cause [1], and if your recovery route was a purchased decryptor rather than a restore, describing your mitigation truthfully is difficult without disclosing it. Article 23(4)(d) does not name payment; it makes silence about it awkward.

Question	Restore from backup	Pay the ransom
Does the Article 23 reporting duty end?	No — all three filings still due	No — all three filings still due
Does it satisfy Article 21 risk-management measures?	Tested backups are evidence for the business continuity measure	No — payment is not a security measure and evidences nothing
Does the root-cause obligation change?	No — still due at one month	No, and a decryptor destroys less evidence than a rebuild only if you imaged first
New legal exposure created?	None beyond the incident itself	Potential EU sanctions exposure — see below

The sanctions point deserves its own sentence because it is the one most boards have not priced. Council Regulation (EU) 2019/796 freezes all funds and economic resources belonging to, owned, held or controlled by persons and entities listed in its Annex I, and prohibits making funds or economic resources available to them, directly or indirectly [5]. The listing criteria cover those responsible for cyber-attacks and those providing financial, technical or material support. Ransomware is not named in the framework — the operative term is cyber-attacks — but the prohibition is drafted by reference to the recipient, not the reason for the transfer. Attribution during a live incident is rarely certain, which is exactly what makes the exposure hard to assess in the 48 hours when the decision is actually made. This is a question for counsel and, in several member states, for the competent authority — not a compliance-checklist item.

Law enforcement’s own position is unambiguous. No More Ransom, the initiative run by the Dutch police National High Tech Crime Unit and Europol’s European Cybercrime Centre with private-sector partners, states that the general advice is not to pay the ransom — payment confirms that ransomware works and carries no guarantee of a working decryption key [7]. The project’s free decryption tools are worth checking before any payment decision is taken.

Still Recovering at Day 30? Article 23(4)(e)

Ransomware is the archetypal incident that outlives its own final-report deadline. Sophos’ 2025 survey of 3,400 IT and cybersecurity leaders across 17 countries found 53% of victims recovered within a week [8] — a vendor survey rather than regulatory data, but it puts a sizeable minority still in recovery well beyond that, and the mean recovery cost excluding any ransom at USD 1.53 million.

The Directive anticipates this. Article 23(4)(e) provides that where an incident is still ongoing when the final report falls due, the entity submits a progress report at that time and a final report within one month of their handling of the incident [2]. The final report is deferred, not waived, and the progress report is mandatory rather than a courtesy.

The Directive sets no content list for a progress report, so what follows is practical guidance rather than a legal requirement: mirror the four headings of the final report and mark each as provisional — what is known about severity and impact so far, the working root-cause hypothesis, mitigation applied and still running, and cross-border position. Add the one thing the authority actually needs from you, which is a realistic estimate of when handling will complete. Recovery that is genuinely open-ended should be described as such.

Double Extortion Turns One Filing Into Two Regulators

Where a ransomware group steals data before encrypting it, the theft adds regulators rather than replacing them. Where personal data is involved, the GDPR Article 33 notification runs in parallel on its own 72-hour clock; the EDPB’s Guidelines 01/2021 on examples regarding data breach notification treat ransomware as a distinct breach category with case-based analysis [6]. For entities bound by CIR 2024/2690, exfiltration of trade secrets is a standalone significance criterion under Article 3(1)(b) [3], so a data-theft-only incident with no encryption can still be significant.

Article 35 requires the NIS2 competent authority to inform the GDPR supervisory authority without undue delay where an infringement could involve a personal data breach — and where a supervisory authority has already fined you for the same conduct, the NIS2 authority may not impose a further fine, though other enforcement measures remain available [10]. Our dedicated guide to running the NIS2 and GDPR notification tracks in parallel maps both timelines against a single ransomware scenario.

What Getting This Wrong Costs

Failure to report is not a lesser administrative slip alongside the security failure. Article 34 applies the same maximum fines to infringements of Article 21 and Article 23 [9].

Entity class	Maximum administrative fine	Comparator	Applies to
Essential entities — Art. 34(4)	EUR 10,000,000 or 2% of total worldwide annual turnover	Whichever is higher	Infringements of Article 21 or 23
Important entities — Art. 34(5)	EUR 7,000,000 or 1.4% of total worldwide annual turnover	Whichever is higher	Infringements of Article 21 or 23

Note that Article 34 uses “whichever is higher” while the CIR significance threshold uses “whichever is lower” — opposite comparators in the same regime, and a frequent source of misquotation. Actual amounts and the enforcement ladder are set by national transposition; our NIS2 penalties overview covers how member states have implemented them.

Your First 24 Hours, by Role

The same incident produces genuinely different tasks depending on where you sit.

Role	Hours 0–4	Hours 4–24
CISO / IT security lead	Contain and isolate; preserve forensic images before any restore; record detection time to the minute — it is the start of the legal clock	Assemble what IOCs are reachable; identify systems and services affected for the 72-hour assessment; request CSIRT operational advice under Art. 23(5)
Compliance officer / legal	Decide and document the significance assessment against Art. 23(3) or the CIR criteria; open the parallel GDPR assessment if personal data is in scope	File the early warning; diary the 72-hour and one-month dates from the correct anchor points; log every decision with a timestamp
Management body / board	Authorise the reporting decision; do not condition filing on knowing the full cost	Take the payment question to counsel with the sanctions exposure on the table; approve customer and recipient communications
Communications / service owners	Establish an out-of-band channel that does not depend on encrypted systems	Prepare recipient notification for affected service users; align wording with what has been filed

Three practices are cheap before an incident and impossible during one: a printed one-page filing card carrying your entity identifier and CSIRT portal details, notification forms stored offline, and a rehearsal of the significance decision rather than only the technical response. Our guides to NIS2 business continuity requirements and backup and recovery obligations cover the controls behind a defensible restore.

Frequently Asked Questions

Does a ransomware attack always have to be reported under NIS2?
Not automatically — the incident still has to be significant. But for the eleven digital-provider categories bound by CIR 2024/2690, successful malicious unauthorised access capable of severe operational disruption is itself a criterion [3], and for everyone else the “capable of causing” limb of Article 23(3) is satisfied by most production-system encryption [1]. In practice the defensible default is to report and document the reasoning if you do not.

We restored in four hours and lost almost nothing. Do we still report?
Assess it properly rather than assuming the answer. Article 23(3) asks what the incident was capable of causing, not only what it did [1]. Fast recovery is a strong mitigating fact for the report, not a reason to skip it — and the assessment needs to be written down either way.

When exactly does the 24-hour clock start?
On becoming aware of the significant incident [2]. For ransomware that is normally the moment a ransom note, mass file-encryption alert or failed-service cascade is identified — not the moment forensics confirms the strain or entry vector.

Do we have to tell the regulator whether we paid?
NIS2 has no ransom-disclosure field. However the final report must describe applied and ongoing mitigation measures and likely root cause [1], which is hard to complete accurately if a purchased decryptor was your recovery route. Take the payment decision with counsel, given the prohibition on making funds available to persons listed under Regulation (EU) 2019/796 [5].

What if we are still recovering when the final report is due?
Submit a progress report on the original due date; the final report is then due within one month of completing your handling of the incident, under Article 23(4)(e) [2].

The Short Version

Start the clock at detection, not at understanding. Assess significance against capability, not against a loss figure you cannot yet compute. File a thin early warning inside 24 hours and let the 72-hour notification carry the detail. Anchor the one-month final report to your 72-hour filing, and reach for Article 23(4)(e) if recovery is still running. Keep the payment question in its own lane, with counsel, and do not let it delay any of the above.

The organisations that handle this well are not the ones with the best forensics. They are the ones that decided in advance who signs the significance assessment, and kept the filing forms somewhere the attacker could not encrypt them.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Article 23 — Reporting obligations, Directive (EU) 2022/2555 — nis-2-directive.com
2. Article 23, Directive (EU) 2022/2555 — full text — nis2resources.eu
3. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
4. ENISA Threat Landscape 2025 — ENISA
5. EU restrictive measures against cyber-attacks — Council Regulation (EU) 2019/796 — EUR-Lex
6. Guidelines 01/2021 on Examples regarding Data Breach Notification — European Data Protection Board
7. About the Project — The No More Ransom Project (Europol EC3, Dutch National High Tech Crime Unit and partners)
8. "The State of Ransomware 2025" — Sophos (sophos.com), vendor survey of 3,400 IT and cybersecurity leaders across 17 countries
9. Article 34 — General conditions for imposing administrative fines — nis-2-directive.com
10. Article 35 — Infringements entailing a personal data breach — nis-2-directive.com