Policy Watch: What NIS2 and the Cyber Resilience Act Mean for Ransomware Reporting

Policy Watch: What NIS2 and the Cyber Resilience Act Mean for Ransomware Reporting

Ransomware does not check your legal calendar. Two EU laws now attach clocks to the way you handle it, and the first one starts ticking the moment someone in your organisation works out that something is wrong. Miss it, and you are managing two incidents: the intrusion and the compliance file.

Here is what NIS2 and the Cyber Resilience Act ask of companies that get hit, what they ask of the vendors those companies buy from, and the handful of things worth fixing before an incident forces the issue.

This is not only a legal problem for the victim. The same rules now reach into the supply chain, which means procurement, contract review, and vendor management are part of incident readiness whether your security team likes it or not.

Two rules, two very different jobs

They are usually mentioned in the same breath, but they do different work.

NIS2 is a directive. Member states transposed it into national law, and it applies to organisations — "essential" and "important" entities across a long list of sectors. That list includes energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, postal services, waste management, chemicals, food, manufacturing, and digital providers. Its core demands are risk management, management accountability, and incident reporting to a national CSIRT or competent authority. Enforcement has arrived at different speeds in different countries, but the underlying duties are already live.

The Cyber Resilience Act (CRA) is a regulation, so it applies directly without national transposition. It targets products with digital elements — hardware and software placed on the EU market — and puts duties on manufacturers across the product lifecycle: secure design, vulnerability handling, security updates, and reporting of actively exploited vulnerabilities and severe incidents to ENISA. Importers and distributors also carry obligations, and open source stewards may have duties depending on how they operate.

The two overlap. A vulnerability in a product you manufacture, exploited in a ransomware campaign, can trigger duties under both. A hospital using that product has NIS2 duties; the vendor that made it has CRA duties. A managed service provider hit by ransomware may owe NIS2 notifications to its own authority while its affected software vendor owes CRA notifications to ENISA.

The CRA's reporting obligations apply from 11 September 2026, with the bulk of the remaining obligations from 11 December 2027. NIS2's national rules have applied since the October 2024 transposition deadline, though enforcement has arrived at different speeds in different countries.

The reporting clocks you should be able to hit in your sleep

Under NIS2

• Early warning — 24 hours from becoming aware of a significant incident. It can be sparse: suspected malicious cause, possible cross-border impact. The point is to alert authorities fast, not to have the story straight.
• Incident notification — 72 hours. An initial assessment covering severity, root cause as far as you know it, and indicators of compromise.
• Final report — one month. Detailed description, root cause, applied and ongoing mitigations, cross-border effects. If the incident is still open, expect to file a progress report too.

There is a separate duty, easy to forget, to inform recipients of your services about significant cyber threats they need to act on. And "becoming aware" is a real legal moment. It is not when the forensic report lands, and not when the board is briefed. It is when the organisation, acting reasonably, has enough information to conclude that a significant incident has occurred.

Consider a regional hospital whose electronic patient record system suddenly shows file-locking messages and a ransom note. The service desk may not yet know whether backups are intact or how many patients are affected. That does not matter for the 24-hour clock. If the organisation reasonably suspects a significant incident, the early warning should be going out while incident response is still triaging.

Under the CRA

• 24 hours — early warning to ENISA through the single reporting platform.
• 72 hours — a vulnerability or incident notification with the details you have.
• 14 days — final report for an actively exploited vulnerability.
• One month — final report for a severe incident.

The single platform exists so manufacturers and service providers are not filing the same facts three times. Reporting deadlines are also floors, not ceilings: contractual and customer notification clauses are frequently shorter. If your enterprise contract says you must notify a customer within 12 hours of confirming a security incident, the CRA's 24-hour early warning is not your real deadline.

Why ransomware almost always counts

NIS2 asks whether an incident has a significant impact on the provision of your services — and ransomware tends to answer that question loudly. The regulation looks at factors such as severe operational disruption, financial loss, and the impact on other persons or organisations. A ransomware attack that encrypts systems, steals data, disables backups, halts billing, or forces staff onto pen and paper is rarely a borderline case.

