Cyberangriff auf den Berliner Senat: Incident Response ohne Asset-Inventar

Fehlendes Asset-Inventar hat den Berliner Senat im August 2026 teuer bezahlt: Die Senatsverkehrsverwaltung meldete den Datenabfluss erstmals am 7. August 2026 intern. Vom Netz getrennt wurden die betroffenen Behörden erst am 14. August, sieben Tage nach der internen Meldung. Was in diesem Zeitfenster abfloss und welche Systeme kompromittiert waren, konnte der Berliner Senat noch Wochen danach nicht vollständig beantworten.

IT Asset Management in Behörden: Was ein Asset-Inventar ist

Ein IT-Asset-Inventar ist die vollständige, gepflegte Bestandsaufnahme aller Informationswerte einer Organisation: Hardware, Software, Dienste, Datenkategorien und die dazugehörigen Eigentümer. ISO 27001 fordert dieses Inventar in Anhang A.5.9 als Kontrollmaßnahme. Ohne es bleibt im Angriffsfall unklar, welche Systeme betroffen sind und welche personenbezogenen Daten abgeflossen sein könnten.

Containment im Blindflug

Berlins Chief Digital Officer Florian Hauer sagte am 24. August 2026 im Innenausschuss des Abgeordnetenhauses: „Das Landesnetz ist groß, wir sind überrascht, wie groß es ist." Der Satz fiel zehn Tage nach der Netztrennung, mitten im Krisenmodus.

Das ist kein Kommunikationsunfall. Es beschreibt ein strukturelles ISMS-Problem. Wer im Ernstfall mit dem Scannen des eigenen Netzes beginnt, hat das Asset-Inventar nicht gepflegt, bevor der Angriff kam. Genau das ist der Unterschied zwischen geordnetem Containment und reaktivem Stochern.

Die materiellen Folgen waren spürbar. Über 50.000 Berliner Haushalte warteten auf Wohngeldzahlungen. Leistungen aus dem Bildungs- und Teilhabepaket stockten. Der Bezirk Steglitz-Zehlendorf richtete ein Notfallportal ein, über das Betroffene Zahlungen beantragen konnten; als äußerste Rückfalloption waren auch Bargeldzahlungen vorgesehen. Mitarbeiter wichen auf private Internetverbindungen aus. Damit schufen sie neue Angriffsflächen.

Die Senatsverkehrsverwaltung meldete den Datenabfluss am 7. August 2026 intern. Die Netztrennung erfolgte erst am 14. August. Warum die Behörde sieben Tage nicht reagierte, blieb unklar.

Am 26. August räumte die Senatskanzlei den Abfluss weiterer Daten ein, darunter möglicherweise personenbezogene Daten. Zuvor hatte sie wiederholt betont, keine sensiblen Daten seien betroffen. Die Korrektur kam zwölf Tage nach der Netztrennung.

IT-Sicherheitsexperte Manuel Atug, Sachverständiger der Bundesregierung und AG KRITIS, fasste das Kommunikationsproblem so zusammen: „Nur eine Pressemitteilung zu veröffentlichen, in der man sagt, wir können nichts sagen und dürfen nichts sagen, das zeigt, dass die Krisenkommunikation nicht sehr gut aufgestellt ist." Atug vermisste eine solche FAQ-Seite mit Zeitstempel-Updates.

NIS2-Meldepflicht und DSGVO: Welche Fristen gelten?

Nach einem Vorfall laufen zwei Fristensysteme parallel: NIS2 (§ 32 BSIG) verlangt eine Frühwarnung binnen 24 Stunden und eine Vorfallsmeldung binnen 72 Stunden an das BSI beziehungsweise das zuständige CSIRT, die DSGVO eine Meldung binnen 72 Stunden an die Datenschutzaufsicht. Beide starten mit der Kenntnisnahme.

DSGVO Art. 33 Abs. 1 verlangt eine Meldung an die zuständige Aufsichtsbehörde „unverzüglich und möglichst binnen 72 Stunden" nach Kenntnisnahme. Ohne vollständiges Asset-Inventar lässt sich der Kreis betroffener Datensätze (im Berliner Fall Wohngelddaten mit Adress-, Sozial- und Finanzdaten) nicht fristgerecht eingrenzen.

