Angriff auf das Berliner Landesnetz: 7 Lehren für NIS2-pflichtige Einrichtungen

Von Frank Becker, Geschäftsführer, Becker Project Consulting GmbH

🇩🇪🇦🇹🇨🇭 Dieser Vorfall betrifft eine deutsche Landesverwaltung. Die Berliner Senatsverwaltungen fallen nicht unter das BSIG — genau das ist eine der Lehren. Für Einrichtungen nach § 30 BSIG gelten die beschriebenen Pflichten unmittelbar, in Österreich ab dem 01.10.2026 nach NISG 2026, in der Schweiz nach ISG/CSV und nDSG. Die technischen und organisatorischen Lehren gelten unabhängig vom Rechtsraum.

Am 4. September 2026 hat die Ransomware-Gruppe Rhysida rund 5,8 Terabyte Daten aus dem Berliner Landesnetz im Darknet veröffentlicht. Das Land Berlin hatte die geforderten 30 Bitcoin — umgerechnet etwa zwei Millionen Euro — nicht gezahlt.

Der Fall ist aus einem Grund lehrreich, der über die Schlagzeile hinausgeht: Fast jeder Fehler, der hier sichtbar wurde, ist ein Fehler, den auch regulierte Einrichtungen mit einem formal etablierten ISMS regelmäßig machen. Es geht nicht um exotische Angriffstechnik. Es geht um Asset-Transparenz, um Zugangsdatenhygiene, um die Frage, wer eine Meldung auslöst — und um eine Regulierungslücke, die viele Häuser für einen Schutzschild halten.

Dieser Artikel ordnet den Sachverhalt ein, trennt Bestätigtes von Behauptetem und zieht sieben Lehren, die sich in ein bestehendes Managementsystem übersetzen lassen.

Was passiert ist — die Chronologie

Bestätigt sind: der Zeitraum des Abflusses, die Isolation der beiden Häuser, der Abfluss von Klartext-Zugangsdaten, die Abschaltung von VPN-Zugängen mit entsprechender Einschränkung der Telearbeit sowie ein laufender Scan sämtlicher rund 12.000 Systeme des Landes.

Von den Tätern behauptet und nur teilweise unabhängig bestätigt sind Umfang und Inhalt: 5,79 Terabyte in rund 1,44 Millionen Dateien, darunter Ausweis- und Passscans, Personalakten, Arbeitszeugnisse, Beurteilungen, Ausschreibungsunterlagen, Dienstverträge, Datenbankexporte aus den Jahren 2006 bis 2026, Ausschussprotokolle sowie Unterlagen zu Schwachstellen in der Wasserversorgung.

Aus Behördenkreisen berichtet, amtlich nicht bestätigt ist der Einstiegsweg: Der Zugang soll über IT-Infrastruktur erfolgt sein, die nie zum zentralen Landesdienstleister ITDZ migriert wurde — also über Systeme außerhalb des Landesrechenzentrums. Auffällig wurde der Vorgang nach diesen Berichten dadurch, dass das ITDZ ungewöhnliche Netzwerkaktivität bemerkte.

Diese Unterscheidung ist kein Formalismus. Wer aus einem laufenden Vorfall Lehren zieht, muss wissen, welche davon auf gesicherten Fakten stehen — sonst baut er Maßnahmen auf Vermutungen.

Lehre 1 — Was nicht im Inventar steht, wird nicht verteidigt

Der Einstiegsweg lag nach den vorliegenden Berichten dort, wo die zentrale IT-Steuerung endete: bei Systemen, die formal zur Landesverwaltung gehörten, aber operativ nie in die zentrale Betreuung überführt wurden. Kein Angreifer musste eine besonders gut geschützte Umgebung überwinden. Er musste nur die Stelle finden, für die sich niemand eindeutig zuständig fühlte.

Diese Konstellation ist in großen Organisationen die Regel, nicht die Ausnahme. Historisch gewachsene Fachanwendungen, Altsysteme einer fusionierten Einheit, ein Server in einem Nebenstandort, ein Dienstleisterzugang aus einem ausgelaufenen Projekt.

