NIS2 and ransomware: what you must report, whether you can pay, and what Article 21 expects

Under NIS2, ransomware that has caused or could cause severe disruption or financial loss is a significant incident. That means an early warning within 24 hours of becoming aware, a notification within 72 hours and a final report within a month of it. NIS2 has no rule on ransom payments: it neither prohibits paying nor requires reporting a payment.

This guide covers when ransomware is a significant incident, what to report and when, whether you can pay, what the COM(2026) 13 proposal would change, the Article 21 measures that matter most, GDPR, a first-24-hours checklist and what the law leaves open.

Question	Short answer	Source
Is ransomware a significant incident?	Yes, if it has caused or can cause severe disruption or financial loss for you, or considerable damage to others	NIS2 Art. 23(3)
When do you report?	Early warning within 24 hours of awareness, notification within 72 hours, final report within a month of the notification	Art. 23(4)
Must you say it was an attack?	The early warning indicates, where applicable, whether unlawful or malicious acts are suspected	Art. 23(4)(a)
Can you pay?	NIS2 is silent. Sanctions law and national law still apply	Reg. (EU) 2019/796
Must you report a payment?	Not under current NIS2. A 2026 proposal would let authorities ask	COM(2026) 13, proposal
Personal data affected?	GDPR notification within 72 hours where feasible, unless unlikely to result in a risk	GDPR Art. 33
Which measures matter most?	Backups and recovery, incident handling, patching, access control, MFA, training	Art. 21(2)

Is a ransomware attack a significant incident under NIS2?

Usually, yes. Article 23(3) makes an incident significant if it “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned”, or has affected or can affect others by causing considerable material or non-material damage.

Ransomware that encrypts production systems, stops order processing or takes down a service your customers depend on meets the first limb without much debate. Note “capable of causing”: you do not wait to see how bad it gets. Ransomware caught on one laptop and removed before it spread may not be significant. Record why you decided either way.

For cloud, data centre, managed service and the other digital providers covered by Implementing Regulation (EU) 2024/2690, the test is more concrete. Its Article 3(1)(e) treats as significant “a successful, suspectedly malicious and unauthorised access to network and information systems” that is capable of causing severe operational disruption. Most ransomware incidents start with exactly that. Direct financial loss above €500,000 or 5% of annual turnover, whichever is lower, is a separate trigger. The full test is in what makes an incident significant under NIS2.

What must you report after a ransomware attack, and when?

The clock starts when you become aware of a significant incident, not when the attacker got in. Article 23(4) then sets the sequence:

1. Early warning, within 24 hours. Where applicable, it indicates whether the incident is “suspected of being caused by unlawful or malicious acts” or could have a cross-border impact. For ransomware, the first answer is almost always yes.
2. Incident notification, within 72 hours. An update of the early warning, an initial assessment of severity and impact, and indicators of compromise where available. For ransomware these are typically file hashes, attacker IP addresses and domains, the ransom note and the extension added to encrypted files.
3. Final report, within one month of the notification. A detailed description, the type of threat or root cause, mitigation applied and ongoing, and any cross-border impact. For ransomware the root cause is the initial access: a phished account, an unpatched VPN appliance, a supplier’s remote access.

The CSIRT or authority can ask for intermediate reports, and an incident still ongoing at the one-month mark gets a progress report first. Reports go to your national CSIRT or, where applicable, the competent authority. The CSIRT replies without undue delay and, where possible, within 24 hours of the early warning. Where the incident is suspected to be of criminal nature, it also gives “guidance on reporting the significant incident to law enforcement authorities” (Art. 23(5)). A NIS2 notification is not a criminal complaint. Filing one is a separate step under national law.

Where appropriate, you also tell the recipients of your services, without undue delay, about significant incidents likely to affect the provision of those services (Art. 23(1)). The same paragraph says: “The mere act of notification shall not subject the notifying entity to increased liability.” Details are in the NIS2 incident reporting timeline.

Is paying a ransom allowed under NIS2?

NIS2 does not regulate ransom payments. No article prohibits paying, requires approval to pay, or requires you to report that you paid or how much. Ransomware appears in the recitals, which explain the law but do not create obligations.

• Recital 54 notes “an exponential increase in ransomware attacks” and ends: “Member States should develop a policy addressing the rise of ransomware attacks as part of their national cybersecurity strategy.”
• Recital 56 says some SMEs face an increased level of threat, “such as ransomware, for which they should receive guidance and assistance.”

