Cyberangriffe: Was Berlin über NIS2 & KRITIS zeigt

Cyberangriffe auf öffentliche Einrichtungen sind längst mehr als ein Datenschutz- oder IT-Problem. Wenn Verwaltungsnetze ausfallen, Bürgerdienste nicht erreichbar sind oder große Datenbestände entwendet werden, wird aus einem technischen Sicherheitsvorfall eine operative Krise.

Bei Krankenhäusern ist die Situation noch kritischer: Dort kann der Ausfall zentraler IT-Systeme unmittelbar die medizinische Versorgung beeinflussen.

Der Cyberangriff auf Teile des Berliner Landesnetzes im August und September 2026 liefert dafür ein aktuelles Beispiel. Gleichzeitig zeigt die Situation, warum NIS2 und das KRITIS-Dachgesetz Cybersecurity zunehmend mit Resilienz, Notfallmanagement und organisatorischer Verantwortung verbinden.

Berlin: Angreifer blieben mehrere Tage unentdeckt

Nach Angaben des Landes Berlin verschaffte sich eine kriminelle Gruppe Zugang zum digitalen Netzwerk der Berliner Verwaltung. Der wesentliche Datenabfluss erfolgte nach bisherigen Erkenntnissen zwischen dem 7. und 12. August 2026.

Am 14. August wurden die Systeme der betroffenen Senatsverwaltungen für Mobilität, Verkehr, Klimaschutz und Umwelt sowie für Stadtentwicklung, Bauen und Wohnen vorsorglich vom Netz getrennt.

Quelle: Land Berlin – Informationen zum Cyberangriff

Damit liegt ein besonders relevanter Punkt offen: Zwischen dem Beginn des bislang festgestellten wesentlichen Datenabflusses und den Gegenmaßnahmen lagen mehrere Tage.

Das beweist für sich genommen noch kein Versagen bestimmter Sicherheitsmaßnahmen. Solange die forensische Untersuchung nicht abgeschlossen ist, wäre eine solche Schlussfolgerung unseriös.

Es zeigt aber das grundlegende Problem der Detection Time: Nicht nur die Abwehr eines Angriffs entscheidet über dessen Folgen, sondern auch die Frage, wie schnell eine Kompromittierung erkannt wird.

5,8 Terabyte und rund 1,44 Millionen Dateien

Das Ausmaß des Vorfalls ist erheblich. Nach Recherchen von Tagesschau und rbb wurden rund 1,44 Millionen Dateien mit einem Volumen von etwa 5,8 Terabyte entwendet. Die Täter verlangten 30 Bitcoin Lösegeld, seinerzeit rund zwei Millionen Euro.

Quelle: Tagesschau – Gefahren durch die Veröffentlichung gestohlener Berliner Daten

Berlin ging auf die Forderung nicht ein.

Am 4. September wurden entwendete Daten im Darknet veröffentlicht. Das Land Berlin bestätigt, dass darunter personenbezogene Informationen von Beschäftigten, Bürgerinnen und Bürgern sowie Daten von Unternehmen sein können. Betroffen sind nach bisherigem Stand überwiegend unstrukturierte Daten aus gemeinsamen und persönlichen Verzeichnissen der Mitarbeiter.

Ein weiteres veröffentlichtes Datenpaket enthielt nach Angaben des Landes auch Zugangsdaten, woraufhin Schutzmaßnahmen nachgeschärft wurden.

Damit besteht der Schaden nicht nur aus gestohlenen Dateien.

Der eigentliche Schaden eines Cyberangriffs

Für eine belastbare Bewertung sollten mindestens vier Schadensdimensionen unterschieden werden.

Erstens: Vertraulichkeit. Daten sind abgeflossen und teilweise öffentlich verfügbar. Anders als verschlüsselte Systeme lassen sich veröffentlichte Informationen nicht durch ein Backup zurückholen.

Zweitens: Verfügbarkeit. Die beiden betroffenen Senatsverwaltungen mussten aus Sicherheitsgründen vom Landesnetz isoliert werden. Teilweise war die Kommunikation nur telefonisch möglich; nach rbb-Recherchen waren verschiedene Bürgerdienste nicht oder nur eingeschränkt verfügbar.

Quelle: Tagesschau/rbb – Fragen und Antworten zum Cyberangriff auf das Berliner Landesnetz

Drittens: Folgeschäden. Veröffentlichte personenbezogene Daten können beispielsweise für Identitätsmissbrauch, Betrug oder glaubwürdiger gestaltete Phishing-Angriffe verwendet werden. Genau vor diesen Risiken warnt inzwischen auch das Land Berlin.

