5% of Customers, 1 Million Users, or 30 Minutes: The Three Thresholds That Trigger NIS2 Incident Reporting for Cloud Providers

When a cloud platform goes dark for 35 minutes, the question is no longer just operational — it is legal. Commission Implementing Regulation (EU) 2024/2690, which entered into force on 7 November 2024, establishes precise numerical triggers that determine whether a cloud provider must notify its national CSIRT under Article 23 of the NIS2 Directive. Get those numbers wrong and you miss the 24-hour early warning window. Misread the multi-tenant boundary and you may fail to file a separate notification as a cloud tenant — even though your cloud provider already reported the same underlying incident.

This guide unpacks the exact thresholds from Article 7 of CIR 2024/2690, the three-stage Article 23 notification cascade, and — critically — the independent reporting obligation that applies when the affected tenant is itself a NIS2-regulated entity. The two notification clocks run in parallel, not in sequence.

Who This Applies To: Cloud Providers Under NIS2 Scope

NIS2 Directive 2022/2555 classifies cloud computing service providers as entities covered under Annex II — placing medium-sized and larger cloud operators within scope as important entities by default. Providers that cross the large-enterprise thresholds (250+ employees or €50 million annual revenue) may be reclassified as essential entities by individual member states, carrying stricter supervision and higher penalty exposure.

The scope covers IaaS, PaaS, and SaaS providers that deliver services to entities in the EU, regardless of where the provider itself is headquartered. A US-headquartered hyperscaler running workloads for a covered EU financial entity falls within the regulation’s reach for those EU-directed services.

Critically, the regulation creates two legally distinct categories of actor in any cloud incident scenario:

Actor	NIS2 Classification	Obligation Trigger	Reports To
Cloud operator (IaaS/PaaS/SaaS provider)	Important entity (Annex II); may be essential	Article 7, CIR 2024/2690 — service-level thresholds	National CSIRT (member state where operator is established)
Cloud tenant (customer that is itself a NIS2 entity)	Essential or important entity in its own sector	Impact on the tenant's own services — sector-specific thresholds	National CSIRT (member state where tenant is established)
Cloud tenant (SME, not a NIS2 entity)	Out of scope	No independent NIS2 obligation	N/A (may receive contractual notification from provider)

Understanding this table is the prerequisite for everything that follows. The cloud operator's NIS2 obligation and the tenant's NIS2 obligation are legally independent — one does not satisfy the other.

For a broader overview of which organisations fall within NIS2 scope, see NIS2 scope and entity classification.

The Significance Thresholds: Article 7 of CIR 2024/2690

Article 3(1)(g) of CIR 2024/2690 establishes the gateway principle: an incident is significant if it meets entity-specific criteria defined in Articles 5 through 14 of the same regulation. For cloud computing service providers, those criteria live in Article 7. There are four distinct triggers — any one is sufficient to make an incident reportable.

Article 7 Criterion	Threshold	Duration	Type
Art.7(a)	Service completely unavailable	More than 30 minutes	Total outage
Art.7(b)	More than 5% of EU users OR more than 1 million EU users (whichever is smaller)	More than 1 hour	Partial outage / degraded availability
Art.7(c)	Integrity, confidentiality, or authenticity of data compromised by suspected malicious action	No duration requirement	Data breach (availability-independent)
Art.7(d)	Data compromise affecting more than 5% of EU users OR more than 1 million EU users (whichever is smaller)	No duration requirement	Data breach at scale

Three technical details in this table deserve explicit attention, because compliance teams consistently misread them.

“Whichever is smaller” is the operative phrase in Art.7(b) and Art.7(d). A cloud provider with 100 million EU users meets the Art.7(b) threshold after 1 million affected users — not after 5 million. The 5% ceiling is a check on small providers, not a floor for large ones. A provider with 5 million EU users must report after 250,000 users are affected (5% of 5M), not after 1 million.