§ 30 BSIG verlangt Risikomanagementmaßnahmen für die genutzten Systeme — nicht für die dokumentierten. Ein Asset-Inventar, das nur die migrierten und betreuten Systeme kennt, erfüllt diese Anforderung formal und verfehlt sie praktisch. Wie die zehn Maßnahmenbereiche im Einzelnen aussehen, steht in unserem Überblick zu den NIS2-Maßnahmen nach § 30 BSIG.

Konkret: Nehmen Sie eine Liste aller Systeme, für die in den letzten zwölf Monaten kein Patch-, Backup- oder Monitoring-Nachweis existiert. Diese Liste ist Ihre Angriffsfläche. Sie ist in fast jedem Haus länger als erwartet.

Lehre 2 — Eine Woche unbemerkt heißt: die Meldefrist war längst gerissen

Die Daten verließen das Netz zwischen dem 7. und 12. August. Bemerkt wurde der Vorgang am 14. August. Zwischen dem Beginn des Abflusses und dem Erkennen lag also mehr als eine Woche.

Für regulierte Einrichtungen ist das der eigentlich beunruhigende Teil. Die Meldefristen knüpfen an die Kenntnis an — aber die Kenntnis knüpft an die Detektionsfähigkeit an. Wer erst nach acht Tagen bemerkt, dass Daten abfließen, hat keine 24 Stunden verloren, sondern acht Tage.

Die Fristenkaskade im D-A-CH-Raum:

Hinzu kommt parallel und unabhängig die datenschutzrechtliche Meldung: in Deutschland und Österreich Art. 33 DSGVO binnen 72 Stunden, in der Schweiz Art. 24 nDSG an den EDÖB, dort ohne feste Stundenfrist, aber „so rasch als möglich". Bei personenbezogenen Daten laufen also zwei Meldepfade gleichzeitig, mit unterschiedlichen Adressaten, Fristen und Inhalten — inhaltlich konsistent, aber adressatengerecht formuliert. Für den österreichischen Rechtsrahmen ist der Stand im Beitrag zum NISG 2026 im Bundesgesetzblatt nachgezeichnet, für den schweizerischen in unserem Beitrag zur BACS-Meldepflicht für Spitäler.

Konkret: Prüfen Sie nicht, ob Sie eine Meldevorlage haben. Prüfen Sie, wer im Haus um 22:30 Uhr an einem Freitag entscheiden darf, dass eine Frühwarnung rausgeht — und ob diese Person erreichbar ist, ohne dass jemand anderes zustimmen muss. Fast alle Fristverletzungen in der Praxis entstehen nicht durch fehlende Formulare, sondern durch ungeklärte Entscheidungsbefugnis.

Lehre 3 — Zugangsdaten im Klartext sind kein Ausrutscher, sondern ein Prozessdefekt

Am 1. September bestätigte das Land Berlin, dass Zugangsdaten und Passwörter im Klartext abgeflossen sind — nach Angaben der Angreifer unter anderem für Verwaltungsdatenbanken und Zahlungsdienstleister. Die Folge war unmittelbar spürbar: VPN-Zugänge mussten abgeschaltet werden, Telearbeit wurde eingeschränkt.

Klartextpasswörter in Office-Dokumenten entstehen nicht aus Nachlässigkeit einzelner Mitarbeitender. Sie entstehen, wenn es kein zentrales Secrets-Management gibt und Menschen trotzdem ihre Arbeit erledigen müssen. Die Datei mit den Dienstleisterzugängen ist eine rationale Reaktion auf ein fehlendes Werkzeug.

Genau hier trennt sich ein gelebtes vom dokumentierten ISMS. § 30 Abs. 2 BSIG nennt Kryptografie und Zugriffskontrolle ausdrücklich als Bestandteile der Risikomanagementmaßnahmen. Eine Richtlinie, die Klartextpasswörter verbietet, ohne eine praktikable Alternative bereitzustellen, erfüllt den Buchstaben und erzeugt genau das Verhalten, das sie verbieten soll.

