1,44 Millionen Dateien aus einer IT, die längst zentral sein sollte
Warum war ein Teil der Berliner Verwaltungs-IT nach zehn Jahren Zentralisierungsplänen noch dezentral – und wer kann bei einem landesweiten Sicherheitsvorfall verbindlich handeln?
Im August 2026 dringen Angreifer in Teile der Berliner Verwaltungs-IT ein. Später werden 1,44 Millionen Dateien mit einem Umfang von rund 5,8 Terabyte veröffentlicht. Betroffen ist ein IT-Bereich, den zwei Senatsverwaltungen noch immer in eigener Verantwortung betrieben. Eigentlich sollte genau diese dezentrale Struktur seit Jahren verschwinden. Berlin hatte seine Verwaltungs-IT bereits 2016 zentralisieren wollen. Zehn Jahre später ist die Migration nicht abgeschlossen. Das dafür geschaffene Programm dagegen schon.
Zwischen dem 7. und 12. August 2026 bewegen sich Angreifer zunächst unbemerkt durch Teile der Berliner Verwaltungsnetze. Betroffen sind Bereiche der Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen sowie der Senatsverwaltung für Mobilität, Verkehr, Klimaschutz und Umwelt. Als die Verwaltung den Angriff entdeckt, sind bereits große Datenmengen kopiert worden. Am 14. August werden die betroffenen Bereiche isoliert, wenige Tage später wird der Vorfall öffentlich.
Was zunächst wie ein begrenzter IT-Sicherheitsvorfall aussieht, wächst in den folgenden Wochen. Die Tätergruppe Rhysida fordert 30 Bitcoin Lösegeld und behauptet, rund 5,7 Terabyte Daten erbeutet zu haben. Berlin zahlt nicht. Nach Ablauf des Ultimatums werden große Datenbestände veröffentlicht. In der Berichterstattung ist schließlich von 1,44 Millionen Dateien mit einem Umfang von rund 5,8 Terabyte die Rede. Darunter befinden sich personenbezogene Informationen von Beschäftigten und möglicherweise von Bürgerinnen und Bürgern. Am 6. September folgt ein weiteres Datenpaket, in dem nach Angaben des Senats auch Zugangsdaten enthalten sind. Die forensische Untersuchung läuft weiter.
Der Angriff
Man könnte diesen Fall deshalb problemlos als Geschichte über Ransomware erzählen: über Schwachstellen, gestohlene Zugangsdaten, Erpressung und die Frage, welche Informationen tatsächlich abgeflossen sind. Uns fiel bei der Rekonstruktion allerdings eine andere Information auf. Der Angriff führte in einen Teil der Berliner Verwaltungs-IT, der zehn Jahre nach Beginn einer großen Zentralisierung noch immer nicht vollständig in den zentralen Betrieb überführt war.
Die Vorgeschichte
Damit bekam der Angriff eine Vorgeschichte.
2016 schuf Berlin mit dem E-Government-Gesetz die Grundlage dafür, die Betriebsverantwortung für wesentliche Teile der Verwaltungs-IT beim IT-Dienstleistungszentrum Berlin, dem ITDZ, zu konzentrieren. Verfahrensunabhängige IT und Basisdienste sollten standardisiert werden, die Behörden waren grundsätzlich zur Abnahme verpflichtet. Das war nicht nur ein Modernisierungsversprechen. Die Betriebsverantwortung sollte tatsächlich von einzelnen Behörden zum zentralen Dienstleister wechseln.
2018 begann mit OneIT@Berlin die operative Umsetzung. Die Migration war modular organisiert. LAN, Telefonie, BerlinPC, Drucker und schließlich die Übernahme der Betriebsverantwortung konnten unterschiedliche Umsetzungsstände besitzen. Das ist zunächst sinnvoll: Eine große Verwaltung lässt sich nicht in einem einzigen Schritt technisch umbauen. Es hatte allerdings eine Konsequenz. Eine Behörde konnte bei einzelnen Modulen bereits weit fortgeschritten sein, während ihre Arbeitsplatz-IT insgesamt noch nicht zentral betrieben wurde.
2022 sollte das Vorhaben schneller werden. Der Senat formulierte konkrete Ziele: Bis Ende 2024 sollten etwa 8.000 Arbeitsplätze der Senatsverwaltungen, bis Ende 2026 insgesamt rund 15.000 Arbeitsplätze in einheitliche Standards und den Betrieb des ITDZ überführt werden. Als Gründe für die Zentralisierung nannte Berlin unter anderem Wirtschaftlichkeit, Benutzerfreundlichkeit und höhere Sicherheit.
Der Fortschritt
Wir haben deshalb zunächst nachgesehen, wie weit Berlin auf diesem Weg gekommen war.
Im Juni 2023 meldete das Land das Landesamt für Flüchtlingsangelegenheiten als erste vollständig umgestellte Behörde. Im Juni 2025 folgte der Rechnungshof als erste vollständig migrierte oberste Landesbehörde. Bemerkenswert daran war nicht nur der Zeitpunkt. Der Rechnungshof war zur Umstellung nicht einmal verpflichtet, sondern hatte sich freiwillig beteiligt. Mitte 2025 wurde damit erstmals eine oberste Landesbehörde als vollständig standardisiert gemeldet – ein halbes Jahr nach dem Zeitpunkt, zu dem nach dem Beschleunigungsplan bereits rund 8.000 Arbeitsplätze der Senatsverwaltungen überführt sein sollten.
Die Fortschrittszahlen erzählen anschließend mehrere Geschichten gleichzeitig. Ende 2025 waren ungefähr 13.500 Arbeitsplätze beim Modul Telefon umgestellt, rund 7.800 beim LAN und etwa 2.100 beim BerlinPC einschließlich Drucken. Insgesamt betrieb das ITDZ zu diesem Zeitpunkt rund 6.000 Arbeitsplatzrechner für die abnahmepflichtigen Behörden. Diese Zahlen lassen sich nicht addieren. Ein Arbeitsplatz konnte bei Telefon oder LAN bereits migriert sein und trotzdem noch keinen BerlinPC besitzen oder vollständig in die Betriebsverantwortung des ITDZ übergegangen sein.
Damit wird der Fortschritt nicht falsch. Tausende Anschlüsse wurden tatsächlich umgestellt, Rechner tatsächlich übernommen und Behörden tatsächlich migriert. Aber der Zustand des Gesamtvorhabens lässt sich aus den einzelnen Erfolgsmeldungen immer schwerer intuitiv ablesen. Das politische Versprechen beschreibt einen standardisierten zentralen Betrieb. Die operative Berichterstattung beschreibt zunehmend die Fortschritte der einzelnen Module.
Ein Teil der Verzögerung lässt sich ziemlich handfest erklären. Der offizielle Umsetzungsbericht nennt als Risiko eine fehlende „Migrationsreadiness“. Dahinter standen nicht nur Softwareprobleme. Gebäude brauchten geeignete Verkabelung, Netzanschlüsse und technische Räume; Standorte mussten vorbereitet, Umbauten geplant und unterschiedliche Beteiligte koordiniert werden. Eine parlamentarische Unterlage von September 2025 führte 60 Standorte in der Realisierungsplanung für 2024 und 2025. Sechs Anschlüsse waren in Betrieb, 54 befanden sich noch in Umsetzung oder Klärung. Für die Herstellung der Migrationsbereitschaft gab es keinen zentralen Gesamtzeitplan.
Spätestens an diesem Punkt war OneIT@Berlin nicht mehr bloß ein IT-Projekt. Die Zentralisierung hing an Gebäudetechnik, Immobilien, Beschaffung, Finanzierung, Fachverfahren, lokalen Vorarbeiten, Behördenautonomie und der Frage, wer zu welchem Zeitpunkt überhaupt bereit war, in den zentralen Betrieb zu wechseln.
Das erklärt, warum eine solche Transformation schwierig werden kann. Es erklärt noch nicht, was danach geschah.
Die Neuausrichtung
Im September 2025 diskutierte das Berliner Abgeordnetenhaus eine Neuausrichtung von OneIT@Berlin. Die Senatskanzlei erklärte ausdrücklich, Zentralisierung und BerlinPC seien in der Vergangenheit nicht so schnell umgesetzt worden wie erhofft. Die operative Verantwortung sollte deshalb ab 2026 weitgehend an das ITDZ übergehen. Die einzelnen Behörden sollten ihre Migration künftig unmittelbar mit dem ITDZ bearbeiten. Gleichzeitig blieb die ministerielle Steuerung und Überwachung bei der Senatskanzlei.
Der offizielle Umsetzungsbericht formuliert die Konsequenz noch deutlicher. OneIT@Berlin werde nach einer Übergangsphase für die bereits in der Roll-out-Planung befindlichen Behörden aufgelöst. Die operative Zentralisierung werde zur Linienaufgabe des ITDZ. Einführung und Betriebsüberführung sollten die Behörden zukünftig eigenständig direkt mit dem ITDZ umsetzen. Gleichzeitig sollte erst noch ein IT-Standard-Controlling aufgebaut werden, das den Standardisierungs- und Zentralisierungsgrad der Behörden sichtbar macht.
Hier begann der Fall für uns seine Form zu verändern.
Berlin hatte die Zentralisierung nicht aufgegeben. Die Verwaltung hatte auch nicht aufgehört zu migrieren. Im Gegenteil: Es gab ein erprobtes Vorgehensmodell, einen Betriebsvertrag, Finanzierungsmodelle und reale Migrationserfahrung. Aus Sicht der Senatskanzlei waren damit Grundlagen geschaffen, auf denen die weitere Umsetzung in der Linie fortgesetzt werden konnte. Diese Gegenhypothese muss ernst genommen werden: Ein Programm muss nicht so lange existieren, bis der letzte Arbeitsplatz umgestellt ist. Es kann sinnvoll sein, eine entwickelte Fähigkeit irgendwann in den Regelbetrieb zu überführen.
Nur entstand dabei eine bemerkenswerte Verschiebung. Vorher gab es ein gemeinsames Zentralisierungsprogramm mit Roll-out-Planung und einem politisch formulierten Zielzustand. Danach gab es einen zentralen Dienstleister und einzelne Behörden, die ihre noch ausstehenden Migrationen direkt miteinander organisieren sollten. Aus einem zeitlich begrenzten Transformationsvorhaben wurde eine fortlaufende Betriebsaufgabe. Das Ziel blieb dasselbe; verändert wurde die Organisationsform, in der sein noch ausstehender Teil bearbeitet wurde.
An dieser Stelle mussten wir deshalb nicht mehr nur fragen, warum die Migration so lange dauerte. Interessanter war, was mit einem nicht erreichten Ziel geschieht, wenn die Organisation, die für seine Transformation geschaffen wurde, vorher endet.
Denn die verbleibende Differenz verschwindet dadurch nicht. Sie wechselt ihren organisatorischen Ort. Eine Behörde kann im nächsten Jahr migriert werden, ein Gebäude später migrationsbereit werden, ein weiterer BerlinPC in den zentralen Betrieb wechseln. Jeder dieser Schritte bleibt realer Fortschritt. Gleichzeitig verliert der noch nicht erreichte Gesamtzustand einen Teil seines Ausnahmecharakters. Er wird zu einer Aufgabe, die im nächsten Planungszeitraum weiterbearbeitet werden kann.
Der August 2026
Dann kam der August 2026.
Die Senatsverwaltung für Stadtentwicklung war in den Umsetzungsunterlagen zwar bei einzelnen Maßnahmen aufgeführt. Als vollständig mit dem Basisdienst ausgestattet und in den ITDZ-Betrieb überführt wurden für 2025 jedoch nur der Rechnungshof und die Senatsverwaltung für Wirtschaft, Energie und Betriebe genannt. Die Zentralisierung selbst war also weiterhin unvollständig.
Der Cyberangriff liefert uns trotzdem nicht den bequemen Schluss, dass die unvollständige Zentralisierung seine Ursache war. Ein zentral betriebener Dienst kann ebenfalls kompromittiert werden. Ein technischer Abschlussbericht, der belegen würde, dass gerade eine vollständige ITDZ-Migration die ausgenutzte Schwachstelle verhindert hätte, liegt öffentlich weiterhin nicht vor. Die laufende forensische Untersuchung ist auch Anfang September noch nicht abgeschlossen.
Diese Kausalität brauchen wir für den Fall auch nicht.
Der Angriff tut etwas anderes: Er macht einen Zustand wieder sichtbar, der organisatorisch längst bearbeitbar geworden war. Zehn Jahre nachdem Berlin begonnen hatte, die dezentrale Betriebsverantwortung seiner Verwaltungs-IT zu verändern, existierten weiterhin nicht vollständig überführte Bereiche. Gleichzeitig war das dafür geschaffene Transformationsprogramm bereits auf dem Weg in seine Auflösung und die verbleibende Migration in den normalen Betrieb überführt worden. Der Angriff beweist nicht, dass die unvollständige Zentralisierung ihn verursacht hat. Diese Kausalität geben die vorliegenden Quellen nicht her.
Er zeigt aber einen Zustand, der zehn Jahre nach Beginn der Zentralisierung noch existierte: Teile der Verwaltungs-IT liefen weiterhin dezentral, während das dafür geschaffene Transformationsprogramm bereits in den Regelbetrieb überführt wurde.
Die zweite Spur
Anfang September kam eine zweite Spur hinzu. Nach dem Angriff beauftragte die Senatskanzlei CrowdStrike mit der Untersuchung. Der Bezirk Lichtenberg verweigerte der Firma den Zugriff auf seine Server und verwies unter anderem auf weitreichende Zugriffsrechte und Datenschutzrisiken.
Damit zeigt sich die Fragmentierung nicht nur im Zustand vor dem Angriff, sondern auch bei der Reaktion darauf.
Die offene Frage dieser Akte lautet deshalb nicht, ob Zentralisierung jeden Angriff verhindert hätte.
Sie lautet: Wer kann bei einem landesweiten Sicherheitsvorfall verbindlich handeln, solange technische Betriebsverantwortung und organisatorische Entscheidungsmacht noch auf mehrere Stellen verteilt sind?
NOMOS · Diagnose
Primärmechanismus offen
Rekonstruierter Organisationsbefund: Berlin hatte die Zentralisierung wesentlicher Teile seiner Verwaltungs-IT bereits 2016 gesetzlich angelegt und mit OneIT@Berlin organisatorisiert. Konkrete Migrationsziele wurden nicht vollständig innerhalb der vorgesehenen Zeit erreicht. Anschließend wurde entschieden, OneIT@Berlin als Programm aufzulösen und die verbleibende operative Zentralisierung in den Linienbetrieb des ITDZ und die direkte Zusammenarbeit mit den einzelnen Behörden zu überführen.
Die bislang nicht abschließend klassifizierte Operation besteht darin, dass ein befristetes Transformationsvorhaben seinen Zielzustand nicht erreicht und die verbleibende Zielerreichung anschließend in den regulären Betrieb überführt wird. Dadurch bleibt das Ziel formal bestehen, während sein Nichterreichen vom Ausnahmezustand zum dauerhaft bearbeitbaren Betriebszustand werden kann.
021 Normalisierung passt als Verdichtung stark: Der ursprünglich temporäre Zwischenzustand wird dauerhaft organisatorisch anschlussfähig. Die Abweichung vom Ziel muss nicht verschwinden; sie kann als reguläre Aufgabe weiterbearbeitet werden.
009 Verfahrensmigration ist verwandt: Die Zentralisierung wird in Migrationsmodule, Readiness, Standortplanung und bilaterale Umsetzung übersetzt. Das erklärt Teile der Bearbeitung, aber nicht den entscheidenden Wechsel von der Sonderorganisation in den Regelbetrieb.
026 Zielersatz trägt nicht ausreichend: Gerade weil das Zentralisierungsziel nicht durch ein anderes Ziel ersetzt wird, reicht dieses Pattern nicht aus.
015 Fortschrittssimulation ist als mögliche Ausdrucksform denkbar, aber nicht belegt: Modulstände können die Lesbarkeit des Gesamtfortschritts erschweren. Die einzelnen Fortschritte sind jedoch real; eine bloße Simulation ist nicht nachgewiesen.
Ghost Log
Zehn Jahre nach dem Beschluss zur Zentralisierung war die Zentralisierung noch nicht abgeschlossen. Das Programm, das sie organisieren sollte, hatte dieses Problem bereits gelöst: Es wurde beendet. Die Migration läuft weiter.
„Vielleicht ist genau das der Moment, in dem aus einem Übergang ein Zustand wird."
NEUE EVIDENZ Lichtenberg verweigert CrowdStrike den Serverzugriff
Neue Evidenz
Nach dem Hackerangriff beauftragt die Berliner Senatskanzlei CrowdStrike mit der Spurensuche. Der Bezirk Lichtenberg lehnt den Einsatz auf seinen Servern ab und verweist unter anderem auf weitreichende Zugriffsrechte und Datenschutzrisiken.
Auswirkung auf die Rekonstruktion
Die organisatorische Fragmentierung zeigt sich nun nicht nur im Zustand vor dem Angriff, sondern auch bei der Reaktion darauf: Eine zentral beauftragte Maßnahme kann auf Bezirksebene zurückgewiesen werden.
Auswirkung auf Verdacht / Hypothese
Die Spur wird gestärkt, ohne die Entscheidung Lichtenbergs zu bewerten. Zu klären bleibt, wer bei einem landesweiten Sicherheitsvorfall verbindlich über Maßnahmen in dezentral betriebenen Systemen entscheiden kann.