Neither says whether a ransom may be paid. Article 7(2), which lists the policies a national strategy must include, does not name ransomware.

Other law does reach a payment:

• EU sanctions. Council Regulation (EU) 2019/796 on restrictive measures against cyber-attacks provides that no funds “shall be made available, directly or indirectly” to persons listed in its Annex I (Art. 3(2)). Other regimes say the same, for example Regulation (EU) No 269/2014 (Art. 2(2)). The practical problem is that you rarely know who controls a wallet.
• National law. Criminal law, sanctions enforcement and insurance rules differ between Member States. Check yours before an incident, not during one.
• Public bodies. According to the Commission, the Union has endorsed a non-binding statement under the International Counter Ransomware Initiative that relevant institutions under the authority of participating national governments should not pay ransomware extortion demands (recital 10 of COM(2026) 13). It is not law.

Paying ends none of your obligations. The 24-hour, 72-hour and one-month reports are still due, and data that was copied out is still a personal data breach. In practice, reserve the decision to the management body, take legal advice, and record the decision with its reasons.

What would the COM(2026) 13 proposal change?

On 20 January 2026 the Commission proposed targeted amendments to NIS2 (COM(2026) 13). As of September 2026 it is a proposal, not law. Two changes concern ransomware:

• New Article 23(12). When the Commission adopts implementing acts on the type of information, format and procedure of notifications, it would have to require information on whether the entity detected a ransomware attack, the attack vector, and whether mitigation measures have been implemented.
• New Article 23(13). In a significant incident caused by ransomware, entities would have to answer, on request of the CSIRT or competent authority and through a channel it provides. Did the entity receive a ransom demand and, where applicable, from whom? Was a ransom paid? If so, the amount, the means of payment and the recipient, “including the crypto-asset and crypto-asset service provider, where applicable”.

Because payment information is sensitive, it would be given only on request, and entities are encouraged to appoint a point of contact for these exchanges (recital 10). The proposal would still not prohibit payment. Either way, keep a record of the demand, the decision and any payment: the final report, your insurer and law enforcement will all ask.

Which Article 21 measures matter most against ransomware?

Article 21(2) does not mention ransomware, but six of its ten minimum measures decide how a ransomware attack ends. Recital 49 describes a cyber hygiene baseline that reads like a ransomware list: software and hardware updates, password changes, “the limitation of administrator-level access accounts, and the backing-up of data”.

Article 21(2) measure	Why it matters for ransomware	What good looks like in practice
(c) Business continuity: backup management, disaster recovery, crisis management	Decides whether you can restore without paying	One copy offline or immutable, restores tested, recovery times known
(b) Incident handling	Decides how fast you detect and contain	Alerts on mass file changes and admin misuse, authority to isolate
(e) Vulnerability handling	Unpatched internet-facing systems are a frequent entry point	Exposed services inventoried and patched within a set deadline
(j) MFA, where appropriate	Stolen passwords are a frequent entry point	MFA on remote access, email and every administrative account
(i) Access control and asset management	Limits how far an attacker spreads	Few domain admins, separate admin accounts, known assets
(g) Cyber hygiene and training	Phishing starts many attacks	Short, regular training and an easy way to report a suspicious email

One observation from practice: a backup that the production domain administrator can reach is usually encrypted in the same attack. “We have backups” and “we can restore” are different statements.

Article 20 requires the management body to approve these measures and oversee them, and its members must follow training. A tabletop exercise on a ransomware scenario, including the payment question, serves both. See NIS2 training for boards and employees and all ten measures in NIS2 Article 21 explained.

What if the ransomware reached personal data?

Then GDPR applies in parallel. Encrypting personal data is a breach of availability; copying it out is a breach of confidentiality. Under Article 33 GDPR, the controller notifies the supervisory authority “without undue delay and, where feasible, not later than 72 hours” after becoming aware, unless the breach is unlikely to result in a risk to people. If it is likely to result in a high risk, the people affected are told as well (Art. 34).

The EDPB’s Guidelines 01/2021 work through four ransomware cases. In the first, a proper backup allowed quick restoration and no data was exfiltrated, so notification was not required. Every breach must still be documented under Article 33(5). In the other three, notification was required: no proper backup, exfiltration, or a hospital where even a two-day restore delayed treatment.

