Meldepflichten bei Sicherheitsvorfällen im Telekommunikationssektor

Problem in der Praxis

In vielen TK-Unternehmen sind die Meldepflichten organisatorisch getrennt: die TKG-Meldung beim Sicherheitsbeauftragten, die DSGVO-Meldung beim Datenschutzbeauftragten, die NIS2-Themen verteilt zwischen IT, Security und Recht. Im Ernstfall arbeiten diese Rollen nicht synchron. Es entstehen widersprüchliche Sachverhalte, doppelte Behördenrückfragen und verspätete Meldungen.

Verschärfend ist, dass sich die rechtlichen Anker bewegen. Mit der NIS2-Umsetzung wurden TK-spezifische Pflichten unmittelbar in das TKG verzahnt; die §§ 165 und 167 TKG wurden Ende 2025 angepasst, und eine überarbeitete Fassung des BNetzA-Sicherheitskatalogs befand sich zuletzt in öffentlicher Konsultation, deren Veröffentlichungsstand am aktuellen Amtsblatt der BNetzA zu prüfen ist. Wer seinen Prozess auf einen veralteten Paragraphenstand oder eine alte Katalogfassung stützt, meldet formal falsch.

CISO-Einordnung

Der CISO sollte die Meldelandschaft als Geflecht aus drei Regimen mit unterschiedlicher Stoßrichtung verstehen:

• TKG (§§ 165 ff.): sektorspezifisches Sonderregime für die Sicherheit von TK-Netzen und -Diensten. Aufsicht ist die BNetzA; die Meldung eines erheblichen Sicherheitsvorfalls geht an BNetzA und BSI.
• NIS2 / BSIG: allgemeines Cybersicherheitsregime für den Sektor digitale Infrastruktur. Deutschland hat NIS2 umgesetzt und TK-spezifische Pflichten direkt im TKG geregelt; das BSI ist über das Katalog-Einvernehmen und als Meldeadressat eingebunden.
• DSGVO: datenschutzrechtliche Meldepflicht bei Verletzungen des Schutzes personenbezogener Daten gegenüber der Datenschutzaufsicht, je nach Risiko mit Benachrichtigung der Betroffenen.

Die Schwellen sind nicht deckungsgleich. Das TKG knüpft an einen "erheblichen Sicherheitsvorfall" an, also an eine schwerwiegende Betriebsstörung oder Beeinträchtigung Dritter; die DSGVO an die Verletzung des Schutzes personenbezogener Daten. Ein Vorfall kann beides auslösen, nur eines oder keines. Diese Abgrenzung sauber zu treffen ist die Kernleistung.

Umsetzungsperspektive

Ein belastbarer Meldeprozess lässt sich als kleiner, betreibbarer Regelkreis aufbauen:

• Einheitliche Vorfallaufnahme: Jeder potenzielle Vorfall wird zentral erfasst; eine Quelle der Wahrheit verhindert divergierende Darstellungen.
• Schwellen- und Triage-Logik: Eine vorab definierte Bewertung klärt, ob ein erheblicher Sicherheitsvorfall im Sinne des TKG vorliegt, ob eine NIS2-relevante Einrichtung betroffen ist und ob personenbezogene Daten verletzt sind. Daraus ergeben sich die Adressaten.
• Adressaten-Matrix: Hinterlegt ist, wer über welchen Kanal mit welchem Mindestinhalt meldet (BNetzA und BSI für die TKG-Meldung, Datenschutzaufsicht für die DSGVO-Meldung).
• Gestufte Meldelogik: TKG und NIS2 folgen einer Systematik aus zeitnaher Erstmeldung, detaillierter Bewertung und Abschlussmeldung. Die konkreten Fristen sind am aktuell geltenden Gesetzestext zu verifizieren.
• Nachweisspur: Jede Meldung, Behördenrückfrage und Statusänderung wird protokolliert.