For a manufacturer, a halted production line can be significant within hours. For a SaaS provider, an outage that affects customers across member states is almost certainly significant and may have cross-border impact. For a managed service provider, one intrusion can become dozens of customer incidents. For a hospital, cancelled operations and inaccessible records speak for themselves.

Even if you recover quickly, the incident may still count. The threshold is not "did we pay a ransom" or "did the attacker succeed for a week." It is whether the incident had a significant impact. And if personal data was exfiltrated, a separate GDPR breach notification clock is likely running alongside the NIS2 and CRA clocks.

Do not self-assess your way out of reporting without writing down why. "We decided it was not significant because X, Y, and Z" is a defensible position. Silence is not.

The vendor side: what the CRA changes for products you buy

If you buy software or hardware, the CRA changes what you should expect from vendors. Manufacturers must handle vulnerabilities, provide security updates, and report actively exploited vulnerabilities and severe incidents. That does not mean every vendor will be good at it by 2026, but it does give you leverage.

What to ask vendors now

• How do you receive and triage vulnerability reports, and what is your coordinated disclosure process?
• How long will you provide security updates for this product, and when does support end?
• Will you provide a software bill of materials or equivalent dependency information?
• What are your notification timelines if an actively exploited vulnerability affects this product?
• Who do we contact at 3 a.m., and what happens if that person does not answer?

What to put in contracts

Push for notification clauses that match or beat your own regulatory deadlines. If your NIS2 early warning is due in 24 hours, a vendor contract that allows five business days to notify you is not fit for purpose. Include security update commitments, end-of-support dates, and a right to audit or receive evidence after a serious incident. Remember: your vendor's CRA report to ENISA does not file your NIS2 report. You still have your own clock.

How to prepare before the clock starts

The worst time to design a reporting workflow is during a ransomware incident. Build it now, then test it.

Before an incident

1. Map your obligations. Confirm whether you are an essential or important entity under NIS2, who your national CSIRT or competent authority is, and whether you have CRA duties as a manufacturer.
2. Pre-draft templates. Create 24-hour, 72-hour, and final report templates for NIS2 and, if relevant, CRA reports. Leave blanks for facts; do not leave the structure to chance.
3. Define "becoming aware." Write down who can trigger the legal clock and how. Train the service desk, SOC, and legal team on immediate escalation of suspected ransomware.
4. Keep a reporting matrix. List incident type, threshold, deadline, recipient, and required content. Include GDPR, contractual, and sector-specific duties.
5. Run a tabletop. Use a ransomware scenario that involves a vendor vulnerability, data exfiltration, and an unclear scope. Practise sending a sparse 24-hour warning.

During an incident

Report early and update often. Preserve evidence — logs, ransom notes, wallet addresses, indicators of compromise — but do not wait for perfect forensics to file the early warning. Assign one person to own the regulatory clock and another to own the technical response. Keep a timeline of decisions, including why you judged an incident significant or not.

After an incident

Use the final report as a forcing function. Fix the root cause, close the vendor gap, update the playbook, and feed lessons into risk management. If management accountability was tested, document how the board or senior leadership was involved.

Common mistakes that turn a breach into a compliance problem

• Waiting for certainty. The 24-hour early warning is designed to be preliminary. A late perfect report is worse than an early imperfect one.
• Forgetting the recipient notification duty. If customers or service recipients need to act on a significant threat, they may need to hear from you separately.
• Assuming the vendor will handle it. The vendor's CRA report does not discharge your NIS2 duty.
• Ignoring shorter contract clocks. Your customer contracts may require notice long before the regulator does.
• Treating it as purely technical. Legal, communications, procurement, and senior management all have roles before, during, and after the incident.

Report early, update often, and keep the paperwork boring. Regulators rarely punish a sparse 24-hour warning filed on time; they do punish a polished report filed late.

NIS2 and the CRA do not make ransomware response easier. They do make it more legible. The organisations that fare best will be the ones that treat reporting as an operational capability — with owners, templates, tests, and vendor pressure — rather than a legal afterthought. When the ransom note appears, you will not have time to invent the process. You will only have time to run it.

Photo: Paolo Rossa / Pexels