NIS2 und die Lieferkette: Warum die Sicherheit Ihrer Anbieter jetzt Ihr Risiko ist

Der Fragebogen, der die Lieferkette sichtbar macht

Anna bekommt den Fragebogen um 9:13 Uhr. Der DACH-B2B-Zulieferer hat 54 Mitarbeitende, liefert Bauteile an mehrere Industriekunden in der DACH-Region und arbeitet mit einem externen IT-Dienstleister, einem CRM, einer Buchhaltungsplattform, einem Website-Hoster, mehreren SaaS-Werkzeugen und einigen n8n-Automationen. Bis zu dieser E-Mail wirkte das vernünftig verteilt. Jetzt fragt ein Großkunde nach Lieferantensicherheit: Wer verarbeitet Kundendaten? Welche Anbieter haben privilegierten Zugriff? Wo liegen Restore-Nachweise? Wer ist Incident-Kontakt? Welche Lieferanten wurden technisch geprüft?

Niemand im Team hat die Antworten vollständig. Lena aus Einkauf kennt Verträge und Erneuerungstermine. Markus, der technische Koordinator, kennt CRM, Website, Automationen und Backup-Fragen. Omar, der externe MSP-Kontakt, administriert Identität, Endgeräte und mehrere SaaS-Integrationen. Anna muss am Ende entscheiden, welche Antwort gegenüber dem Kunden belastbar ist. Der Fragebogen ist nicht das eigentliche Problem. Er zeigt nur, dass die digitale Lieferkette bisher aus Rechnungen, Admin-Panels, E-Mails und persönlicher Erinnerung bestand.

Das Szenario ist illustrativ, aber der Mechanismus ist realistisch für KMU mit 10 bis 100 Mitarbeitenden. Viele Unternehmen haben sensible digitale Fähigkeiten ausgelagert, bevor sie ein internes Betriebsbild aufgebaut haben. Ein Anbieter hostet die Website, ein anderer hält Backups, ein SaaS-Tool speichert etwa 18.000 Kundendatensätze, vier Anbieter haben privilegierten Zugriff, sieben Workflows berühren Kundendaten, neun Automationen laufen täglich. Solange nichts passiert, wirkt das überschaubar. Sobald ein Kunde, Versicherer, Auditor oder Incident fragt, wird daraus ein Nachweisproblem.

Warum NIS2 Lieferantenrisiko operativ macht

NIS2 ist nicht nur ein neues Wort für IT-Sicherheit. Die Richtlinie (EU) 2022/2555 verbindet Cybersecurity-Risikomanagement mit technischen, operativen und organisatorischen Maßnahmen. Für Einrichtungen im Anwendungsbereich nennt Artikel 21 unter anderem Risikoanalyse, Incident Handling, Business Continuity, Backup, Krisenmanagement, Lieferkettensicherheit, sichere Beschaffung, Wirksamkeitsprüfung, Cyberhygiene, Schulung, Zugriffskontrolle und Asset Management. Dieser Artikel ist keine Rechtsberatung und entscheidet nicht, ob Ihr Unternehmen wesentlich, wichtig oder gar nicht direkt betroffen ist. Er betrachtet die Betriebsarbeit, die aus Lieferantenrisiko entsteht.

Der Lieferkettenpunkt ist wichtig, weil er die Verantwortung aus dem eigenen Serverraum heraus erweitert. Artikel 21 nennt die Sicherheit in Beziehungen zu direkten Lieferanten und Dienstleistern. Das deutsche BSI beschreibt Lieferkettensicherheit ebenfalls als Teil eines umfassenden Risikomanagements: Anbieterlisten, Prozesse, Wirksamkeitsprüfungen, Audits, Krisenübungen, SLAs, Incident Handling, Patch Management und nachvollziehbare Prozesse zählen mehr als ein einzelner Ordner mit Zertifikaten. Gleichzeitig warnt das BSI sinngemäß davor, Standards oder Prüfungen automatisch mit Erfüllung gleichzusetzen. Ein Zertifikat kann helfen. Es ersetzt nicht die Frage, welcher Anbieter welchen Workflow beeinflusst.

