NIS2 Cloud Outage Reporting: Your Provider Files Its Own Report — You May Still Owe One Within 24 Hours

In October 2025, Amazon’s own post-event summary records that the DynamoDB endpoint in us-east-1 failed to resolve “between 11:48 PM PDT on October 19 and 2:40 AM PDT on October 20” — a little under three hours, caused by “a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record” [5]. But new EC2 instance launches kept failing until 10:36 AM, and load-balancer connection errors ran to 2:09 PM. AWS’s incident lasted just under three hours. Its customers’ incidents lasted most of a working day.

That gap is where the reporting question lives. Your cloud provider, if it is an in-scope entity, files its own Article 23 notification about its own service. That filing does nothing for you. NIS2 contains no pass-through, no single-window, and no rule that excuses an entity because someone else caused the failure. This guide works through the actual test: whether you are in scope, which threshold set binds you, what you measure, when your 24-hour clock starts, and the one duty that fires even when no report is due.

First, Which of the Three Positions Are You In?

In plain terms: three different organisations can be looking at the same cloud outage, and all three have different obligations. Find yourself in the table before reading further.

Your position	Which significance test applies to you	What you are measuring
You are an essential or important entity (energy, health, transport, manufacturing, water, public administration and so on) that consumes cloud services	Article 23(3) of the Directive — the two-limb test. CIR 2024/2690 does not legally bind you, but your national authority may use it as the benchmark	Disruption to the services you provide to your recipients
You are one of the eleven categories of entity named in CIR 2024/2690 Article 1 (cloud, data centre, DNS, TLD, CDN, MSP, MSSP, marketplace, search, social platform, trust services)	CIR 2024/2690 Articles 3 to 14 — hard, category-specific thresholds	Availability of the specific service you operate, measured in minutes and Union users
You are the cloud provider whose platform failed	CIR 2024/2690 Article 7	Your own service, under the jurisdiction of the Member State of your main establishment (Article 26(1)(b))

Position three is the one everyone reads about. Positions one and two are the ones that generate the missed filings, because the entity in those seats spends the outage watching a status page it does not control and concludes, reasonably but wrongly, that the incident belongs to someone else.

Two Separate Filings, Not One Report Passed Down the Chain

The Directive’s reporting duty is written around services, not assets. Article 23(1) requires notification of “any incident that has a significant impact on the provision of their services” [1] — their services, meaning yours. Nothing in that sentence asks who owns the failed hardware.

Two definitions close the question. Article 6(6) defines an incident as “an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems”. And Article 21(1) attaches the whole risk-management duty to “network and information systems which those entities use for their operations or for the provision of their services” [1]. The operative verb is use, not own, not host, not control. A platform you rent is a network and information system you use.

Recital 83 signals the same intent in plainer language — the obligations apply “regardless of whether those entities maintain their network and information systems internally or outsource the maintenance thereof” [1]. Recitals are interpretive aids and create no obligation on their own, so the binding hook remains Articles 21(1) and 23(1). Germany’s BSI, as national competent authority, puts the practical version bluntly: even where IT is completely outsourced, the entity itself remains responsible and must ensure “dass Vorfälle ordnungsgemäß gemeldet werden” — that incidents are properly reported. Contracts alone are not sufficient [4]. The same logic already governs outsourcing security operations to an MSSP, and even AWS’s own customer guidance concedes it: the customer “must verify that the incident is managed and that regulatory reporting requirements to relevant stakeholders are fulfilled in tandem” [6].

So there is no delegation and no netting off. If the outage is significant for the provider, the provider files. If it is significant for you, you file. Both can be true at once, to different authorities, on different clocks. That is the same structure as a supplier breach, with one difference: a breach is an attack, and an outage usually is not.

Run the Test on Your Service, and Measure Your Own Window

In plain terms: the 30-minute figure you have read about is the provider’s threshold. Do not apply it to yourself unless you are also a digital provider — and if you are, apply it to your own service, not to theirs.

CIR 2024/2690 Article 7 makes a cloud incident significant where “a cloud computing service provided is completely unavailable for more than 30 minutes”, or where availability is “limited for more than 5 % of the cloud computing service’s users in the Union, or for more than 1 million… whichever number is smaller, for a duration of more than one hour” [2]. That provision is addressed to the provider. It sits inside a set of category-specific availability thresholds in Articles 5 to 14, running from no duration qualifier at all for data centres and TLD registries, through 20 minutes for trust services, to 30 for cloud, DNS, CDN and managed service providers.

If you consume cloud services and sit outside the eleven CIR categories, your test is the Article 23(3) two-limb test: significant if the incident “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned”, or if it “has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage” [1]. No minutes, no user percentages — a judgement about your operations. The BSI narrows that judgement usefully for German entities: outside the CIR-bound sectors, an incident can be presumed significant where at least one Article 3(1) criterion is met, and “Zudem ist immer dann von einem erheblichen Sicherheitsvorfall auszugehen, wenn die Erbringung kritischer Dienstleistungen ausgefallen oder beeinträchtigt ist” — a significant incident is always to be assumed where the delivery of critical services has failed or been impaired [3]. No duration element at all. That is one national authority’s reading, not Directive text, but it is the clearest published answer to the question.