Viertens: Wiederherstellungs- und Bewältigungskosten. Forensik, Krisenorganisation, Wiederherstellung, Datenschutzprüfung, Kommunikation, externe Spezialisten und die Information Betroffener binden erhebliche Ressourcen. Eine belastbare Gesamtschadenssumme für den Berliner Vorfall liegt derzeit nicht vor.

Der Schaden darf deshalb nicht mit der Lösegeldforderung von zwei Millionen Euro verwechselt werden. Diese war eine Forderung der Angreifer und keine Schadensberechnung.

Krankenhäuser: Wenn IT-Ausfall zum Versorgungsproblem wird

Im Krankenhaus verschärft sich diese Problematik.

Das BBK bezeichnet Krankenhäuser wegen ihrer Bedeutung für die Bevölkerung ausdrücklich als zentrale Kritische Infrastruktur. Zugleich weist es darauf hin, dass auch der Ausfall von Häusern unterhalb formaler KRITIS-Schwellenwerte erhebliche regionale Versorgungsprobleme verursachen kann.

Quelle: BBK – KRITIS-Sektor Gesundheit und Krankenhäuser

Wie stark die Abhängigkeit inzwischen ist, zeigte erst am 14. und 15. September das Klinikum Main-Spessart.

Dort führte eine schwerwiegende IT-Störung zentraler Systeme zu einem Aufnahmestopp und zur zeitweisen Abmeldung von der Notfallversorgung. Telefon und E-Mail waren ebenfalls beeinträchtigt. Wichtig ist die Abgrenzung: Nach Angaben des Klinikums handelte es sich ausdrücklich nicht um einen Cyberangriff, sondern um eine interne technische Störung.

Quelle: Tagesschau/BR – IT-Störung am Klinikum Main-Spessart

Gerade deshalb ist der Fall für NIS2 und KRITIS interessant.

Resilienz muss nicht nur gegen Hacker funktionieren. Auch Hardwarefehler, Softwareprobleme, Stromausfälle, Fehlkonfigurationen oder Ausfälle externer Dienstleister können kritische Dienste beeinträchtigen.

Beim Klinikum Main-Spessart wurden Krankenhauseinsatzleitung und Notfallplan aktiviert. Die Versorgung bereits aufgenommener Patienten konnte nach Angaben des Hauses aufrechterhalten werden.

Das ist praktisch gelebtes Business Continuity Management.

Was NIS2 genau an dieser Stelle verlangt

Das aktuelle BSIG setzt bei besonders wichtigen und wichtigen Einrichtungen nicht erst beim erfolgreichen Angriff an.

§ 30 BSIG verlangt geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen, um Störungen von Verfügbarkeit, Integrität und Vertraulichkeit zu vermeiden und die Auswirkungen von Sicherheitsvorfällen möglichst gering zu halten.

Quelle: Gesetze im Internet – BSI-Gesetz

Zu den ausdrücklich genannten Bereichen gehören unter anderem Risikoanalyse und Sicherheitskonzepte, Bewältigung von Sicherheitsvorfällen, Aufrechterhaltung des Betriebs, Backup-Management, Wiederherstellung nach Notfällen, Krisenmanagement, Sicherheit der Lieferkette, Schwachstellenmanagement, Bewertung der Wirksamkeit von Sicherheitsmaßnahmen, Cyberhygiene und Zugriffskontrolle.

Genau hier treffen sich ISMS, Incident Response und BCMS.

NIS2-Compliance bedeutet deshalb nicht, eine weitere Richtlinie zu schreiben. Die Organisation muss im Ernstfall tatsächlich funktionieren.

Meldepflicht ist nicht Incident Response

Ein besonders sichtbarer Teil von NIS2 sind die Meldepflichten.

§ 32 BSIG sieht bei einem erheblichen Sicherheitsvorfall für betroffene besonders wichtige und wichtige Einrichtungen grundsätzlich eine frühe Erstmeldung unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung vor. Innerhalb von 72 Stunden folgt eine weitere Meldung mit einer ersten Bewertung des Vorfalls.

Quelle: Gesetze im Internet – § 32 BSIG

Das kann leicht dazu führen, NIS2 vor allem als Melde- und Dokumentationsprojekt zu betrachten.

Der Berliner Fall zeigt jedoch, dass eine ganz andere Zeitspanne mindestens ebenso entscheidend ist:

Wie lange dauert es überhaupt, bis eine Organisation erkennt, dass sie kompromittiert wurde?

Eine perfekte 24-Stunden-Meldeorganisation hilft nur begrenzt, wenn Angreifer vorher über Tage unbemerkt Daten exfiltrieren können.

