NIS2: Wer ist betroffen? Direkt, indirekt – und über die Lieferkette

Viele Organisationen schätzen ihr Risiko unter NIS-2 falsch ein. Nicht, weil sie uninformiert sind, sondern weil sie nur auf formale Schwellen schauen: Branche, Größe, gesetzliche Definitionen. In der Realität entsteht Betroffenheit in drei Wegen – und zwei davon funktionieren ohne formalen Bescheid. Wer das ignoriert, steht im Ernstfall ohne Nachweise , ohne vertragliche Absicherung der Lieferkette und ohne geübte Meldewege da.

Die drei Wege der Betroffenheit

1. Direkt betroffen : Unternehmen, die formal als „wesentlich“ oder „wichtig“ eingeordnet werden. Sie tragen explizite Pflichten zu Governance , Risikomanagement, technischen/organisatorischen Maßnahmen und Incident -Meldungen.

2. Indirekt betroffen : Dienstleister und Zulieferer, die für direkt betroffene Kunden arbeiten. Die Anforderungen kommen per Vertrag: Mindestkontrollen (z. B. phishingsichere MFA, Patch-SLOs), Audit - und Nachweisrechte, Meldefristen, Notfallkontakte.

3. Faktisch betroffen : Unternehmen ohne formale Einordnung, deren Ausfall aber kritische Kundenprozesse blockiert. Spätestens beim Onboarding oder der Rezertifizierung werden sie auf die gleichen Kontrollen verpflichtet – oder verlieren Aufträge.

Der Unterschied ist juristisch relevant, operativ aber zweitrangig: In allen drei Fällen müssen Sie zeigen, dass Ihre IT-Sicherheit angemessen, dokumentiert und wirksam ist.

Warum Größe nicht das Kriterium ist

Akute Betroffenheit entsteht aus Wirkungsketten: Wenn Ihr System stillsteht und dadurch Produktion, Logistik oder Bürgerdienste eines Kunden ausfallen, zählt nicht Ihre Mitarbeiterzahl, sondern die Abhängigkeit. Typische Trigger sind Internet-exponierte Schnittstellen, Admin-Zugriffe auf Kundensysteme, Verarbeitung sensibler Daten oder Betriebsverantwortung für zentrale Plattformen. Kurz: Wer eine kritische Funktion ermöglicht oder beeinflusst, wird geprüft – formal oder vertraglich.

Indirekter Druck: Compliance „von oben nach unten“

Direkt betroffene Auftraggeber reichen Pflichten in ihre Lieferkette weiter. Das ist kein „Nice to have“, sondern Überlebensstrategie: Ein Schwachpunkt beim Dienstleister ist ein Schwachpunkt im eigenen Audit. Erwartet werden daher klare Mindeststandards – ohne Vendor-Namen, aber mit prüfbarer Wirkung:

• Identitäten zuerst : phishingsichere MFA für privilegierte Rollen, Abschaltung schwacher Legacy-Protokolle.

• Patch-Disziplin : verbindliche Fristen nach Exponierung (Internet vs. intern), dokumentierte Ausnahmen mit Kompensation.

• Backups mit Beweis : Integritätsnachweis und zeitgestoppte Wiederherstellung.

• Meldeweg & Ansprechpartner: 24/7-Kontakt, definierte Schwellen, Protokoll der Erstmeldung.

• Protokollierung : nachvollziehbare Logs über kritische Zugriffe und Änderungen – revisionssicher, zweckgebunden.

Wer das liefern kann, besteht das Onboarding; wer nicht, fliegt aus Shortlists – unabhängig von der formalen NIS-2-Einordnung.

Häufige Fehlannahmen – nüchtern entkräftet

• „Wir sind zu klein.“ – Bis ein großer Kunde Ihre Plattform als kritisch einstuft. Dann gelten dessen Regeln sofort.

• „Ein Zertifikat reicht.“ – Nein. Zertifikate sind Helfer, ersetzen aber keine gelebten Prozesse, Audits und Nachweise.

