TKG-Sicherheitskatalog im Zusammenspiel mit NIS-2, KRITIS und ISO 27001: eine CISO-Roadmap

Problem in der Praxis

In der Praxis werden die Regime nacheinander entdeckt: Erst lebt das TKG-Sicherheitskonzept für die BNetzA, dann kommt das NIS2-Umsetzungsgesetz, dann fragt jemand nach KRITIS. Jede Welle erzeugt ihr eigenes Dokument, ihre eigene Meldelogik und ihren eigenen Ansprechpartner.

Das führt zu Reibungen. Begriffe werden vermischt: Die NIS2-Kategorien "besonders wichtige" und "wichtige Einrichtungen" sind seit dem NIS2-Umsetzungsgesetz teilweise direkt im TKG verankert, dürfen aber nicht mit dem allgemeinen BSIG-Auffangregime zusammengeworfen werden. Zuständigkeiten werden verwechselt: Im TK-Sektor ist die BNetzA die sektorale Sicherheitsaufsicht; das BSI ist nur über das Einvernehmen beim Katalog (gemeinsam mit der oder dem BfDI) und als Meldeadressat eingebunden. Spätestens bei einem Vorfall oder einer BNetzA-Prüfung zeigt sich, ob ein integriertes Steuerungsmodell vorliegt oder nur ein Stapel paralleler Artefakte.

CISO-Einordnung

Sinnvoll ist ein Schichtenmodell statt konkurrierender Regelwerke:

• Sektorspezifische TK-Sicherheit: TKG §§ 165 ff. mit dem BNetzA-Katalog nach § 167. Aufsicht: BNetzA.
• Cyber-/IT-Sicherheit nach NIS2: für TK unmittelbar in das TKG verzahnt. Das TKG ist insoweit nicht nur faktisch, sondern rechtlich das führende Regime, weil § 28 Absatz 5 Nummer 1 BSIG die entsprechenden allgemeinen BSIG-Pflichten für TK-Betreiber ausnimmt. Die Freistellung ist enumeriert, nicht pauschal: Der Status als besonders wichtige oder wichtige Einrichtung bleibt, und die Registrierungspflichten der §§ 33 und 34 BSIG werden nicht ausgeschlossen. Sie entfällt zudem, soweit die Einrichtung weitere kritische Anlagen nach § 2 Nummer 22 BSIG betreibt oder aufgrund weiterer Tätigkeiten einer der in Anlage 1 oder 2 bestimmten Einrichtungsarten zuzuordnen ist; für den Energiefall der Nummer 2 tritt hinzu, dass Absatz 5 keine Anwendung findet, wenn der Betrieb der Energieanlage im Hinblick auf die gesamte Geschäftstätigkeit nur eine Nebentätigkeit darstellt. Fassungsstand am geltenden BSIG prüfen.
• Physische Resilienz: über das KRITIS-Recht (All-Gefahren-Ansatz), getrennt von der reinen IT-Sicherheit.

Das TKG ist seit der Novelle 2021 (in Kraft im Wesentlichen seit 01.12.2021) der zentrale Anker; die Sicherheitspflichten stehen in Teil 10: § 165 (technische/organisatorische Schutzmaßnahmen), § 166 (Sicherheitsbeauftragter und Sicherheitskonzept), § 167 (Katalog von Sicherheitsanforderungen) und § 168 (Meldung eines Sicherheitsvorfalls); sie lösen die früheren § 109/§ 109a TKG a.F. ab. Da §§ 165 und 167 zuletzt durch das NIS2-Umsetzungsgesetz (Ende 2025) geändert wurden, sind Paragraphenzuordnung und Wortlaut am geltenden Gesetzestext und am festgestellten BNetzA-Katalog zu verifizieren.

ISO/IEC 27001 ist kein weiteres Pflichtregime, sondern die Umsetzungsbasis: Risikomanagement, Rollen, Maßnahmensteuerung und Nachweisführung des ISMS bedienen alle Schichten zugleich. Ein vorhandenes ISMS ersetzt aber keine Pflicht und ist kein Zertifizierungsschema für den Katalog.

Umsetzungsperspektive

Eine knappe CISO-Roadmap folgt der Logik der TKG-Pflichten und nutzt das ISMS als Maschinenraum:

1. Betroffenheit und Scope klären. Feststellen, ob das Unternehmen Betreiber/Anbieter im Sinne des TKG ist, nach den Kriterien des Katalogs (§ 167) erhöhtes Gefährdungspotenzial aufweist und zugleich als "besonders wichtige" oder "wichtige Einrichtung" gilt. Daraus folgt die Pflichtentiefe.

2. Beauftragte und Verantwortung verankern. § 166 TKG verlangt einen Sicherheitsbeauftragten und einen in der EU ansässigen Ansprechpartner. Die Geschäftsleitung trägt seit der NIS2-Verzahnung ausdrücklich Verantwortung und Schulungspflichten. Diese Rollen gehören ins ISMS-Rollenmodell, nicht daneben.

3. Sicherheitskonzept aufsetzen und pflegen. Das Konzept nach § 166 beschreibt Netze und Dienste, Gefährdungen und Maßnahmen zur Erfüllung des § 165 und des Katalogs nach § 167; es ist der BNetzA vorzulegen und bei geänderten Bedingungen anzupassen. Methodisch deckt es sich mit der Risiko- und Maßnahmenlogik eines ISMS.