Für viele KMU entsteht der Druck nicht zuerst über eine Behörde. Er kommt über Kunden, Muttergesellschaften, Versicherer, Ausschreibungen oder eigene Managementfragen. Ein größerer Kunde muss seine Lieferkette erklären und bittet deshalb den kleineren Zulieferer um Nachweise. Ein Cyberversicherer will wissen, welche Dienstleister kritische Systeme administrieren. Ein Incident bei einem SaaS-Anbieter zwingt die Geschäftsführung zur Entscheidung, ob Kundendaten, Lieferfristen oder Wiederherstellung betroffen sind. Die juristische Einstufung bleibt eine eigene Prüfung. Die operative Frage beginnt früher: Welche Lieferanten wären morgen erklärbar?

Die fünf Vendor-Risiken, die KMU zuerst kartieren sollten

Ein Lieferantenregister wird schnell unübersichtlich, wenn jedes Abo gleich wichtig wirkt. Deshalb sollte ein kleines Team zuerst die Risiken kartieren, die unter NIS2-, Kunden- und Incident-Druck am häufigsten Fragen auslösen. Die erste Kategorie ist Datenverarbeitung. Welche Anbieter speichern, übertragen oder analysieren Kundendaten, Vertragsdaten, Zahlungsdaten, Produktionsdaten oder Support-Historien? Ein Newsletter-Tool ist anders zu bewerten als ein CRM mit kompletter Kundenhistorie. Ein Dateispeicher mit Projektunterlagen ist anders zu behandeln als ein Terminbuchungswerkzeug ohne sensible Inhalte.

Die zweite Kategorie ist privilegierter Zugriff. Der externe MSP, die Agentur mit Admin-Rechten im CMS, der Cloud-Partner mit Root-Zugriff, das Monitoring-Tool mit Leserechten auf Infrastruktur und das Automationskonto mit Schreibrechten in CRM und Buchhaltung sind keine normalen Lieferanten. Sie können Stabilität verbessern, aber auch Schaden vergrößern, wenn Zugriff, Offboarding, MFA, Protokollierung und Break-glass-Regeln nicht nachvollziehbar sind. Hier hilft keine pauschale Vertrauensformel. Es braucht Owner, Zweck, Umfang, Review-Datum und einen dokumentierten Entzugspfad.

Die dritte Kategorie sind kritische Workflows. Ein Anbieter kann wenig sensible Daten halten und trotzdem geschäftskritisch sein. Wenn ein Logistikdienstleister Versandstatus liefert, eine SaaS-Plattform Angebotsfreigaben steuert oder ein Zahlungsanbieter Rechnungsprozesse blockieren kann, geht es um Verfügbarkeit und Entscheidungsfähigkeit. Die vierte Kategorie ist Backup und Wiederherstellung. Wer hält Restore-Nachweise? Wer kann eine Wiederherstellung auslösen? Welche Anbieter beeinflussen RTO, RPO, Verschlüsselung, Aufbewahrung oder Testprotokolle? Die fünfte Kategorie ist Incident-Kommunikation: Wer meldet einen Vorfall, an wen, in welcher Frist, mit welchen Informationen und auf welchem Eskalationsweg?

Das BSI empfiehlt bei der Risikoanalyse, Assets und Geschäftsprozesse zu identifizieren, Schutzbedarfe für Vertraulichkeit, Integrität und Verfügbarkeit zu bewerten, Bedrohungen und Schwachstellen zu betrachten, Verantwortliche zuzuweisen und Ergebnisse zu dokumentieren. Genau diese Logik lässt sich auf Lieferanten übertragen. Es geht nicht darum, alle Anbieter am ersten Tag perfekt zu bewerten. Es geht darum, die Top-10-Risiken sichtbar zu machen, bevor der nächste Fragebogen eine Sofortantwort verlangt.

Vom Lieferantenregister zum Nachweis-Workflow

Ein Spreadsheet kann ein guter Anfang sein. Es wird erst dann wertlos, wenn es wie ein Archiv behandelt wird. Ein wirksames Lieferantenregister beantwortet nicht nur, wen Sie bezahlen. Es beantwortet, welche digitale Fähigkeit der Anbieter berührt, welche Datenklasse betroffen ist, wer intern verantwortlich ist, welche Evidenz vorliegt, wann der nächste Review fällig ist und welche Ausnahme bewusst akzeptiert wurde. Damit wird aus einer Liste ein Betriebsartefakt.

