Microsoft 365 in kritischen Infrastrukturen: Wie viel Cloud verträgt die Versorgung?

Microsoft 365 ist in vielen Unternehmen längst mehr als eine Office-Suite. Outlook und Exchange Online übernehmen Kommunikation, Teams die Zusammenarbeit, SharePoint und OneDrive die Dokumentenablage und Entra ID zentrale Funktionen des Identitätsmanagements. Fällt diese Umgebung aus oder wird ein Tenant kompromittiert, können wesentliche Unternehmensprozesse betroffen sein. Für Betreiber kritischer Infrastrukturen stellt sich deshalb eine besondere Frage: Wie weit darf die Abhängigkeit von einer Public-Cloud-Plattform reichen, wenn das Unternehmen für Strom- oder Wasserversorgung verantwortlich ist?

NIS2 und KRITIS führen dabei nicht zu einem generellen Verbot von Microsoft 365. Sie verschieben jedoch die Perspektive: Nicht die Produktentscheidung allein ist entscheidend, sondern ob Abhängigkeiten, Risiken und Ausfallszenarien kontrolliert werden.

Energie und Wasser sind regulatorisch besonders relevant

Das aktuelle BSIG nennt Stromversorgung und Wasser ausdrücklich in den erfassten Sektoren. Zur Stromversorgung gehören unter anderem Stromlieferanten sowie Betreiber von Verteil- und Übertragungsnetzen. Im Bereich Wasser werden Trinkwasserversorgung und Abwasserbeseitigung erfasst. Welche konkrete regulatorische Kategorie für einen Betreiber gilt, hängt von den gesetzlichen Voraussetzungen ab.
Gesetze im Internet – Anlage 1 BSIG

Für die Energiewirtschaft kommt eine Besonderheit hinzu: Die Bundesnetzagentur arbeitet an der Überarbeitung der IT-Sicherheitskataloge vor dem Hintergrund der NIS2-Umsetzung. Ziel ist unter anderem der Schutz von Verfügbarkeit, Integrität und Vertraulichkeit der Systeme kritischer Infrastrukturen im Strom- und Gassektor.
Bundesnetzagentur – IT-Sicherheit in der Energieversorgung

Microsoft 365 ist nicht automatisch kritische Prozess-IT

Eine wichtige Trennung wird in Diskussionen über Cloud und KRITIS häufig übersehen. Bei einem Wasserversorger sollte Microsoft 365 normalerweise nicht unmittelbar Pumpen, Aufbereitungsanlagen oder Prozessleittechnik steuern. Ebenso wenig sollte Teams die technische Voraussetzung dafür sein, dass ein Netzbetreiber sein Stromnetz kontrollieren kann.

Zwischen Office-IT und Operational Technology (OT) sollte deshalb architektonisch klar unterschieden werden. Das bedeutet aber nicht, dass M365 für den Betrieb irrelevant wäre. Einsatzplanung, Krisenkommunikation, technische Dokumentationen, Bereitschaftslisten, Lieferanteninformationen und Managemententscheidungen können über Microsoft-Dienste laufen. Damit entsteht eine indirekte Kritikalität: Die Anlage funktioniert möglicherweise weiter, während wesentliche organisatorische Fähigkeiten beeinträchtigt sind. Genau diese Abhängigkeit muss ein Betreiber kennen.

NIS2 macht Cloud-Nutzung zum Risikomanagementthema

§ 30 BSIG verlangt von betroffenen wichtigen und besonders wichtigen Einrichtungen geeignete, verhältnismäßige und wirksame technische und organisatorische Risikomanagementmaßnahmen. Dazu gehören unter anderem Incident Management, Business Continuity, Backup und Wiederherstellung, Krisenmanagement, Lieferkettensicherheit, Zugriffskontrolle und die Bewertung der Wirksamkeit von Sicherheitsmaßnahmen. Damit wird auch ein strategisch wichtiger Cloud-Dienst Teil des Risikomanagements.
Gesetze im Internet – § 30 BSIG

Die entscheidende Frage lautet deshalb nicht: „Ist Microsoft 365 NIS2-konform?“
Sondern: „Ist unsere konkrete Nutzung von Microsoft 365 innerhalb unserer Architektur, Prozesse und Abhängigkeiten angemessen abgesichert?“
Ein Hersteller kann Zertifikate, Sicherheitsfunktionen und Compliance-Nachweise bereitstellen. Die Verantwortung für Konfiguration, Berechtigungen, Prozesse und das eigene Risikomanagement bleibt dennoch beim Betreiber.