KRITIS-Dachgesetz erweitert die Perspektive

Parallel dazu ist seit dem 17. März 2026 das KRITIS-Dachgesetz in Kraft. Es ergänzt die IT-Sicherheitsregulierung um einen sektorübergreifenden Ansatz für die Resilienz kritischer Infrastrukturen. Erfasst werden unter anderem Gesundheit und öffentliche Verwaltung.

Quelle: Bundesregierung – KRITIS-Dachgesetz: Stärkerer Schutz kritischer Infrastrukturen

Dabei geht es nicht ausschließlich um Cyberangriffe.

Risikoanalysen, Resilienzmaßnahmen, physischer Schutz, Aufrechterhaltung kritischer Dienstleistungen und Wiederherstellungsfähigkeit rücken stärker zusammen. Die Bundesregierung nennt beispielsweise Notfallteams, Objektschutz und Maßnahmen zur Ausfallsicherheit.

Allerdings ist auch hier eine wichtige Einschränkung erforderlich: Aus der Tatsache, dass eine Organisation zur öffentlichen Verwaltung oder zum Gesundheitswesen gehört, folgt nicht automatisch, dass jede einzelne Behörde oder jedes Krankenhaus sämtlichen Pflichten unterliegt.

Beim BSIG bestehen insbesondere für Organisationseinheiten von Ländern und Kommunen spezielle Abgrenzungen. § 28 Abs. 8 BSIG enthält zudem eine Ausnahme für bestimmte öffentlich getragene Organisationen, wenn entsprechende landesrechtliche Regulierung besteht.

Der Berliner Vorfall sollte daher nicht pauschal als „NIS2-Verstoß“ bezeichnet werden. Dafür wären sowohl die konkrete rechtliche Einordnung als auch belastbare Erkenntnisse über die Ursachen und vorhandenen Sicherheitsmaßnahmen erforderlich.

Wo trotzdem offensichtliche Defizite sichtbar werden

Auch ohne voreilige Schuldzuweisung lassen sich aus den aktuellen Vorfällen strukturelle Schwachstellen ableiten.

1. Erkennungsgeschwindigkeit

In Berlin fand der wesentliche Datenabfluss nach bisherigen Erkenntnissen vom 7. bis 12. August statt. Die Systeme wurden am 14. August isoliert.

Organisationen sollten deshalb messen, wie schnell ungewöhnliches Verhalten, kompromittierte Accounts und größere Datenbewegungen erkannt werden können.

2. Unstrukturierte Datenbestände

Dass überwiegend Daten aus gemeinsamen und persönlichen Verzeichnissen betroffen sind, zeigt ein häufig unterschätztes Problem: Cybersecurity betrifft nicht nur Datenbanken und Fachverfahren.

File Shares, persönliche Laufwerke, alte Projektordner und historisch gewachsene Berechtigungen können enorme Mengen sensibler Informationen enthalten.

Datensparsamkeit, Datenklassifizierung, Löschkonzepte und Berechtigungsmanagement sind damit unmittelbar Teil der Schadensbegrenzung.

3. Abhängigkeit von zentraler IT

Sowohl Verwaltung als auch Krankenhaus zeigen, wie schnell zentrale IT-Störungen auf operative Prozesse durchschlagen.

Deshalb muss eine Business-Impact-Analyse beantworten, welche Dienste nach 30 Minuten, vier Stunden, zwölf Stunden oder mehreren Tagen IT-Ausfall noch erbracht werden können.

4. Notbetrieb muss praktisch funktionieren

Papierbasierte Ersatzverfahren, alternative Kommunikationskanäle und manuelle Prozesse sind nur dann belastbar, wenn Mitarbeiter sie kennen und regelmäßig üben.

Der aktuelle Fall Main-Spessart liefert hierzu auch ein positives Gegenbeispiel: Nach Angaben des Klinikums griffen Notfallpläne, obwohl zentrale IT ausgefallen war.

5. Wiederherstellung allein reicht nicht

Bei Ransomware wird häufig zuerst über Backups gesprochen.

Beim Berliner Vorfall liegt jedoch ein wesentliches Schadensbild in der Exfiltration und Veröffentlichung von Daten. Ein technisch einwandfreies Backup verhindert diesen Schaden nicht.

Organisationen benötigen deshalb gleichzeitig Prävention, Detection, Data-Loss-Kontrollen, Segmentierung, Berechtigungsmanagement und Incident Response.

Praxis-Check: Würde Ihre Organisation den Berlin-Test bestehen?