Konkret: Suchen Sie in Ihren Dateiablagen nach Dokumenten mit „Zugang", „Passwort", „Kennwort", „Login" oder „Zugangsdaten" im Dateinamen. Das Ergebnis ist eine belastbare Aussage über den Reifegrad Ihres Zugriffsmanagements — und ein Befund, der sich in einer Managementbewertung vorlegen lässt.

Lehre 4 — Keine Verschlüsselung heißt nicht: kein Schaden

Nach bisherigem Stand wurden die Systeme nicht verschlüsselt. Es handelt sich um reine Exfiltration mit anschließender Erpressung.

Das ist die relevante Verschiebung im Angriffsmodell, und sie entwertet einen erheblichen Teil der üblichen Abwehrargumentation. Ein sauber getestetes Backup-Konzept, eine kurze RTO, eine geübte Wiederanlaufplanung — all das hilft gegen Verschlüsselung. Gegen Veröffentlichung hilft nichts davon. Die Daten sind draußen, und sie bleiben draußen.

Wer Ransomware primär als Verfügbarkeitsrisiko modelliert, hat das falsche Szenario im Risikokatalog. Das tatsächliche Risiko ist ein Vertraulichkeitsrisiko mit dauerhaftem Schaden: Personaldaten, Ausweiskopien, Vertragsunterlagen, in diesem Fall offenbar auch Dokumente über Schwachstellen kritischer Versorgungsinfrastruktur.

Konkret: Prüfen Sie in Ihrer Risikoanalyse, ob das Szenario „Datenabfluss ohne Betriebsunterbrechung" eigenständig bewertet ist — oder ob es implizit unter „Ransomware" mitläuft und deshalb mit Backup-Maßnahmen als behandelt gilt. Wenn Ihr Schutzbedarf nach Vertraulichkeit, Integrität und Verfügbarkeit getrennt geführt wird, fällt dieser Fehler sofort auf. Wenn nicht, fällt er gar nicht auf. Eine Struktur dafür liefert unsere Vorlage für das NIS2-Risikomanagement.

Lehre 5 — Containment ist eine Geschäftsentscheidung, keine IT-Entscheidung

Berlin hat getan, was in jeder Übung empfohlen wird: die betroffenen Umgebungen isolieren. Die Folge war neun Tage weitgehender Stillstand in zwei Senatsverwaltungen. Kein Internet, keine externe Mailkommunikation, keine Telearbeit, Rückfall auf Papierakten und Festnetz. Betroffen waren Genehmigungsverfahren und andere Bürgerdienste.

Isolation ist die richtige Maßnahme. Aber sie ist keine technische Maßnahme mit technischen Folgen — sie ist eine Entscheidung, die den Betrieb anhält. In einer Klinik heißt das Ausfall von Befundübermittlung und Terminvergabe, in einem Versorger Ausfall von Leitwarte-Nebensystemen, in einem Industriebetrieb Stillstand von Auftragsabwicklung.

Wenn diese Abwägung erst im Vorfall getroffen wird, wird sie zu langsam getroffen — oder gar nicht, weil niemand die Verantwortung für den Betriebsausfall übernehmen will. Das ist der häufigste Grund, warum Containment verzögert wird. Wie sich ein solcher Ausfall entlang der Lieferkette fortsetzt, zeigt der Unimed-Cyberangriff.

Konkret: Legen Sie vorab fest, wer die Isolation welcher Segmente anordnen darf und welche Betriebsausfälle dafür ohne weitere Rückfrage akzeptiert werden. Das gehört in den BCM-Teil des Managementsystems, nicht in eine technische Betriebsanweisung — und es gehört von der Geschäftsleitung freigegeben, nicht von der IT-Leitung.

Lehre 6 — Die Regulierungslücke ist kein Schutzschild

Hier liegt die für regulierte Einrichtungen aufschlussreichste Beobachtung.

