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