Die inhaltliche Basis liefert das Sicherheitskonzept nach § 166 TKG. Die ISO/IEC 27001 dient nur als Referenz für das zugrunde liegende Managementsystem.

Typische Fehler

1. TKG- und DSGVO-Meldung werden als dieselbe Pflicht behandelt, obwohl Schwelle, Adressat und Zweck verschieden sind.
2. Es wird nur an die BNetzA gemeldet, obwohl die TKG-Meldung zugleich an das BSI geht.
3. Fristen werden aus dem Gedächtnis gesetzt statt am aktuellen TKG-Text und am geltenden BNetzA-Katalog geprüft.
4. Der Prozess stützt sich auf einen überholten Paragraphenstand und ignoriert die NIS2-bedingten Änderungen.
5. Ohne zentrale Vorfallaufnahme melden mehrere Rollen abweichende Sachverhalte; die Abschlussmeldung wird vergessen.

Risiken und Trade-offs

Ein zu eng definierter Prozess meldet zu selten und riskiert Pflichtverletzungen; ein zu weiter überlastet Behörden und Team mit Meldungen unterhalb der Erheblichkeitsschwelle. Die Schwellenlogik ist damit der sensibelste Hebel. Hinzu kommt der Trade-off zwischen Geschwindigkeit und Präzision: Erstmeldungen müssen schnell heraus, sind aber unvollständig, detaillierte Meldungen brauchen belastbare Fakten. Eine gemeinsame Faktenbasis ist Risikosteuerung, weil parallele Meldungen an BNetzA, BSI und Datenschutzaufsicht sonst auseinanderlaufen.

Entscheidungspunkte

• Welche Schwellen grenzen einen "erheblichen Sicherheitsvorfall" nach TKG von meldefreien Störungen ab?
• Wer trägt im Vorfall die Gesamtverantwortung, und wie sind Sicherheits- und Datenschutzbeauftragter verzahnt?
• Wie halten wir Fristen und Meldekanäle dauerhaft auf dem aktuellen TKG-Stand und Katalog?
• Welche Vorfallarten erfordern eine parallele DSGVO-Meldung?

Praktische Empfehlungen

1. Etablieren Sie eine zentrale Vorfallaufnahme als einzige Faktenquelle für alle Meldewege.
2. Hinterlegen Sie eine schriftliche Schwellen- und Adressaten-Matrix, die TKG-, NIS2- und DSGVO-Pflichten trennt und ihre Überschneidungen sichtbar macht.
3. Verankern Sie die TKG-Meldung fest als Doppelmeldung an BNetzA und BSI.
4. Pflegen Sie Fristen und Meldekanäle als Verweise auf den aktuellen TKG-Text und Katalog, nicht als feste Werte im Prozessdokument.
5. Üben Sie den Meldeprozess regelmäßig durch und verbinden Sie ihn mit dem Sicherheitskonzept nach § 166 TKG.

Relevante Normreferenzen

• TKG, Teil 10 Abschnitt 1, §§ 165 ff. (insb. § 165 technische/organisatorische Schutzmaßnahmen, § 166 Sicherheitsbeauftragter und Sicherheitskonzept, § 167 Katalog von Sicherheitsanforderungen, § 168 Meldung eines Sicherheitsvorfalls): amtliches Werk, frei zitierbar mit Quellenangabe. Verbindlich ist der aktuell geltende Gesetzestext.
• BNetzA-"Katalog von Sicherheitsanforderungen" nach § 167 TKG: amtliche Allgemeinverfügung, frei zitierbar mit Quellenangabe. Maßgeblich ist die jeweils festgestellte Fassung; eine überarbeitete Fassung ist in Konsultation.
• NIS2-Richtlinie samt Umsetzungsrecht und DSGVO: öffentliche Rechtsquellen; Schwellen und Fristen am jeweiligen Text verifizieren.
• ISO/IEC 27001: Referenz für das zugrunde liegende Managementsystem (reference-only, keine Control-Listen).