Die Berliner Senatsverwaltungen unterliegen nicht dem BSIG. Das neue BSI-Gesetz, seit dem 6. Dezember 2025 ohne Übergangsfrist in Kraft, erfasst wirtschaftlich tätige Einrichtungen und die Bundesverwaltung — Länder, Kommunen und Sozialversicherungsträger jedoch nicht. Die Gesetzgebungskompetenz für die Cybersicherheit der Landes- und Kommunalverwaltung liegt bei den Ländern selbst; der IT-Planungsrat hat zudem entschieden, die kommunale Ebene nicht in den Anwendungsbereich einzubeziehen. Bislang haben nur einzelne Länder eigene Umsetzungsakte geschaffen. Das Ergebnis ist ein Flickenteppich.

Die Länder-Lücke hat den Angriff nicht verhindert und die Folgen nicht gemildert. Sie hat lediglich dazu geführt, dass für dieselben Systeme keine bundeseinheitlichen Mindestanforderungen, keine Registrierungspflicht und keine durchsetzbaren Meldefristen galten.

Der Kontrast zu den Nachbarländern ist deutlich: In der Schweiz sind kantonale und kommunale Verwaltungen ausdrücklich meldepflichtig nach ISG. In Österreich erfasst das NISG 2026 auch Gemeinden mit kritischen Diensten wie der Wasserversorgung.

Die praktische Konsequenz für Ihr Haus ist weniger rechtlicher als organisatorischer Natur: Wenn Sie mit Landeseinrichtungen, kommunalen Trägern oder deren IT-Dienstleistern Daten austauschen, können Sie sich nicht darauf verlassen, dass dort ein vergleichbares Schutzniveau reguliert ist. Ihre eigene Pflicht zur Sicherheit in der Lieferkette nach § 30 BSIG endet nicht an der Grenze des Anwendungsbereichs Ihres Gegenübers. Für die physische Seite derselben Frage siehe das KRITIS-Dachgesetz.

Lehre 7 — Der Schaden trifft Dritte, die nie Vertragspartner waren

Im veröffentlichten Paket befinden sich nach Angaben der Täter Unterlagen über Schwachstellen der Wasserversorgung, Ausschussprotokolle und Zugangsdaten zu Zahlungsdienstleistern. Betroffen sind damit Organisationen, die selbst nicht angegriffen wurden — deren Daten aber bei einer angegriffenen Stelle lagen.

Das ist die Umkehrung des klassischen Lieferkettenrisikos. Üblicherweise fragen Sie: Was passiert, wenn mein Dienstleister kompromittiert wird? Die relevantere Frage lautet zunehmend: Welche Daten über andere liegen bei mir — und was löse ich aus, wenn ich kompromittiert werde? Wie sich das systematisch fassen lässt, beschreibt der Beitrag zum Drittanbieter-Risikomanagement.

Für jede Einrichtung mit Aufsichts-, Prüf- oder Koordinationsfunktion ist das eine ernsthafte Frage. Auditberichte über Dritte, Schwachstellenanalysen, Netzpläne von Partnern, Zugangsdaten zu fremden Systemen: All das erhöht Ihren eigenen Schutzbedarf, ohne dass es in der klassischen Schutzbedarfsfeststellung sichtbar wird, die sich auf eigene Geschäftsprozesse konzentriert.

Und es ist der Punkt, an dem § 38 BSIG greift: Geschäftsleitungen sind verpflichtet, die Risikomanagementmaßnahmen nach § 30 umzusetzen und ihre Umsetzung zu überwachen — mit Haftung nach den gesellschaftsrechtlichen Regeln bei Pflichtverletzung. Die Delegation an die IT-Leitung entlastet nicht.

Was Krankenhäuser aus diesem Fall mitnehmen sollten

Der Vorfall betrifft eine Verwaltung, aber die Übertragung auf den Klinikbetrieb ist direkt:

• Nicht migrierte Systeme heißen im Krankenhaus: Medizingerätearbeitsplätze, Fachanwendungen einzelner Abteilungen, Gebäudeleittechnik. Es sind genau die Bereiche, in denen die zentrale IT häufig keine vollständige Zuständigkeit hat.
• Klartext-Zugangsdaten finden sich typischerweise dort, wo Servicetechniker, Gerätehersteller und Fernwartungszugänge zusammenkommen.
• Isolation als Betriebsentscheidung ist im Klinikkontext eine Patientensicherheitsfrage. Sie kann nicht von der IT allein getroffen werden.
• Datenabfluss ohne Verschlüsselung trifft im Krankenhaus besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO — mit entsprechend hoher Wahrscheinlichkeit einer Benachrichtigungspflicht der Betroffenen nach Art. 34 DSGVO.