Die Grundfelder sind einfach: Anbietername, Service, Business Owner, technischer Owner, Datenklasse, Kritikalität, Zugriffstyp, Vertrags- oder SLA-Kontext, Incident-Kontakt, letzte Evidenz, nächstes Review-Datum, offene Lücken, Entscheidung. Für Anbieter mit Kundendaten, privilegiertem Zugriff oder Recovery-Auswirkung reicht ein kaufmännischer Owner nicht. Markus prüft technische Evidenz, Anna entscheidet über kritische Ausnahmen, Lena verfolgt Fristen und Kontaktwege. n8n erinnert an fällige Reviews, eskaliert überfällige Evidenz und erzeugt eine Statusliste für den Monatsreview.

Der wichtigste Unterschied liegt im Review-Gate. Neue oder erneuerte kritische Anbieter bekommen einen 15-Minuten-Lieferantencheck. Die Fragen sind nicht kompliziert: Welche Daten verarbeitet der Anbieter? Welchen Zugriff hält er? Welchen Workflow beeinflusst er? Welcher Incident-Kontakt ist gültig? Welche Wiederherstellung hängt an ihm? Welche Evidenz liegt vor, und welche fehlt? Wenn eine Antwort fehlt, ist das nicht automatisch ein Stoppschild. Es ist eine Entscheidung: akzeptieren, anfordern, kompensieren, ersetzen oder eskalieren.

Ein realistisches KMU-Szenario: 36 Anbieter, ein Kunde, eine Frist

Zurück zu diesem DACH-B2B-Zulieferer. Der Fragebogen des Großkunden hat 42 Sicherheitsfragen. Im alten Zustand hätte das Team zwei Tage lang Informationen gesucht. Lena hätte Verträge geöffnet, Markus hätte Screenshots aus Admin-Oberflächen gesammelt, Omar hätte Backup- und Identity-Fragen beantwortet, Anna hätte zwischen Vertrieb und Technik vermittelt. Am Ende wären viele Antworten technisch halb richtig, aber nicht als wiederholbarer Nachweis nutzbar gewesen.

Nach einem ersten Vendor-Risk-Sprint sieht der Arbeitsstand anders aus. Nicht alles ist gelöst, und das muss auch so benannt werden. Von 36 digitalen Anbietern sind die Top-10 priorisiert. Vier Anbieter mit privilegiertem Zugriff haben Owner, Zugriffszweck, MFA-Status, Kontaktweg, Review-Datum und offene Evidenzlücken. Zwei Restore-Nachweise, die bisher nur beim Dienstleister lagen, sind angefragt. Ein SaaS-Workflow mit Kundendaten bekommt einen dokumentierten Fehlerpfad und eine menschliche Review-Grenze. Lena sieht monatlich, welche Nachweise fehlen. n8n eskaliert überfällige Einträge. Anna entscheidet nur noch über die Ausnahmen, die wirklich Geschäftsrisiko tragen.

Die Wirkung ist nicht "Compliance erledigt". Das wäre falsch und unseriös. Die Wirkung ist Entscheidungsfähigkeit. Das Team kann dem Kunden sagen, welche Lieferanten geprüft wurden, wo Evidenz vorliegt, wo Lücken bestehen und wer die nächste Entscheidung trägt. Es kann außerdem erklären, dass rechtliche Meldungen oder Kundenkommunikation bei Datenschutzverantwortlichen, Rechtsberatung, Management oder offiziellen Stellen liegen, während der Betriebsworkflow die Fakten bereitstellt. Diese Trennung ist wichtig: Architektur unterstützt Compliance-Readiness, sie ersetzt keine Rechtsbewertung.

