Es beginnt selten mit einem direkten Angriff auf das eigene Haus. Häufiger startet die Kettenreaktion einige Sprünge entfernt: ein „Minor Incident“ bei einem SaaS-Anbieter, eine Schwachstelle in einer File-Transfer-Lösung, ein überprivilegierter Account beim Managed Service Provider, ein Update, das im Build-Prozess eines Partners kompromittiert wurde. Für die Öffentlichkeit sind das zunächst nur Randnotizen. Für Betreiber kritischer oder wichtiger Dienste können es jedoch die Sekunden sein, in denen aus einem Fremdproblem eine eigene Meldepflicht wird. Spätestens mit NIS2 ist klar: Wer auf Lieferketten setzt (und wer tut das nicht?), trägt Verantwortung – und zwar nicht nur für die Prävention, sondern auch für die Meldung. Dieses „NIS2 im Nacken“-Gefühl ist kein Aktionismus, sondern Ausdruck einer Realität, in der Abhängigkeiten Teil des Kernbetriebs sind.

Dieser Beitrag erklärt, warum Lieferkettenereignisse unter NIS2 meldepflichtig werden können, wie sich Meldewege, Schwellen und Verantwortlichkeiten in der Praxis anfühlen, welche Governance-Bausteine jetzt zählen – und wie man den Spagat schafft zwischen Transparenz, Tempo und Verlässlichkeit. Nicht als trockene Gesetzeslektüre, sondern als Betriebsanleitung für den Ernstfall.

In der Welt der Cybersicherheit ist es ein offenes Geheimnis: Kein Unternehmen kann sich allein verteidigen. Die Angreifer arbeiten längst nicht mehr isoliert – sie tauschen sich aus, handeln im Darknet mit Schwachstellen und Angriffswerkzeugen und nutzen koordinierte Kampagnen, um möglichst viele Ziele gleichzeitig zu treffen. Wer darauf nur mit einer isolierten Verteidigungsstrategie reagiert, läuft Gefahr, in der Informationslücke zwischen den Organisationen unterzugehen. Genau hier setzt eine der Kernideen von DORA an: den strukturierten und sicheren Informationsaustausch im Finanzsektor zu fördern. Die Botschaft dahinter ist klar – Sicherheit wird zur Gemeinschaftsaufgabe.

Der Gedanke ist so einfach wie kraftvoll: Wenn ein Unternehmen eine Bedrohung erkennt oder einen Angriff erlebt, können andere davon profitieren, diese Informationen schnell zu kennen. Ob es sich um neue Phishing-Muster, Zero-Day-Schwachstellen oder komplexe Supply-Chain-Angriffe handelt – je früher andere potenzielle Opfer gewarnt sind, desto besser können sie reagieren. DORA will diesen Austausch nicht nur ermöglichen, sondern systematisieren. Das Ziel: Angriffszeiten verkürzen, Verteidigungsmaßnahmen beschleunigen und die kollektive Widerstandsfähigkeit des gesamten Sektors steigern.

Auf dem Papier wirkt die Risikologik des EU AI Act zunächst wie eine saubere Sortierung: Einordnen, Pflichten ableiten, fertig. In der Praxis ist genau dieser Schritt einer der größten Stolpersteine. Nicht, weil Teams das Thema „nicht verstehen“, sondern weil Klassifizierung im Alltag selten an einem klaren, stabilen Entscheidungsprozess hängt. Stattdessen passiert sie oft nebenbei: im Projekt, im Einkauf, in der IT, manchmal in der Fachabteilung – je nachdem, wer gerade am schnellsten ist. Das Ergebnis ist dann eine Mischung aus gut gemeinten Annahmen und unvollständigen Informationen. Und genau dort entstehen Fehlklassifizierungen.

Warum ist das so kritisch? Weil die Risikoklasse im EU AI Act nicht nur ein Label ist. Sie steuert, wie streng Sie Anforderungen erfüllen müssen, welche Nachweise Sie brauchen, wie viel Governance-Takt sinnvoll ist – und welche Risiken Sie eingehen, wenn Sie zu locker oder zu streng einsortieren. Eine Fehlklassifizierung ist daher selten nur ein „Formfehler“. Sie führt typischerweise zu einem von zwei Problemen: Entweder Sie unterschätzen Pflichten und stehen später mit Lücken da. Oder Sie überziehen unnötig und bauen eine Governance, die Projekte bremst und dann umgangen wird. Beides ist gefährlich – nur auf unterschiedliche Weise.

Die Schutzbedarfsfeststellung ist eine der zentralen Grundlagen der Informationssicherheit – und trotzdem gehört sie zu den am meisten unterschätzten Disziplinen. Viele Unternehmen starten in Projekte, schreiben Sicherheitskonzepte oder definieren Maßnahmen, ohne vorher genau zu wissen, welchen Schutzbedarf ihre Informationen und Systeme eigentlich haben. Das Ergebnis sind oft überdimensionierte Lösungen, die Zeit und Geld verschwenden, oder zu schwache Schutzmechanismen, die kritische Werte unzureichend absichern. Eine systematische und pragmatische Einstufung verhindert genau das. Sie sorgt dafür, dass Sicherheitsmaßnahmen zielgerichtet und angemessen sind – nicht zu wenig, aber auch nicht zu viel. Und das Beste: Mit einer klaren Methode ist die Schutzbedarfsfeststellung weder kompliziert noch bürokratisch, sondern ein handfestes Planungswerkzeug.

Die Schutzziele im Kern – plus zwei, die oft vergessen werden

Der Kern der Schutzbedarfsermittlung besteht darin, für jedes Asset – also jede Information, jedes IT-System, jede Anwendung, jede Schnittstelle und jeden Prozess – festzulegen, wie hoch die Anforderungen an Vertraulichkeit (C), Integrität (I) und Verfügbarkeit (A) sind.

NIS2 und ISO 27001 begegnen sich in vielen Unternehmen gerade auf eine Weise, die erst einmal „logisch“ wirkt – und dann erstaunlich schnell anstrengend wird: Man hat ein etabliertes ISMS, dazu ein Set an Kontrollen, Richtlinien und Nachweisen. Dann kommt NIS2, und plötzlich entstehen neue Listen, neue Workstreams, neue Maßnahmenpläne, neue Reportings. Alles mit gutem Grund. Und trotzdem bleibt bei vielen Teams am Ende ein Gefühl: Wir machen vieles doppelt, und trotzdem sind wir nicht sicher, ob es wirklich besser geworden ist.

Genau hier lohnt sich ein Perspektivwechsel. Denn NIS2 ist kein Ersatz für ISO 27001, aber es zwingt dazu, den Blick zu erweitern: weg von „Sicherheitsmanagement als System“ hin zu „Sicherheits- und Resilienzfähigkeit als Betriebsrealität“. ISO 27001 liefert Ihnen die Struktur, um Informationssicherheit systematisch zu managen. NIS2 setzt stärker auf die Frage, ob diese Struktur in der Praxis spürbar wirkt – besonders dort, wo es unangenehm wird: bei Incidents, bei Lieferkettenabhängigkeiten, bei Managementverantwortung, bei operativer Steuerung. Das ist keine Kritik an ISO 27001. Es ist eine Erinnerung daran, dass ein Managementsystem erst dann seine Stärke zeigt, wenn es den Betrieb stabilisiert, nicht nur Dokumente erzeugt.