Now the trap that catches software companies. The BSI’s own FAQ addresses whether a SaaS offering counts as a cloud computing service when the provider does not operate the underlying compute itself. The answer is yes: “Dass der SaaS-Anbieter die zugrunde liegenden Rechenressourcen nicht selbst physisch betreibt, sondern diese von einem externen Cloud-Provider bezieht, steht einer Einordnung als Cloud-Computing-Dienst… nicht entgegen, da eine solche Betreiberidentität gesetzlich nicht gefordert wird” [4]. Operator identity is not required by law. If you sell a functionally independent, scalable, elastic, remotely accessed service, you are a cloud computing service provider — and Article 7’s 30-minute bar applies to your service even though you own not one server. When your hyperscaler fails, you are simultaneously a victim and a regulated provider.

Which brings up the measurement window. The provider measures its component; you measure your service. In the October 2025 event, DynamoDB name resolution was broken for roughly two hours and fifty-two minutes, but AWS records that new EC2 launches failed “between 2:25 AM and 10:36 AM” and that load-balancer connection errors persisted “between 5:30 AM and 2:09 PM PDT” [5]. A workload that could not scale or failover for eight hours had an eight-hour outage, whatever the provider’s own summary says. Take your restoration timestamps from your monitoring, not from their status page.

Service model	Who controls recovery	What you measure and against which test
IaaS (compute, storage, network)	Mostly you — you own the failover architecture, multi-AZ and multi-region design	Your application’s unavailability. Article 23(3), or CIR Articles 5–14 if you are a digital provider
PaaS (managed databases, queues, serverless)	Split — the provider owns the runtime, you own placement and retry logic	Same. Note that regional dependencies you did not choose can still be your single point of failure
SaaS you consume (email, CRM, ticketing)	Almost entirely the vendor	Article 23(3) only. Ask first whether the tool supports a service in your NIS2 annex scope at all
SaaS you sell, running on someone else’s infrastructure	Split — but the regulatory exposure is entirely yours	CIR Article 7 applies to your own service: 30 minutes complete unavailability, or the 5 % / 1 million Union-user degradation test over one hour

When Your 24-Hour Clock Actually Starts

Article 23(4)(a) requires the early warning “without undue delay and in any event within 24 hours of becoming aware of the significant incident” [1]. The Directive does not define awareness, so national guidance carries the weight. The BSI defines Kenntniserlangung as the moment at which an employee of the entity, during working hours, learns of a significant incident [3] — not the moment the security team confirms it. A support engineer reading a provider status update at 02:00 is capable of starting that clock.

What the status page does not do is decide significance for you. A provider notification tells you a component failed; it does not tell you whether your service was severely disrupted. The sequence is: notification, then your own timely assessment, then awareness of a significant incident, then 24 hours. Keep that assessment short and documented, because a slow assessment is indistinguishable from a late filing after the fact.

One field on the early warning deserves attention. Article 23(4)(a) says it “shall indicate whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact” [1]. Most cloud outages are configuration errors, race conditions or power events, not attacks — Recital 79 confirms the all-hazards scope covers “theft, fire, flood, telecommunication or power failures” [1], though as a recital it explains intent rather than creating the duty. Answering “no malicious act suspected” is a complete and correct answer, not a reason to skip the filing. The BSI’s stated posture is Schnelligkeit vor Vollständigkeit — speed before completeness [3] — and Article 23(1) adds that “the mere act of notification shall not subject the notifying entity to increased liability” [1].

Role	What you own in the first 24 hours
CISO / IT security manager	Timestamp your own service degradation independently of the provider. Capture monitoring evidence before it rolls off retention
Compliance officer / legal	Run the Article 23(3) test and record the reasoning, including a decision not to file. Confirm which Member States are in scope
SME owner without a security team	Decide one thing: did customers lose the service you sell them? If yes, contact your national CSIRT and say so. It costs nothing to be early
Board / management body	Approve the filing decision and note it. Under German law, reporting failures carry fines up to EUR 7m or 10m, or 1.4 % or 2 % of total turnover [4]

The Two Carve-Outs Worth Knowing, and the One That Does Not Exist

CIR 2024/2690 Article 3(2) is short and almost never cited: “Scheduled interruptions of service and planned consequences of scheduled maintenance operations carried out by or on behalf of the relevant entities shall not be considered to be significant incidents” [2]. Read the phrase by or on behalf of. It reaches work your provider performs for you — a planned migration window, an announced maintenance event. It does not reach an unplanned failure, and it does not stretch to cover the consequences of your own emergency remediation. A provider’s scheduled window is outside the regime; a provider’s outage is not.

The second is Article 6(5) of the Directive: a near miss is an event that “could have compromised” availability “but that was successfully prevented from materialising or that did not materialise” [1]. If your multi-region failover absorbed the outage cleanly and your recipients never lost the service, you arguably had a near miss rather than an incident. That is not reportable under Article 23, though Article 30 allows a voluntary notification.