Auch Einwände werden praktischer. "Wir sind zu klein für NIS2" wird getrennt von "Können wir Kundenfragen beantworten?" "Unser MSP macht Security" wird übersetzt in "Wer besitzt MSP-Zugriff, Restore-Evidenz, Incident-Kontakt und Offboarding?" "Der Anbieter hat ISO 27001" wird ergänzt durch "Welchen unserer Workflows betrifft das, und welche Ausnahme haben wir akzeptiert?" So wird die Diskussion weg von Beruhigung und hin zu Verantwortung geführt.

Technischer Deep-Dive: Wie die Vendor-Risk-Schleife gebaut wird

Der technische Kern ist keine schwere GRC-Suite. Für ein KMU ohne eigenes Security- oder Plattformteam reicht oft ein leichtes Architekturmodell: ein zentrales Register als Quelle der Wahrheit, ein Evidence-Ordner oder Git-Repository für Nachweise, ein n8n-Workflow für Fristen und Eskalationen, ein Runbook für Supplier-Incidents, eine Review-Notiz für Managemententscheidungen und klare Zugriffsprüfungen für privilegierte Anbieter. Entscheidend ist, dass die Schleife wiederholbar ist.

Eine einfache Datenstruktur sieht so aus:

vendor-risk-register
├── supplier: Name, service, contract owner, technical owner
├── exposure: data class, privileged access, critical workflow, recovery role
├── evidence: certificate, SLA, security contact, restore proof, questionnaire
├── review: due date, reviewer, decision, exception, next action
├── incident: contact path, notification source, affected workflows, runbook
└── audit trail: timestamp, change, reviewer, accepted risk, follow-up

Das Register kann zuerst eine strukturierte Tabelle sein. Für stärker technische Umgebungen kann es in Git liegen, damit Änderungen reviewbar werden. Wichtig ist nicht die Plattform, sondern die Eigentumsgrenze: Jede Zeile hat einen Business Owner und einen technischen Owner. Jede kritische Ausnahme hat eine Entscheidung. Jede fehlende Evidenz hat ein Datum. Jeder Supplier-Incident hat einen Kontaktpfad. Jeder Review hinterlässt eine Notiz, die später erklärt, warum etwas akzeptiert oder geändert wurde.

n8n passt hier nicht als "magische Compliance-Automation", sondern als Orchestrierung für wiederholte Arbeit. Ein Workflow kann monatlich fehlende Evidenz abrufen, Review-Tickets erstellen, überfällige Einträge eskalieren, Supplier-Incident-Meldungen an die richtigen Rollen leiten und Statuslisten für Anna, Markus und Lena erzeugen. Die Entscheidung bleibt menschlich. Automatisierung sorgt dafür, dass die Entscheidung rechtzeitig, mit Kontext und mit Spur passiert.

Das Incident-Runbook verbindet Lieferantenrisiko mit Reaktionsfähigkeit. Die BSI-Hinweise zur Meldepflicht beschreiben für betroffene Einrichtungen unter anderem frühe Meldung, Folgeinformationen, Verantwortlichkeit trotz Dienstleistermeldung und geeignete Kontakte. Ein KMU sollte daraus keine eigene Rechtsdiagnose ableiten. Es sollte aber operativ wissen, welche Lieferantenmeldung intern bewertet wird, wer Daten- oder Workflow-Auswirkung prüft, wann ein Prozess pausiert wird, wer Kundenkommunikation vorbereitet und welche Rolle Rechtsberatung oder Datenschutzverantwortliche übernehmen.

Wie Planfold aus Lieferantenrisiko Betriebsfähigkeit baut

Planfold betrachtet Lieferantenrisiko nicht als Formularsammlung, sondern als Betriebsschicht. Plan bedeutet: Abhängigkeiten, Datenflüsse, privilegierte Zugänge, Verträge, Incident-Kontakte, Restore-Nachweise und bestehende Fragebogenantworten auditieren. Das Ergebnis ist keine große Compliance-Behauptung, sondern eine priorisierte Lieferantenkarte: Was ist kritisch, was ist unklar, wer entscheidet und wo fehlt Evidenz?

