Der Eintrag im BSI-Portal ist bestätigt, die Kontaktdaten sind hinterlegt, der Vorgang kann geschlossen werden. Genau hier entsteht ein gefährliches Gefühl von Fertigsein. Die Registrierung erfüllt eine konkrete Pflicht und schafft einen Kommunikationskanal. Sie zeigt aber weder, ob der Scope stimmt, noch ob Risikomanagementmaßnahmen wirksam betrieben, Änderungen nachgeführt und Leitungsentscheidungen belegt werden. Wer nach dem Portal-Haken stoppt, hat eine Adresse abgegeben – kein steuerbares Sicherheitsmodell aufgebaut.
Hinweis: Allgemeine fachliche Einordnung; keine Rechtsberatung, Zertifizierungs- oder Auditgarantie.
Der falsche Abschlussmoment: „Wir sind jetzt NIS2-compliant“
Seit dem 6. Dezember 2025 gilt das novellierte BSI-Gesetz. Das BSI hat den zweiten Schritt des Registrierungsprozesses am 6. Januar 2026 über das BSI-Portal freigeschaltet. Nach § 33 BSIG müssen besonders wichtige und wichtige Einrichtungen sowie Domain-Name-Registry-Dienstleister die dort verlangten Angaben grundsätzlich spätestens drei Monate, nachdem sie erstmals oder erneut als solche gelten beziehungsweise den Dienst anbieten, übermitteln. Änderungen an diesen Angaben sind unverzüglich, spätestens binnen zwei Wochen nach Kenntnis, mitzuteilen.
Das sind wichtige Fristen. Sie machen aus der Registrierung aber keine Konformitätsfeststellung. Das BSI weist selbst darauf hin, dass betroffene Unternehmen eine Risikoanalyse durchführen sowie angemessene Risikomanagementmaßnahmen umsetzen und dokumentieren müssen. § 30 BSIG verlangt geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen. Nach § 38 müssen Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen diese Maßnahmen umsetzen und ihre Umsetzung überwachen sowie regelmäßig an Schulungen teilnehmen. Bei schuldhaft verursachtem Schaden knüpft § 38 die Haftung grundsätzlich an die auf die Rechtsform anwendbaren Regeln des Gesellschaftsrechts; nur soweit diese keine entsprechende Haftungsregel enthalten, greift die Haftungsregel des BSIG selbst.
Der Portalbeleg bestätigt daher nur, dass die Einrichtung mit den geforderten Angaben registriert wurde. Er zeigt nicht, welche Gesellschaften, Dienste, Standorte und Abhängigkeiten tatsächlich erfasst sind. Er dokumentiert weder die Kriterien der Risikobewertung noch den Betriebs- und Wirksamkeitsstatus der Maßnahmen. Auch lässt sich daraus nicht ablesen, welche Lücken eine autorisierte Instanz akzeptiert, finanziert oder eskaliert hat und welche Angaben sich seit der Einreichung verändert haben. Ebenso belegt die Portalregistrierung keine allgemeine Duldungs- oder Schonfrist des BSI. Ohne eine einschlägige amtliche Primärquelle darf ein intern oder extern genannter Termin nicht als gesetzliche Frist oder gesicherte Aufsichtspraxis behandelt werden.
Ein PDF mit Registrierungsbestätigung ist belastbare Evidenz – für die Registrierung. Ein Feuerlöscher ist schließlich auch kein Brandschutzkonzept, obwohl er erfreulich rot aussieht.
Die drei Lücken nach dem Portal-Haken
1. Der registrierte Rechtsträger und der operative Scope driften auseinander
Die Registrierung enthält unter anderem Name, Rechtsform, Kontaktdaten, öffentliche IP-Adressbereiche, Sektor und Angaben zu Tätigkeiten in EU-Mitgliedstaaten. In der Praxis verändern sich diese Informationen: Gesellschaften werden umgebaut, Services migriert, Netze erweitert, Anbieter ausgetauscht oder Verantwortliche wechseln.
Deshalb braucht die Einrichtung ein geführtes Scope- und Registrierungsregister. Es sollte den registrierten Rechtsträger mit den betroffenen Diensten, wesentlichen Informationssystemen, Betriebsstandorten, unmittelbaren kritischen Abhängigkeiten und den ans BSI übermittelten Angaben verbinden. Jede relevante Änderung erhält einen Trigger, einen Owner und ein Prüfdatum. So wird die Zweiwochenfrist für geänderte Registrierungsangaben zu einem Prozess statt zu einer Kalenderüberraschung.
Nehmen wir eine ausdrücklich hypothetische Betriebsszene. Eine registrierte deutsche Gesellschaft betreibt einen kundennahen Dienst, dessen Plattform sechs Monate später zu einem anderen Cloud-Provider migriert wird. Gleichzeitig übernimmt eine Schwestergesellschaft Teile des Supports, und die bisherige Kontaktperson wechselt intern. Jede Änderung wirkt für sich wie gewöhnlicher Betrieb. Zusammen verändern sie jedoch technische Abhängigkeiten, Zuständigkeiten und möglicherweise die Daten, auf denen die Registrierung und der Scope-Abgleich beruhen.
Ein funktionierender Mechanismus beginnt nicht mit einer jährlichen Erinnerungsmail. Der genehmigte Providerwechsel löst einen Scope-Check aus; der Organisationswechsel löst eine Kontaktprüfung aus. Die zuständige Rolle vergleicht den neuen Stand mit den übermittelten Angaben, dokumentiert die Bewertung und stößt erforderliche Aktualisierungen an. Wenn unklar ist, ob eine Änderung relevant ist, erhält die Frage einen Entscheider und eine Frist. So bleibt der Klärungsstatus sichtbar und kann rechtzeitig eskaliert werden.
Im hypothetischen Fall übernimmt der Service Owner die fachliche Änderung, der Cloud-Architekt dokumentiert neue technische Abhängigkeiten und Einkauf stellt die Vertrags- und Lieferantenunterlagen bereit. Die NIS2-Koordination prüft diese Informationen gegen Scope-Register und Portalangaben. Sie entscheidet nicht anstelle der Fachrollen über jedes Detail, sorgt aber dafür, dass aus drei lokalen Änderungen ein zusammenhängender Governance-Vorgang wird. Der Abschluss des Migrationsprojekts wird an die Scope-Prüfung gekoppelt. Dadurch kann das Projekt nicht formal grün werden, während die Registrierungs- und Risikobasis noch den alten Provider beschreibt.
Die naheliegende Fehlsteuerung wäre, nur die sichtbaren Portalangaben zu aktualisieren. Damit wäre möglicherweise die Kontaktperson korrigiert, während die veränderten Wiederanlaufannahmen, Supportabhängigkeiten und Zugriffswege in den Maßnahmenregistern auf altem Stand blieben. Das Register braucht deshalb Beziehungen: Die Änderung verweist auf betroffene Dienste, Risiken, Maßnahmen, Nachweise und Entscheidungen. Die zuständigen Owner bestätigen, welche Artefakte weiter gelten, welche neu geprüft werden und welche Übergangsabweichung bis dahin besteht.
Für die Geschäftsleitung entsteht daraus eine echte Ressourcenaussage. Wenn der neue Provider technisch bereit ist, aber ein priorisierter Wiederherstellungstest und die Prüfung privilegierter Supportzugänge fehlen, stehen mehrere Optionen offen: Migration verschieben, nur einen begrenzten Teil freigeben oder die Restabweichung befristet akzeptieren. Die Vorlage muss Folgen, Frist, verantwortliche Rolle und Abbruchkriterium benennen. Der rote Punkt allein wäre dekorativ; die Entscheidung macht ihn nützlich.
2. Maßnahmen existieren, aber ihre Wirkung bleibt unbelegt
§ 30 BSIG nennt unter anderem Risikoanalyse, Incident-Bewältigung, Betriebskontinuität, Lieferkettensicherheit, sichere Entwicklung und Wartung, Wirksamkeitsbewertung, Schulung, Kryptografie, Personalsicherheit, Zugriffskontrolle und Multi-Faktor-Authentifizierung. Eine generische Liste vorhandener Policies ist dafür zu wenig.
Für die Steuerung sollte jede priorisierte Risikobehandlung das Geschäftsrisiko und den betroffenen Dienst mit einem Kontrollziel und einer konkreten Maßnahme verbinden. Hinzu kommen eine verantwortliche Rolle mit Entscheidungsbefugnis, der erwartete Nachweis, das Prüfintervall sowie der aktuelle Betriebs- und Wirksamkeitsstatus. Bleibt eine Abweichung offen, braucht sie eine Frist, eine Risikoentscheidung und einen Eskalationsweg. Diese Beziehungen sind wichtiger als die Anzahl der Kontrollzeilen, weil sie zeigen, wie aus einem Befund eine verantwortete Handlung wird.
„MFA vorhanden“ ist eine Existenzbehauptung. Aussagekräftiger ist: für welche privilegierten Zugänge MFA erzwungen wird, welche Ausnahmen bestehen, wie die Konfiguration geprüft wurde und wann die Wirksamkeit erneut bewertet wird.
3. Die Geschäftsleitung erhält Statusfolien statt Entscheidungen
§ 38 BSIG macht die Führungsdimension ausdrücklich. Ein quartalsweises Ampelbild ohne Quellen, Entscheidungsbedarf und Restunsicherheit reicht als Steuerungsinstrument nicht aus. Die Leitung benötigt entscheidungsfähige Vorlagen mit dem Risiko, den betroffenen Diensten, den verfügbaren Optionen, Kosten und Fristen, der zuständigen Entscheidungskompetenz und dem Nachweis, der später die Umsetzung belegt.
Aus professioneller Governance-Sicht sollte der Managementzyklus mindestens drei Dinge sauber trennen: bestätigte Tatsachen, fachliche Bewertung und Entscheidung. Sonst wird aus „Backup-Policy vorhanden“ schnell „Wiederherstellung beherrscht“. Zwischen beiden Aussagen liegt bekanntlich nur ein Restore-Test – und gelegentlich ein sehr langer Montag.
Auch die Nachweiszeitlinie muss trennscharf bleiben. § 39 BSIG verpflichtet Betreiber kritischer Anlagen, die Umsetzung der einschlägigen Maßnahmen zu einem vom BSI festgelegten Zeitpunkt nachzuweisen: frühestens drei Jahre nach erstmaliger und spätestens drei Jahre nach erneuter Einstufung als Betreiber einer kritischen Anlage, danach alle drei Jahre. Diese spezielle KRITIS-Nachweispflicht ist weder eine allgemeine dreijährige Übergangsfrist für alle wichtigen oder besonders wichtigen Einrichtungen noch ein Aufschub für Risikomanagement, Dokumentation oder Leitungssteuerung. Das Management sollte deshalb im Register kennzeichnen, welche Evidenz laufend für die eigene Steuerung benötigt wird und welche zusätzlich einem gesetzlichen KRITIS-Nachweiszyklus unterliegt.
Scope, Maßnahmen und Leitung bilden einen gemeinsamen Regelkreis
Die drei Lücken sind nicht unabhängig voneinander. Ein veralteter Scope führt dazu, dass Risiken für den falschen technischen oder organisatorischen Zustand bewertet werden. Darauf aufbauende Maßnahmen können formal vollständig und trotzdem am aktuellen Dienst vorbeigeplant sein. Das Management erhält anschließend einen beruhigenden Status, dessen Datenmodell bereits überholt ist. Governance muss diese Kette in umgekehrter Richtung schließen: Änderungen aktualisieren den Scope, der Scope bestimmt die Risikobetrachtung, Risiken bestimmen Maßnahmen und Nachweise, und offene Abweichungen werden zu Entscheidungen.
In der Praxis treffen dabei unterschiedliche Arbeitsrhythmen aufeinander. Projekte steuern auf einen Go-live zu, Einkauf auf Vertragstermine, IT-Betrieb auf stabile Changes, Sicherheitsfunktionen auf Risikoreviews und die Leitung auf periodische Entscheidungssitzungen. Keiner dieser Rhythmen ist falsch. Problematisch wird es, wenn ein früher Projekttermin eine spätere Governance-Entscheidung faktisch vorwegnimmt. Verbindliche Übergabepunkte verhindern das: Vor der technischen Freigabe muss der aktuelle Scope bestätigt sein; vor der Risikoakzeptanz müssen die fehlenden Nachweise und die zeitliche Begrenzung sichtbar sein; nach dem Go-live müssen Betriebsevidenz und offene Maßnahmen in den Regelbetrieb übergehen.
Die Nachweisarchitektur sollte diesen Regelkreis abbilden, ohne ein zweites Unternehmen aus Dokumenten zu errichten. Stabile IDs verbinden Dienst, Risiko, Maßnahme, Evidenz und Entscheidung. Version und Geltungszeitraum zeigen, welche Aussage zu welchem Betriebszustand gehört. Ein zentrales Register verweist auf die Fachartefakte, statt Kopien unkontrolliert zu vermehren. Auf diese Weise kann eine Führungskraft vom offenen Risiko bis zum letzten Test navigieren, während der technische Owner weiterhin im geeigneten Fachsystem arbeitet.
Typische Kennzahlen gewinnen erst in diesem Zusammenhang Bedeutung. Die Zahl geschlossener Maßnahmen sagt wenig, wenn kritische Dienste ohne aktuellen Wirksamkeitsnachweis bleiben. Aussagekräftiger sind überfällige Tests für priorisierte Maßnahmen, Scope-Änderungen ohne abgeschlossene Bewertung, befristete Ausnahmen nahe ihrem Ablauf und Entscheidungen ohne bestätigte Umsetzung. Jede Kennzahl erhält eine definierte Reaktion und einen Entscheider. Ohne diese Kopplung ist das Berichtswesen beschäftigt, aber nicht zwingend führend.
Ein konkreter 30-Tage-Plan nach der Registrierung
Tage 1–5: Registrierung und Scope zusammenführen
Legen Sie Registrierungsbestätigung, übermittelte Angaben und zuständige Kontakte kontrolliert ab. Gleichen Sie Rechtsträger, Sektoreinordnung und betroffene Dienste mit der internen Betroffenheitsanalyse ab. Für Kontaktdaten, IP-Bereiche, EU-Tätigkeiten, M&A, neue Dienste und Providerwechsel werden konkrete Change Trigger festgelegt. Portalpflege und Behördenkommunikation erhalten einen fachlichen Owner und eine benannte Vertretung.
Tage 6–15: Risiken, Maßnahmen und Nachweise verbinden
Priorisieren Sie die wichtigsten dienstbezogenen Risiken, nicht die längste Kontrollliste. Ordnen Sie jedem priorisierten Risiko konkrete Maßnahmen, Owner, Evidenz und ein Wirksamkeitskriterium zu. Fehlende oder veraltete Nachweise werden sichtbar gekennzeichnet; Dokumentenexistenz ist kein Ersatz für Wirksamkeit. Abweichungen wandern mit Frist, Budgetbedarf und Eskalationsweg in ein Maßnahmenregister.
Tage 16–23: Melde- und Krisenfähigkeit testen
§ 32 BSIG gibt für erhebliche Sicherheitsvorfälle eine gestufte Meldekette vor: unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung, eine frühe Erstmeldung; unverzüglich, spätestens innerhalb von 72 Stunden, eine bestätigte oder aktualisierte Vorfallmeldung mit erster Bewertung; und spätestens einen Monat nach der 72-Stunden-Meldung grundsätzlich eine Abschlussmeldung. Dauert der Vorfall dann noch an, tritt zunächst eine Fortschrittsmeldung an ihre Stelle. Die gesetzlichen Zeitfenster ersetzen keine interne Vorlaufzeit: Bewertung, Freigabe und Übermittlung müssen innerhalb derselben Uhr laufen.
Führen Sie deshalb eine kurze Tabletop-Übung durch: technischer Alarm, unvollständige Faktenlage, abwesender Hauptkontakt, Managemententscheidung und externe Kommunikation. Prüfen Sie Zeitstempel, Vertretung, Freigabebefugnis, sichere Kontaktwege und die Trennung zwischen bestätigten Fakten und Annahmen.
In einer hypothetischen Übung meldet das Monitoring am Freitagnachmittag ungewöhnliche Zugriffe auf einen priorisierten Dienst. Der technische Befund ist echt, seine Ursache aber offen. Der Hauptkontakt ist nicht erreichbar, und das erste Lagebild vermischt bestätigte Logdaten mit einer Vermutung über den Angriffsweg. Die Übung ist gelungen, wenn die Vertretung den Fall übernimmt, Annahmen sichtbar trennt und rechtzeitig eine freigabefähige Entscheidungsvorlage erzeugt. Sie ist nicht gelungen, nur weil alle Beteiligten nach 90 Minuten ein sehr vollständiges Protokoll ihrer Ratlosigkeit besitzen.
Der Test zeigt den Steuerungsmechanismus unter Last: Erkenntnis wird zeitgestempelt, Verantwortung wechselt kontrolliert, Unsicherheit erhält eine nächste Prüfzeit und Management bekommt Optionen statt Rohdaten. Aus den beobachteten Übergabefehlern entstehen Maßnahmen mit Ownern. Damit prüft die Organisation nicht nur ein Dokument, sondern die Fähigkeit, das dokumentierte Modell tatsächlich zu betreiben.
Im durchgehenden hypothetischen Szenario betrifft der Alarm den zuvor migrierten Dienst. Dadurch wird unmittelbar sichtbar, ob die Governance-Kette gehalten hat. Das Incident-Team benötigt den aktuellen Service Owner, die Supportkontakte des neuen Providers, die gültigen Zugriffswege und die jüngsten Nachweise. Verweist das Register noch auf den alten Betriebszustand, verliert das Team Zeit und die Leitung entscheidet auf unvollständiger Grundlage. Stimmen Scope und Verknüpfungen, kann die Vertretung den technischen Befund einordnen, ohne Sicherheit vorzutäuschen. Der Wert der Post-Registrierungsarbeit zeigt sich damit nicht im Portal, sondern in einer belastbaren Übergabe unter Zeitdruck.
Tage 24–30: Managemententscheidung und Regelbetrieb
Bereiten Sie ein kurzes Decision Brief mit Top-Risiken, Evidenzlücken, Optionen, Kosten und Fristen vor. Ressourcen, Risikoakzeptanzen und Eskalationen werden ausdrücklich entschieden. Danach werden monatliche operative Reviews und ein passender Managementrhythmus festgelegt. Scope-, Risiko-, Maßnahmen- und Nachweisregister erhalten eindeutige, miteinander verknüpfte IDs. Der nächste Wirksamkeitstest und die nächste Managementvorlage stehen bereits im Kalender, bevor der 30-Tage-Plan endet.
Danach beginnt die weniger spektakuläre, aber entscheidende Disziplin der Nachweispflege. Ein Restore-Test, ein Berechtigungsreview oder eine Lieferantenbewertung ist nicht dauerhaft aktuell, nur weil die Datei noch geöffnet werden kann. Jede Evidenz braucht deshalb einen fachlichen Gültigkeitsbezug: für welchen Dienst und Zeitraum sie gilt, welche Maßnahme sie stützt und welches Ereignis eine frühere Prüfung verlangt. Eine wesentliche Architekturänderung kann einen noch jungen Testbericht sachlich überholen.
Im monatlichen Review werden daher nicht Dokumente gezählt, sondern Aussagen geprüft. Der Betriebsstatus der Maßnahme, die Tragfähigkeit des Wirksamkeitsnachweises sowie gewachsene Ausnahmen und neue Abhängigkeiten werden gegen den beschriebenen Scope gehalten. Aus einem negativen Befund folgt entweder eine operative Korrektur oder eine sichtbare Risikoentscheidung. So bleibt die Registrierung mit dem tatsächlichen Betrieb verbunden, statt als administrativer Vorfall in einem abgeschlossenen Projektordner zu enden.
Eine kurze Managementprüfung hält die Registrierung im Betrieb
- Rechtsträger, Dienste, Portalangaben und aktuelle Scope-Analyse sind nachvollziehbar verbunden.
- Priorisierte Risiken führen zu konkreten Maßnahmen, aktueller Evidenz und Wirksamkeitskriterien.
- Änderungen, Ausnahmen und Nachweislücken haben Owner, Frist und Eskalationsweg.
- Leitungsunterlagen trennen Tatsachen, Bewertung, Optionen, Entscheidung und Umsetzungsnachweis.
- Melde- und Krisenrollen sind gegen die 24-Stunden-, 72-Stunden- und Monatsstufe mit Vertretung getestet; der nächste Review ist terminiert.
Fazit und A-R-C-Handlungsimpuls
Die Registrierung ist ein notwendiger administrativer Meilenstein. Compliance entsteht daraus erst durch laufende Risikosteuerung, wirksame Maßnahmen, aktuelle Nachweise und dokumentierte Managemententscheidungen.
Der sinnvolle nächste Schritt ist klein und überprüfbar: Wählen Sie einen kritischen Dienst und verbinden Sie innerhalb einer Woche Scope, Top-Risiken, Maßnahmen, Evidenz und offene Entscheidungen in einer einzigen steuerbaren Sicht. Wenn das für einen Dienst nicht gelingt, wird es für das Gesamtunternehmen nicht durch mehr Policies gelingen.
A-R-C unterstützt als Interim CISO und ISMS/GRC-Beratung dabei, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen – von Scope und Maßnahmensteuerung bis zu belastbaren Entscheidungs- und Evidenzwegen.
Abgrenzung
Dieser Beitrag ist eine fachliche Einordnung zu Informationssicherheit, Governance und Umsetzungspraxis. Er ersetzt keine Rechtsberatung, behördliche Auskunft, Zertifizierung oder unabhängige Prüfung. Betroffenheit, Pflichten, Fristen und zulässige Nachweise sind für den konkreten Rechtsträger und Sachverhalt zu prüfen. A-R-C garantiert weder Rechtskonformität noch eine Zertifizierung oder ein bestimmtes Prüfungsergebnis.
Primärquellen
- Bundesamt für Sicherheit in der Informationstechnik (BSI), „Cybersicherheitsrecht: NIS-2-Umsetzungsgesetz ab morgen in Kraft“, veröffentlicht am 05.12.2025, geprüft am 02.08.2026: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2025/251205_NIS-2-Umsetzungsgesetz_in_Kraft.html
- Bundesamt für Sicherheit in der Informationstechnik (BSI), „Zweiter Schritt zur NIS-2-Registrierung: BSI-Portal ab sofort freigeschaltet“, veröffentlicht am 06.01.2026, geprüft am 02.08.2026: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260601_NIS2_BSI-Portal.html
- Bundesministerium der Justiz/Bundesamt für Justiz, BSI-Gesetz (BSIG), insbesondere §§ 30, 32, 33, 38 und 39, geltende Fassung, geprüft am 02.08.2026: https://www.gesetze-im-internet.de/bsig_2025/BJNR12D0B0025.html
Über den Autor
Andreas Rühl unterstützt Unternehmen als Interim CISO und ISMS/GRC-Berater. Sein Schwerpunkt liegt darauf, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen.