Der Cyberangriff auf Teile der Berliner Verwaltung ist mehr als ein erfolgreicher Einbruch in zwei Senatsverwaltungen. Er ist ein Belastungstest für die Behauptung, dass Informationssicherheit in einer digital abhängigen Verwaltung tatsächlich als Führungs-, Risiko- und Resilienzaufgabe betrieben wird. Die entscheidende Frage lautet deshalb nicht, ob Berlin jedes Eindringen hätte verhindern können. Das kann niemand. Entscheidend ist, warum ein Angriff über Tage unbemerkt blieb, große Datenmengen exfiltriert werden konnten und warum nach Jahren gesetzlicher ISMS-Pflichten weiterhin strukturelle Defizite sichtbar werden.
Ein Angriff, der zunächst wie ein begrenzter Vorfall wirkte
Zwischen dem 7. und 12. August 2026 verschafften sich Angreifer nach heutigem Kenntnisstand Zugriff auf Teile des Berliner Landesnetzes und kopierten Daten. Entdeckt wurde der Vorfall am 14. August. Die Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen sowie die Senatsverwaltung für Mobilität, Verkehr, Klimaschutz und Umwelt wurden daraufhin aus Sicherheitsgründen vom Landesnetz getrennt. Landeskriminalamt, Staatsanwaltschaft, BSI und weitere Stellen wurden eingeschaltet. Drei Tage später informierte Berlin öffentlich über den Vorfall.
In den ersten Tagen dominierte ein Bild kontrollierter Eindämmung. Am 19. August erklärte der Regierende Bürgermeister Kai Wegner, nach dem damaligen Kenntnisstand seien keine sensiblen Daten abgeflossen. Diese Aussage war ausdrücklich vorläufig formuliert – und genau darin liegt das Kommunikationsproblem: Zu diesem Zeitpunkt war die Forensik noch nicht abgeschlossen. Wenige Tage später musste der Senat einräumen, dass weitere Daten abgeflossen waren; Anfang September bekannte sich Rhysida zur Tat und behauptete, rund 5,7 Terabyte erbeutet zu haben. Rhysida ist eine seit 2023 beobachtete, international agierende Ransomware-Gruppe, die in der Vergangenheit gezielt Organisationen aus dem öffentlichen Sektor, dem Gesundheitswesen, dem Bildungsbereich und weiteren kritischen Branchen angegriffen hat. Ihr Geschäftsmodell folgt typischerweise dem Prinzip der "Double Extortion": Die Angreifer verschlüsseln nicht nur Systeme, sondern kopieren zuvor sensible Daten und drohen anschließend mit deren Veröffentlichung auf speziellen Leak-Seiten im Darknet, falls kein Lösegeld gezahlt wird. Damit wird aus einem Angriff auf die Verfügbarkeit von IT-Systemen zugleich ein massives Vertraulichkeits- und Datenschutzproblem.
Am 4. September wurden große Teile des Diebesguts veröffentlicht. In der Nacht zum 6. September folgte ein weiteres Paket, das nach Angaben des Landes auch Zugangsdaten enthielt. Damit hatte sich der Vorfall von einer Betriebsstörung zu einem dauerhaften Vertraulichkeitsverlust entwickelt: Systeme können neu aufgebaut und Passwörter geändert werden; einmal weltweit veröffentlichte Dokumente lassen sich nicht zuverlässig zurückholen.
Was den Angriff ausgelöst haben könnte
Eine abschließende, von Berlin oder den Ermittlungsbehörden veröffentlichte technische Rekonstruktion des Erstzugangs liegt bislang nicht vor. Medienberichte verdichten jedoch das Bild eines Social-Engineering-Angriffs. Der Tagesspiegel rekonstruierte, dass ein Beschäftigter der Verkehrsverwaltung auf einen Link in einer Phishing-Mail geklickt habe. Parallel veröffentlichte das BSI Anfang September einen Sicherheitshinweis zur sogenannten TerminalFix-Kampagne und erklärte, Erkenntnisse aus dem Berliner Vorfall seien in diese Schutzinformation eingeflossen. Golem folgerte daraus, dass der Berliner Angriff offenbar über ein manipuliertes CAPTCHA beziehungsweise eine ClickFix-/TerminalFix-Kette erfolgt sei. Das BSI selbst vermeidet wegen des laufenden Vorfalls eine vollständige öffentliche Zuordnung.
Bei TerminalFix wird ein Nutzer typischerweise dazu gebracht, einen vermeintlichen Verifikationsschritt auszuführen. Nach der Ausführung eines vom Angreifer vorgegebenen Befehls können Schadkomponenten nachgeladen, Persistenz aufgebaut, erreichbare Netze erkundet und Daten exfiltriert werden. Das ist technisch relevant, aber organisatorisch noch relevanter: Solche Kampagnen kalkulieren menschliche Fehlhandlungen bewusst ein. Ein wirksames Sicherheitsmodell darf deshalb nicht darauf beruhen, dass zehntausende Beschäftigte niemals auf einen überzeugenden Link klicken oder eine täuschend echte Anweisung ausführen.
Die zentrale Ursachenfrage beginnt erst nach dem Klick: Welche Rechte hatte das kompromittierte Konto? War Mehrfaktor-Authentisierung wirksam und flächendeckend? Konnte ein Arbeitsplatz ungehindert zu weiteren Systemen kommunizieren? Wie schnell wurden ungewöhnliche PowerShell-Aktivitäten, neue Persistenzmechanismen, große Datenbewegungen oder atypische Cloud-Uploads erkannt? Welche Segmentierung trennte Benutzerarbeitsplätze von besonders sensiblen Datenbeständen? Und warum dauerte es mehrere Tage, bis der Angriff erkannt wurde?
Der Schaden liegt nicht nur in 5,7 oder 5,8 Terabyte
Rhysida bezifferte den eigenen Datendiebstahl auf rund 5,7 Terabyte; Medienberichte sprechen von etwa 1,44 Millionen Dateien und knapp 5,8 Terabyte. Solche Zahlen beeindrucken, sagen aber wenig über die eigentliche Risikohöhe aus. Eine einzelne Datei mit Zugangsdaten, Lageplänen, Notfallkontakten oder detaillierten Sicherheitsinformationen kann gefährlicher sein als zehntausende unkritische Dokumente. Der Wert eines Leaks bemisst sich nach Inhalt, Kontext, Aktualität und Kombinierbarkeit – nicht nach Gigabyte.
Nach Angaben des Landes können personenbezogene Daten von Beschäftigten, Bürgern und Unternehmen betroffen sein. Die Berliner Datenschutzbeauftragte warnt deshalb unter anderem vor Identitätsmissbrauch und empfiehlt 2FA sowie das sofortige Ändern wiederverwendeter Passwörter. Besonders brisant ist, dass Berlin am 6. September selbst bestätigte, dass ein weiteres veröffentlichtes Paket Zugangsdaten enthielt.
Mediale Stichproben in dem veröffentlichten Material zeichnen ein noch breiteres Bild. Diverse Medien berichteten – unter Bezug auf den Chaos Computer Club und eigene Recherchen – über Personalunterlagen, interne Schreiben, Notfallpläne und Informationen mit Bezug zu kritischen Infrastrukturen. Genannt wurden unter anderem Heizkraftwerke, Tanklager, Ersatzstromanlagen, Umspannwerke, Wasserwerke, Justizvollzugsanstalten sowie Unterlagen mit Bezug zu Bundesstellen. Solche Berichte sind nicht mit einer amtlichen Vollprüfung gleichzusetzen; sie zeigen aber, warum eine reine Einordnung nach formaler Geheimhaltungsstufe zu kurz greifen kann.
Der Senat erklärte am 7. September, nach dem bisherigen Prüfstand seien keine Daten mit erhöhter Relevanz für die nationale Sicherheit entwendet worden; betroffen seien allenfalls Unterlagen der niedrigsten Verschlusssachenstufe VS-NfD. Zugleich waren mehr als 1,2 Millionen Dateien noch nicht vollständig bewertet. Das ist ein legitimer Zwischenstand, aber noch kein abschließender Entwarnungsbefund.
Warum veröffentlichte Daten einen zweiten Angriff ermöglichen
Mit der Veröffentlichung endet der Primärangriff nicht. Gestohlene Daten können Phishing-Mails glaubwürdiger machen, Organisationsstrukturen offenlegen, Ansprechpartner identifizieren, Lieferantenbeziehungen zeigen und Zugangsdaten oder technische Hinweise für Folgeangriffe liefern. Das BSI weist ausdrücklich darauf hin, dass Datenleaks die Bedrohungslage für Betroffene, kritische Infrastrukturen, Unternehmen und politische Institutionen erhöhen können. Vor Wahlen kommt zusätzlich das Risiko von Hack-and-Leak-Kampagnen hinzu, bei denen echte Dokumente selektiv veröffentlicht, aus dem Kontext gerissen oder mit manipulierten Inhalten vermischt werden können.
Damit verschiebt sich das Risikomanagement von "Systeme wieder online bringen" zu einem jahrelangen Nachsorgeproblem: Zugangsdaten müssen systematisch widerrufen, Zertifikate und Schlüssel überprüft, interne Informationen neu bewertet, besonders gefährdete Personen informiert und mögliche Folgeangriffe überwacht werden. Dass der Staat nun mehr als eine Million Dateien nach Risikopotenzial kategorisieren muss, ist selbst ein Indikator dafür, dass Datenklassifikation und Exfiltrationskontrolle vor dem Vorfall möglicherweise nicht ausreichend operationalisiert waren – zumindest soweit sich dies aus der öffentlichen Lage ableiten lässt.
Die unmittelbaren Auswirkungen: Verwaltung ist kritische Infrastruktur ihrer eigenen Aufgaben
Die Abtrennung der beiden Senatsverwaltungen war als Eindämmungsmaßnahme nachvollziehbar, hatte aber direkte Folgen für Verwaltungsleistungen. Zeitweise waren Bereiche nur eingeschränkt erreichbar; bei den Wohngeldleistungen kam es zu Störungen. Nach der Wiederanbindung Ende August liefen Fachverfahren wieder an, allerdings mit Verzögerungen. Nach dem späteren Fund veröffentlichter Zugangsdaten wurden Sicherheitsmaßnahmen erneut verschärft, was wiederum kurzfristige Einschränkungen in Fachverfahren nach sich ziehen konnte.
Diese operative Dimension wird in Cyberdebatten oft unterschätzt. Für eine Verwaltung ist Verfügbarkeit kein Komfortmerkmal. Sie ist Teil der staatlichen Leistungsfähigkeit. Wenn Wohngeld, Genehmigungen, Verkehrssteuerung, Bauverfahren oder interne Krisenprozesse von digitalen Systemen abhängen, wird Business Continuity Management (BCM) zu einer Kernaufgabe der Daseinsvorsorge. Der Cyberangriff ist deshalb nicht nur Datenschutzvorfall und nicht nur IT-Schaden, sondern ein Test staatlicher Handlungsfähigkeit.
IT-Grundschutz: Berlin hatte die Regeln – die entscheidende Frage ist ihre Wirksamkeit
Der regulatorische Ausgangspunkt ist ungewöhnlich klar. § 23 des Berliner E-Government-Gesetzes verpflichtet alle Behörden der Berliner Verwaltung, ein Informationssicherheitsmanagementsystem nach den Standards des BSI aufzubauen und weiterzuentwickeln. Zugleich ist das Berlin-CERT gesetzlich verankert. Berlin hat damit nicht erst nach diesem Angriff entdeckt, dass Informationssicherheit strukturiert organisiert werden muss; die Pflicht besteht seit Jahren.
Auch die Berliner Cybersicherheitsstrategie von 2025 beschreibt die Architektur ausführlich: ISMS, kontinuierlicher Verbesserungsprozess, ein ISMS-Tool zur messbaren Steuerung, Schulung und Sensibilisierung, Berlin-CERT, Cyber Defence Center, Security Operations Center, Schwachstellenscans, Penetrationstests sowie die Konsolidierung der Infrastruktur über OneIT@Berlin. Auf dem Papier ist das ein plausibles Verteidigungsmodell.
Genau deshalb ist der Vorfall so relevant. Der IT-Grundschutz ist kein Katalog, den eine Behörde einmal abhakt. Die BSI-Standards 200-1 und 200-2 verstehen Informationssicherheit als Managementprozess: Leitung, Ziele, Ressourcen, Verantwortlichkeiten, Risikoentscheidungen, Umsetzung, Kontrolle und kontinuierliche Verbesserung müssen ineinandergreifen. Die Leitungsebene bleibt verantwortlich, auch wenn operative Aufgaben an Informationssicherheitsbeauftragte, CERTs oder IT-Dienstleister delegiert werden. Das BSI bringt den Grundsatz auf die kurze Formel: "Informationssicherheit ist Chefsache."
Eine Behörde kann deshalb formal ein ISMS besitzen und praktisch trotzdem ein unzureichendes Sicherheitsniveau haben. Entscheidend ist die Evidenz: Sind Informationsverbünde vollständig erfasst? Werden Risiken regelmäßig bewertet? Sind Rest-Risiken transparent akzeptiert? Werden kritische Maßnahmen mit Fristen, Verantwortlichen und Budget hinterlegt? Gibt es belastbare Kennzahlen zur MFA-Abdeckung, Patchgeschwindigkeit, Endpoint Detection, privilegierten Konten, Segmentierung, Backup-Wiederherstellung und Awareness? Werden Abweichungen eskaliert? Werden Notfallübungen ausgewertet und Verbesserungen nachverfolgt? Erfolgt die Umsetzung eines wirksames Risikomanagements basierend auf fundierten Methoden? Ohne solche Nachweise bleibt "ISMS vorhanden" eine formale Aussage, keine Aussage über Wirksamkeit.
In der Berliner Cybersicherheitsstrategie 2025 steht: "Derzeit erfolgt die IKT-Notfallbewältigung in den meisten Einrichtungen reaktiv.". Dieser Satz wiegt schwer. Die Strategie ergänzt, vorhandene Konzepte und Strukturen bildeten erst die Voraussetzung für ein Business-Continuity-Management mit höherem Reifegrad. Das ist kein Beweis dafür, dass gerade die beiden angegriffenen Senatsverwaltungen ohne Notfallvorsorge arbeiteten. Es ist aber eine offizielle Selbstbeschreibung eines Systems, dessen Reifegrad noch nicht dort war, wo eine hochgradig digital abhängige Hauptstadtverwaltung ihn benötigen würde.
Papier-Compliance ist kein präventives IT-Risikomanagement
Ob Berlin vor dem Angriff über ein "wirksames präventives IT-Risikomanagement" verfügte, lässt sich aus öffentlich zugänglichen Unterlagen nicht mit einem einfachen Ja oder Nein beantworten. Berlin betrieb CERT-, SOC- und ISMS-Strukturen, führte Scans und Penetrationstests durch und nahm an Krisenübungen teil. Die belastbarere Frage lautet: War dieses System in den betroffenen Bereichen reif genug, um reale Risiken rechtzeitig zu erkennen, zu priorisieren und wirksam zu behandeln?
Mehrere Indikatoren sprechen für erhebliche Zweifel. Erstens blieb der Angreifer nach bisheriger Rekonstruktion mehrere Tage unentdeckt. Zweitens konnte eine sehr große Datenmenge abgeführt werden. Drittens tauchten Zugangsdaten in den Veröffentlichungen auf. Viertens berichtete ein CCC-Sprecher am 7. September, dass einzelne veröffentlichte Zugänge nach seinen Informationen noch Tage nach einem ersten Daten-Sample nutzbar gewesen seien und teilweise einfache Passwörter im Klartext vorgelegen hätten. Diese Aussagen sind derzeit externe Kritik und keine abschließenden amtlichen Feststellungen – sie sind jedoch so konkret, dass sie in einer unabhängigen Aufarbeitung geprüft werden müssen. Fünftens hat Berlin selbst strukturelle Defizite eingeräumt. Bereits am 24. August sagte CDO Florian Hauer, Berlin sei bei der IT-Sicherheit nicht perfekt aufgestellt und es gebe strukturelle Defizite. Am 7. September erklärte er erneut, bei weiteren Sicherheitsprüfungen würden höchstwahrscheinlich seit Jahren entstandene strukturelle Defizite sichtbar werden. Für ein ISMS ist das zentral: Ein Risiko, das strukturell seit Jahren besteht, aber nicht rechtzeitig und priorisiert abgestellt wird, ist kein rein technisches Problem. Es ist ein Governance- und Ressourcenproblem.
Warnsignale gab es schon vor dem Angriff
Die Berichte des Berliner Rechnungshofs verstärken diesen Befund. 2024 stellte er in der Senatsverwaltung für Justiz schwerwiegende Mängel fest: fehlendes Notfallmanagement, unzureichend geschützte IT-Infrastruktur, Defizite bei Schulungen und ein mangelhaftes Informationssicherheitsmanagement. Der Rechnungshof warnte ausdrücklich, Risiken könnten dadurch nicht erkannt und Gegenmaßnahmen nicht rechtzeitig eingeleitet werden.
2025 folgte ein ähnlich harter Befund für das Bezirksamt Marzahn-Hellersdorf: Fehlende oder teils 20 Jahre alte IT-Konzepte, unzureichend geschützte Technikräume, fehlende Schulungen und seit 2015 kein ordnungsgemäßes IT-Notfallkonzept. Diese Prüfungen betrafen nicht die beiden 2026 angegriffenen Senatsverwaltungen. Sie dürfen daher nicht als direkte Vorwarnung für genau diesen Einbruch missverstanden werden. Sie zeigen jedoch, dass gravierende Reifegradprobleme innerhalb der Berliner Verwaltung weder theoretisch noch neu waren.
Hinzu kommt die noch laufende Konsolidierung. OneIT@Berlin soll den dezentralen Betrieb standardisieren und zum ITDZ überführen. Im Juni 2025 war der Rechnungshof nach eigener Darstellung die erste oberste Landesbehörde, die ihre verfahrensunabhängige IT vollständig nach OneIT-Standards umgestellt hatte. Auch das ist keine direkte Kausalität zum Angriff. Es zeigt aber, dass die Hauptstadtverwaltung noch mitten in einer komplexen Transformation von heterogenen Strukturen zu einer stärker zentralisierten Betriebs- und Sicherheitsarchitektur stand.
Mehr Pflichten lösen das Umsetzungsproblem nicht automatisch
Neben dem Berliner E-Government-Gesetz wirken Datenschutzrecht und die europäische NIS2-Logik als zusätzlicher Druck. Die DSGVO verlangt bei personenbezogenen Daten ein dem Risiko angemessenes Schutzniveau und bei Datenschutzverletzungen klare Melde- und gegebenenfalls Benachrichtigungspflichten. Berlin hat die Datenschutzaufsicht über neue Erkenntnisse informiert und kündigt eine risikobasierte Information identifizierter Betroffener an.
Für NIS2 hat Berlin eigene Zuständigkeiten und Aufsichtsprozesse für den öffentlichen Sektor beschrieben: Die Senatskanzlei soll die Umsetzung beaufsichtigen, Berlin-CERT fungiert als zentrale Meldestelle beziehungsweise CSIRT. Solche Regeln sind sinnvoll. Sie lösen aber das Kernproblem nicht, wenn die Aufsicht vor allem Dokumentations- und Berichtspflichten prüft. Ein wirksames Regime muss Reifegrad, technische Mindestkontrollen und die tatsächliche Risikobehandlung testen – einschließlich Stichproben, Angriffssimulationen und nachvollziehbarer Eskalation nicht behobener Hochrisiken.
Der Fall Berlin illustriert damit ein grundsätzliches Problem staatlicher Cyberregulierung: Je umfangreicher die Regelwerke werden, desto größer ist die Gefahr, dass Organisationen Compliance mit Resilienz und wirksamen Risikomanagement verwechseln. Wird aus IT-Grundschutz (und dem neuen Grundschutz++) primär Dokumentation, entsteht eine gefährliche Illusion von Kontrolle.
Die Rolle des Regierenden Bürgermeisters: Politische Führungsverantwortung
Die Verantwortungsfrage darf weder personalisiert noch entpolitisiert werden. Kai Wegner hat weder Firewall-Regeln konfiguriert noch Benutzerkonten administriert. Ein erfolgreicher Phishing- oder TerminalFix-Angriff begründet keine persönliche technische Schuld des Regierenden Bürgermeisters. Ebenso wenig lässt sich aus dem bisherigen Material eine individuelle straf- oder disziplinarrechtliche Verantwortlichkeit ableiten.
Politisch ist die Lage anders. Berlin selbst formuliert: "Die Gewährleistung der IT-Sicherheit der Berliner Verwaltung obliegt der Senatskanzlei." OneIT@Berlin wird ebenfalls von der Senatskanzlei verantwortet. Der Regierende Bürgermeister leitet den Senat, bestimmt – mit Berliner Einschränkungen – die Richtlinien der Regierungspolitik und überwacht deren Einhaltung. Die Fachsenatorinnen und -senatoren führen ihre Ressorts eigenständig, aber die zentrale IT-Sicherheitsarchitektur ist ausdrücklich keine rein dezentrale Ressortangelegenheit.
Hinzu kommt eine Governance-Konstellation, die kritisch geprüft werden sollte: Ende Mai 2026 übertrug Wegner dem Staatssekretär Florian Hauer zusätzlich und für "die kommenden Monate" die Geschäfte des Chief Digital Officer sowie des Staatssekretärs für Verwaltungsmodernisierung und Digitalisierung. Eine solche Doppelrolle ist mitunter problematisch. In einer Phase tiefgreifender IT-Konsolidierung und wachsender Cyberbedrohungen stellt sich aber die legitime Frage, ob die zentrale Digital- und Sicherheitssteuerung dauerhaft mit ausreichender Führungskapazität, Fachnähe und Eskalationsmacht ausgestattet war.
Eine seriöse Bewertung sollte nicht daran hängen, ob der Bürgermeister während der Krise an einem öffentlichen Termin teilnahm oder persönlich in einem Lagezentrum saß. Entscheidend sind Governance-Fragen, die sich dokumentieren lassen: Welche Risikoberichte erreichten die Senatskanzlei und den Regierenden Bürgermeister vor August 2026? Welche Hochrisiken waren offen? Welche Fristen und Budgets waren für ihre Beseitigung beschlossen? Wie wurde auf Rechnungshofbefunde und interne Reifegradbewertungen reagiert? Welche Mindeststandards wurden ressortübergreifend tatsächlich durchgesetzt? Welche Rest-Risiken wurden bewusst akzeptiert – und von wem?
Auch die Krisenkommunikation ist Teil politischer Verantwortung. Wegners Aussage vom 19. August, nach damaligem Kenntnisstand seien keine sensiblen Daten abgeflossen, war formal vorsichtig. Im Rückblick zeigt sie jedoch, wie riskant frühe Entwarnung in einer noch laufenden Forensik ist. Besser wäre eine Kommunikation gewesen, die Unsicherheit selbst zur Kernbotschaft macht: Angriff eingedämmt, Umfang unbekannt, Datenabfluss nicht ausgeschlossen, Bewertung laufend. Gerade bei Cybervorfällen ist Glaubwürdigkeit ein Sicherheitsfaktor, weil Bürger, Beschäftigte und Unternehmen ihre Schutzmaßnahmen vom Informationsstand des Staates abhängig machen.
Die Opposition fordert inzwischen politische Konsequenzen; die FDP verlangte Rücktritte, Linke und Grüne eine Aktuelle Stunde zum Umgang mit dem Vorfall. Solche Forderungen sind Teil des politischen Wettbewerbs und noch kein Nachweis persönlichen Versagens. Sie erhöhen aber den Druck auf den Senat, nicht nur Täter und Technik zu erklären, sondern die eigene Sicherheitsgovernance offenzulegen.
Was jetzt unabhängig aufgeklärt werden muss
Eine belastbare Aufarbeitung darf sich nicht auf eine technische Forensik des kompromittierten Endgeräts beschränken. Sie muss den gesamten Sicherheitsprozess prüfen – vom Risikoentscheid bis zur Krisenkommunikation. Mindestens folgende Fragen gehören in einen öffentlich nachvollziehbaren Abschlussbericht:
- Initial Access: Welcher konkrete Angriffsweg führte in das Netz – Phishing, TerminalFix/ClickFix oder eine Kombination? Welche Schutzmechanismen hätten diesen Weg erkennen oder blockieren sollen?
- Identitäten und Rechte: Welche Konten und Privilegien wurden missbraucht? Wo galt MFA, wo nicht? Wie wurden administrative Konten, Service-Accounts und VPN-Zugänge geschützt?
- Segmentierung und Bewegung im Netz: Welche Systeme konnte der erste kompromittierte Arbeitsplatz erreichen, und warum? Welche lateralen Bewegungen wurden erkannt oder übersehen?
- Detektion: Welche EDR-, SOC- und Logging-Signale lagen zwischen 7. und 14. August vor? Warum lösten sie keinen früheren Alarm aus? Welche Abdeckung hatten die betroffenen Systeme?
- Datenabfluss: Über welche Wege wurden Terabytes exfiltriert? Gab es Schwellenwerte, DLP-Regeln oder Netzwerkalarme für ungewöhnliche Datenmengen?
- Zugangsdaten: Warum befanden sich nutzbare oder sensible Credentials in den veröffentlichten Daten? Wurden nach Bekanntwerden des Angriffs alle potenziell kompromittierten Geheimnisse systematisch rotiert?
- IT-Risikomanagement: Welche konkreten Risiken waren in den beiden betroffenen Senatsverwaltungen vor dem Angriff dokumentiert? Mit welchen Methoden wurden IT-Risikomanagement umgesetzt? Welche Maßnahmen waren offen, überfällig oder aus Ressourcenmangel verschoben?
- BCM und Wiederanlauf: Welche Wiederanlaufziele bestanden für Fachverfahren, wie wurden sie getestet, und welche Lehren ergeben sich aus den Leistungseinschränkungen?
- Zentrale Governance: Welche Rolle spielten Senatskanzlei, CDO, Landesbevollmächtigter für Informationssicherheit, ITDZ, Berlin-CERT und die Fachressorts? Wo lagen unklare Schnittstellen oder fehlende Durchgriffsrechte?
- Information der Öffentlichkeit: Wann wusste der Senat von welchem Umfang des Datenabflusses? Welche Kriterien galten für Entwarnungen, Betroffeneninformation und Veröffentlichung von Zwischenständen?
Was sich aus dem Fall bereits jetzt ableiten lässt
Erstens: Der Angriff ist die Tat einer kriminellen Gruppe. Die Verantwortung für die Straftat liegt bei den Angreifern. Diese Feststellung darf aber nicht als Entlastungsformel für die Organisation dienen. Informationssicherheitsmanagement existiert gerade deshalb, weil Angriffe erwartbar sind.
Zweitens: Der Erfolg eines Social-Engineering-Angriffs ist kein Beweis für mangelnde Mitarbeitermoral oder individuelle Fahrlässigkeit. Sicherheitsarchitekturen müssen Fehlhandlungen einkalkulieren. Wer den "menschlichen Faktor" zum schwächsten Glied erklärt, ohne Rechtekonzepte, Segmentierung, Detection, MFA, Egress-Kontrollen und Krisenprozesse zu prüfen, verschiebt Verantwortung von der Organisation auf den Einzelnen.
Drittens: Berlin hatte regulatorische Vorgaben, Sicherheitsakteure und Strategiepapiere. Gerade deshalb muss die Untersuchung die Lücke zwischen Soll und Ist vermessen. Die entscheidende Kennzahl eines ISMS ist nicht die Zahl seiner Dokumente, sondern wie schnell es bekannte Risiken reduziert, Angriffe erkennt, Schäden begrenzt und den Betrieb wiederherstellt.
Viertens: Die Rechnungshofbefunde von 2024 und 2025 sowie Berlins eigene Aussage über überwiegend reaktive IKT-Notfallbewältigung zeigen, dass Reifegradprobleme vor dem August 2026 bekannt waren. Nicht bewiesen ist, dass genau diese Defizite den Rhysida-Angriff ermöglichten. Bewiesen ist aber, dass die politische und administrative Leitung keinen Anlass hatte, Cyberrisiken als hypothetisches Randthema zu behandeln.
Fünftens: Politische Verantwortung beginnt dort, wo Prioritäten, Ressourcen und Kontrolle entschieden werden. Für Kai Wegner ist deshalb nicht die Frage entscheidend, ob er einen Angriff persönlich hätte verhindern können. Entscheidend ist, ob seine Senatskanzlei und sein Senat ein wirksames System geschaffen haben, das bekannte strukturelle Risiken sichtbar macht, Abhilfen erzwingt und Verantwortliche bei Verzögerungen zur Rechenschaft zieht. Diese Frage ist bislang offen – und sie verdient eine dokumentierte Antwort statt einer parteipolitischen Kurzformel.
Fazit
Kein IT-Grundschutz, keine Zertifizierung und kein SOC kann garantieren, dass eine moderne Verwaltung nie kompromittiert wird. Ein realistisches Sicherheitsziel lautet anders: Angriffe sollen schwerer werden, früh erkannt, in ihrer Ausbreitung begrenzt und mit beherrschbaren Folgen überstanden werden. Gemessen daran wirft der Berliner Fall erhebliche Fragen auf. Mehrtägige unbemerkte Aktivität, massiver Datenabfluss, veröffentlichte Zugangsdaten und die lange Dauer der Schadenssichtung passen nur schwer zu dem Anspruch einer durchgehend reifen, präventiven Sicherheitssteuerung.
Die politisch wichtigste Konsequenz wäre deshalb nicht noch ein Strategiepapier, sondern Transparenz über Reifegrade, offene Hochrisiken und ihre Behandlung. Berlin sollte nach Abschluss der Forensik einen unabhängigen Post-Incident-Bericht vorlegen: mit Angriffsweg, Detektionslücken, organisatorischen Ursachen, Entscheidungswegen, Zeitachsen, Maßnahmen, Verantwortlichen und überprüfbaren Fristen. Nur dann lässt sich beurteilen, ob aus dem Angriff ein besseres Sicherheitsniveau entsteht – oder lediglich ein weiterer Krisenzyklus, nach dem die strukturellen Defizite in neuen Dokumenten beschrieben werden. Und Berlin sollte sich intensiv mit den Anforderungen an ein wirksames Risikomanagement beschäftigen.