Ein C5-Nachweis allein löst das Problem nicht

Für Cloud-Dienste spielt der BSI-Kriterienkatalog C5 eine wichtige Rolle. Microsoft führt für bestimmte Cloud-Angebote C5-Prüfungen beziehungsweise entsprechende Nachweise an. Das ist für eine Anbieterbewertung relevant.
Microsoft – Cloud Computing Compliance Criteria Catalogue C5

Ein häufiger Fehlschluss wäre jedoch: C5 vorhanden – Cloud-Risiko erledigt.
Das BSI weist selbst darauf hin, dass ein C5-Testat allein nicht hinreichend ist, um sämtliche Anforderungen an eine konkrete Cloud-Nutzung zu erfüllen. Der Cloud-Kunde muss die eigene Nutzung und die ihm zugewiesenen Kontrollen weiterhin bewerten. Für KRITIS-Betreiber ist das besonders relevant. Die Hilfestellung des UP KRITIS zur Cloud-Nutzung fordert unter anderem die Einbindung des Cloud-Dienstes in ISMS-Prozesse, Verantwortlichkeiten, Kontrolle des Dienstleisters, Assetmanagement sowie Datensicherung und Wiederanlaufverfahren.
BSI/UP KRITIS – Nutzung cloudbasierter Dienstleistungen in Kritischen Infrastrukturen

Das eigentliche Risiko heißt Abhängigkeit

Für einen Strom- oder Wasserversorger sollte deshalb ein Szenario besonders betrachtet werden:
Microsoft 365 ist für 24 oder 48 Stunden vollständig nicht verfügbar.

Können Bereitschaftsteams noch erreicht werden? Sind Telefonnummern offline verfügbar? Liegen Notfallhandbücher ausschließlich in SharePoint? Befinden sich Krisenpläne in Teams? Funktioniert die Authentisierung kritischer Anwendungen unabhängig vom Cloud-Identity-Service? Besonders problematisch wird es, wenn mehrere Abhängigkeiten zusammenlaufen. Wer beispielsweise Kommunikation, Identitäten, Dokumentation, Dateiablage und Krisenorganisation vollständig auf denselben Cloud-Stack konzentriert, kann einen erheblichen Common Mode Failure erzeugen.

Der Ausfall einer Plattform betrifft dann nicht eine Funktion, sondern mehrere gleichzeitig. Digitale Souveränität bedeutet deshalb nicht zwingend, jede Software selbst zu betreiben. Entscheidend ist vielmehr, ob Abhängigkeiten transparent, steuerbar und mit getesteten Alternativen versehen sind. Genau diese Perspektive wird auch in der aktuellen KRITIS-Diskussion um M365 hervorgehoben.

Was ein Strom- oder Wasserversorger praktisch prüfen sollte

Eine M365-Risikobewertung sollte daher über MFA und Passwortregeln hinausgehen. Zunächst sollte dokumentiert werden, welche kritischen Prozesse von welchen Microsoft-Diensten abhängen. Anschließend lässt sich bestimmen, welche Ausfallzeit tolerierbar ist. Besonders relevant sind dabei:

administrative Konten und privilegierte Rollen,
Entra ID und Conditional Access,
Gastkonten und externe Zugriffe,
Teams- und SharePoint-Berechtigungen,
Protokollierung und Angriffserkennung,
Backup- und Restore-Strategien,
Schnittstellen zu Drittanwendungen,
Datenklassifizierung,
Krisenkommunikation sowie
Exit- und Fallback-Verfahren.

Aktuelle Beiträge zur M365-Governance unter NIS2 greifen genau diese Probleme auf: verwaiste SharePoint-Sites, unklare Verantwortlichkeiten und historisch gewachsene Zugriffsrechte können aus einem Kollaborationsproblem ein Compliance- und Sicherheitsrisiko machen.

DSGVO: Datenstandort allein genügt nicht

Neben NIS2 und KRITIS bleibt die DSGVO relevant, sobald personenbezogene Daten verarbeitet werden. Microsoft stellt für seine Dienste umfangreiche Datenschutz- und Vertragsunterlagen bereit und beschreibt unter anderem seine EU-Datengrenze und Data-Residency-Möglichkeiten.
Microsoft – Products and Services Data Protection Addendum

