Seit dem 12. November 2026 ca. 17:30 Uhr also kurz nach der üblichem Arbeitstag in Deutschland begannen die Beeinträchtigungen in Bezug auf die Nutzung einiger Microsoft Dienste. Die Beeinträchtigungen halten auch heute am 13. November noch an und werden nun auch zu 17:00 Uhr aber besser. Was war passiert und was kann ich tun; dies beantwortet dieser Beitrag.
Aktuelle Situation und was ist passiert?
Es war kein Cyberangriff. Diese Gerüchte und auch viele lustige Bilder auf Sozialen Netzwerken (siehe Ende des Artikels) sind im Umlauf. Es könnte durch einen Angriff auch zu genau den gleichen Beeinträchtigungen kommen, so auch Manuel Atung im Interview beim ZDF. Aber es war kein Angriff auf die Microsoft Intrastruktur.
Die Beeinträchtigungen sind auf die folgenden Dienste begrenzt:
- Microsoft Exchange Online und Outlook
- z.B. Versenden und Empfangen von Emails
- Laden von Outlook
- Starten von OWA, Outlook in der Cloud
- Microsoft SharePoint und OneDrive
- z.B. Teilen
- Exchange Online Protection
- Auflösen von URLs
- Microsoft Teams
- Chats und Aufnahmen sind beeinträchtigt
- Besprechungen laufen und liefen.
Warum?
Die Beeinträchtigung hat die Ursache, dass am 11.11 und 12.11 bei Microsoft in den Rechenzentren weltweit einem ständigen Statusprüfung unterzogen. Dies ist auch für alle Firmen und deren eigenen Server eine übliche Vorgehensweise, so dass Probleme mit den Diensten rechtzeitig festgestellt werden können.
Microsoft handelte und stellte die betroffenen Server ab und so waren nur noch die nicht betroffenen Server zur Verfügung und konnten die Daten verarbeiten. Dies hatte zur Folge, dass die verbleibenden Server die Last nicht mehr komplett abfangen konnten und die Daten verarbeiten.
Microsoft löst das Problem in zwei Schritten:
- Warum waren die Server beeinträchtig? Fehlerhaft? War es ein Update?
- Server in dem vorherigen Zustand installieren und hochfahren.
Trennung Server und Daten
Man muss dabei wissen, dass Microsoft in Ihrer Infrastruktur Server immer neu installiert und keine Inpace Updates macht. Es wird installiert und dann Daten migriert. Dies führt dazu, dass auch das Problem relativ schnell behoben werden kann, da Server schnell ausgerollt und nicht mit 4-5 Updates seit dem letzten Image hochgezogen werden müssen.
Informationen findet ihr hier:
Hier ist eine kuratierte Liste offizieller Microsoft-Learn-Dokumentationen zu Business Continuity, Resiliency und Disaster Recovery (BCDR). Für Microsoft 365 Governance, Betriebskonzepte oder eine DSFA würde ich insbesondere die ersten vier Quellen verwenden.
Microsoft 365 / Microsoft Service Assurance
- Ausfallsicherheit und Kontinuität – Microsoft Service Assurance
Zentrale Microsoft-Dokumentation zum Business Continuity Management (BCM), Enterprise Resilience and Crisis Management (ERCM), BIA sowie zum Testen von Business-Continuity- und Disaster-Recovery-Plänen.
Microsoft Learn öffnen [learn.microsoft.com] - Data Resiliency in Microsoft 365
Beschreibt die grundlegenden Prinzipien zur Datenresilienz und Wiederherstellbarkeit innerhalb von Microsoft 365.
Microsoft Learn öffnen [learn.microsoft.com] - Dienststatus und Verfügbarkeit – Microsoft 365
Dokumentation zu Service Health, geplanten Wartungen, ungeplanten Ausfällen und Service Incidents in Microsoft 365.
Microsoft Learn öffnen [learn.microsoft.com]
Grundlagen zu BCDR
- What are business continuity, high availability, and disaster recovery?
Sehr gute Grundlagenquelle zur Abgrenzung von Business Continuity, High Availability (HA) und Disaster Recovery (DR) sowie zur Business-Continuity-Planung.
Microsoft Learn öffnen [learn.microsoft.com] - Business continuity and disaster recovery – Cloud Adoption Framework
Behandelt BCDR aus Architektur- und Governance-Sicht, insbesondere RTO, RPO, Availability Zones, Geo-Replication, Backup und Azure Site Recovery.
Microsoft Learn öffnen [learn.microsoft.com]
Windows 365
- Microsoft Business Continuity and Disaster Recovery (BCDR) with Windows 365
Überblick über Verfügbarkeit, Datenresilienz, In-Zone- und Cross-Region-Disaster-Recovery für Windows 365 Cloud PCs.
Microsoft Learn öffnen [learn.microsoft.com] - Business Continuity und Disaster Recovery ermöglichen
Praktische Konfiguration von BCDR für Windows 365, einschließlich Point-in-Time Recovery und regionsübergreifender Disaster Recovery.
Microsoft Learn öffnen [learn.microsoft.com]
Power Platform / Dynamics 365
- Geschäftskontinuität und Katastrophenwiederherstellung – Power Platform
Beschreibt unter anderem Availability Zones, Backups, Cross-Region Disaster Recovery, Failover/Failback, DR-Tests sowie RPO und RTO für Power Platform und Dynamics 365.
Microsoft Learn öffnen [learn.microsoft.com]
Wann sollte die Störung behoben sein?
Die Störung wird in 48h behoben sein, sagt mein Kontakt bei Microsoft. In Deutschland sind deutliche Besserungen ab 13:00 Uhr am 13.11 schon spürbar geworden. Vollständig sollte es zur Ignite Woche, also zum nächsten Montag sein.
Wo finde ich meinen Status meines M365 Tenants?
Dazu gibt es das Service Health Center:
Webseite https://admin.cloud.microsoft/#/servicehealth
Meldung beim LDSB? NIS 2?
Datenschutz
Ja, ein IT-Ausfall kann eine meldepflichtige Datenschutzverletzung nach Art. 33 DSGVO sein, aber nicht jeder IT-Ausfall ist automatisch beim LDSB bzw. der zuständigen Datenschutzaufsichtsbehörde zu melden.
Die LDI NRW beschreibt eine Datenschutzverletzung ausdrücklich auch als Ereignis, das zur Vernichtung oder zum Verlust personenbezogener Daten führt. Entscheidend ist damit neben Vertraulichkeit und Integrität auch die Verfügbarkeit personenbezogener Daten. [ldi.nrw.de]
Beispiel: IT-Ausfall
| Situation | Datenschutzvorfall? | Meldung Art. 33 DSGVO? |
|---|---|---|
| Server 30 Minuten nicht erreichbar, danach wieder verfügbar | möglicherweise Sicherheitsvorfall | typischerweise nein, wenn kein relevantes Risiko |
| System mehrere Stunden ausgefallen, Kundendaten zeitweise nicht verfügbar | grundsätzlich Datenschutzverletzung möglich | abhängig vom Risiko |
| Krankenhaus kann wegen Ausfall nicht auf Patientendaten zugreifen | klar relevante Verfügbarkeitsverletzung | häufig meldepflichtig |
| Daten nach Storage-Ausfall verloren | Datenschutzverletzung | bei mehr als geringem Risiko meldepflichtig |
| Ransomware verschlüsselt personenbezogene Daten | Datenschutzverletzung | regelmäßig genaue Art.-33-Prüfung erforderlich |
| Redundanz übernimmt sofort, Daten und Prozesse bleiben verfügbar | regelmäßig keine relevante Datenschutzverletzung | regelmäßig keine Meldung |
Entscheidend ist die Risikobewertung
Der richtige Prüfweg ist:
IT-Ausfall → personenbezogene Daten betroffen? → Verfügbarkeit/Integrität/Vertraulichkeit verletzt? → Risiko für natürliche Personen?
Nach der LDI NRW gilt:
- kein oder nur geringes Risiko: keine Meldung an die Aufsicht, aber interne Dokumentation nach Art. 33 Abs. 5 DSGVO,
- mehr als geringes Risiko: Meldung nach Art. 33 DSGVO, unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden,
- hohes Risiko: zusätzlich grundsätzlich Benachrichtigung der betroffenen Personen nach Art. 34 DSGVO. [ldi.nrw.de], [ldi.nrw.de]
Wichtig bei einem reinen IT-Ausfall
Ein häufiger Fehler ist die Aussage:
„Es sind keine Daten abgeflossen, deshalb liegt keine Datenschutzverletzung vor.“
Das greift zu kurz. Die DSGVO schützt auch die Verfügbarkeit. Deshalb kann beispielsweise der längerfristige Ausfall eines HR-, Gesundheits-, Zahlungs- oder sonstigen geschäftskritischen Systems datenschutzrechtlich relevant sein, obwohl kein Dritter auf Daten zugegriffen hat. Die LDI NRW nennt Vernichtung und Verlust ausdrücklich neben unbefugter Offenlegung und unbefugtem Zugang. [ldi.nrw.de]
Für eine DSFA-/Incident-Dokumentation würde ich daher formulieren:
„Der IT-Ausfall wurde als mögliche Verletzung der Verfügbarkeit personenbezogener Daten bewertet. Im Rahmen der Prüfung nach Art. 33 DSGVO wurden insbesondere Dauer und Umfang des Ausfalls, Art und Sensibilität der betroffenen personenbezogenen Daten, Anzahl der Betroffenen, vorhandene Wiederherstellungs- und Ausweichmöglichkeiten sowie mögliche Auswirkungen auf die Rechte und Freiheiten der betroffenen Personen berücksichtigt.“
Wenn dabei kein bzw. nur ein geringes Risiko festgestellt wird, muss der Vorfall trotzdem intern nachvollziehbar dokumentiert werden. Genau darauf weist die LDI NRW ausdrücklich hin. [ldi.nrw.de]
Wenn du mir Dauer des Ausfalls, betroffenes System, Datenarten, Anzahl der Personen und Auswirkungen nennst, kann ich daraus auch konkret die Art.-33-Risikobewertung (kein/geringes Risiko vs. meldepflichtig) formulieren.
Ergebnis:
Beim aktuellen Ausfall ist eine Meldung beim LDSB nicht vorzunehmen.
NIS 2 und DSGVO
Ja. Auch nach NIS2 kann ein reiner IT-Ausfall meldepflichtig sein, und sogar unabhängig davon, ob personenbezogene Daten betroffen sind.
Nach dem aktuellen deutschen BSI-Regime müssen besonders wichtige und wichtige Einrichtungen erhebliche Sicherheitsvorfälle melden. Ein Vorfall kann erheblich sein, wenn er eine schwerwiegende Betriebsstörung, finanzielle Verluste oder erhebliche materielle bzw. immaterielle Schäden bei Dritten verursacht hat oder verursachen kann. Das BSI weist zudem darauf hin, dass bei Ausfall oder Beeinträchtigung kritischer Dienstleistungen von einem erheblichen Sicherheitsvorfall auszugehen ist. [bsi.bund.de], [bsi.bund.de]
Der wesentliche Unterschied zu DSGVO
| IT-Ausfall | DSGVO | NIS2 / BSIG |
|---|---|---|
| Reiner Systemausfall | Relevant, wenn personenbezogene Daten in ihrer Verfügbarkeit betroffen sind | Kann unmittelbar relevant sein |
| Personenbezogene Daten erforderlich? | Ja | Nein |
| Zentrale Schwelle | Risiko für Rechte/Freiheiten natürlicher Personen | Erheblicher Sicherheitsvorfall, z. B. schwerwiegende Betriebsstörung |
| Erste externe Meldung | möglichst binnen 72 h | unverzüglich, spätestens 24 h |
| Meldestelle | Datenschutzaufsicht | BSI |
Für NIS2 sieht der deutsche Meldeprozess bei einem erheblichen Sicherheitsvorfall eine frühe Erstmeldung spätestens innerhalb von 24 Stunden, eine weitere Meldung spätestens innerhalb von 72 Stunden und grundsätzlich eine Abschlussmeldung innerhalb eines Monats vor. [bsi.bund.de]
Beispiel
Ein Unternehmen fällt unter NIS2 und sein zentrales ERP-System ist acht Stunden nicht verfügbar:
DSGVO:
→ Prüfen, ob dadurch personenbezogene Daten nicht verfügbar waren.
→ Dann Datenschutzverletzung prüfen.
→ Anschließend Risiko für Betroffene bewerten.
→ Erst bei mehr als geringem Risiko Meldung an Datenschutzaufsicht.
NIS2:
→ Prüfen, ob ein Sicherheitsvorfall vorliegt.
→ Auswirkungen auf die angebotenen Dienste und Geschäftsprozesse bewerten.
→ Erreicht der Ausfall die Schwelle zum erheblichen Sicherheitsvorfall, greift die Meldepflicht gegenüber dem BSI. [bsi.bund.de]
Wichtig für ein Incident-Management-System
Ich würde deshalb IT-Ausfälle niemals nur über die DSGVO bewerten, sondern mindestens zweigleisig:
Incident → DSGVO-Prüfung + NIS2/BSIG-Prüfung
Ein und derselbe Ausfall kann damit zu vier Ergebnissen führen:
- weder DSGVO- noch NIS2-meldepflichtig
- nur DSGVO-meldepflichtig
- nur NIS2-meldepflichtig
- nach beiden Regelwerken meldepflichtig
Gerade Nr. 3 ist wichtig: Ein erheblicher Ausfall ohne irgendeinen Verlust oder Abfluss personenbezogener Daten kann NIS2-meldepflichtig sein.
Für ein Betriebskonzept bzw. Incident-Response-Handbuch würde ich deshalb einen gemeinsamen DSGVO/NIS2-Entscheidungsbaum mit 24h-/72h-Fristen und Eskalationsstufen verwenden.
Ergebnis
Es ist kein meldepflichtiger NIS 2 Vorfall!
Was kann ich nun? Schadensersatz? – Unternehmen, Behörden, EDU
Ich solltet wie folgt reagieren:
- Ausfälle dokumentieren intern und aufnahmen
- MitarbeiterInnen informieren (z.B. Email, Intranetpost)
- Ticket bei Microsoft aufmachen und Ausfälle dokumentieren.
Schadensersatz für den Ausfall?
Microsoft hat in seinen Verträgen den Schaden, der durch Ausfälle, passiert auf die Höhe der gezahlten Lizenzgebühren begrenzt.
Meldungen von anderen Firmen
