NIS2 for Cloud Providers and SaaS: The "Cloud Computing" Sector

Main article: NIS2 implementation in Germany — the full pillar article on the topic.

1. Sector classification

Cloud computing services belong to the digital infrastructure sector (Annex I NIS2 Directive / Annex 1 BSIG). Unlike DNS service providers, TLD name registries or qualified trust service providers, however, cloud providers are not essential entities irrespective of size — classification depends on the size of the undertaking (§ 28(1) and (2) BSIG):

• Particularly important (= essential) entity: large undertaking of a type listed in Annex 1 (§ 28(1) no. 4 BSIG).
• Important entity: medium-sized undertaking (§ 28(2) no. 3 BSIG).

Below the threshold for medium-sized undertakings (fewer than 50 employees and less than EUR 10 million each), cloud providers are in principle not covered by NIS2 — the size independence that applies to operators of critical installations, DNS, TLD, trust services and certain telecommunications providers precisely does not apply to the entity type cloud computing. Anyone who also operates a critical installation is, however, a particularly important entity irrespective of size by virtue of that operator status (§ 28(1) no. 1 BSIG).

For size-based classification, two conditions must be met at the same time: allocation to an entity type specified in Annex 1 or 2 BSIG and reaching the size threshold. For cloud computing services, the entity type is one under Annex 1; that is the reason why a cloud provider can move up into the 'particularly important' category at all — § 28(1) no. 4 BSIG covers Annex 1 types exclusively, whereas § 28(2) no. 3 BSIG covers Annex 1 and Annex 2 types.

Two pitfalls in the calculation: first, turnover alone is never sufficient — § 28(1) no. 4(b) BSIG requires turnover and balance sheet total cumulatively; only the number of employees works as a stand-alone criterion. Second, the calculation of employee numbers, annual turnover and balance sheet total follows Recommendation 2003/361/EC with the exception of Art. 3(4) of its Annex (§ 28(4) BSIG) — belonging to a group may bring linked undertakings into the calculation and pull a SaaS provider that is small in itself into scope. In Austria, from 1 October 2026 the size determination is made under the same recommendation with the same exception (§ 25 NISG 2026).

Germany and Austria: §§ 28, 30, 32, 33, 35, 38, 39 and 65 BSIG referred to in this article apply in Germany only. In Austria, the NISG 2026 (BGBl. I Nr. 94/2025) applies instead of the BSIG — promulgated on 23 December 2025, but applicable only upon expiry of nine months after promulgation, as of the first day of the following month, i.e. from 1 October 2026 (§ 51(1) and (2) NISG 2026); as at the date of this article, no effective obligations arise from it yet. All following statements on the NISG 2026 apply from that date. There, too, cloud computing belongs to digital infrastructure (Annex 1); the size thresholds (large undertaking = essential entity, medium-sized undertaking = important entity) correspond to the German values. The Austrian obligations in detail — catalogue of measures, reporting channels and deadlines, registration and self-declaration — are set out in sections 3, 5 and 7.

2. SaaS providers as cloud providers?

SaaS is expressly one of the service models of cloud computing within the meaning of NIS2. The statutory definition is decisive: a 'cloud computing service' is a digital service that enables on-demand administration of, and broad remote access to, a scalable and elastic pool of shareable computing resources, including where such resources are distributed across several locations (§ 2 no. 4 BSIG; to the same effect Art. 6 no. 30 NIS2 Directive). Recital 33 of the NIS2 Directive expressly lists the service models: IaaS (infrastructure as a service), PaaS (platform as a service), SaaS (software as a service) and NaaS (network as a service) are 'among others' included. The deployment models comprise private, community, public and hybrid cloud.

Whether you are covered is therefore decided not by the service model, but by two other questions: (1) does the service meet the definition — scalable and elastic pool of resources, on-demand administration, broad remote access? (2) are the size thresholds from section 1 reached? A single, non-scalable web application without an elastic pool of resources does not fall under the definition — but 'pure SaaS' as a category is not a ground for exclusion.

The allocation does not remain internal; it is placed on record with the authority: § 33(1) BSIG requires the relevant sector under Annex 1 or 2 to be stated upon registration (deadlines and the full list of details: section 7). Practical recommendation: document the assessment in this order — fulfilment of the statutory definition, then size under § 28(1) and (2) BSIG, then group affiliation under § 28(4) BSIG — and record the result with a date.

3. Obligations to take measures under Section 30 BSIG — what is added for cloud providers

The general catalogue of measures in Section 30 BSIG applies to cloud providers; two points in particular have a cloud-specific effect: the allocation to Annex 1, with the move up into the 'particularly important' category that goes with it, and the reporting threshold specified by Implementing Regulation (EU) 2024/2690 (section 5).

The standard is anchored in law first of all: § 30(1) BSIG requires appropriate, proportionate and effective technical and organisational measures to avoid disruptions to the availability, integrity and confidentiality of IT systems and to keep the impact of security incidents small; compliance must be documented. The Austrian counterpart, § 32(1) NISG 2026, requires appropriate and proportionate risk management measures in technical, operational and organisational terms. Under § 30(2) sentence 1 BSIG, the measures should also follow the state of the art and the relevant standards and must be based on an all-hazards approach (evidentiary value of certificates: section 6).

The catalogue in § 30(2) BSIG names ten areas: (1) policies on risk analysis and information system security, (2) incident handling, (3) business continuity with backup management, disaster recovery and crisis management, (4) supply chain security, (5) security in acquisition, development and maintenance, (6) assessment of the effectiveness of the measures, (7) basic training and awareness measures, (8) cryptography and encryption, (9) human resources security and access control, (10) multi-factor authentication, continuous authentication and secure communication. In Austria, the corresponding catalogue is set out in § 32(4)(a) to (j) NISG 2026, in the same order ((d) = supply chain security, (g) = cyber hygiene and training). Practical recommendation: providers who develop their platform themselves typically fill area 5 along OWASP lines and add vulnerability management via a CVD process (coordinated vulnerability disclosure).

Practical recommendation: set out the four cloud-typical expectations of your customers — stricter service level agreements, higher availability standards, alignment with the ENISA cloud security benchmark and an EU data boundary — expressly in the customer contract and in the package of measures; the depth of implementation remains risk-based under § 30(1) BSIG.

4. Supply chain and sub-providers: who is responsible for what

You remain responsible for the security of your supply chain: it is a separate area of obligation within the catalogue of measures (§ 30(2) no. 4 BSIG; § 32(4)(d) NISG 2026) and therefore your own obligation as an entity — regardless of which obligations apply to your suppliers in turn. In practice, this concerns the data centres, managed service partners and software suppliers from which your service is assembled — contractual cybersecurity clauses vis-à-vis sub-providers are the practical lever for this. Area 4 is at the same time the most frequent audit finding in 2026, typically because cybersecurity clauses are missing from the contracts. In implementation, four building blocks have become established (practical recommendation, not a statutory list):

• Supplier assessment with risk classification — separating critical from non-critical sub-providers.
• Cybersecurity clauses in the standard contract documents rather than in individual negotiations.
• Right to audit for critical suppliers.
• Contractual incident notification by the sub-provider, usually within 24 hours — so that your own 24-hour deadline under § 32(1) no. 1 BSIG remains achievable.

Under data protection law, the chain runs in parallel but follows a different logic: Art. 28(1) GDPR obliges the Controller — that is, your customer — to work only with Data Processors providing sufficient guarantees of appropriate technical and organisational measures; Art. 28(3) GDPR sets out the minimum content of the data processing agreement (subject matter and duration, nature and purpose, type of data, categories of data subjects, obligations and rights of the Controller). That is the reason why your customers request questionnaires, evidence and audit reports — the basis of the request is their own obligation under Art. 28(1) GDPR; which evidence you provide for this as a Data Processor is governed by the data processing agreement under Art. 28(3) GDPR.

5. Incident reporting: authority, customers, deadlines

The 24-hour deadline does not apply to customer information. It concerns solely the early warning to the authority: in Germany the early initial notification to the joint reporting office of the BSI and the BBK (§ 32(1) no. 1 BSIG), in Austria the early warning to the competent CSIRT (§ 34(2) no. 1 NISG 2026). This is followed by the notification with an initial assessment within 72 hours and the final report within one month.

Vis-à-vis the recipients of the services — that is, your customers — no hourly grid applies, but the standard of 'without undue delay':

• Germany: the BSI may order that the recipients of the services be informed without undue delay of a significant security incident that could adversely affect the provision of the service in question; the information may also be provided via the entity's own website (§ 35(1) BSIG). Without such an order — and thus on their own initiative — entities in the sectors digital infrastructure, ICT service management and digital services, including cloud providers, must inform the recipients potentially affected by a significant cyber threat, and the BSI, without undue delay of possible remedial measures and of the threat itself (§ 35(2) BSIG).
• Austria: where a significant cybersecurity incident adversely affects the provision of the service, the recipients of the services must be informed without undue delay and, where possible, told of possible remedial measures (§ 34(3) NISG 2026); the Cybersecurity Authority (Cybersicherheitsbehörde, Austria) may additionally order by formal decision that the persons potentially affected by a significant cyber threat be informed (§ 39(3) no. 1(a) NISG 2026).
• Under data protection law: as a Data Processor, the cloud provider likewise notifies a personal data breach to the Controller 'without undue delay' (Art. 33(2) GDPR). The 72-hour deadline in Art. 33(1) GDPR applies to the Controller vis-à-vis the supervisory authority — not to the provider vis-à-vis the customer. Communication to the data subjects where a high risk is likely also lies with the Controller under Art. 34(1) GDPR.