Für den Betreiber folgt daraus jedoch nicht automatisch DSGVO-Konformität. Er muss weiterhin unter anderem Verarbeitungszwecke, Berechtigungen, Aufbewahrung, technische und organisatorische Maßnahmen sowie die konkrete Konfiguration seiner Umgebung bewerten. Auch hier gilt: Der Cloud-Anbieter stellt Funktionen bereit – der Verantwortliche muss sie angemessen einsetzen.

Krankenhäuser zeigen dasselbe Problem in verschärfter Form

Im Gesundheitswesen stellt sich die Grundfrage ähnlich, auch wenn zusätzliche sektorspezifische Anforderungen hinzukommen können. Das BSIG führt Erbringer von Gesundheitsdienstleistungen ebenfalls im relevanten Sektor Gesundheit auf. Ein Krankenhaus kann Teams oder Exchange problemlos für administrative Kommunikation benötigen, während klinische Kernsysteme separat betrieben werden.
Kritisch wird es, wenn ein Ausfall der Office- und Identitätsplattform indirekt medizinische Abläufe beeinträchtigt – beispielsweise weil Bereitschaftspläne, interne Kommunikation oder notwendige Dokumente nicht mehr erreichbar sind.
Das gleiche Prinzip gilt für Energie und Wasser: Nicht nur direkte technische Steuerung erzeugt Kritikalität. Auch organisatorische Abhängigkeit kann kritisch werden.

Praxis-Check: Ist M365 bei uns beherrschbar?

Ein KRITIS-Betreiber sollte mindestens folgende Fragen beantworten können:

☐ Welche kritischen Prozesse hängen direkt oder indirekt von M365 ab?
☐ Was passiert bei einem vollständigen Ausfall für 24, 48 oder 72 Stunden?
☐ Funktionieren OT und Prozessleittechnik unabhängig vom M365-Tenant?
☐ Gibt es einen unabhängigen Kommunikationsweg für den Krisenstab?
☐ Sind Notfallkontakte und Krisendokumente offline verfügbar?
☐ Können Administratoren bei kompromittierten Cloud-Identitäten noch handlungsfähig bleiben?
☐ Werden privilegierte Konten besonders geschützt und regelmäßig überprüft?
☐ Existieren belastbare Backup- und Restore-Verfahren für relevante Cloud-Daten?
☐ Sind Cloud-Anbieter und wesentliche Unterauftragnehmer im Lieferantenrisikomanagement berücksichtigt?
☐ Gibt es eine dokumentierte Exit-Strategie?

Wer diese Fragen nicht beantworten kann, hat weniger ein Microsoft-Problem als ein Cloud-Governance- und Resilienzproblem.

Fazit: M365 ist nicht die Leitwarte – kann aber trotzdem kritisch werden

Microsoft 365 lässt sich nicht sinnvoll mit den Kategorien „für KRITIS erlaubt“ oder „für KRITIS verboten“ beurteilen. Die regulatorische Kernfrage ist risikobasiert. Für Strom- und Wasserversorger sollte eine klare Grenze gelten: Die Fähigkeit, die kritische Dienstleistung zu erbringen, darf nicht unkontrolliert von einer einzelnen Office-Cloud abhängig werden.
Gleichzeitig wäre es wenig realistisch, moderne Kollaborations- und Cloud-Plattformen grundsätzlich aus kritischen Unternehmen zu verbannen. NIS2 und KRITIS verlangen vielmehr ein professionelleres Modell: Abhängigkeiten identifizieren, Cloud-Dienste in das ISMS integrieren, Lieferantenrisiken bewerten, Zugriffe kontrollieren und Ausfälle realistisch testen. Die entscheidende Prüfung findet deshalb nicht im Lizenzvertrag statt, sondern im Notfalltest:

Kann der Versorger Strom oder Wasser zuverlässig bereitstellen und seine Krise beherrschen, wenn Microsoft 365 morgen nicht verfügbar ist?
Wer diese Frage mit einem nachgewiesenen Notbetrieb beantworten kann, hat einen wesentlichen Schritt von bloßer Cloud-Nutzung hin zu tatsächlicher Cyberresilienz gemacht.

Quellen und weiterführende Informationen

Zur rechtlichen und fachlichen Verifikation wurden zusätzlich folgende Primär- und Herstellerquellen verwendet: