Cloud provider outage under NIS 2
Your provider being down is the test of your continuity plan, not an exemption from it.
What this page is
A major cloud provider goes down. Production stops. The question in the room is whether NIS 2 obligations sit with the provider or with your entity. The directive's answer is that both layers carry their own obligations and one does not discharge the other. Your duties under Article 21(2)(c) NIS 2 to maintain business continuity, backups and recovery, and under Article 23 to report significant incidents, apply to your entity regardless of what your provider does on its own clock.
This page is written for an IT lead or a managing director in a 50 to 250 person company that runs most of its production on a hyperscaler or a regional cloud. It is not legal advice. It is the mechanics of which clause applies to whom when the provider's status page goes red.
The single most useful sentence: a cloud outage is the live test of your Article 21(2)(c) recovery plan. If the plan works, no significant incident has happened at your entity. If the plan does not work, Article 23 starts running on your clock, not the provider's.
Directive (EU) 2022/2555 (NIS 2)
Article 21(2)(c): policies and procedures concerning business continuity, such as backup management and disaster recovery, and crisis management. Article 21(2)(d): supply chain security, including security related aspects concerning the relationships between each entity and its direct suppliers or service providers.
Article 21(2)(c) places the continuity, backup and recovery obligation on the entity. The directive does not allow that obligation to be delegated to a cloud provider through a contract. Article 21(2)(d) is the supplier risk leg: you are required to assess and manage the security of your direct providers, which includes contractual notification clauses for outages and incidents at the provider. Article 23 then sets the reporting cascade with the 24 hour early warning, the 72 hour incident notification, an intermediate update on request, and a final report within one month.
Commission Implementing Regulation (EU) 2024/2690
Article 23(3) NIS 2: An incident shall be considered to be significant if it 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.
The CIR quantifies what counts as significant for the 11 digital infrastructure and digital service categories it covers, which includes cloud computing service providers under Annex I sector 8 of NIS 2. Annex section 11 of the CIR lists scenarios that constitute a significant incident at that provider layer. For entities outside the CIR's scope, the Article 23(3) significance test is the one that applies and a cascading outage that stops production almost always meets it.
BSIG (Germany)
§30 BSIG: technical and organisational measures appropriate to the risk. §32 BSIG: notification of significant incidents to the BSI via the Meldeportal at bsi.bund.de. §31 BSIG: supply chain security duties for the entity.
BSIG is the German transposition example. Netherlands (Cyberbeveiligingswet) and Austria (NISG 2024) have their own. The 24 / 72 hour / intermediate / one month cascade is directive level and identical across member states. A cloud provider that is itself a NIS 2 entity in the EU has its own §32 BSIG or equivalent national reporting duty. That duty does not extinguish yours.
Assess against your Article 21(2)(c) plan
Open the business continuity and disaster recovery plan and run it. The question is not whether the provider is down. The question is whether your services can keep operating under the plan you wrote. Failover to a secondary region, switch to a documented offline workflow, or restore from a backup held outside the affected provider. Article 21(2)(c) NIS 2 puts the continuity duty on your entity. If the outage exposes that there was no plan, that is the first finding, not the outage.
Trigger your Article 21(2)(d) supplier process
Article 21(2)(d) NIS 2 requires you to manage the security of your direct providers. In practice that means three things in an outage: open the contract and read the notification and SLA clauses, log the provider's incident reference and any timeline they publish, and capture the evidence in your audit trail. If the contract does not require provider notification of incidents that affect you, that is the second finding, separate from the outage itself.
Report if your entity has a significant incident
The Article 23(3) test is applied to your entity, not to the provider. If the outage causes severe operational disruption of your services, financial loss to you, or considerable damage to others who depend on you, then Article 23 NIS 2 starts running on your clock. Early warning to the national CSIRT or competent authority within 24 hours of becoming aware, incident notification within 72 hours, intermediate report on request, final report within one month. In Germany this goes through the BSI Meldeportal under §32 BSIG. The provider's own report under its own NIS 2 status is separate and does not file for you.
Continuity is the entity's duty, not the provider's
Article 21(2)(c) NIS 2 places the continuity, backup and recovery duty on the entity. A contract with a hyperscaler that promises a 99.99 percent availability target is not a continuity plan in the directive's sense. The plan has to describe what your entity does when the provider is unavailable. The auditor next year tests whether such a plan exists and whether it was exercised, not whether the SLA was honoured.
Backups have to be recoverable, not just present
The BSI position is that the existence of a backup is not the test. Restorability under the conditions of an actual incident is. A backup held in the same cloud region as the production system, against the same identity provider, is not a backup in the Article 21(2)(c) sense when the region or the identity layer is what fails. The recoverable backup obligation requires separation across the failure domain you are trying to survive.
BSI Meldeportal (Germany), national CSIRT (other member states)
If the outage causes a significant incident at your entity under Article 23(3), the report goes through your national channel. In Germany that is the BSI Meldeportal under §32 BSIG. In Netherlands the National Cyber Security Centre, in Austria the GovCERT. The report is yours to file even though the root cause sits with the provider. A provider's status page is not a filing.
Cloud provider as a NIS 2 entity, Annex I sector 8
An EU established cloud computing service provider is an essential or important entity under Annex I sector 8 of NIS 2 (digital infrastructure). It owes its own Article 23 reporting on its own clock to its own competent authority or CSIRT. The CIR 2024/2690 specifies the significance thresholds for digital infrastructure providers. The provider's report is not your report. A provider outside the EU is outside the directive's scope, in which case Article 21(2)(d) supplier risk management is your only handle on it.
ENISA and the CSIRTs network
Cross border outages of major cloud providers are coordinated through the CSIRTs network coordinated by ENISA under Article 15 NIS 2. ENISA publishes situational awareness across member states. For an individual entity this is reference material rather than a reporting channel. The reporting channel is national. ENISA is where you read what is happening at the EU level when the provider is down across several countries.
The cloud is the provider's problem. NIS 2 sits with them.
Article 21(2)(c) NIS 2 puts the continuity, backup and recovery obligation on your entity. Article 21(2)(d) puts the supplier risk obligation on your entity. The provider has its own duties under the directive if it is an EU established cloud provider under Annex I sector 8, but those duties run in parallel with yours and do not discharge them. The audit next year tests your plan, not the provider's SLA.
Wait for the provider's post incident SLA report before filing or reviewing.
Article 23(4) NIS 2 requires the early warning within 24 hours of becoming aware of a significant incident at your entity. The provider's report can take weeks. If the outage caused severe operational disruption at your entity, the 24 hour clock runs against you whether or not the provider has issued anything. Waiting for the SLA report is the single most common reason entities miss the deadline in cloud outage cases.
The provider came back, everything works again, the incident is closed.
Article 21(2)(c) NIS 2 expects the continuity and recovery plan to be exercised and improved. A cloud outage is a live exercise of that plan, and the post incident review is what feeds the next iteration. The auditor will ask what changed in the recovery plan after the last outage. If nothing changed and the same gap is still there, that is a finding. A return to normal operations is not a closed incident in the directive's sense.
A 110 person logistics company in North Rhine Westphalia, classified as wichtige Einrichtung under NIS 2 because the sector and headcount put it in scope. Tuesday 09:14: the hyperscaler's EU central region degrades and the company's transport management system, identity provider and shared file storage all go unreachable. 09:20: IT lead opens the continuity plan, switches dispatch to the documented offline workflow on local laptops, and informs the managing director. 09:35: management body briefed, decision logged in the audit trail to treat this as a continuity event under Article 21(2)(c) and to monitor against the Article 23(3) significance test. The provider's status page is screenshotted and attached to the incident record.
11:50: the outage has lasted over two hours and is now affecting customer delivery commitments. Article 23(3) test is reassessed: severe operational disruption of services is met. The 24 hour early warning is filed through the BSI Meldeportal under §32 BSIG citing the provider's incident reference and the company's own impact. 14:30: provider recovers the region. The company runs the post incident review the next morning. Finding: the secondary identity provider was on paper but never exercised, so failover took 40 minutes longer than the plan assumed. Two written changes go into the plan: monthly exercise of the secondary identity provider, and a contract amendment with the cloud provider to require notification of regional incidents within 30 minutes. The intermediate report and the one month final report under Article 23 are filed from the audit trail, not from memory.
The platform stores the four written things you need before the next provider outage: the continuity plan tied to Article 21(2)(c), the recoverable backup configuration with evidence of its separation from the primary failure domain, the supplier register with notification and SLA clauses tied to Article 21(2)(d), and the reporting templates and contact list for the Article 23 cascade. Every change and every exercise is captured in the audit trail with timestamps, so the auditor next year sees a plan that was actually run, not a document that was once written.
The platform is free and open source. There is no paid tier and no lock in. The point of this page is not to sell anything. It is to make sure that when the provider's status page goes red, your management body knows whether the directive's clock is ticking on you and what the next written step is.
- Directive (EU) 2022/2555 (NIS 2): Article 21(2)(c) (business continuity, backup, recovery, crisis management), Article 21(2)(d) (supply chain security), Article 23 (reporting cascade) and Article 23(3) (significance test). Annex I sector 8 (digital infrastructure, including cloud computing service providers). EUR-Lex.
- Commission Implementing Regulation (EU) 2024/2690: technical and methodological requirements and significance thresholds for digital infrastructure and digital service providers, including cloud providers. Annex section 11. EUR-Lex.
- BSIG (Germany): §30 (risk management measures), §31 (supply chain security), §32 (BSI Meldeportal). Gesetze im Internet.
- BSI: NIS 2 information packages on continuity, recoverable backups and the position that the existence of a backup is not the test. bsi.bund.de.
- ENISA: CSIRTs network coordination under Article 15 NIS 2 for cross border incidents. enisa.europa.eu.