Anders als die Berliner Senatsverwaltungen fallen deutsche Krankenhäuser ab den einschlägigen Schwellen unmittelbar unter das BSIG, dazu je nach Größe unter § 391 SGB V und den B3S Krankenhaus. Die Regulierungslücke, die in Berlin bestand, besteht für Kliniken nicht.

Was in den nächsten 30 Tagen zu tun ist

1. Inventarabgleich: Liste aller Systeme ohne Patch-, Backup- oder Monitoring-Nachweis der letzten zwölf Monate. Ergebnis in der Managementbewertung dokumentieren.
2. Suchlauf Zugangsdaten: Dateiablagen und Wikis nach Klartext-Zugangsdaten durchsuchen. Befund als Risiko erfassen, nicht nur bereinigen.
3. Eskalationsweg testen: Unangekündigt prüfen, wer außerhalb der Geschäftszeiten eine Frühwarnung nach § 32 BSIG bzw. Art. 74b ISG auslösen darf und ob diese Person erreichbar ist.
4. Szenario ergänzen: „Datenabfluss ohne Betriebsunterbrechung" als eigenständiges Risiko in den Risikokatalog aufnehmen und getrennt nach Vertraulichkeit bewerten.
5. Isolationsmandat freigeben: Schriftliche Festlegung, wer welche Netzsegmente abtrennen darf und welche Betriebsausfälle dafür akzeptiert sind — durch die Geschäftsleitung gezeichnet.
6. Fremddaten identifizieren: Bestandsaufnahme, welche Daten über Dritte im Haus liegen, und Abgleich mit dem daraus folgenden Schutzbedarf.
7. Lieferkette prüfen: Für Dienstleister und Partner außerhalb des NIS2-Anwendungsbereichs vertragliche statt regulatorische Absicherung des Schutzniveaus.

FAQ

Waren die Berliner Senatsverwaltungen nach NIS2 verpflichtet? Nein. Das BSIG erfasst Länder, Kommunen und Sozialversicherungsträger nicht. Die Gesetzgebungskompetenz für die Cybersicherheit der Landesverwaltungen liegt bei den Ländern; der IT-Planungsrat hat zudem entschieden, die lokale Verwaltungsebene nicht einzubeziehen. Bislang haben nur einzelne Bundesländer eigene Umsetzungsakte erlassen. Für Landesverwaltungen entfaltet das BSI-Gesetz keine unmittelbare normative Wirkung, sondern dient als Orientierung.

Wie viele Daten sind tatsächlich abgeflossen? Die Angabe von 5,79 Terabyte in rund 1,44 Millionen Dateien stammt von den Tätern und ist in dieser Genauigkeit nicht unabhängig bestätigt. Bestätigt ist, dass zwischen dem 7. und 12. August 2026 Daten aus zwei Senatsverwaltungen abgeflossen sind und dass darunter Zugangsdaten im Klartext waren. Das am 4. September veröffentlichte Paket hat einen Umfang von rund 5,8 Terabyte.

Wurden die Systeme verschlüsselt? Nach bisherigem Stand nicht. Es handelt sich um Exfiltration mit anschließender Erpressung durch Veröffentlichungsandrohung. Das ist ein Vertraulichkeits-, kein Verfügbarkeitsvorfall — mit der Folge, dass Backup- und Wiederanlaufkonzepte den Schaden nicht begrenzen konnten.

War die Entscheidung, nicht zu zahlen, richtig? Diese Frage lässt sich nicht allgemein beantworten, aber der Fall zeigt die Realität hinter der Alternative: Eine Zahlung hätte keine Garantie für die Löschung der Daten geschaffen und die Erpressbarkeit für künftige Fälle erhöht. Behörden und das BSI raten grundsätzlich von Lösegeldzahlungen ab. Die praktische Konsequenz muss man aber vorher durchdacht haben — die Entscheidung fällt sonst unter Zeitdruck und öffentlicher Beobachtung.