• „Melden wir später, wenn alles klar ist.“ – Meldepflichten verlangen frühzeitige, strukturierte Erstmeldungen mit Aktualisierung.

• „Das macht die IT.“ – NIS-2 adressiert Leitungspflichten. Budget, Risiken, Eskalationen sind Governance -Themen.

Was jetzt sinnvoll ist (ohne Aktionismus)

Beginnen Sie dort, wo Versagen teuer wird, und schaffen Sie Belege statt Absichtserklärungen:

• Risikokarte & Verantwortlichkeiten: Welche Services sind für Kunden kritisch? Wer entscheidet im Vorfall? Schriftlich, freigegeben, auffindbar.

• Kontroll-Runbooks : Je Maßnahme eine Seite: Ziel, Trigger, Schritte, Owner, Beweisführung (Screens, Logs, Tickets).

• Lieferketten-Stufenmodell : Desk-Review für alle, Remote-Nachweise für „hoch“, gezielte Tests für „kritisch“. Fristen und Eskalation sind vertraglich geregelt.

• Incident-Kommunikation : Vorlagen und Kontaktmatrizen (intern/extern), Schwellenwerte, Out-of-Band-Kanäle – einmal geprobt, nicht nur beschrieben.

• Beleg-Disziplin : „Nicht dokumentiert“ gilt im Audit als „nicht passiert“. Sammeln, versionieren, zentral ablegen.

Kennzahlen, die im Zweifel tragen

• MFA-Abdeckung (phishing-resistent) bei privilegierten Rollen.

• Patch-SLO-Einhaltung getrennt nach Internet-exponiert/intern.

• Restore-Zeit & Integritätsnachweis für zwei geschäftskritische Prozesse.

• Zeit bis Erstmeldung und Vollständigkeit der Incident -Erstinformation.

• Lieferketten-Fitness : Anteil kritischer Partner mit aktuellen Nachweisen und funktionierendem 24/7-Kontakt.

Diese KPIs sind kein Selbstzweck; jede Abweichung braucht eine definierte Konsequenz (Eskalation, Change-Freeze, Zusatzprüfung). Nur so wird Governance wirksam.

Fazit

Die Frage „Sind wir formal NIS-2?“ ist wichtig – aber nicht die entscheidende. Entscheidend ist, ob Sie zeigen können, dass Ihre Kontrollen angemessen sind, funktionieren und im Notfall belastbar belegt werden. Direkt, indirekt oder faktisch betroffen: Das Ergebnis zählt. Wer heute Verantwortlichkeiten klärt, Runbooks schreibt, Lieferkette vertraglich absichert und Belege sammelt, besteht nicht nur das nächste Audit – er reduziert real das Risiko von Ausfällen und Folgekosten.

FAQ zum Blogbeitrag

Wer ist von NIS-2 betroffen – nur direkt gelistete Unternehmen?

Nein. Neben direkt eingestuften Firmen sind auch Dienstleister und Zulieferer indirekt betroffen, etwa durch vertragliche Anforderungen im Onboarding oder in der Lieferketten.

Was löst eine NIS-2-Betroffenheit aus?

Typische Trigger sind Adminzugriffe auf Kundensysteme, die Verarbeitung sensibler Daten sowie kritische Abhängigkeiten in Produktion, Logistik oder IT-Plattformen.

Wie kann ein Unternehmen die Angemessenheit seiner IT-Sicherheit nachweisen?

Durch messbare Kennzahlen wie MFA-Abdeckung, Einhaltung von Patch-SLOs, dokumentierte Restore-Tests sowie strukturierte Incident-KPIs.

Welche Anforderungen stellen Kunden im Rahmen von NIS-2?

Gefordert werden belastbare Nachweise, vertraglich geregelte Auditrechte, klare Meldefristen und definierte 24/7-Kontakte.

Was ist die häufigste Fehlannahme bei NIS-2?

„Wir sind zu klein.“ Diese Annahme endet, sobald der eigene Ausfall kritische Prozesse eines Kunden beeinträchtigt.