Unfold bedeutet: den Workflow bauen. Das kann eine Git- oder Tabellen-basierte Registerstruktur sein, n8n-gestützte Reminder, technische Review-Checklisten, Zugriffskontrollroutinen, Restore-Nachweisablage, Supplier-Incident-Runbooks und Management-Review-Notizen umfassen. Infrastrukturstandardisierung hilft dort, wo Lieferantenrisiko mit Hosting, Backups, Zugriff, Deployment oder Wiederherstellung zusammenhängt. Kubernetes-Betrieb und cloud-native Delivery sind nur dort relevant, wo der Aufwand zur Anwendung passt. CKA, CKAD und LFCS sind Fähigkeitsnachweise für kritische Betriebsarbeit, keine Compliance-Badges.

Resonate bedeutet: den Nachweis aktuell halten. Monatliche oder quartalsweise Reviews, überfällige Evidenz, Lieferantenwechsel, neue Automationen, Incident-Learnings und Restore-Tests fließen zurück in das Register. So bleibt das System klein genug für ein Team ohne Plattformabteilung und robust genug, um Kundenfragen nicht jedes Mal neu aus Erinnerung zu rekonstruieren. Das ist der Unterschied zwischen einem Fragebogenprojekt und einer digitalen Maschine, die ihre Abhängigkeiten kennt.

Die Grenze bleibt klar: Planfold gibt keine Rechtsberatung, zertifiziert keine NIS2-Konformität, führt keine formalen Penetrationstests als Compliance-Ersatz durch und entscheidet nicht, ob Ihr Unternehmen wesentlich oder wichtig ist. Planfold kann die Architektur, Routinen und Nachweisschicht bauen, die qualifizierte Rechts-, Datenschutz- und Managemententscheidungen mit belastbaren Fakten versorgt.

Ein 30-Tage-Startplan für Lieferantenrisiko

Ein brauchbarer Start muss klein genug sein, um wirklich zu passieren. In Woche 1 listen Sie die wichtigsten digitalen Anbieter: SaaS, Cloud, Hosting, MSP, Automatisierung, Backup, Monitoring, Payment, Logistik, Support, Entwicklungspartner. Markieren Sie nicht alle gleich. Markieren Sie Anbieter mit Kundendaten, privilegiertem Zugriff, kritischem Workflow, Recovery-Rolle oder Incident-Bedeutung. Das ist Ihre erste Risikoauswahl.

In Woche 2 klassifizieren Sie die Top-10. Für jeden Anbieter bestimmen Sie Business Owner, technischen Owner, Datenklasse, Zugriffstyp, betroffene Workflows, Incident-Kontakt und vorhandene Evidenz. Fehlt etwas, bekommt es keinen grünen Haken, sondern eine offene Aktion. In Woche 3 sammeln Sie Nachweise: SLA, Sicherheitskontakt, Zertifikat, Restore-Test, Backup-Auszug, Fragebogenantwort, Zugriffsliste, Patch- oder Incident-Prozess. Akzeptieren Sie, dass nicht alles sofort da ist. Entscheidend ist, dass die Lücke sichtbar wird.

In Woche 4 legen Sie den Review-Rhythmus fest. Kritische Anbieter werden bei Erneuerung, größerer Änderung oder fehlender Evidenz geprüft. Lena sieht monatlich fällige Reviews. Markus prüft technische Evidenz bei Kundendaten, privilegiertem Zugriff oder Recovery-Auswirkung. Anna entscheidet kritische Ausnahmen. Ein kurzer Supplier-Incident-Pfad hält fest, wer informiert wird, welche Workflows geprüft werden und wann qualifizierte Rechts- oder Datenschutzverantwortliche übernehmen.

Wenn Ihr Unternehmen gerade einen Kundenfragebogen nicht belastbar beantworten kann, ist das kein Grund für Theater. Es ist ein guter Startpunkt. Welche Anbieter sind kritisch? Wer besitzt die Beziehung? Welche Evidenz liegt vor? Welche Lücke ist akzeptiert, welche muss geschlossen werden? Und welcher Workflow sorgt dafür, dass diese Antworten in drei Monaten nicht wieder verschwunden sind?

Lieferantensicherheit wird nicht leichter, wenn sie bis zum nächsten Fragebogen liegen bleibt. Sie wird leichter, wenn sie Teil des Betriebs wird: sichtbar, zuständig, wiederholbar und ehrlich über offene Lücken.