NIS2 gives you 24 hours to report a full cloud outage longer than 30 minutes

At 02:14 a region fails over badly and the product is fully down. Someone gets paged, the rollback works, and by 02:45 the dashboards are green again. Thirty-one minutes. The incident channel gets a thumbs up and everybody goes back to bed.

Nobody on that call knew the outage had cleared a reporting threshold, because the number that makes 31 minutes reportable is not in NIS2 itself. It sits in an implementing regulation that engineering teams have mostly never opened, and it says 30 minutes.

Check first whether any of this reaches you, because the covered set is narrower than "SaaS" suggests. You have to be a listed type of provider, and you have to be at least medium-sized: 50 staff or more, or both annual turnover and balance sheet total above 10 million euros 3, with group companies counted in. Under that, you are generally out. NIS2 is also a directive rather than a regulation, so it binds you only through your own country's national law, which each member state has to pass separately. Our earlier post on NIS2 scope has the full test if you want it afterwards.

If you are inside, here is what follows. Your reporting duty turns on four numeric thresholds, so the work is measurement rather than judgement, and a team that cannot measure fast will spend most of its 24 hours working out whether they started.

What makes an incident significant for a cloud service?

Four specific tests, set out in Article 7 of Commission Implementing Regulation (EU) 2024/2690 2. They exist because the directive itself is vague on purpose.

NIS2 says 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 people or organisations by causing considerable material or non-material damage 1. Read that at 03:00 with a half-restored database and it decides nothing. So the directive told the European Commission to write the numbers down for cloud providers and similar types 1, and those numbers have been in force since November 2024 2.

For a cloud computing service provider, an incident is significant where any one of these is true. The user counts are of your European users, not your global ones 2.

• (a) a cloud computing service provided is completely unavailable for more than 30 minutes
• (b) availability is limited for more than 5% of the service's users in the Union, or more than 1 million of them, whichever number is smaller, for more than one hour
• (c) the integrity, confidentiality or authenticity of stored, transmitted or processed data related to the provision of the service is compromised as a result of a suspectedly malicious action
• (d) that same kind of compromise has an impact on more than 5% of the service's users in the Union, or more than 1 million of them, whichever number is smaller

In (b) and (d), the 5% is the number that will bind you. The million-user alternative only takes over once 5% of your EU base is itself more than a million people.

The regulation adds five general criteria on top, which apply across every kind of provider it covers rather than to cloud alone. Two of them are about death and serious harm to health. The other three reach an ordinary SaaS 2:

• direct financial loss over 500,000 euros, or 5% of your total annual turnover in the preceding financial year, whichever is lower
• exfiltration of your trade secrets
• a successful, suspectedly malicious and unauthorised access to your systems that is capable of causing severe operational disruption

Scheduled interruptions and the planned consequences of maintenance are carved out 2, so a migration window you announced is not an incident.

Who counts as a user when you sell to businesses?

Both. Article 3(3) says to consider the customers who hold a contract granting access to your systems or services, and the natural and legal persons associated with business customers that use them 2. The two get added together, and for a B2B product the second number swamps the first.

Say you have 380 customer companies in the EU and 92,000 people at those companies with logins. The population you measure 5% against is 92,380, so tests (b) and (d) trip at roughly 4,620 people. It also means one customer can carry the threshold alone: if a single enterprise tenant holds 5,000 of those seats and that tenant is degraded for seventy minutes, you have crossed test (b) while every other customer had a normal afternoon.

Your billing system knows the 380. The number the regulation turns on is the other one, counted per service and restricted to the EU, and it is almost certainly on no dashboard you have today.

Does a small data compromise count?

Yes, if you suspect it was malicious. Test (c) carries no volume threshold at all, while test (d), which does carry one, says nothing about malice 2. Putting the two side by side gives you the shape of the rule: a suspected attack is significant at any size, and a compromise with no suspicion of malice behind it becomes significant when it gets wide enough.

So one stolen session token, used once, to read one tenant's data, is inside test (c). So is a support engineer's account being used by somebody who should not have it. What the test asks for is your suspicion at the time, so it fires well before the forensics that would tell you whether the suspicion was right.

The general criterion listed earlier reaches further still, because it asks for no data compromise at all. Someone getting a shell on a production host is significant on its own where that access was capable of causing severe operational disruption, even if you locked them out before they used it 2. Capability is the element that decides it, not damage done.

When does the 24-hour clock start?