Practical consequence: shorter information deadlines towards customers (e.g. 'within 24 hours') are a contractual commitment from a data processing agreement or SLA, not a statutory NIS2 obligation.

When is an incident significant?

Whether the reporting chain is triggered at all is decided by the significance threshold. What must be reported is the significant security incident under § 2 no. 11 BSIG: a security incident that has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or that has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage; each of the two alternatives is sufficient in itself, and both also cover the mere capability of causing such effects. For cloud providers there is an additional feature: Implementing Regulation (EU) 2024/2690 specifies this threshold with quantitative criteria — including the number of users affected, financial impact and duration — and does so for certain digital entity types which expressly include cloud and data centre services (alongside DNS service providers, TLD name registries, CDN, managed (security) service providers, online marketplaces, search engines, social networks and trust service providers; cf. § 30(3) BSIG). For entities outside that list, only the definition in § 2 no. 11 BSIG applies until a statutory instrument under § 56(5) BSIG is adopted. In Austria, § 35(1) NISG 2026 defines the significant cybersecurity incident by way of the same two alternatives, but its wording expressly requires severe operational disruption of the services provided or severe financial loss.

Practical recommendation: because the significance assessment takes place under time pressure when it matters, the assessment logic belongs in the incident response playbook in advance — with its own triggers, the quantitative criteria of Implementing Regulation (EU) 2024/2690 and a named person who takes the reporting decision. The 24-hour clock runs from becoming aware, not from the start of the incident, and it also runs at night and at weekends; continuous availability through an internal on-call rota or an external SOC service provider is the usual way to hold this together organisationally.

6. Recommended standards and their evidentiary value

Four standards are relevant for cloud and SaaS providers: ISO 27017 (cloud security), ISO 27018 (cloud privacy), the BSI cloud standard C5 and CSA STAR.

What evidentiary value such certificates have is determined by § 30(2) sentence 1 BSIG: the measures should comply with the state of the art and take into account the relevant European and international standards. In supervisory practice, the BSI IT-Grundschutz modules, ISO 27002, the ENISA Technical Implementation Guidance v1.0 (26 June 2025) and sector-specific standards serve as a guide to the state of the art; this is not a static standard — keeping it up to date is part of it.

For a gap analysis, experience with ISO 27001 is the most useful reference point: certification covers 70 to 80% of the requirements of Section 30 BSIG. The typical gaps lie in the reporting obligations of 24 h / 72 h / 1 month (§ 32 BSIG), in supply chain due diligence under § 30(2) no. 4 BSIG and in the management obligations under Section 38 BSIG — precisely the three points covered in sections 4, 5 and 8. Practical recommendation on area 8 (cryptography): TLS 1.3 in line with BSI TR-02102 for data in transit and HTTPS throughout, AES-256 for data at rest including backups, S/MIME or PGP for sensitive email communication, an HSM or equivalent key management system for key administration, and preparation for post-quantum procedures (NIST standards 2024).

7. Registration, evidence and supervision

Registration is a stand-alone obligation and not part of risk management: particularly important and important entities as well as domain name registry service providers register at the latest three months after they first or again qualify as such, via a registration facility set up jointly by the BSI and the Federal Office of Civil Protection and Disaster Assistance (BBK) — in practice via the 'Mein Unternehmenskonto' portal (§ 33(1) BSIG). The BSI points out that the statutory registration deadline has already expired; anyone who has missed it should register subsequently — the obligation continues to apply.

The details to be transmitted are the name including legal form and, where applicable, commercial register number, the address and current contact details including email, public IP address ranges and telephone numbers, the relevant sector under Annex 1 or 2, the list of EU Member States in which services are provided, and the competent federal and Land supervisory authorities. Practical recommendation: maintain the list of countries as a separate, versioned data set — what matters is in which Member States the service is provided. Changes must be transmitted without undue delay, at the latest two weeks after becoming aware of them (§ 33(5) BSIG). Operators of critical installations register by way of derogation under § 8 of the German KRITIS Umbrella Act (KRITIS-Dachgesetz) (§ 33(2) BSIG); if an entity fails to comply with its registration obligation, the BSI may carry out the registration itself (§ 33(3) BSIG).