The GDPR clock starts when you become aware of a personal data breach, which may be hours after the NIS2 clock. Two authorities, two deadlines, one set of facts: NIS2 and GDPR has a joint playbook.

Ransomware under NIS2: the first 24 hours

A sensible first-day sequence, not a legal requirement. Adjust it to your national reporting portal and your own plan.

RANSOMWARE: FIRST 24 HOURS (NIS2)

HOUR 0  DETECT AND RECORD
  [ ] Open one incident record: ID, first alert time (UTC)
  [ ] Record who became aware of what, and when
  [ ] Preserve the ransom note, sample encrypted files, logs

HOUR 0-2  CONTAIN
  [ ] Disconnect affected hosts and segments; avoid powering off
  [ ] Disable compromised accounts; reset admin credentials
  [ ] Check backups: reachable by the attacker? last clean copy?

HOUR 1-4  DECIDE
  [ ] Significant incident? Severe disruption, financial loss,
      damage to others (NIS2 Art. 23(3)). Record decision, time
  [ ] Personal data encrypted or copied? Start GDPR assessment
  [ ] Convene the crisis team; inform the management body

HOUR 4-24  REPORT
  [ ] Early warning to CSIRT or competent authority, Art. 23(4)(a)
      suspected unlawful or malicious act: yes
      possible cross-border impact: yes / no / unknown
  [ ] Tell recipients of services where appropriate, Art. 23(1)
  [ ] Law enforcement: follow CSIRT guidance and national rules
  [ ] Ransom demand: no contact without legal advice;
      sanctions screening before any payment decision

NEXT DEADLINES
  [ ] NIS2 incident notification with IoCs: 72 h from awareness
  [ ] GDPR notification, if required: 72 h from breach awareness
  [ ] NIS2 final report: 1 month after the incident notification

What NIS2 leaves open, and what closing it looks like

NIS2 says “backup management”. It does not say how many copies, whether one must be offline, or how often a restore is tested. It says MFA “where appropriate”, not on which accounts. It says incident handling, not who may cut a site off the network at three in the morning. Those choices are yours, and your risk analysis has to justify them.

After an incident, the authority’s questions are about evidence, which Articles 32 and 33 let it request. When was the last successful restore? Was MFA on the account the attacker used? How long had the exploited vulnerability been open? A policy saying backups are tested monthly does not answer that. The restore log does.

That evidence sits in your backup system, identity provider, endpoint tools and patch management. Collected by hand before an audit, it describes a past state. Collected continuously, with a person reviewing the exceptions, it shows the admin account without MFA or the backup job that stopped three weeks ago before an attacker finds them. That is how the CloudSoul platform works: automated collection with human-in-the-loop expertise. A security audit run against a ransomware scenario shows where you stand, and the wider programme is on the NIS2 compliance page.

NIS2 ransomware checklist

• Define what counts as a significant incident for your services, with examples, before you need it.
• Keep at least one backup copy that production admin accounts cannot reach, and test a restore.
• Enforce MFA on remote access, email and all administrative accounts, and measure coverage.
• Patch internet-facing systems within a deadline you set and track.
• Rehearse the 24-hour early warning: who decides, who sends it, through which channel.
• Decide in advance who may approve or refuse a ransom payment, with legal advice on sanctions.
• Run a ransomware tabletop exercise with the management body, including the NIS2 and GDPR decisions.

Sources

• Directive (EU) 2022/2555 (NIS2), Articles 7, 20, 21, 23, 32 and 33 and recitals 49, 54 and 56, EUR-Lex.
• Commission Implementing Regulation (EU) 2024/2690, Article 3, EUR-Lex.
• Regulation (EU) 2016/679 (GDPR), Articles 33 and 34, EUR-Lex.
• EDPB Guidelines 01/2021 on examples regarding personal data breach notification, EDPB.
• Council Regulation (EU) 2019/796 concerning restrictive measures against cyber-attacks threatening the Union or its Member States, Article 3, EUR-Lex.
• Council Regulation (EU) No 269/2014, Article 2, EUR-Lex.
• Proposal for a Directive amending Directive (EU) 2022/2555, COM(2026) 13, 20 January 2026, EUR-Lex.

Frequently asked questions