The carve-out that does not exist is cumulative downtime. Article 4 aggregates individually sub-threshold incidents into one significant incident only where they occur at least twice in six months, share the same apparent root cause, and “collectively meet the criteria set out in Article 3(1)(a)” [2] — the financial limb. There is no mechanism anywhere in the Regulation for summing elapsed minutes. Five 25-minute outages from the same provider fault never become a reportable 125-minute outage; they aggregate only if the combined direct financial loss crosses EUR 500,000 or 5 % of turnover, whichever is lower. Nor does your SLA set your threshold. Service credits are a contractual matter between you and your vendor; they have no bearing on Article 23, and sources that describe an SLA breach as the reporting trigger are describing a commercial event, not a regulatory one.

The Deliverable You Owe Even When You File Nothing

Suppose you run the test and conclude no report is due. One obligation still fires, and it is written rather than optional.

CIR Annex point 5.1.6 requires entities to review the supply chain security policy and act on changes in supplier practice not only at planned intervals but “when significant changes to operations or risks or significant incidents related to the provision of ICT services… from suppliers and service providers occur”. Point 5.1.7 then specifies what that means in practice: (b) “review incidents related to ICT products and ICT services from suppliers and service providers”; (c) “assess the need for unscheduled reviews and document the findings in a comprehensible manner”; and (d) analyse the risks arising from changes and take mitigating measures in a timely manner [2]. A provider outage is precisely a significant incident related to the provision of ICT services. It produces a documented re-assessment with no reporting threshold attached to it at all — a paper trail an auditor can ask for even in a year where you filed nothing.

Two smaller duties travel with it. Article 23(1)’s second sentence: “Where appropriate, entities concerned shall notify, without undue delay, the recipients of their services of significant incidents that are likely to adversely affect the provision of those services” [1] — your customers, separately from the regulator. And Annex 5.2 requires a current registry of direct suppliers with contact points [2], which during an outage is the difference between escalating through a named contact and refreshing a public dashboard. All of it sits on top of the standing Article 21 control set for cloud environments.

Two boundaries close this out. A notification to one authority does not discharge obligations elsewhere: the BSI states plainly that a report to it “erfüllt nicht automatisch alle Meldepflichten in anderen Staaten” — it does not automatically satisfy reporting duties in other states [4]. And financial entities should check the DORA interaction; under section 28(7) of the German BSIG, the NIS2 reporting duty falls away where an incident exclusively concerns DORA-regulated undertakings and is already reportable under DORA [4]. That is a national provision, and other Member States may have drawn the line differently.

Frequently Asked Questions

My cloud provider already filed an Article 23 report. Do I still need to file?
If the outage significantly impacted the provision of your services, yes. Article 23(1) attaches the duty to each entity’s own service provision, and the Directive contains no pass-through or single-window mechanism. Their filing covers their service to their regulator.

Does a cloud outage count at all if nobody attacked anything?
Yes. Article 6(6) defines an incident by compromised availability, with no requirement of malice, and Recital 79 confirms the all-hazards intent covering events such as power and telecommunication failures. Article 23(4)(a) simply asks you to indicate whether unlawful or malicious acts are suspected.

Does the 30-minute threshold apply to me?
Only if you are one of the eleven categories of entity in CIR 2024/2690 Article 1 — and then to your own service, not your provider’s. A SaaS company running on rented infrastructure generally is such an entity, per BSI guidance. Everyone else applies the Article 23(3) two-limb test.

We failed over successfully and customers noticed nothing. Reportable?
Probably a near miss under Article 6(5) rather than an incident, so not reportable under Article 23. Article 30 permits a voluntary notification, and the Directive states that voluntary reporting imposes no additional obligations you would not otherwise have had.

Our provider took nine hours to send a formal notice. Does that excuse a late filing?
No. Your clock runs from your own awareness of a significant incident, not from the vendor’s paperwork. This is why practitioners increasingly negotiate notification timelines into cloud contracts; existing standard notification clauses generally fall short of NIS2’s timelines (DLA Piper, dlapiper.com). Note too that under Article 26(3) a non-EU provider offering services in the Union must designate an EU representative — but its own scope status does not change yours either way.

Closing the File

The instinct after a provider outage is to treat it as someone else’s incident, file the vendor’s post-mortem and move on. The Directive does not read that way. It measures the disruption to the service you provide, using systems you use, on a clock that starts when your own people become aware. Build the assessment into your incident runbook as a standing branch — provider-caused, own-service impact, documented decision — and the 24-hour question answers itself while the outage is still running.

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. Directive (EU) 2022/2555 (NIS2), full text — EUR-Lex
2. Commission Implementing Regulation (EU) 2024/2690, full text and Annex — EUR-Lex
3. “#nis2know: NIS-2-Meldepflicht” — BSI, Bundesamt für Sicherheit in der Informationstechnik, German national competent authority (bsi.bund.de)
4. “Fragen und Antworten zu NIS-2” — BSI (bsi.bund.de)
5. Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region — AWS post-event summary
6. NIS 2 Considerations for AWS Customers — Amazon Web Services
7. “NIS2 directive explained Part 3: Supply chain security” — DLA Piper (dlapiper.com)