Geschäftsleitung, CISO, ISB und BCM-Verantwortliche sollten sich nach solchen Vorfällen einige unangenehme Fragen stellen:

☐ Würden wir einen ungewöhnlich großen Datenabfluss innerhalb von Stunden erkennen?
☐ Wissen wir, welche sensiblen Informationen auf File Shares und persönlichen Laufwerken gespeichert sind?
☐ Können kompromittierte Benutzerkonten kurzfristig organisationsweit gesperrt werden?
☐ Können kritische Bereiche isoliert werden, ohne die gesamte Organisation stillzulegen?
☐ Existieren alternative Kommunikationswege, wenn E-Mail, VoIP oder zentrale Netze ausfallen?
☐ Können kritische Prozesse mindestens 24 bis 72 Stunden ohne zentrale IT weitergeführt werden?
☐ Wurde die Wiederherstellung aus Backups tatsächlich getestet?
☐ Haben wir einen getesteten Incident-Response-Plan mit klaren Entscheidungsbefugnissen?
☐ Können NIS2-, Datenschutz- und gegebenenfalls KRITIS-Meldepflichten parallel bewertet werden?
☐ Wissen Geschäftsleitung, IT, Datenschutz, Kommunikation und Fachbereiche, wer im Krisenfall welche Entscheidung trifft?

Wenn mehrere dieser Fragen nicht eindeutig beantwortet werden können, besteht unabhängig von der formalen NIS2-Einstufung ein konkreter Handlungsbedarf.

Der wichtigste Unterschied: Compliance versus Resilienz

Die aktuellen Fälle machen eine Schwäche vieler Cybersecurity-Projekte sichtbar: Regulatorische Konformität und tatsächliche Widerstandsfähigkeit sind nicht dasselbe.

Ein Unternehmen kann Richtlinien, Risikoanalysen und Schulungsnachweise besitzen und trotzdem schlecht auf einen Angriff vorbereitet sein.

Umgekehrt zeigte die technische Störung im Klinikum Main-Spessart, welchen Wert funktionierende Notfallorganisation haben kann: Obwohl zentrale Systeme ausfielen, wurden Krisenstrukturen aktiviert und die Versorgung bereits aufgenommener Patienten nach Angaben des Klinikums aufrechterhalten.

Für NIS2 und KRITIS sollte deshalb nicht die Frage im Mittelpunkt stehen:

„Haben wir alle vorgeschriebenen Dokumente?“

Die entscheidendere Frage lautet:

„Was passiert bei uns am Montagmorgen, wenn zentrale IT-Systeme nicht mehr verfügbar sind – und wie lange können wir unseren kritischen Dienst trotzdem aufrechterhalten?“

Fazit

Der Berliner Cyberangriff ist mit dem derzeit bekannten Datenabfluss, der Veröffentlichung von Informationen und den betrieblichen Einschränkungen ein schwerwiegender Sicherheitsvorfall. Eine abschließende Schadensbewertung ist noch nicht möglich, weil die forensische Analyse andauert und Berlin selbst darauf hinweist, dass Umfang und Betroffenheit noch untersucht werden.

Gerade deshalb wäre es verfrüht, einzelne technische oder organisatorische Verantwortlichkeiten als erwiesen darzustellen.

Die strukturelle Lehre ist dagegen bereits deutlich: Erkennung, Eindämmung, Datenmanagement, Notbetrieb und Wiederherstellung müssen als zusammenhängendes Resilienzsystem funktionieren.

Für Krankenhäuser gilt dies in besonderem Maße. Dort ist Cyberresilienz keine abstrakte Compliance-Anforderung. Wenn digitale Prozesse ausfallen, kann aus einem IT-Problem innerhalb kürzester Zeit ein Versorgungsproblem werden.

NIS2 und KRITIS sollten deshalb nicht als zusätzliche Dokumentationspflichten verstanden werden. Richtig umgesetzt liefern sie einen Rahmen für genau das, was aktuelle Vorfälle immer wieder vermissen lassen: die Fähigkeit, Angriffe früh zu erkennen, Auswirkungen zu begrenzen und kritische Leistungen auch unter außergewöhnlichen Bedingungen aufrechtzuerhalten.

Quellen und weiterführende Informationen

Als aktuelle Hauptquellen wurden die fortlaufend aktualisierten Informationen des Landes Berlin zum Cyberangriff, die Berichterstattung von Tagesschau/rbb sowie aktuelle Veröffentlichungen zu Krankenhäusern und KRITIS ausgewertet. Die gesetzlichen Aussagen wurden zusätzlich anhand des geltenden BSIG und aktueller Informationen der Bundesregierung und des BBK überprüft.