4. Maßnahmen nach Stand der Technik umsetzen. § 165 verlangt Schutz des Fernmeldegeheimnisses und personenbezogener Daten, Risikobeherrschung, bei erhöhtem Gefährdungspotenzial verpflichtende Angriffserkennung sowie Zertifizierung kritischer Komponenten vor Einsatz. Die gestaffelten Detailanforderungen ergeben sich aus dem gültigen BNetzA-Katalog.

5. Meldekette einrichten. § 168 TKG adressiert erhebliche Sicherheitsvorfälle an BNetzA und BSI; die Fristen sind an der NIS2-Logik orientiert (kurzfristige Erstmeldung, folgende Detail- und Abschlussmeldung) und im Detail dem geltenden TKG zu entnehmen. Wichtig sind eine einheitliche Vorfalldefinition und ein abgestimmter Workflow.

6. Nachweis sichern. Aus dem ISMS-Regelbetrieb sollten Nachweise als Nebenprodukt entstehen, auf die sich BNetzA-Prüfungen stützen. Die BSIG-Nachweispflicht für Betreiber kritischer Anlagen ist über § 28 Absatz 5 Nummer 1 BSIG ausgenommen, soweit keine Rückausnahme greift; wo sie greift, ist sie gesondert zu bedienen.

Typische Fehler

1. TKG, NIS2 und KRITIS als getrennte Projekte mit eigenen Dokumentenwelten führen statt als Schichten eines Managementsystems.
2. BSI und BNetzA verwechseln und die sektorale Aufsicht der BNetzA unterschätzen.
3. Das Sicherheitskonzept als einmaliges Vorlagedokument behandeln statt als gepflegtes Steuerungsartefakt.
4. ISO/IEC 27001 als Pflichtersatz missverstehen statt als Umsetzungsbasis.
5. Den Versionsstand des BNetzA-Katalogs nicht nachhalten und mit veralteten Anforderungen planen.
6. Kritische Komponenten ohne Blick auf Zertifizierungs- und Untersagungsmechanismen (Verzahnung mit dem BSIG) beschaffen.

Risiken und Trade-offs

Ein integriertes Modell spart Aufwand, kann aber sektorale Besonderheiten verwischen: Die BNetzA-Pflichten haben eine eigene Aufsichts- und Meldelogik, die nicht in einem generischen NIS2-Prozess untergehen darf. Umgekehrt erzeugt eine vollständige Trennung der Regime Doppelarbeit, widersprüchliche Nachweise und Meldekonfusion. Der Trade-off liegt zwischen Konsolidierung und sauberer Differenzierung der Vorfalldefinitionen und Aufsichtskanäle.

Zeitliches Risiko: TKG-Rechtsstand und BNetzA-Katalog sind in Bewegung. Wer auf einen überholten Stand plant, riskiert Nacharbeit; verbindliche Detailentscheidungen sind stets gegen das aktuelle TKG und die festgestellte Katalogfassung zu spiegeln.

Entscheidungspunkte

• Ist das Unternehmen Betreiber/Anbieter im Sinne des TKG und Einrichtung mit erhöhtem Gefährdungspotenzial?
• Gemeinsames ISMS für TKG, NIS2 und KRITIS oder bewusst getrennte Teilsysteme?
• Wie definieren wir einen einheitlichen "erheblichen Sicherheitsvorfall" und eine konsolidierte Meldekette an BNetzA und BSI?
• Welche Funktionen sind kritisch, und wie steuern wir die Zertifizierung der realisierenden Komponenten vor Einsatz?
• Wer überwacht laufend den Versionsstand von TKG und BNetzA-Katalog und triggert Anpassungen?

Praktische Empfehlungen

1. Erstellen Sie eine Betroffenheitsmatrix, die jede Pflicht einem Regime (TKG / NIS2-BSIG / KRITIS) und einer Aufsicht (BNetzA / BSI) zuordnet.
2. Führen Sie Sicherheitsbeauftragten, EU-Ansprechpartner und Geschäftsleitungsverantwortung im ISMS-Rollenmodell zusammen.
3. Pflegen Sie das Sicherheitskonzept nach § 166 als lebendes Dokument, gespeist aus dem ISMS-Risiko- und Maßnahmenregister.
4. Bauen Sie eine einheitliche Vorfall- und Meldelogik mit klaren Eskalationsstufen und definierten Adressaten (BNetzA und BSI) auf.
5. Nutzen Sie ISO/IEC 27001 als methodisches Rückgrat, ohne es mit der regulatorischen Pflichterfüllung gleichzusetzen, und halten Sie Katalog- und Gesetzesstand aktiv nach.

Relevante Normreferenzen

• Telekommunikationsgesetz (TKG 2021), Teil 10, insbesondere §§ 165 bis 168; amtliches, gemeinfreies Werk, zitierfähig mit Quellenangabe (gesetze-im-internet.de/tkg_2021). Paragraphennummerierung und Wortlaut am aktuellen Stand verifizieren (Änderungen u. a. durch das NIS2-Umsetzungsgesetz).
• BNetzA-Katalog von Sicherheitsanforderungen nach § 167 TKG; amtliche Allgemeinverfügung, frei nutzbar mit Quellenangabe (bundesnetzagentur.de). Aktuell festgestellte Fassung heranziehen; eine Neufassung wird an die TKG-/NIS2-Änderungen angepasst.
• ISO/IEC 27001: Referenz für den ISMS-Unterbau zur Umsetzung der TKG-Pflichten (reference-only, keine Volltexte oder Control-Listen).