Alle Fristen laufen ab Kenntnisnahme. Wer nicht weiß, was im Netz liegt, weiß auch nicht, wann er Kenntnis von einem Abfluss hat.

Das BSI ordnet die NIS-2-Anforderung zur Verwaltung von IKT-Systemen, -Produkten und -Prozessen direkt ISO 27001 A.5.9 zu. Das Berliner Landesnetz fällt als öffentliche Verwaltungsinfrastruktur in den Anwendungsbereich dieser Regelung.

CMDB und IT-Asset-Management: sechs Schritte zum Inventar

Ein Inventar entsteht nicht im Krisenmodus. Es muss stehen, bevor der Angriff kommt. Für den Aufbau gilt eine klare Reihenfolge:

1. Automatisierter Netzwerkscan als Startpunkt. Discovery-Tools liefern den Ist-Stand. Die Ergebnisse fließen in eine Configuration Management Database (CMDB).
2. Klassifizierung nach Schutzbedarf. Welche Systeme verarbeiten personenbezogene Daten? Welche sind für Kernprozesse kritisch? BSI-Grundschutz-Kataloge und die Schutzbedarfsfeststellung nach ISO 27001 liefern den Rahmen.
3. Asset-Owner-Zuweisung. Jedes System braucht eine benannte Person, die für Patch-Stand und Verfügbarkeit verantwortlich ist. Fehlt diese Zuweisung, bleibt das Inventar eine Momentaufnahme ohne Wartung.
4. Kontinuierlicher Abgleich. Schatten-IT wächst schnell. Discovery-Tools sollten automatisiert laufen und neu erscheinende Systeme melden, bevor sie zum blinden Fleck werden.
5. Verknüpfung mit dem Notfall-Playbook. Ein Incident-Response-Plan ist nur ausführbar, wenn er auf das aktuelle Inventar zeigt. Fehlt diese Verbindung, bleibt Containment reaktiv, wie der Berliner Fall zeigt.
6. Tabletop-Übung mit Kommunikations-Templates. DSGVO-Meldepflichttexte und öffentliche Statements müssen vorbereitet sein, bevor der Ernstfall eintritt. Wer sie im Stress formuliert, macht Fehler.

Behörden ohne eigenen Informationssicherheitsbeauftragten können diese Aufgabe an einen externen Informationssicherheitsbeauftragten übertragen. Die fachlichen Grundlagen zum IT Asset Management sind im Wiki-Eintrag beschrieben.

Einordnung

Der Berliner Vorfall steht nicht allein. Im BSI-Jahresbericht 2025 verzeichnet das Bundesamt einen Anstieg täglich neu entdeckter Schwachstellen von 24 Prozent gegenüber dem Vorjahr. BSI-Präsidentin Claudia Plattner fasste die Angriffslogik knapp zusammen. Cyberkriminelle „dringen überall dort ein, wo es ihnen möglich ist, und eruieren erst danach den Schaden".

Aus dieser Logik folgt: Das Asset-Inventar ist keine Zertifizierungsübung, sondern operative Voraussetzung. Geordnetes Containment setzt voraus, dass bekannt ist, welche Systeme existieren. Die DSGVO-Meldung setzt voraus, welche Daten darauf verarbeitet werden. Beides ist ohne gepflegtes Asset-Inventar nicht leistbar, und der Berliner Senat musste das lernen, während der Krisenstab tagte.

Zur kommunalen Perspektive: Informationssicherheit in Kommunen: fünf Erkenntnisse aus vergangenen Vorfällen und Incident Response im Wiki beschreiben weiterführende Grundlagen.

Quellen

• Tagesspiegel: Hacker waren sieben Tage unbemerkt im Berliner IT-Netz (26.08.2026)
• Senatskanzlei Berlin: Senatsverwaltungen wieder online (23.08.2026)
• rbb24: Manuel Atug zum Stand der Cybersicherheit in Berliner Senatsverwaltungen (19.08.2026)
• rbb24: Hackerangriff führt zu Einschränkungen bei vielen Bürgerdiensten (21.08.2026)
• BSI: NIS-2-Anforderungen Asset-Management und ISO 27001 A.5.9
• BSI: Jahresbericht 2025: Lage der IT-Sicherheit in Deutschland (11.11.2025)
• Golem.de: Nach Hackerangriff - Berliner Senat überrascht über Größe des IT-Systems (26.08.2026)