Scheduled maintenance is explicitly excluded under Article 3(2). A planned maintenance window that takes the service offline does not constitute a significant incident even if it runs longer than 30 minutes. The exclusion requires the interruption to be announced in advance and result from planned maintenance operations — an announced maintenance window that is extended due to an unexpected failure loses this exclusion for the extension period.

The user count in Article 3(3) is broader than contractual customers. The regulation specifies that user counts include the cloud provider's direct contractual customers and the natural and legal persons associated with those customers. A SaaS platform serving 100 enterprise customers, each with 500 end users, has a relevant user base of 50,000 when assessing the Art.7(b) threshold — not 100.

The Article 23 Notification Cascade: Three Stages, One Month

Once an Art.7 threshold is crossed, Article 23 of Directive 2022/2555 activates a three-stage mandatory reporting process. Each stage has a hard deadline measured from the moment of awareness — not from the moment the incident started, not from when root cause is confirmed. The clock starts when a person in the organisation becomes aware that an incident may meet the significance criteria [3].

For a full walkthrough of this process across all entity types, see Article 23 incident notification requirements and the broader incident reporting obligations guide.

Stage	Deadline	Recipient	Mandatory Content
Early warning	24 hours from awareness	National CSIRT	Confirmation of significant incident; indication of suspected unlawful or malicious cause; whether cross-border impact is possible; entity contact details
Incident notification	72 hours from awareness	National CSIRT	Updated information from early warning; initial severity and impact assessment; indicators of compromise (where available); initial cause analysis; mitigation measures already taken
Final report	1 month after 72-hour notification	National CSIRT	Detailed incident description; root cause analysis; applied and ongoing countermeasures; cross-border impact (if any); lessons learned

Two conditional stages supplement this baseline. An intermediate report is required only if a national CSIRT or competent authority requests one between the 72-hour and one-month marks. A progress report replaces the final report when the incident is still unresolved at the one-month mark; the final report is then due within one month of resolution [4].

The delegation trap. One frequently misunderstood rule: the Art.23 notification obligation cannot be transferred to a managed security service provider or any third party. The NIS2-regulated entity itself is responsible for submitting each stage on time. Outsourcing incident detection and response does not outsource the reporting obligation [4].

Penalties for non-compliance under Article 32 and 33 of NIS2 are substantial: essential entities face fines up to €10 million or 2% of global annual turnover (whichever is higher); important entities face up to €7 million or 1.4% of global annual turnover [7].

The Multi-Tenant Boundary: Two Independent Notification Obligations

This is where most compliance guidance stops short. The architecture of cloud services means a single underlying infrastructure incident can simultaneously trigger notification obligations for two entirely separate entities — the cloud operator and an affected tenant — each filing with its own national CSIRT, on its own timeline, using its own sector-specific significance criteria.

The legal basis for this dual obligation sits in Article 23(3) of Directive 2022/2555, which makes incidents significant where they affect other natural or legal persons by causing “considerable material or non-material damage.” A cloud outage that disrupts a hospital's patient record system, or a bank's trading infrastructure, satisfies this criterion for the tenant — independently of whether the cloud provider's own Art.7 thresholds were crossed [3][6].

Use this decision framework to determine which notifications are required:

Step	Question	If Yes	If No
1	Is the cloud provider an essential or important entity under NIS2?	Proceed to Step 2	No Art.23 obligation for provider; tenant obligation still possible if tenant is in scope
2	Does the incident meet any Article 7 criterion (30-min outage / 5%–1M users / data breach)?	Cloud provider must file Art.23 notifications (24h / 72h / 1M)	No provider obligation — but monitor for escalation
3	Is the affected tenant itself an essential or important entity under NIS2?	Proceed to Step 4	No independent tenant obligation (though contractual notification may still apply)
4	Did the cloud disruption cause “severe operational disruption” to the tenant's own services, or “considerable damage” to the tenant's users?	Tenant must file its own Art.23 notifications, independently of the provider's filing	No tenant obligation — document the assessment and retain it