Was bedeutet der Fall für Organisationen, die mit Landes- oder Kommunalverwaltungen zusammenarbeiten? Dass die dortigen Sicherheitsanforderungen nicht regulatorisch garantiert sind. Wer Daten mit solchen Stellen austauscht, muss das Schutzniveau vertraglich und organisatorisch absichern. Die eigene Pflicht zur Sicherheit in der Lieferkette nach § 30 BSIG bleibt bestehen, unabhängig davon, ob der Partner selbst reguliert ist.

Gilt in der Schweiz und Österreich dasselbe? Nein — und zwar zugunsten der Verwaltung. In der Schweiz sind kantonale und kommunale Verwaltungen ausdrücklich meldepflichtig nach ISG, mit einer Frist von 24 Stunden nach Entdeckung an das BACS. In Österreich erfasst das NISG 2026 ab dem 1. Oktober 2026 auch Gemeinden mit kritischen Diensten. Die deutsche Länder-Lücke ist eine nationale Besonderheit.

Fazit

Der Angriff auf das Berliner Landesnetz war technisch unspektakulär und in seinen Ursachen ausgesprochen gewöhnlich: ein System außerhalb der zentralen Betreuung, Zugangsdaten im Klartext, eine Detektionslücke von über einer Woche. Nichts davon setzt einen besonders fähigen Angreifer voraus.

Genau deshalb ist der Fall als Prüfmuster brauchbar. Die sieben Lehren lassen sich in einem Nachmittag gegen das eigene Haus halten, und die Antworten sind unangenehm konkret: Kennen Sie alle Ihre Systeme? Wissen Sie, wo Ihre Zugangsdaten liegen? Wer darf um 22:30 Uhr eine Meldung auslösen? Und was passiert, wenn Ihre Daten veröffentlicht werden, statt verschlüsselt?

Ein Managementsystem, das diese vier Fragen nicht beantwortet, ist dokumentiert, aber nicht wirksam.

Unsicher, ob Ihr Haus die Risikomanagementmaßnahmen nach § 30 BSIG vollständig umgesetzt hat? Das kostenfreie NIS2-Self-Assessment liefert in rund 15 Minuten einen anonymen Bericht mit konkreten Handlungsempfehlungen.

Lieber im Gespräch? Buchen Sie einen 15-minütigen Discovery Call — wir zeigen Ihnen die ISMShield AI Suite und besprechen Ihren konkreten Handlungsbedarf.

Weiterführende Artikel

• NIS2-Maßnahmen im Krankenhaus: § 30 BSIG in der Praxis
• Der Unimed-Cyberangriff: 5 Lehren für Krankenhäuser
• KRITIS-Dachgesetz: Was Krankenhäuser jetzt tun müssen
• Österreich: NISG 2026 im Bundesgesetzblatt verkündet
• BACS-Meldepflicht für Cyberangriffe: Was Spitäler wissen müssen
• Drittanbieter-Risikomanagement im Spital
• NIS2-Risikomanagement Krankenhaus: Vorlage

---

Der Beitrag dient der allgemeinen Information und stellt keine Rechts- oder Beratungsdienstleistung dar. Für die Umsetzung in der eigenen Organisation sollten Sie einen Fachanwalt bzw. Ihren Datenschutzbeauftragten konsultieren.

Stand der Informationen: 4. September 2026. Quellen: Senatskanzlei Berlin (Pressemitteilungen vom 17.08.2026 und 23.08.2026), Berichterstattung von rbb24, t-online und dpa vom 14.08.–04.09.2026, BSI-FAQ „NIS-2 für die Landes- und Kommunalverwaltung", Beschluss 2023/39 des IT-Planungsrats, BSIG vom 02.12.2025 (BGBl. 2025 I Nr. 301), NISG 2026 (Österreich) sowie ISG Art. 74a–74f und die Cybersicherheitsverordnung (CSV).