From becoming aware of the significant incident. Article 23(4)(a) asks for an early warning without undue delay and in any event within 24 hours of that awareness, saying whether you suspect unlawful or malicious acts and whether there could be cross-border impact 1.

After that the cadence is fixed 1. At 72 hours from the same awareness you owe a fuller notification with an initial assessment of severity and impact, and a final report a month after that notification rather than a month after the incident.

You file with a CSIRT, the computer security incident response team a member state designates, or with the competent authority where that state routes it differently. Which state is not decided by where your customers are. Article 26(1)(b) puts cloud computing service providers under the jurisdiction of the member state where they have their main establishment in the Union, meaning where cybersecurity risk-management decisions are predominantly taken, and a provider with no EU establishment that offers services into the EU designates a representative and falls under that state's jurisdiction instead 1. One country, one filing, however many markets you sell into.

Filing early costs you less than it looks. Article 23(1) says the mere act of notification shall not subject the notifying entity to increased liability 1.

You also get something back. The CSIRT should respond within 24 hours where possible with initial feedback, and on request with guidance or operational advice on mitigation 1.

The Dutch NCSC, to take one national channel, runs a single reporting point for the Dutch cybersecurity act where one submission reaches both the sector CSIRT and the supervisor, and it runs the deadline from the moment you learn of the incident, exactly as the directive does. That law only took effect on 15 August 2026, and some member states have not transposed NIS2 at all yet, so your own regulator may not be waiting for you. The classification work below is worth doing anyway, because it is the same work you will otherwise be doing against a running clock, done calmly.

The law does not define awareness, and I am not certain which reading wins: awareness that a threshold was cleared, or awareness of the facts that cleared it. It lands you in the same place either way. Not measuring does not buy you time, it just means you find out late.

What has to exist before the incident, not during it?

Three numbers you can produce quickly, one decision somebody is authorised to make, and one field on your incident records.

Downtime per service, at minute resolution. Complete unavailability has to be separated from degradation, because they are different tests with different thresholds, and unplanned has to be separated from scheduled 2. "More than 30 minutes" should be answerable from your own tooling, not reconstructed from message timestamps a week later.

A current count of your EU users, per service. On the Article 3(3) definition, so seats plus accounts rather than accounts alone. If producing that number needs a data pull and a day of work, it is useless inside a 24-hour window.

How many users a partial outage reached, and for how long. This is test (b), and most incident tooling cannot answer it: dashboards show error rates and saturation, not distinct affected users over a window.

A named person who can record a suspicion of malice, and a default while it is unknown. Test (c) turns on suspicion. If nobody is empowered to write down "we suspect this was malicious" at 03:00, nothing gets recorded, and the clock runs regardless.

A root-cause label that survives across incidents. Under Article 4, incidents that are individually not significant count collectively as one where they happened at least twice in six months, share the same apparent root cause, and together cross the financial-loss criterion 2. Answering that is a query over your incident history, so the history needs a stable field to group on rather than a free-text postmortem title.

All five are ordinary engineering work. The same regulation's annex sets out the security measures these providers owe, and the EU's cybersecurity agency, ENISA, published technical implementation guidance for it in June 2025 with worked examples of the evidence expected, which is an easier way in than the annex itself.

Where should you start?

Open your last six months of incidents and mark each one against the four tests in Article 7. You are looking for outages that ran past 30 minutes, degradations that touched a large tenant for more than an hour, and anything where somebody said the word "suspicious" in the channel.

Late filing is fineable, and the floors are set in the directive. Below roughly 250 staff you are an important entity, and Article 34 requires your member state to set its maximum fine for an Article 23 infringement at no less than 7 million euros or 1.4% of worldwide annual turnover, whichever is higher 1. Above that line you are an essential entity and the floors are 10 million or 2%. Those are national maximums rather than expected fines, and no regulator has made an example of a late NIS2 filer yet.

Then read what you have already promised. Article 23(1) also expects you to notify the recipients of your services, where appropriate, of significant incidents likely to adversely affect the service 1, and your DPA, your security page and your status-page policy all describe what you do when this happens. Those documents were written once and your incident process has moved since. (Keeping that kind of document matching the product as it changes is what we build at Lawcel: it watches the pull requests and tickets that change your product and flags the ones that leave a published document saying something no longer true.)

Start with the replay. It needs no lawyer and no budget, just your own incident history and the four tests above, and it tells you whether the 24-hour clock is a problem you have already been failing quietly or one you are ready for.