BERLINER DATENDIEBSTAHL. DER ANGRIFF TRAF DEN ÜBERGANG.

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.

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.

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.

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.

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.

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.

Damit bekommt das Wort Übergang eine eigentümliche Bedeutung. Normalerweise bezeichnet es den begrenzten Zustand zwischen einem Ausgangspunkt und einem Ziel. Organisationen können einen solchen Zwischenzustand jedoch so organisieren, dass er selbst dauerhaft anschlussfähig wird. Das Ziel muss dafür weder aufgegeben noch umdefiniert werden. Es kann vollständig bestehen bleiben, während seine noch ausstehende Erreichung in immer neue operative Schritte zerfällt.

Berlin kann weiter zentralisieren. Das ITDZ kann weitere Rechner übernehmen. Behörden können weitere Gebäude vorbereiten und weitere Module migrieren. All das kann sinnvoll und notwendig sein. Der entscheidende Unterschied liegt woanders: Der Abstand zum ursprünglichen Ziel muss nicht mehr als außergewöhnlicher Zustand eines unvollendeten Transformationsprogramms behandelt werden. Er kann als reguläre Arbeit weiterexistieren.

Der Angriff traf deshalb nicht nachweislich die Ursache einer gescheiterten Zentralisierung. Er traf etwas organisationsdiagnostisch Interessanteres: einen Übergang, der lange genug gedauert hatte, um selbst Teil des Betriebs zu werden.