Steps 2 and 4 run concurrently once Step 1 is satisfied. The tenant does not wait for the provider's notification before assessing its own obligation.

The “two clocks” problem. The provider's 24-hour early warning clock starts from when the provider became aware of the incident. The tenant's 24-hour clock starts from when the tenant became aware — which may be earlier (if the tenant detected the impact before the provider reported it) or later (if the tenant learned about it through a provider notification). These clocks are legally independent. A tenant cannot extend its 24-hour window by waiting for the provider to notify first.

The incident boundary. For NIS2 purposes, the cloud provider's incident and the tenant's incident are distinct legal events, even when caused by the same root failure. The provider reports an incident in its cloud infrastructure. The tenant reports an incident in its service delivery. The root cause may be identical; the reportable events are not.

For sector-specific incident response obligations, see digital infrastructure compliance requirements.

Cascaded Impact: When One Outage Creates Multiple Filings

The multi-tenant architecture of public cloud means that a single Art.7-threshold breach by a cloud operator can cascade into multiple simultaneous notification obligations across the operator's customer base. A cloud provider serving 10 million EU users needs only 500,001 affected users (5% of 10M) to cross the Art.7(b) threshold. Those 500,001 users are distributed across potentially thousands of corporate tenants — each of which must independently assess its own reporting obligations.

The supply chain cascade works like this in practice:

A hyperscaler's EU region experiences a compute control-plane failure lasting 55 minutes, affecting 6% of its EU user base across all tenants. The cloud provider crosses Art.7(a) (complete outage for the affected zone, >30 minutes) and Art.7(b) (>5% of users, approaching 1 hour). The provider files its 24-hour early warning.

Simultaneously, three tenant scenarios unfold:

Tenant A: A financial institution (essential entity under NIS2). The control-plane failure takes their core banking platform offline for 48 minutes during trading hours. This constitutes severe operational disruption to their own services — an independent significant incident. They file their own Art.23 early warning within 24 hours of detecting the outage, referencing the cloud failure as cause. They do not wait for the provider's notification.

Tenant B: A healthcare provider (essential entity). Their patient record system becomes read-only during the outage but does not go completely offline. Clinical staff can still view existing records but cannot admit new patients. Whether this meets the “severe operational disruption” test is a judgment the healthcare entity's CISO must make and document — the provider's filing does not make that determination for them.

Tenant C: A medium-sized logistics company (important entity). Their warehouse management system experiences a 3-hour degradation, but the impact on their end customers is limited to delayed shipping notifications. Their compliance team assesses that this does not rise to “considerable damage” to third parties under Art.23(3). No filing required — but the assessment itself must be documented and retained for audit purposes.

GDPR runs concurrently, not after. When the underlying incident involves personal data, the affected entity faces two parallel notification obligations: the NIS2 Art.23 early warning to the national CSIRT (24 hours) and the GDPR Article 33 breach notification to the data protection authority (72 hours). These go to different recipients and require different content. A cloud tenant whose data is compromised during a provider security failure must prepare both notifications simultaneously [6].

Contractual leverage. The NIS2 supply chain requirements under Article 21(2)(d) oblige NIS2 entities to address security in supplier relationships. In the cloud context, this means tenants should include explicit contractual clauses requiring the cloud provider to notify them of incidents as early as possible — to preserve the tenant's ability to meet its own 24-hour window. A provider that notifies its tenants 22 hours after an incident effectively leaves them no time to prepare an informed early warning [5]. For related supply chain obligations, see NIS2 supply chain security requirements.

Practical Compliance: Pre-Incident Preparation

The 24-hour early warning window is too short to build notification procedures under pressure. The following checklist separates what cloud operators and cloud tenants must each have in place before an incident occurs.