Registration must be kept strictly separate from ongoing evidence — and here the jurisdictions differ markedly. In Germany, the periodic obligation to provide evidence through security audits, reviews or certifications under § 39(1) BSIG primarily concerns operators of critical installations: at a point in time determined by the BSI, at the earliest three years after they first qualify as the operator of a critical installation, and every three years thereafter; the results including any security deficiencies identified must be transmitted. For the remaining particularly important and important entities, the documentation obligation under § 30(1) BSIG applies in any event. In Austria, a different model applies: essential and important entities transmit structured information on the risk management measures implemented to the Cybersecurity Authority within twelve months of the registration obligation arising (self-declaration, § 33(1) NISG 2026); upon request, implementation must be evidenced within two years by an independent body, with essential entities having to demonstrate operational and organisational implementation within as little as two months of the request (§ 33(2) NISG 2026). The first such request may be made at the earliest two years after entry into force, i.e. from 1 October 2028.

The intensity of supervision also differs: under the scheme of the NIS2 Directive, essential entities are subject to proactive supervision and important entities to ex post supervision. In Germany, the competent authority is the BSI as a higher federal authority within the remit of the Federal Ministry of the Interior and the central body for information security at national level (§ 1 BSIG). In Austria it is the Federal Office for Cybersecurity (Cybersicherheitsbehörde), an authority directly subordinate to the Federal Minister of the Interior with nationwide competence and its seat in Vienna (§ 3a(1) and (2), § 3b(3) NISG 2026); supervision and enforcement follow §§ 38 and 39 NISG 2026. Registration there is with the Cybersecurity Authority within three months of entry into force, i.e. by the end of 2026 (§ 29(2) and (3) NISG 2026); the details to be transmitted include the sector and sub-sector under Annex 1 or 2, the Member States in which services are provided, the main establishment and information on the thresholds. Changes to the core data must be notified within two weeks (§ 29(4) NISG 2026). Group structures with a German and an Austrian company must register separately in both countries.

8. Management bodies and the range of fines

Responsibility for the risk management measures lies with the management bodies themselves: § 38(1) BSIG obliges them to implement the measures under § 30 and to supervise their implementation — both, not just one. If they breach these obligations, they are liable to their entity for culpably caused damage under the rules of the company law applicable to the legal form; under the BSIG itself, the management is liable only on a subsidiary basis, namely where the relevant company law contains no such liability rule (§ 38(2) sentence 2 BSIG). Added to this is the obligation to take part in training on a regular basis (§ 38(3) BSIG); the law says 'regularly' — the specific frequency is a practical decision, not a statutory deadline.

The difference between the jurisdictions is finer than it appears. Unlike the Directive, the BSIG knows no blanket 'whichever is higher': the turnover variant applies only from a total turnover of more than EUR 500 million and only for the breaches designated in § 65(6) and (7) BSIG. Total turnover here is the sum of all worldwide revenues of the undertaking to which the entity belongs in the financial year preceding the authority's decision (§ 65(8) BSIG). Where a data protection supervisory authority has already imposed a GDPR fine for the same conduct, an additional fine under the BSIG is excluded (§ 65(11) BSIG) — a point of contact of real practical significance for cloud providers, because the same incident frequently also involves personal data. Austria, by contrast, adopts the EU maxima including the 'whichever is higher' rule; the administrative penalties there are imposed by the district administrative authority (§ 44(1) NISG 2026), while supervision remains with the Cybersecurity Authority. For the management bodies, § 31(1) and (2) NISG 2026 requires them to ensure and supervise compliance with the risk management measures and to take part in cybersecurity training; the NISG 2026 contains no express internal liability rule analogous to § 38(2) BSIG.

9. Practical roadmap for cloud and SaaS providers

The roadmap has nine steps — from checking the statutory definition through registration, a management decision and the package of measures to the separate Austrian company; each step provides the basis for the next. It is a practical recommendation, not a statutory chain of deadlines — the only things fixed by law are the deadlines that the 'Character' column expressly identifies as such.

Practical rhythms (experience from implementation, not statutory deadlines): annual training for all staff with a learning check, onboarding training for new employees within the first four weeks, quarterly phishing simulation with an evaluation of the click rate, an annual penetration test, an internal audit as well as an external audit every two years, and quarterly reporting of effectiveness metrics to the management. What the law prescribes at this point is that training and an effectiveness assessment take place (§ 30(2) nos. 6 and 7 BSIG; § 32(4) NISG 2026) — the entity determines the frequency itself on a risk basis.