¶ Behörden und Kontaktstellen
Keine öffentliche Kontaktliste: Reale Namen, persönliche Kontaktdaten, Portalzugänge, Token, Zertifikate, Behördenreferenzen und Bereitschaftsdaten werden geschützt geführt. Portale, Zuständigkeiten und Kommunikationswege sind veränderlich und werden unmittelbar vor einer Registrierung oder Meldung erneut anhand amtlicher Quellen geprüft.
¶ Behördenkontakte und Meldebereitschaft systematisch vorbereiten
NIS2-/BSIG-Pflichten lassen sich nur fristgerecht erfüllen, wenn die zuständigen Stellen, Portalzugänge, internen Freigaben und Vertretungen bereits vor einem Sicherheitsvorfall geklärt sind. Eine unstrukturierte Liste mit Telefonnummern reicht nicht aus. Benötigt wird ein gelenktes Register, das den Anlass des Kontakts, die zuständige Behörde, den zugelassenen Kommunikationsweg, die intern entscheidungsbefugte Rolle und den aktuellen Funktionsnachweis miteinander verbindet.
Das Bundesamt für Sicherheit in der Informationstechnik ist nach § 40 BSIG nationale Verbindungsstelle sowie zentrale Melde- und Anlaufstelle für besonders wichtige und wichtige Einrichtungen. Abhängig von Einrichtungsart, Sektor und zusätzlichem Fachrecht können weitere Bundes- oder Landesbehörden, das BBK, Datenschutzaufsichtsbehörden oder sektorale Stellen beteiligt sein. Deshalb muss die Zuständigkeit organisationsbezogen geprüft werden; eine Musterseite kann diese Entscheidung nicht vorwegnehmen.
Diese Seite stellt die Registerstruktur und den Betriebsprozess bereit. Die realen Kontakt- und Zugangsdaten verbleiben in einer geschützten, auch während eines IT-Ausfalls erreichbaren Ablage.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-REG-01-06 |
| Dokumentenart | Behörden-, Portal-, Kontaktstellen- und Kommunikationsregister |
| Wiki.js-Pfad | /NIS2/01-Governance-und-Geschaeftsleitung/Behoerden-und-Kontaktstellen |
| Verantwortlich | NIS2-Koordination gemeinsam mit Incident-, Krisen- und Rechts-/Compliance-Funktion |
| Status | Entwurf – keine realen Kontakte, Zuständigkeiten oder Zugänge enthalten |
| Version / Stand | 0.4 / 09.08.2026 |
| Schutzklasse | Vertraulich; öffentliche Seite enthält ausschließlich Struktur und Musterdaten |
| Rechtsbezug | Insbesondere §§ 32 bis 36 und 40 BSIG; zusätzliche sektorale und datenschutzrechtliche Pflichten gesondert prüfen |
| Review | mindestens jährlich, zusätzlich bei Behörden-, Portal-, Rollen-, Sektor- oder Rechtsänderungen |
Zuständigkeiten, sichere Kanäle und Vertretungen so vorbereiten, dass gesetzliche Fristen auch im Notfall eingehalten werden können. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Ziel und Geltungsbereich des Registers
Das Register unterstützt folgende Anwendungsfälle:
- Registrierung einer besonders wichtigen oder wichtigen Einrichtung,
- Aktualisierung bereits übermittelter Registrierungsdaten,
- Meldung und Nachverfolgung erheblicher Sicherheitsvorfälle,
- Beantwortung behördlicher Rückfragen und Auskunftsverlangen,
- Empfang von Warnungen, Lageinformationen oder Unterstützungsangeboten,
- Kommunikation mit sektoralen Aufsichten und zuständigen Landesstellen,
- gesonderte Meldung von Datenschutzverletzungen,
- Strafanzeige, Beweissicherung und Abstimmung mit Strafverfolgungsbehörden,
- vertragliche Meldungen an Kunden, Versicherer oder Geschäftspartner,
- Krisenkommunikation mit betroffenen Personen und der Öffentlichkeit.
Die Aufnahme einer Stelle bedeutet nicht, dass sie bei jedem Vorfall zu kontaktieren ist. Für jeden Anlass wird die Entscheidungskompetenz, Rechtsgrundlage, Frist und Freigabe gesondert festgelegt.
¶ 2. Aktuelle Portal- und Übergangssituation
¶ NIS2-Registrierung und Meldung
Nach der amtlichen BSI-Information vom Abrufstand 09.08.2026 erfolgt die Registrierung nach dem NIS-2-Umsetzungsgesetz ausschließlich über das dafür vorgesehene BSI-Portal unter portal.bsi.bund.de und nicht über das MIP. Im BSI-Portal können registrierte Unternehmen und Behörden Sicherheitsvorfälle melden. Auch freiwillige Vorfallmeldungen und anonyme Schwachstellenmeldungen werden dort angeboten.
Sobald eine Einrichtung im BSI-Portal registriert ist, soll sie dieses nach dem BSI-Hinweis auch für künftige Sicherheitsvorfall- oder Schwachstellenmeldungen verwenden.
¶ KRITIS und Bundesbehörden
Betreiber kritischer Anlagen und Bundesbehörden nutzen laut BSI-Information während der beschriebenen Übergangsphase prioritär weiterhin das Melde- und Informationsportal – MIP. Eine identische Meldung muss nicht zusätzlich über das BSI-Portal eingereicht werden.
Die MIP-Meldestellenübersicht enthielt beim Abruf am 09.08.2026 zudem einen Hinweis, dass die Registrierung für die Meldestelle KRITIS seit 22.06.2026 vorläufig deaktiviert ist, während bestehende Zugänge fortbestehen können. Dieser operative Status kann sich kurzfristig ändern und wird deshalb nicht dauerhaft als Prozessannahme festgeschrieben.
Betriebsregel: Vor jeder Echtregistrierung oder Echtmeldung werden Einrichtungsart, Portalzuständigkeit, aktueller Behördenhinweis und mögliche sektorale Sonderregelungen erneut geprüft. Der aktuelle Weg wird mit Abrufdatum und prüfender Rolle dokumentiert.
¶ Schnellzugriff auf zentrale Portale
Wichtig: Ein Direktlink bestätigt noch keine Zuständigkeit. Vor einer Meldung sind Einrichtungsart, betroffener Dienst, Ereignis, Rechtsgrundlage, Frist und aktuell vorgesehener Übermittlungsweg zu prüfen. Bei akuter Gefahr ist die Polizei über 110 zu verständigen; die Onlinewache ist nicht für Notfälle bestimmt.
¶ 3. Behörden- und Kontaktkategorien
| Kategorie | Möglicher Anlass | Zuständigkeit vor Nutzung prüfen |
|---|---|---|
| BSI / BSI-Portal | NIS2-Registrierung, Aktualisierung, Sicherheitsvorfall, Schwachstelle, Rückfrage | Einrichtungsart, gesetzliche Pflicht, Portalstatus und Registrierungsstand |
| BSI und BBK / MIP | insbesondere Übergangs- oder KRITIS-bezogene Registrierung, Meldung und Informationsaustausch | aktuelle Meldestelle, KRITIS-Status, Portalverfügbarkeit und behördlicher Hinweis |
| sektorale Bundesaufsicht | branchenbezogene Aufsicht, Auskunft, Vorfall- oder Nachweispflicht | Spezialgesetz, Zuständigkeitsabgrenzung und Vermeidung unzulässiger Doppelmeldungen |
| zuständige Landesbehörde | gegebenenfalls Aufsicht regionaler öffentlicher Verwaltung oder andere Landeszuständigkeit | Sitz, Einrichtungstyp, Fachrecht und behördliche Benennung |
| Datenschutzaufsichtsbehörde | Verletzung des Schutzes personenbezogener Daten, Beratung oder Prüfung | Verantwortlicher, Niederlassung, federführende Aufsicht und Artikel-33-Tatbestand |
| Strafverfolgungsbehörde | Verdacht auf Straftat, Gefahrenlage oder notwendige Beweissicherung | Entscheidungsbefugnis, Ermittlungsinteressen und Schutz vertraulicher Informationen |
| Versicherer / Incident-Dienstleister | versicherter Vorfall, Assistance, Forensik oder Krisenunterstützung | Police, Meldefrist, Vorabfreigabe, Beauftragung und Vertraulichkeit |
| Kunden und Vertragspartner | vertragliche Sicherheits-, Leistungs- oder Datenschutzmeldung | konkrete Vertragsklausel, Frist, Empfänger und freizugebender Inhalt |
| betroffene Personen / Öffentlichkeit | Datenschutzbenachrichtigung, Warnung oder Krisenkommunikation | Rechtsgrundlage, Risiko, Kommunikationsstrategie und Behördenabstimmung |
§ 40 BSIG benennt das BSI als nationale Verbindungsstelle sowie zentrale Melde- und Anlaufstelle. Die Vorschrift beschreibt außerdem die Zusammenarbeit unter anderem mit BBK, Bundesnetzagentur, BaFin und zuständigen Länderbehörden. Daraus folgt keine pauschale Direktzuständigkeit jeder dieser Stellen für jede Einrichtung; die Organisation muss ihr konkretes Aufsichts- und Meldemodell bestimmen.
¶ 4. Pflichtfelder je Registereintrag
| Feldgruppe | Mindestinhalt |
|---|---|
| Register-ID | eindeutige Kennung, beispielsweise KON-NIS2-001 |
| Stelle | offizielle Bezeichnung, Behörde, Portal, Aufsicht oder sonstiger Empfänger |
| Anlass und Rechtsbezug | Registrierung, Aktualisierung, Vorfall, Unterrichtung, Auskunft, Fachaufsicht oder Vertrag |
| Zuständigkeit | juristische Person, Sektor, Dienst, Standort, Region und Ereignisart |
| offizieller Nachweis | amtliche Webseite, Vertrag oder sonstige belastbare Quelle mit Abrufdatum |
| interner Owner | fachlich verantwortliche Rolle, Freigaberolle und Stellvertretung |
| Kommunikationsweg | Portal, Funktionsadresse, gesicherte E-Mail, Telefon, Ersatzweg und Betriebszeit |
| Authentisierung | Benutzerrollen, MFA, Zertifikate, Token und Notfallzugriff – ausschließlich geschützte Referenz |
| Erreichbarkeit | Regelbetrieb, Rufbereitschaft, Ausfall- und Eskalationsweg |
| Teststatus | letzter kontrollierter Funktionstest, Ergebnis, Abweichung und nächste Prüfung |
| Datenminimierung | zulässige Inhalte, Klassifizierung und Freigabe vor Übermittlung |
| Nachweis | kontrollierter Ablageort für Registrierung, Versand, Empfang, Aktenzeichen und Rückfragen |
| Lebenszyklus | Status, Gültigkeit, letzte Prüfung, nächste Prüfung und Stilllegung |
¶ 5. Internes Rollen- und Freigabemodell
| Rolle | Aufgabe |
|---|---|
| Geschäftsleitung / Krisenleitung | wesentliche Kommunikations- und Risikoentscheidungen, Ressourcen und externe Positionierung |
| NIS2-Meldekoordination | Fristen steuern, Portalweg vorbereiten, Fassungen konsolidieren und Nachweise sichern |
| Incident Manager | technische Fakten, Zeitstrahl, Auswirkungen, Maßnahmen und Status bereitstellen |
| Dienstverantwortliche | Auswirkungen auf relevante Dienste, Kunden und Wiederanlauf beurteilen |
| Recht / Compliance | Rechtsgrundlage, Meldepflicht, Zuständigkeit, Inhalt und Aussagegrenzen prüfen |
| Datenschutzfunktion | Datenschutzverletzung, Aufsichtsbehörde und Betroffenenbenachrichtigung getrennt bewerten |
| Portaladministration | Konten, Rollen, MFA, Zertifikate, Stellvertretungen und Funktionsprüfung verwalten |
| Kommunikation | freigegebene interne, externe und öffentliche Aussagen konsistent umsetzen |
| Dokumentation / Nachweisführung | versendete Fassungen, Bestätigungen, Referenzen und Aufbewahrung lenken |
Für jede Meldestufe ist vorab festgelegt, wer erstellt, fachlich prüft, rechtlich prüft, freigibt, übermittelt und den Eingang kontrolliert. Vertretungen müssen dieselben notwendigen Befugnisse und einen funktionsfähigen Zugang besitzen.
¶ 6. Lebenszyklus eines Behördenkontakts
¶ 6.1 Aufnahme
Eine Kontaktstelle wird nur aus einer amtlichen oder vertraglich belastbaren Quelle aufgenommen. Freie Internetverzeichnisse, Suchmaschinenauszüge oder übernommene Altlisten genügen nicht. Quelle, Abrufdatum und prüfende Rolle werden gespeichert.
¶ 6.2 Zuständigkeitsprüfung
Einrichtung, Sektor, betroffener Dienst, Standort, Rechtsgrundlage und Anlass werden mit der Stelle abgeglichen. Bei Unsicherheit wird der Status „zu klären“ vergeben; die Stelle wird nicht als bestätigter Meldeweg dargestellt.
¶ 6.3 Freigabe und Bereitstellung
Nach fachlicher Prüfung werden Kontaktart, Kommunikationskanal, Berechtigungsgruppe, Stellvertretung und Reviewtermin freigegeben. Sensible Direktkontakte werden nur den erforderlichen Rollen zugänglich gemacht.
¶ 6.4 Nutzung
Jede Kommunikation erhält Fall-ID, Version, Zeitpunkt, Absender, Empfänger, Übermittlungsweg und Freigabenachweis. Telefonische oder informelle Abstimmungen werden zeitnah nachdokumentiert.
¶ 6.5 Review und Änderung
Bei Behörden-, Portal-, Rechts-, Sektor-, Organisations- oder Rollenänderung erfolgt ein außerplanmäßiger Review. Veraltete Einträge werden historisiert und dürfen in Einsatzlisten nicht mehr auswählbar sein.
¶ 6.6 Stilllegung
Nicht mehr benötigte Konten, Zertifikate, Token oder Verteiler werden kontrolliert entzogen. Aufbewahrungspflichtige Kommunikationsnachweise bleiben geschützt erhalten.
¶ 7. Kommunikations- und Freigabematrix
| Ereignisart | Interne Vorbereitung | Externe Kommunikation |
|---|---|---|
| mögliche NIS2-Meldelage | Incident Response, Dienst-Owner, NIS2-Meldekoordination und Recht | ausschließlich über den aktuell bestätigten gesetzlichen Meldeweg |
| Datenschutzverletzung | Datenschutzfunktion, Incident Response und Verantwortlicher im Sinne der DSGVO | zuständige Datenschutzaufsicht nach eigener Artikel-33-Bewertung; gegebenenfalls betroffene Personen |
| Straftatverdacht | Geschäftsleitung, Recht, Incident Response und Beweissicherung | zuständige Strafverfolgung nach dokumentierter Entscheidung |
| Kunden- oder Vertragspflicht | Dienst-, Vertrags-, Datenschutz- und Kommunikationsverantwortung | definierter Vertragspartner über vertraglich vorgesehenen Kanal |
| Auskunftsverlangen | NIS2-/Compliance-Koordination, Recht, betroffene Owner | zuständige Behörde; Inhalt und Frist nachvollziehbar steuern |
| Warnung oder öffentliche Kommunikation | Krisenleitung, Recht, Datenschutz und Kommunikation | freigegebene, konsistente und auf den erforderlichen Umfang begrenzte Information |
Die Matrix verhindert widersprüchliche Aussagen, ersetzt aber nicht die Einzelfallprüfung. Alle Meldungen referenzieren einen gemeinsamen Zeitstrahl und eine freigegebene Faktenbasis.
¶ 8. Faktenbasis und Versionssteuerung
Vor externer Kommunikation werden mindestens folgende Angaben konsolidiert:
- betroffene juristische Person und Fall-ID,
- Zeitpunkt der Entdeckung und der maßgeblichen Kenntniserlangung,
- betroffene Dienste, Standorte, Systeme und Nutzergruppen,
- Art, Ursache und aktueller Status des Sicherheitsvorfalls,
- Ausmaß, Dauer und tatsächliche oder mögliche Auswirkungen,
- Anzeichen für rechtswidrige oder böswillige Handlungen,
- mögliche grenzüberschreitende Auswirkungen,
- eingeleitete Eindämmungs-, Wiederherstellungs- und Abhilfemaßnahmen,
- bekannte Unsicherheiten und noch ausstehende Informationen,
- Ansprechpartner für fachliche und organisatorische Rückfragen.
Jede versendete Fassung erhält Versionsnummer und Freigabe. Korrekturen oder Ergänzungen werden als neue Fassung nachvollziehbar übermittelt; die alte Fassung wird nicht stillschweigend überschrieben.
¶ 9. Portal-, Identitäts- und Zugriffsmanagement
¶ Rollen und Konten
Portalkonten werden funktionsbezogen beantragt und soweit technisch möglich nicht an nur eine Person gebunden. Kontoinhaber, Administrationsrolle, Melderolle, Leserechte und Stellvertretungen sind dokumentiert. Privilegierte Rechte folgen dem Need-to-know- und Vier-Augen-Prinzip.
¶ Authentisierung und Geräte
Mehrfaktor-Authentisierung, Token, Zertifikate, zulässige Endgeräte, Browseranforderungen und gesicherte Netzzugänge werden technisch beschrieben. Zugangsdaten oder Wiederherstellungscodes gehören weder in das Wiki noch in das Kontaktregister.
¶ Joiner-Mover-Leaver
Eintritt, Rollenwechsel, längere Abwesenheit und Austritt lösen eine sofortige Berechtigungsprüfung aus. Eine Vertretung wird eingerichtet, bevor der primäre Zugang entfällt.
¶ Notfallzugang
Für den Ausfall regulärer Identitäten, Geräte, Netze oder Passwortmanager ist ein geschütztes Break-Glass-Verfahren vorgesehen. Nutzung, Rückgabe und anschließende Änderung der Notfallmittel werden protokolliert.
¶ 10. Meldebereitschaft im Sicherheitsvorfall
Die Friststeuerung beginnt nicht erst mit dem Öffnen des Portals. Der Incident-Prozess muss Kenntniserlangung, Erheblichkeitsbewertung, Einbindung der Entscheider, Informationsbeschaffung, Freigabe und Übermittlung als zusammenhängenden Ablauf behandeln.
| Zeitpunkt / Stufe | Organisatorische Vorbereitung |
|---|---|
| unverzüglich nach Alarm | Incident eröffnen, Zeitstempel sichern, Dienst- und Meldeverantwortliche alarmieren |
| frühe Erstmeldung spätestens innerhalb 24 Stunden, sofern § 32 BSIG anwendbar | Mindestfakten, Verdacht böswilliger Handlung, grenzüberschreitenden Bezug und Freigabe bereitstellen |
| Meldung spätestens innerhalb 72 Stunden | Erstmeldung bestätigen oder aktualisieren, erste Bewertung von Schwere und Auswirkungen sowie gegebenenfalls Kompromittierungsindikatoren ergänzen |
| Zwischenmeldung auf Ersuchen | Status, neue Erkenntnisse, Maßnahmen und offene Punkte versioniert bereitstellen |
| Abschlussmeldung grundsätzlich spätestens einen Monat nach der 72-Stunden-Meldung | Ursache, Verlauf, Auswirkungen, Abhilfe und gegebenenfalls grenzüberschreitende Folgen konsolidieren |
| fortdauernder Vorfall | Fortschrittsmeldung statt Abschlussmeldung und späteren Abschluss steuern |
Die gesetzliche Verpflichtung nach § 32 BSIG gilt nach dem aktuellen Gesetzestext frühestens ab Einrichtung des Meldewegs. Diese Übergangsregel wird nicht als Grund genutzt, die organisatorische Meldebereitschaft aufzuschieben.
¶ 11. Ersatzwege und Offline-Verfügbarkeit
Ein Ausfall des primären Portals, der Identitätsplattform, des Firmennetzes oder des Hauptstandorts darf die Handlungsfähigkeit nicht vollständig beseitigen. Festgelegt werden:
- amtlich bestätigter Ersatz- oder Eskalationsweg,
- alternative, gehärtete Endgeräte und Netzzugänge,
- offline erreichbare Rollen- und Funktionskontakte,
- geschützter Zugriff auf Meldeentwürfe und Mindestinformationen,
- Verfahren für telefonische Vorabstimmung und nachträgliche Dokumentation,
- Rückkehr vom Ersatzweg in den regulären Prozess,
- Beweissicherung für gescheiterte Übermittlungsversuche.
Ein improvisierter Versand an irgendeine bekannte E-Mail-Adresse ist kein freigegebener Ersatzweg. Der aktuelle Behördenhinweis bleibt maßgeblich.
¶ 12. Kontrollierte Tests und Übungen
Erreichbarkeit und Meldefähigkeit werden risikobasiert geprüft, ohne unbeabsichtigt eine echte Meldung auszulösen. Übungen nutzen Test-, Entwurfs- oder Simulationswege, soweit verfügbar.
¶ Prüfumfang
- Alarmierung von Primärrolle und Stellvertretung,
- Zugriff auf Register, Portal und geschützte Nachweise,
- Funktionsfähigkeit von MFA, Zertifikaten und zugelassenem Gerät,
- Erstellung und Vier-Augen-Freigabe einer Meldung im vorgegebenen Zeitfenster,
- Übergabe zwischen Incident, Dienst-Owner, Recht, Datenschutz und Kommunikation,
- Nutzung des Ersatzwegs als Tabletop-Szenario,
- Export, Archivierung und Wiederauffinden der freigegebenen Fassung,
- Behandlung einer behördlichen Rückfrage.
¶ Ergebnis
Testdatum, Szenario, Teilnehmerrollen, Sollzeit, Istzeit, Ergebnis, Abweichungen, Maßnahmen, Owner, Termin und Nachtest werden dokumentiert. Ein erfolgreicher Login allein belegt noch keine vollständige Meldefähigkeit.
¶ 13. Schutz und Aufbewahrung
Das öffentliche Wiki enthält keine realen Kontaktdaten. Die geschützte Kontaktakte trennt mindestens:
- öffentlich verfügbare Behörden- und Portalinformationen,
- interne Rollen- und Bereitschaftskontakte,
- persönliche Direktkontakte,
- Authentisierungs- und Wiederherstellungsinformationen,
- fallbezogene Meldungen und Behördenkommunikation,
- Aktenzeichen, Empfangsbestätigungen und Nachforderungen.
Zugriffe werden rollenbasiert vergeben. Aufbewahrungsfristen ergeben sich aus Rechts-, Vertrags-, Beweis- und Löschanforderungen und werden im Rechts- und Vertragskataster begründet. Portalexporte werden rechtzeitig in der kontrollierten Ablage gesichert, wenn das Portal selbst keine dauerhafte Aufbewahrung gewährleistet.
¶ 14. Muster eines Registereintrags
| Feld | Musterwert |
|---|---|
| Register-ID | KON-NIS2-001 |
| Stelle | BSI-Portal – Musterreferenz, vor Nutzung amtlich verifizieren |
| Anlass | NIS2-Registrierung und Meldung erheblicher Sicherheitsvorfälle |
| betroffene Einrichtung | offen – organisationsbezogene Betroffenheitsprüfung erforderlich |
| interner Owner | Rolle NIS2-Meldekoordination – namentliche Zuordnung geschützt |
| Stellvertretung | offen – vor Freigabe zu benennen und zu testen |
| Portalzugang | geschützte Referenz im Identity-/Secrets-Management |
| letzter Quellencheck | 09.08.2026 – amtlicher BSI-Hinweis |
| letzter Funktionstest | offen – keine Umsetzung behauptet |
| nächster Review | nach Benennung beziehungsweise bei Portaländerung |
| Schutzklasse | Vertraulich |
Die Angaben sind Musterdaten und keine Bestätigung einer Registrierung, Zuständigkeit oder Funktionsfähigkeit.
¶ 15. Kennzahlen und Managementinformation
Geeignete Kennzahlen sind beispielsweise:
- Anteil bestätigter Kontaktstellen mit amtlicher Quelle und aktuellem Review,
- Anteil kritischer Kontakte mit geprüfter Stellvertretung,
- Portalkonten ohne aktuellen Owner, MFA oder Berechtigungsreview,
- Zeit bis zur Alarmierung aller erforderlichen Rollen,
- Zeit bis zur Erstellung und Freigabe eines meldefähigen Entwurfs,
- erfolgreiche beziehungsweise fehlgeschlagene Zugriffs- und Bereitschaftstests,
- offene Abweichungen nach Kritikalität und Überfälligkeit,
- behördliche Rückfragen aufgrund unvollständiger oder widersprüchlicher Angaben.
Kennzahlen enthalten Datenquelle, Zielwert, Schwelle, Trend, Owner und erforderliche Managemententscheidung.
¶ 16. Qualitätsprüfung vor Freigabe
- Betroffene Einrichtung, relevante Dienste und mögliche sektorale Aufsichten sind geprüft.
- BSI-Portal, MIP oder anderer Meldeweg wurden anhand aktueller amtlicher Hinweise zugeordnet.
- Kontakt- und Portalinformationen stammen aus belastbaren Quellen mit Abrufdatum.
- Anlass, Rechtsbezug, interner Owner und Freigaberolle sind je Kontakt bestimmt.
- Portalkonten, MFA, Stellvertretung und sichere Endgeräte sind funktionsfähig oder offen gekennzeichnet.
- NIS2-, KRITIS-, Datenschutz-, Strafverfolgungs- und Vertragswege sind abgegrenzt.
- Ersatzwege sind amtlich beziehungsweise vertraglich bestätigt und dokumentiert.
- Kontrollierte Tests verhindern versehentliche Echtmeldungen.
- Versendete Fassungen, Empfang, Aktenzeichen und Rückfragen werden geschützt aufbewahrt.
- Keine reale Kontakt- oder Zugangsinformation wird öffentlich im Wiki angezeigt.
¶ 17. Offene Punkte vor organisationsbezogener Freigabe
- NIS2-/BSIG-Betroffenheit und sektorale Sonderrollen bestätigen,
- zuständige Behörden und Portale für jeden Anlass festlegen,
- NIS2-Meldekoordination, Freigaberollen und Stellvertretungen benennen,
- Portalregistrierung und rollenbasierte Zugänge durchführen,
- geschützte Online- und Offline-Kontaktakte einrichten,
- Ersatz- und Eskalationswege amtlich verifizieren,
- Bereitschafts- und Stellvertretungstest planen,
- Reviewintervall, Änderungsmonitoring und Kennzahlen freigeben.
¶ 18. Verknüpfte Arbeitsseiten
- Registrierung und Aktualisierung
- Rollen und Verantwortlichkeiten
- Meldeweg erhebliche Sicherheitsvorfälle
- Kommunikation mit BSI und Betroffenen
- Melderegister und Fristenkontrolle
- Kontakt- und Eskalationslisten
- Incident Response
- Meldeweg Datenschutzverletzungen
- Kontakt- und Eskalationslisten Datenschutz
¶ 19. Direktlinks wichtiger Meldestellen, Portale und Behörden
Die nachfolgenden Verweise führen ausschließlich zu amtlichen Portalen oder Informationsseiten. Alle Links öffnen in einem neuen Browser-Tab. Vor einer Echtmeldung wird die Zieladresse erneut über die offizielle Hauptseite der Behörde verifiziert. Zugangsdaten, Ansprechpartner, Aktenzeichen und versendete Inhalte werden nicht auf dieser öffentlichen Seite gespeichert.
¶ 19.1 NIS2, BSI und KRITIS
| Offizielle Stelle / Portal | Wofür der Link genutzt werden kann | Direktlink |
|---|---|---|
| BSI-Portal | NIS2-Registrierung sowie gesetzliche, freiwillige oder – soweit angeboten – anonyme Meldungen; maßgeblich ist der jeweils aktuelle Funktionsumfang | BSI-Portal öffnen ↗ |
| BSI – Informationen zu NIS2 | aktuelle Abgrenzung zwischen BSI-Portal und MIP sowie Hinweise zu Registrierung und Meldung | NIS2-Portalhinweise prüfen ↗ |
| Melde- und Informationsportal – MIP | insbesondere für die vom BSI beschriebenen KRITIS- und Bundeswege während der aktuellen Übergangssituation | MIP öffnen ↗ |
| MIP-Meldestellenübersicht | verfügbare Meldestellen, aktuelle KRITIS-Hinweise sowie Registrierungs- und Änderungswege prüfen | Meldestellenübersicht öffnen ↗ |
| Meldung ohne MIP-Registrierung | verfügbares Formular und zuständige Meldestelle auswählen, wenn dieser Weg im konkreten Fall zulässig ist | Formularauswahl öffnen ↗ |
| BSI-Vorfallunterstützung | Unterstützungsangebote und Hinweise des BSI zur Bewältigung eines IT-Sicherheitsvorfalls | Vorfallunterstützung ansehen ↗ |
Die frei zugängliche Formularauswahl im MIP ist kein pauschaler Ersatz für den gesetzlich oder behördlich vorgeschriebenen registrierten Meldeweg. Eine Meldung wird erst nach bestätigtem Empfänger, geeignetem Formular, interner Freigabe und dokumentierter Zuständigkeitsprüfung versendet.
¶ 19.2 Datenschutzverletzung und Strafverfolgung
| Offizielle Stelle / Portal | Wofür der Link genutzt werden kann | Direktlink |
|---|---|---|
| Datenschutzkonferenz – Aufsichtsbehörden | zuständige Datenschutzaufsichtsbehörde des Bundes oder eines Landes ermitteln; das konkrete Meldeformular befindet sich regelmäßig auf der Seite der zuständigen Behörde | Aufsichtsbehörden anzeigen ↗ |
| Zentrale Ansprechstellen Cybercrime – ZAC | zuständige polizeiliche Ansprechstelle für Wirtschaftsunternehmen bei Cybercrime ermitteln; Kontaktaufnahme und Strafanzeige ersetzen keine NIS2-Meldung | ZAC-Leistung im Bundesportal öffnen ↗ |
| Onlinewachen der Polizeien der Länder | Strafanzeige oder Hinweis über das zuständige Bundesland übermitteln, soweit der Sachverhalt für die Onlinewache geeignet ist | Polizei-Onlinewache öffnen ↗ |
| BKA – Cybercrime für Wirtschaftsunternehmen | Handlungsempfehlungen und Verweis auf die zuständige ZAC bei einem Cybercrime-Vorfall | BKA-Hinweise öffnen ↗ |
Keine Vermischung der Verfahren: Eine Meldung an die Datenschutzaufsicht, eine Kontaktaufnahme mit der ZAC oder eine Strafanzeige erfüllt nicht automatisch die NIS2-/BSIG-Meldepflicht. Umgekehrt ersetzt die NIS2-Meldung keine Datenschutzmeldung oder Strafanzeige. Bei unmittelbarer Gefahr für Personen oder Sachgüter ist 110 zu wählen.
¶ 19.3 Sektorale Meldeseiten – nur bei bestätigter Zuständigkeit
| Sektorale Stelle | Anwendungsbereich | Direktlink |
|---|---|---|
| Bundesnetzagentur | Meldung erheblicher Sicherheitsvorfälle durch Betreiber öffentlicher Telekommunikationsnetze oder Anbieter öffentlich zugänglicher Telekommunikationsdienste nach dem von der Behörde beschriebenen Verfahren | Meldeseite nach § 168 TKG öffnen ↗ |
| BaFin | Informationen zu Meldungen schwerwiegender IKT-bezogener Vorfälle nach DORA über die MVP; nur für beaufsichtigte und vom jeweiligen Verfahren erfasste Finanzunternehmen | BaFin-Ausfüllhinweise zu DORA-Meldungen öffnen ↗ |
Weitere sektorale Behörden, Landesstellen, Versicherer, Kundenkontakte und vertragliche Meldestellen werden erst nach der organisationsbezogenen Betroffenheits- und Vertragsprüfung in das geschützte Register aufgenommen. Die Liste ist daher bewusst nicht als allgemeingültiges Behördenverzeichnis zu verstehen.
¶ 19.4 Rechtsgrundlagen
- § 32 BSIG – Meldepflichten ↗
- § 33 BSIG – Registrierungspflicht ↗
- § 40 BSIG – nationale Verbindungsstelle sowie zentrale Melde- und Anlaufstelle ↗
- Artikel 33 DSGVO – Meldung von Verletzungen des Schutzes personenbezogener Daten ↗
¶ 20. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung beim Aufbau belastbarer NIS2-Meldewege, Incident-Response-Strukturen, Kommunikationsmatrizen und prüffähiger Nachweise
- NIS2-Beratung und Meldewege
- Management von Sicherheitsvorfällen
- Business Continuity und Krisenorganisation
- Lessons Learned aus Sicherheitsvorfällen
¶ 21. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.4 | 09.08.2026 | Schnellzugriff und geprüfte Direktlinks zu BSI-Portal, MIP, Datenschutzaufsicht, ZAC, Polizei-Onlinewache, BKA sowie ausgewählten sektoralen Meldeseiten ergänzt; Abgrenzung der Meldeverfahren verdeutlicht | Ausstehend |
| 0.3 | 09.08.2026 | SEO- und Facheinleitung, aktuelle Portalabgrenzung, Behördenkategorien, Rollen, Kontaktlebenszyklus, Fakten- und Versionssteuerung, Portalzugriffe, Meldebereitschaft, Ersatzwege, Tests, Schutz, Musterregister, Kennzahlen und Quellen ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Kontaktkategorien, Verifikation, Kommunikationsmatrix, Portalzugriff, Vorfallnutzung und Freigabekriterien fachlich vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Leere Registerstruktur für Behörden- und Kontaktstellen erstellt | Ausstehend |