Role	Pre-Incident Requirement	Owner	Effort
Cloud operator	Document which services/regions fall under Art.7 scope; map user counts including end-users of enterprise customers (Art.3(3))	CISO / Legal	Medium
Cloud operator	Establish threshold monitoring: automated alerting when cumulative outage approaches 25 minutes (pre-warning for Art.7(a)) or affected-user percentage approaches 4%	Engineering / Operations	High
Cloud operator	Pre-draft Art.23 notification forms for early warning and 72h notification; designate a named signatory and CSIRT submission credential holder	Legal / CISO	Low
Cloud tenant (NIS2 entity)	Insert contractual clause in cloud service agreement requiring provider to notify within 6 hours of any Art.7-threshold incident affecting tenant's services	Legal / Procurement	Low
Cloud tenant (NIS2 entity)	Define internal significance thresholds for cloud-sourced disruptions: what impact level on tenant's own services triggers Art.23 assessment?	CISO / Compliance	Medium
Cloud tenant (NIS2 entity)	Establish a documentation protocol for “no-filing” decisions: when a cloud incident is assessed as sub-threshold, that assessment must be recorded with reasoning and retained	Compliance Officer	Low

The role-responsibility split between cloud operator and cloud tenant mirrors the broader Art.21 governance structure covered in more detail in the digital infrastructure compliance guide.

Frequently Asked Questions

Does the cloud provider's CSIRT notification satisfy my obligation as a tenant?

No. The cloud provider files as a cloud operator under Art.7 and Art.23 — reporting an incident in its own infrastructure. You, as a NIS2-regulated tenant, must assess and report independently if the impact on your own services is significant. The provider's filing is not a substitute. National CSIRTs treat these as separate events.

What if I do not know the precise user count within 24 hours?

The 24-hour early warning does not require precise figures. Article 23 explicitly allows for estimated or partial impact data at this stage — the requirement is to provide an “initial” indication of severity and cross-border impact. Updated and more precise data is expected in the 72-hour notification. Use best available estimates at the 24-hour mark and correct them in subsequent filings [3].

Do I need to notify under both NIS2 and GDPR when personal data is involved?

Yes, and the obligations are concurrent rather than sequential. NIS2 early warning goes to the national CSIRT; GDPR Art.33 notification goes to the supervisory data protection authority. The GDPR deadline is 72 hours from awareness of the personal data breach — the same starting clock as the NIS2 incident notification stage, but a different recipient and different content requirements. Where member states have designated a single-entry-point authority for both, check national transposition rules for whether a single submission covers both obligations [6].

Is a planned maintenance window exempt even if it runs over?

Partially. The planned portion is exempt under Art.3(2). If the window extends beyond its announced end time due to an unexpected technical failure — not a planned extension — the overrun period is treated as an unplanned outage. If the overrun alone exceeds the Art.7(a) 30-minute threshold, the incident becomes reportable based on that overrun [1].

Key Takeaways

• Cloud providers must notify under Art.23 when any one of four Article 7 criteria is met: 30-minute complete outage, 5%/1M-user partial outage for 1+ hours, data breach from malicious action, or data compromise at 5%/1M-user scale [1]
• The 5%/1M threshold uses whichever is smaller — large providers hit the 1-million cap before the percentage cap [1]
• The three-stage Art.23 cascade (24h / 72h / 1 month) cannot be delegated to an MSP; the entity itself must file [4]
• Cloud tenants that are themselves NIS2 entities face independent notification obligations, triggered by the impact on their own services — not by the provider's filing [3]
• Two clocks run simultaneously: the provider's from its awareness, the tenant's from the tenant's awareness [3]
• When personal data is involved, GDPR Art.33 runs concurrently with NIS2 Art.23 — two filings, two recipients [6]
• No-filing decisions must be documented and retained for audit purposes [4]

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. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
2. CIR 2024/2690 Official Journal — EUR-Lex
3. Article 23 Reporting Obligations — nis-2-directive.com
4. NIS2 Incident Reporting Playbook — nisd2.eu
5. Implementing Regulation NIS2 Rules — Hunton Andrews Kurth
6. NIS2 for Hosting Providers and Their Clients — Jorijn Schrijvershof
7. NIS2 Incident Reporting 24h/72h Framework — Legiscope