¶ Lieferketten-Risikomanagement
Leeres Musterverfahren – keine reale Lieferantenbewertung: Diese öffentliche Beispielseite enthält keine echten Anbieter, Verträge, Unterauftragnehmer, Preise, Regionen, Schwachstellen, Konten, Schlüssel, Prüfberichte oder Risikoentscheidungen. Farben, Musterwerte und Statusangaben erläutern nur das vorgesehene Verfahren.
Drittleistung ersetzt keine eigene Steuerung: Ein Zertifikat, Prüfbericht, Vertrag oder großer Markenname belegt weder die Eignung für den konkreten relevanten Dienst noch die Wirksamkeit eigener Kundenkontrollen, Kontinuität oder Exit-Fähigkeit.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-VER-05-01 |
| Dokumentenart | Verfahrensbeschreibung und Registermodell für Lieferketten- und Drittparteienrisiken |
| Wiki.js-Pfad | /NIS2/05-Lieferkette-und-Drittparteien/Lieferketten-Risikomanagement |
| Verantwortlich | Einkauf/Lieferantenmanagement und Informationssicherheitsfunktion |
| Mitwirkende | Dienst-Owner, IT-/OT-Betrieb, Recht, Datenschutz, BCM, Entwicklung und Fachbereiche |
| Status | Entwurf – keine realen Lieferanten, Produkte oder Verträge bewertet |
| Version / Stand | 0.1 / 09.08.2026 |
| Schutzklasse | Wiki enthält Methodik und anonymisierte Muster; Verträge, Bewertungen und Sicherheitsnachweise geschützt |
| Rechtsbezug | insbesondere § 30 Absatz 2 Nummer 4 und 5 BSIG; abhängig von der Einrichtungsart zusätzlich Durchführungsverordnung (EU) 2024/2690 |
| Freigabe | Ausstehend; Scope, Kritikalitätsklassen, Prüftiefe, Vertragsmindestanforderungen und Eskalation festzulegen |
Lieferanten, Produkte, Dienste, Unterauftragnehmer und Exit dienstbezogen steuern. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Steuerungscockpit – Muster ohne Echtdaten
Ein Gedankenstrich bedeutet kein Messwert im Muster-Wiki. Er darf nicht als Null, vollständige Prüfung oder wirksame Kontrolle interpretiert werden.
■ Kritische Beziehungen ohne Owner
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
▲ Offene Vertragslücken
—
Vorfall, Audit, Schwachstelle, Exit
—
Vorfall, Audit, Schwachstelle, Exit
● Überfällige Lieferantenreviews
—
Nachweis und Risikostatus offen
—
Nachweis und Risikostatus offen
? Ungetestete Ersatz-/Exit-Wege
—
Portabilität und Mindestbetrieb
—
Portabilität und Mindestbetrieb
Ein produktives Cockpit nennt Stichtag, Grundgesamtheit, Kritikalitätsklassen, überfällige Prüfungen, Datenquellen und Aussagegrenzen. Ein grüner Status erfordert ein festgelegtes Kriterium, einen aktuellen Nachweis und eine bestätigte Bewertung.
¶ 2. End-to-End-Steuerung auf einen Blick
1 · Bedarf und Scope
Dienst, Produkt, Leistung, Daten, Zugriff
Dienst, Produkt, Leistung, Daten, Zugriff
2 · Einstufung
Kritikalität, Abhängigkeit, Lieferkette
Kritikalität, Abhängigkeit, Lieferkette
3 · Auswahl und Vertrag
Due Diligence, Anforderungen, Entscheidung
Due Diligence, Anforderungen, Entscheidung
4 · Einführung und Betrieb
Abnahme, Monitoring, Nachweise, Änderungen
Abnahme, Monitoring, Nachweise, Änderungen
5 · Vorfall und Eskalation
Meldung, Kooperation, Behandlung, Lernen
Meldung, Kooperation, Behandlung, Lernen
6 · Ersatz und Exit
Portabilität, Übergang, Löschung, Review
Portabilität, Übergang, Löschung, Review
Das Verfahren beginnt beim relevanten Dienst und nicht beim Lieferantennamen. Nur so werden kleine, aber hochkritische Anbieter, Softwarekomponenten, Identitätsdienste oder Wartungszugänge sichtbar.
¶ 3. Zweck und erwartete Arbeitsergebnisse
| Steuerungsfrage | Erwartetes Ergebnis |
|---|---|
| Welche Drittleistungen unterstützen relevante Dienste? | vollständige Dienst-Lieferanten-Produkt-Zuordnung |
| Welche Beziehungen sind kritisch oder schwer ersetzbar? | begründete Kritikalitätsklasse und Prüftiefe |
| Welche Risiken entstehen aus Produkt, Anbieter und Lieferkette? | aktuelle Lieferketten-Risikobewertung |
| Welche Kontrollen liegen bei wem? | bestätigte Verantwortungs- und Kontrollmatrix |
| Welche Anforderungen müssen vertraglich abgesichert werden? | geprüfte Vertrags- und Abweichungsmatrix |
| Wie werden Unterauftragnehmer einbezogen? | Transparenz-, Genehmigungs- und Flow-down-Regelung |
| Wie werden Änderungen, Schwachstellen und Vorfälle behandelt? | Melde-, Bewertungs- und Eskalationsprozess |
| Kann die Leistung ersetzt oder kontrolliert beendet werden? | realistischer und getesteter Ersatz-/Exit-Plan |
| Woran wird Wirksamkeit erkannt? | Nachweise, Tests, Kennzahlen, Abweichungen und Maßnahmen |
¶ 4. Rechtlicher Rahmen und Anwendbarkeit
§ 30 Absatz 2 Nummer 4 BSIG nennt die Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern. Nummer 5 erfasst Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen einschließlich Schwachstellenmanagement. Die Maßnahmen müssen geeignet, verhältnismäßig, wirksam und dokumentiert sein.
Artikel 21 Absatz 3 der NIS-2-Richtlinie verlangt bei der Auswahl angemessener Lieferkettenmaßnahmen die Berücksichtigung spezifischer Schwachstellen der unmittelbaren Anbieter und Diensteanbieter sowie der Qualität von Produkten und Cybersicherheitspraktiken einschließlich sicherer Entwicklung.
Die Durchführungsverordnung (EU) 2024/2690 gilt unmittelbar nur für die dort genannten Einrichtungsarten. Nummer 5.1 konkretisiert unter anderem Auswahl- und Vertragskriterien, Diversifizierung, Audit- oder Berichtszugänge, Vorfallmeldungen, Schwachstellenbehandlung, Unterauftragnehmer und Pflichten bei Vertragsende. Für andere Einrichtungen kann sie als strukturierte Orientierung dienen, ohne automatisch verbindlich zu sein.
Branchen-, produkt-, datenschutz-, exportkontroll-, vergabe- oder aufsichtsrechtliche Anforderungen werden zusätzlich geprüft. Diese Musterseite ist keine Rechtsberatung.
¶ 5. Begriffe und Abgrenzung
| Begriff | Verwendung auf dieser Seite |
|---|---|
| unmittelbarer Anbieter/Diensteanbieter | direkter Vertragspartner oder direkter Leistungserbringer der Organisation |
| Lieferant | Oberbegriff für Hersteller, Anbieter, Dienstleister oder sonstige Drittpartei |
| Unterauftragnehmer/Subdienstleister | vom unmittelbaren Anbieter zur Leistungserbringung eingesetzte weitere Partei |
| IKT-Produkt | Hardware, Software, Komponente, Bibliothek, Firmware oder technische Lösung |
| IKT-Dienst | Cloud, Managed Service, Kommunikation, Identität, Support oder andere IT-/OT-Leistung |
| Drittpartei | externe oder konzerninterne rechtlich/organisatorisch getrennte Stelle mit relevanter Abhängigkeit |
| Lieferkette | Beziehungen, Produkte, Komponenten, Personen, Orte und Leistungen vom Hersteller bis zum eigenen Dienst |
| Flow-down | Weitergabe eigener Sicherheitsanforderungen an relevante Unterauftragnehmer |
Nicht jede Geschäftsbeziehung benötigt dieselbe Prüftiefe. Entscheidend sind Dienstwirkung, Zugriff, Daten, Produktfunktion, Austauschbarkeit, Lieferkettentiefe und mögliche Ausfallfolgen.
¶ 6. Scope: Welche Beziehungen gehören in das Verfahren?
| Kategorie | Beispiele | Mögliche Wirkung |
|---|---|---|
| Hardware/Komponenten | Server, Netzwerk, OT, Sicherheitsgerät, Ersatzteil | Manipulation, Supportende, Lieferengpass |
| Software | Betriebssystem, Fachanwendung, Bibliothek, Update | Schwachstelle, kompromittierte Aktualisierung |
| Cloud/SaaS | Plattform, Speicher, Kollaboration, Fachservice | Ausfall, Datenverlust, Lock-in |
| Managed Service | Administration, SOC, Support, Betrieb | privilegierter Zugriff, Betriebsabhängigkeit |
| Kommunikation/Identität | Internet, Telefonie, DNS, PKI, IdP, MFA | organisationsweiter Ausfall oder Vertrauensverlust |
| Entwicklung/Wartung | Softwareentwicklung, Fernwartung, Systemintegration | Code-, Build-, Update- oder Administrationsrisiko |
| Rechenzentrum/Standort | Colocation, Hosting, Energie, Klima | physischer oder regionaler Ausfall |
| Backup/Kontinuität | Sicherung, Archiv, Wiederherstellungsplattform | Verlust der Wiederanlauffähigkeit |
| Logistik/Spezialleistung | Transport, Ersatzteile, Entsorgung, Prüfdienst | Lieferunterbrechung oder Informationszugriff |
| Konzernleistung | zentrale IT, Einkauf, Personal, Sicherheitsbetrieb | nicht marktübliche, aber reale Abhängigkeit |
Kostenlose Open-Source-Komponenten, eingebettete Bibliotheken und Herstellerabhängigkeiten können relevant sein, auch wenn kein klassischer Lieferantenvertrag besteht.
¶ 7. Zusammenspiel mit anderen Registern
| Führende Information | Typische Quelle | In der Lieferkette ergänzt |
|---|---|---|
| relevante Dienste | Dienstekatalog | Ausfallwirkung und Mindestleistung |
| Systeme/Assets | Asset- und Systeminventar | Hersteller, Produkt, Support und Lieferant |
| externe Services | Service-/Cloud-Register | Leistung, Region, Kundenkontrollen und Exit |
| Verträge | Vertragsmanagement | Sicherheitsanforderungen, Laufzeit und Abweichung |
| Datenschutz | AV-Verzeichnis | Rolle, Datenarten, Unterauftragnehmer, Drittland |
| Risiken | NIS2-Risikoregister | Lieferketten-Szenario, Behandlung und Restrisiko |
| Nachweise | Nachweisregister | Scope, Ergebnis, Fälligkeit und geschützter Ablageort |
Stammdaten sollen nicht widersprüchlich kopiert werden. Eindeutige IDs verbinden die Register; fachliche Bewertungen bleiben in der jeweils führenden Dokumentation.
¶ 8. Rollen und Entscheidungsrechte
| Rolle | Mindestaufgabe | Entscheidung/Nachweis |
|---|---|---|
| Geschäftsleitung | Schutzniveau, Ressourcen und wesentliche Lieferkettenrestrisiken | dokumentierte Entscheidung |
| Dienst-/Prozess-Owner | Bedarf, Kritikalität, Mindestleistung und Ersatzfähigkeit | Dienstfreigabe |
| Einkauf/Lieferantenmanagement | Auswahl, Vertrag, Laufzeit, Leistungs- und Eskalationssteuerung | Beschaffungs-/Lieferantenakte |
| Informationssicherheit | Kriterien, Sicherheitsrisiko, Nachweise und Abweichungen | Sicherheitsbewertung |
| IT-/OT-/Product-Owner | Architektur, Produktintegration, Konfiguration, Betrieb und Exit | technische Abnahme |
| Entwicklung | sichere Beschaffung, Komponenten, Build-/Updatekette und Schwachstellen | Entwicklungs-/Release-Nachweis |
| Recht/Datenschutz | Vertrag, Geheimhaltung, Rollen, Verarbeitung und Drittland im Mandat | Fachprüfung |
| BCM/Notfallmanagement | Ersatz, Mindestbetrieb, Wiederherstellung und Tests | Kontinuitätsbewertung |
| Fachbereich | Leistungsanforderung, Nutzerkontrollen und Betriebsbeobachtung | fachliche Abnahme |
Ein Anbieter kann Informationen liefern, aber nicht das eigene Restrisiko akzeptieren. Befristete Ausnahmen benötigen einen internen Owner, Kompensation, Termin und entscheidungsbefugte Freigabe.
¶ 9. Lieferkettenregister – Mindestfelder
| Feldgruppe | Pflichtangaben |
|---|---|
| Identität | Lieferanten-ID, Produkt-/Dienst-ID, konkrete Leistung, Status |
| Dienstbezug | relevante Dienste, Prozesse, Systeme, Informationen und Owner |
| Beziehung | Vertragspartner, Hersteller, Betreiber, Integrator, Unterauftragnehmer |
| Kritikalität | Klasse, Begründung, Ausfalltoleranz, Austauschbarkeit, Privilegien |
| Orte | Leistungs-, Daten-, Support-, Backup- und Administrationsregionen, soweit relevant |
| Lieferkette | wesentliche Komponenten, Unterauftragnehmer, Abhängigkeiten, Konzentration |
| Sicherheit | sichere Entwicklung, Zugriff, Kryptografie, Logging, Schwachstellen, Vorfälle |
| Vertrag | Laufzeit, Kündigung, SLA, Sicherheitsanhang, Audit, Meldung, Exit |
| Nachweise | Typ, konkreter Scope, Zeitraum, Ausnahmen, Kundenkontrollen, Fälligkeit |
| Kontinuität | RTO/RPO-Bezug, Ersatzweg, Mindestbetrieb, Portabilität, letzter Test |
| Governance | Owner, Vertreter, Freigabe, Restrisiko, Maßnahmen und Reviewtermin |
Das Register enthält keine unkontrollierten Kopien kompletter Verträge oder vertraulicher Prüfberichte. Es referenziert geschützte Originale.
¶ 10. Beziehungskarte: vom Dienst bis zur tieferen Lieferkette
Relevanter Dienst
Wirkung, Zeit, Mindestleistung
Wirkung, Zeit, Mindestleistung
Eigenes System/Prozess
Integration und Kundenkontrollen
Integration und Kundenkontrollen
Unmittelbarer Anbieter
Vertrag, Leistung, Verantwortung
Vertrag, Leistung, Verantwortung
Produkt/Plattform
Hersteller, Update, Support
Hersteller, Update, Support
Unterauftragnehmer
Flow-down, Änderung, Region
Flow-down, Änderung, Region
Kritische Komponente
Bibliothek, Infrastruktur, Identität
Bibliothek, Infrastruktur, Identität
Nicht jede tiefere Ebene kann vollständig transparent sein. Unklarheit wird als bewertbare Informationslücke dokumentiert – nicht stillschweigend als erfüllt.
¶ 11. Kritikalitätsklassen
| Klasse | Typische Auswirkung | Mindeststeuerung |
|---|---|---|
| L1 – kritisch | erhebliche Dienstbeeinträchtigung, privilegierter Zugriff oder geringe Ersetzbarkeit | vertiefte Due Diligence, verbindliche Anforderungen, enges Monitoring, getesteter Ersatz/Exit |
| L2 – wesentlich | merkliche Auswirkung; Ersatz innerhalb tolerierbarer Zeit begrenzt möglich | risikobasierte Prüfung, regelmäßiger Review, vorbereitete Alternative |
| L3 – unterstützend | begrenzte direkte Wirkung und gute Austauschbarkeit | dokumentierte Basisprüfung und angemessene Vertragskontrollen |
| Ungeklärt | Dienstbezug, Produktrolle oder Ausfallfolge nicht belastbar bestimmt | keine positive Freigabe; Klärung mit Owner und Termin |
Die Klasse richtet sich nicht nach Einkaufsvolumen oder Anbietergröße. Ein preiswerter Identitäts-, DNS-, Zertifikats- oder Bibliotheksdienst kann hochkritisch sein.
¶ 12. Bewertungsfaktoren für Kritikalität und Prüftiefe
| Faktor | Leitfrage |
|---|---|
| Dienstwirkung | Welche relevanten Dienste werden unsicher oder fallen aus? |
| Zeit | Wie schnell entsteht eine erhebliche Beeinträchtigung? |
| Daten/Schutzziele | Welche Informationen und Anforderungen sind betroffen? |
| Privilegien | Besitzt die Drittpartei administrativen, physischen oder Entwicklungszugriff? |
| Produktfunktion | Ist das Produkt Sicherheits-, Identitäts-, Update- oder Vertrauensanker? |
| Austauschbarkeit | Wie lange dauern Ersatz, Migration, Beschaffung und Abnahme realistisch? |
| Konzentration | Welche weiteren Dienste hängen vom Anbieter, Konzern oder Unterbau ab? |
| Lieferkettentiefe | Welche wesentlichen Unterauftragnehmer/Komponenten sind unbekannt? |
| Reife/Nachweise | Wie belastbar sind Sicherheitspraktiken, Berichte und Kundenkontrollen? |
| Kontinuität | Kann die Organisation unabhängig sichern, wiederherstellen oder reduziert arbeiten? |
Bewertung und Prüftiefe werden begründet. Eine Checkliste mit identischen Fragen für alle Lieferanten ist weder verhältnismäßig noch risikoorientiert.
¶ 13. Risikoszenarien der Lieferkette
| Szenario | Typische Ursache | Mögliche Behandlung |
|---|---|---|
| kompromittiertes Update | Build-/Signatur-/Distributionskette angegriffen | Verifikation, gestufte Verteilung, Monitoring, Rollback |
| unbekannte Schwachstelle | unsichere Entwicklung oder Komponente | SBOM/Komponenteninformation, Meldung, Patch- und Kompensation |
| privilegierter Missbrauch | Anbieter- oder Wartungskonto kompromittiert | MFA, JIT/JEA, Freigabe, Logging, Sitzungsüberwachung |
| Anbieterausfall | Cyberangriff, Insolvenz, Personalmangel, Region | Notbetrieb, Alternative, Daten-/Konfigurationssicherung |
| Lieferengpass/Supportende | Produktabkündigung, Export-/Marktrisiko | Lebenszyklusplanung, Ersatz, Vorrat nach Risiko |
| Unterauftragnehmerwechsel | neue Region, Kontrolle oder Abhängigkeit | Vorabinformation, Bewertung, Widerspruch/Exit |
| Lock-in | proprietäre Formate, Identitäten, Schnittstellen | Portabilität, Dokumentation, Probeexport, Übergangsplan |
| Nachweisversagen | Bericht ohne passenden Scope oder kritische Ausnahme | Nachforderung, Zusatzprüfung, Kompensation, Eskalation |
Szenarien werden mit dem allgemeinen NIS2-Risikoregister verbunden und erhalten Owner, Behandlung, Termin, Restrisiko und Reviewtrigger.
¶ 14. Due Diligence vor Auswahl und Beauftragung
| Prüffeld | Kernfrage | Geeigneter Nachweis |
|---|---|---|
| Organisation | Sind Rollen, Governance und Sicherheitsprozesse nachvollziehbar? | Richtlinienauszug, Organisations-/Kontaktinformation |
| Produkt-/Dienst-Scope | Deckt die Bewertung die konkrete Leistung und Ausprägung ab? | Leistungs-/Systembeschreibung |
| sichere Entwicklung | Wie werden Anforderungen, Code, Build, Tests, Updates und Komponenten geschützt? | Prozessbeschreibung, Prüfbericht, Entwicklungsnachweis |
| Identitäten/Zugriff | Wie werden privilegierte Zugriffe, MFA, Austritte und Fernwartung gesteuert? | Kontrollbeschreibung und Stichprobe |
| Schwachstellen | Wie erfolgen Entgegennahme, Bewertung, Behebung und Kundeninformation? | PSIRT-/Vulnerability-Prozess, Fristen, Kennzahlen |
| Vorfälle | Wann und wie informiert und unterstützt der Anbieter? | Incident-Verfahren und Kontaktmodell |
| Unterauftragnehmer | Welche wesentlichen Parteien und Änderungen sind relevant? | Liste, Genehmigungs-/Informationsverfahren |
| Kontinuität | Sind Backup, Wiederherstellung, Kapazität und Krisenkommunikation geeignet? | Testauszug, SLA, BCP-Information |
| Exit | Sind Daten, Konfiguration und Wissen portierbar und löschbar? | Exitbeschreibung, Export-/Löschverfahren |
Fehlende Angaben sind eine Lücke. Sie können je nach Risiko durch andere Nachweise oder Kontrollen kompensiert werden; eine Annahme ohne Begründung gilt nicht als Prüfung.
¶ 15. Produkte, Software und sichere Entwicklung
| Thema | Zu prüfende Frage |
|---|---|
| Sicherheitsanforderungen | Sind Anforderungen vor Auswahl und Entwicklung festgelegt? |
| Komponenten/SBOM | Sind wesentliche Bestandteile, Versionen und Abhängigkeiten nachvollziehbar? |
| Entwicklungsumgebung | Werden Quellcode, Build, Signierung, Geheimnisse und Zugriffe geschützt? |
| Tests | Welche Sicherheits-, Qualitäts- und Integritätsprüfungen erfolgen? |
| Updates | Wie werden Herkunft, Signatur, Freigabe, Verteilung und Rollback gesteuert? |
| Schwachstellen | Gibt es Meldeweg, Bewertung, Fristen, Advisories und Support? |
| Lebenszyklus | Sind Supportbeginn/-ende, Migration und Ersatz rechtzeitig bekannt? |
| sichere Voreinstellung | Welche Risiken verbleiben in Kundenkonfiguration und Betrieb? |
Eine Herstellererklärung oder Produktzertifizierung wird auf Version, Konfiguration, Schutzprofil, Laufzeit und eigene Einsatzbedingungen geprüft.
¶ 16. Verantwortungs- und Kontrollmatrix
| Kontrollfeld | Anbieter | Eigene Organisation | Gemeinsame Schnittstelle |
|---|---|---|---|
| Plattform-/Produktbetrieb | vereinbarte Basisleistung | sichere Nutzung/Integration | Änderung und Störung |
| Identitäten | Anbieterpersonal und Anbieterzugänge | eigene Nutzer, Rollen, MFA | privilegierter Supportzugriff |
| Konfiguration | sichere Optionen bereitstellen | risikogerechte Einstellung | Abnahme und Drift |
| Logging/Monitoring | vereinbarte Ereignisse erzeugen/bereitstellen | eigene Auswertung und Reaktion | Zeit, Format und Eskalation |
| Schwachstellen | Produktfehler behandeln und informieren | Exposition bewerten, patchen/kompensieren | Priorität und Frist |
| Vorfälle | eindämmen, untersuchen, informieren | eigene Auswirkungen/Meldepflicht bewerten | Kooperation und Beweissicherung |
| Backup/Wiederherstellung | vertragliche Plattformfunktionen | eigene Daten-/Konfigurationssicherung | Restore-Test |
| Exit/Löschung | Export, Übergang und sichere Löschung unterstützen | Migration, Kontrolle und Freigabe | Abschlussnachweis |
„Shared Responsibility“ bedeutet nicht „unklare Verantwortung“. Jede relevante Kontrolle erhält eine verantwortliche Seite, Schnittstelle, Nachweisart und Eskalation.
¶ 17. Vertragsmindestanforderungen
| Vertragsfeld | Erwarteter Inhalt |
|---|---|
| Leistungs-/Sicherheits-Scope | konkrete Leistung, Systeme, Orte, Rollen und Schutzziele |
| Sicherheitsanforderungen | technische, organisatorische und personelle Mindestkontrollen |
| Service Levels | Verfügbarkeit, Reaktion, Wiederherstellung, Support und Eskalation |
| Vorfallmeldung | Auslöser, Inhalt, Kanal, Ansprechpartner und Frist ohne unangemessene Verzögerung |
| Schwachstellen | Meldung, Priorisierung, Behebung, Kompensation und Kundeninformation |
| Audit/Nachweise | Prüfungsrecht oder geeignete Berichte, Scope, Frequenz, Maßnahmenzugang |
| Unterauftragnehmer | Transparenz, Änderung, Genehmigung/Widerspruch und Flow-down |
| Personal/Zugriff | Qualifikation, Vertraulichkeit, Prüfung nach Rechtslage, Berechtigungen |
| Kontinuität | Backup, Wiederherstellung, Notbetrieb, Tests und Kommunikation |
| Änderung | wesentliche Produkt-, Standort-, Eigentums-, Kontroll- und Supportänderungen |
| Exit | Daten-/Konfigurationsexport, Unterstützung, Übergang, Rückgabe und Löschung |
| Haftung/Eskalation | risikogerechte Folgen, Governance und Streit-/Notfallweg |
Nicht jede Anforderung muss wortgleich geregelt sein. Abweichungen werden jedoch sichtbar bewertet, kompensiert, befristet oder abgelehnt.
¶ 18. Vertragsabweichungen und Freigabestatus
| Ergebnis | Bedeutung | Zulässige Entscheidung |
|---|---|---|
| geeignet | Anforderungen im geprüften Scope erfüllt; Restrisiko vertretbar | Freigabe mit Reviewtermin |
| bedingt geeignet | begrenzte Lücken mit wirksamer Kompensation und Termin | befristete Freigabe |
| nicht geeignet | wesentliche Anforderung oder Steuerbarkeit fehlt | keine Produktivfreigabe |
| nicht bewertbar | Scope, Nachweis oder Verantwortung unzureichend | Informationsnachforderung/Eskalation |
Eine wirtschaftliche Dringlichkeit ändert das Sicherheitsrisiko nicht. Sie kann eine befristete Managemententscheidung erforderlich machen, muss aber mit Risiko, Kompensation und Ausstiegsoption dokumentiert werden.
¶ 19. Unterauftragnehmer und Flow-down
| Kontrollpunkt | Leitfrage |
|---|---|
| Transparenz | Welche Unterauftragnehmer sind für Leistung, Daten, Support oder Sicherheit wesentlich? |
| Vorabinformation | Wann und wie werden neue oder geänderte Unterauftragnehmer gemeldet? |
| Bewertung | Welche Änderungen an Region, Zugriff, Kontrolle, Konzentration oder Rechtslage entstehen? |
| Flow-down | Werden relevante Sicherheits-, Vorfall-, Schwachstellen- und Exit-Pflichten weitergegeben? |
| Nachweise | Sind Berichte und Ausnahmen bis zur relevanten Leistungsebene nachvollziehbar? |
| Entscheidung | Bestehen Widerspruch, Kompensation, Übergang oder Kündigungsoptionen? |
Die Organisation muss nicht jede beliebige Unterstufe gleich tief prüfen. Sie muss jedoch wesentliche Abhängigkeiten und unvertretbare Intransparenz risikobasiert behandeln.
¶ 20. Konzentrations- und Kaskadenrisiken
| Konzentration | Beispielhafte Frage | Gegenmaßnahme |
|---|---|---|
| Anbieter | Unterstützt derselbe Anbieter mehrere kritische Dienste? | Portfolioübersicht und alternative Strategie |
| Konzern | Wirken verschiedene Marken über denselben Konzern/Unterbau? | wirtschaftliche und technische Zuordnung |
| Plattform | Nutzen mehrere Dienste dieselbe Cloud-, Identitäts- oder Integrationsplattform? | Zonen, unabhängige Sicherung, Notbetrieb |
| Region/Standort | Liegen Primär- und Ersatzleistung im selben Gefahrenraum? | regionale Diversifizierung nach Risiko |
| Softwarekomponente | Ist dieselbe Bibliothek in vielen Systemen enthalten? | Komponentenübersicht und schnelle Expositionsanalyse |
| Kommunikationsweg | Teilen Anbieter denselben Carrier, DNS, PKI oder Netzpfad? | End-to-End-Abhängigkeitsanalyse |
| Personal/Wissen | Ist eine Spezialperson oder ein Supportteam unverzichtbar? | Dokumentation, Vertretung, Übergabe |
Konzentration ist nicht automatisch unzulässig. Sie muss sichtbar, begründet, überwacht und in Kontinuität sowie Risikobehandlung einbezogen sein.
¶ 21. Vendor Lock-in und Diversifizierung
| Dimension | Prüffrage |
|---|---|
| Daten | Können Daten vollständig, rechtzeitig und verständlich exportiert werden? |
| Konfiguration | Sind Regeln, Workflows, Identitäten und Metadaten übertragbar? |
| Schnittstellen | Gibt es dokumentierte, stabile und nutzbare APIs/Formate? |
| Lizenzen | Bleiben Lesbarkeit, Übergang und Betrieb während Migration möglich? |
| Kompetenzen | Ist Wissen intern oder bei mehreren Partnern verfügbar? |
| Infrastruktur | Benötigt die Alternative denselben Anbieter oder proprietäre Komponenten? |
| Zeit/Kosten | Passen Migration und Übergang zur maximal tolerierbaren Unterbrechung? |
Diversifizierung kann durch mehrere Anbieter, standardisierte Schnittstellen, unabhängige Backups, vorbereitete Alternativen oder bewusst akzeptierte Konzentration mit wirksamer Kompensation erfolgen.
¶ 22. Einführung und technische Abnahme
| Abnahmepunkt | Mindestprüfung |
|---|---|
| bestellte Ausprägung | Vertrag und tatsächlicher Dienst/Produkt stimmen überein |
| Architektur/Schnittstellen | Daten-, Identitäts-, Netz- und Administrationswege bestätigt |
| sichere Konfiguration | Baseline, MFA, Rollen, Verschlüsselung, Logging und Updates geprüft |
| Anbieterzugriffe | Zweck, Freigabe, Befristung, Protokollierung und Notfallzugriff geregelt |
| Daten/Backups | Speicherorte, Sicherung, Restore und Löschung geklärt |
| Monitoring | Ereignisse, SLA, Schwachstellen und Ansprechpartner eingebunden |
| Notbetrieb/Exit | Mindestverfahren und kontrollierter Export vor Produktivsetzung geprüft |
| Dokumentation | Owner, Betriebsübergabe, Nachweise und Reviewtermin vollständig |
Die Freigabe eines Anbieters ersetzt nicht die Abnahme der konkreten Produktinstanz oder Konfiguration.
¶ 23. Laufende Lieferantenüberwachung
| Beobachtungsfeld | Quelle | Reaktion |
|---|---|---|
| Leistung/SLA | Servicebericht, Monitoring, Tickets | Ursachenanalyse und Eskalation |
| Sicherheitsstatus | Bericht, Zertifikat, Audit, Selbstauskunft | Scope-/Lückenbewertung |
| Schwachstellen | Herstellerhinweis, CERT/CSIRT, eigene Exposition | Patch, Kompensation, Risiko |
| Vorfälle | Anbietermeldung, Medien, Betriebsbeobachtung | Auswirkung und Meldeprüfung |
| Änderungen | Release, Region, Architektur, Eigentümer, Unterauftragnehmer | Neubewertung und Freigabe |
| Support/Lebenszyklus | Roadmap, EOL/EOS, Vertragsstatus | Migration oder Ausnahme |
| Konzentration | Portfolio-/Abhängigkeitsanalyse | Diversifizierung/Notbetrieb |
| Exit-Fähigkeit | Probeexport, Restore, Übergabeübung | Maßnahme und Plananpassung |
Monitoringfrequenz und Prüftiefe folgen der Kritikalität. Ein jährlich erneuertes Zertifikat reicht bei kritischen Änderungen oder Vorfällen nicht als alleiniger Review aus.
¶ 24. Nachweise richtig bewerten
| Nachweis | Nützliche Aussage | Typische Grenze |
|---|---|---|
| Zertifikat | Managementsystem/Scope wurde nach bestimmtem Standard geprüft | nicht automatisch konkrete Leistung, Konfiguration oder Wirksamkeit |
| Prüfbericht | Kontrollen, Zeitraum, Ausnahmen und Testergebnisse | Vertraulichkeit, eingeschränkter Scope, Kundenkontrollen |
| C5-/Kontrollbericht | dienstbezogene Kontrollen und ergänzende Nutzerkontrollen | konkreten Dienst, Zeitraum und Abweichungen prüfen |
| Penetrationstest | technische Schwächen im getesteten Scope/Zeitpunkt | keine vollständige Governance- oder Lieferkettenbewertung |
| Selbstauskunft | strukturierte Anbieterinformation | nicht unabhängig bestätigt |
| SLA-/Betriebsreport | Leistungs- und Ereignisverlauf | Sicherheitsursachen ggf. nicht vollständig |
| Übungs-/Restorebericht | praktische Kontinuitätsfähigkeit | Szenario, Datenumfang und Zielerreichung prüfen |
Jeder Nachweis erhält Scope, Zeitraum, Prüfer, Ergebnis, Einschränkung, Kundenkontrollen, Schutzklasse, Review und Verknüpfung zu offenen Maßnahmen.
¶ 25. Schwachstellen und Sicherheitsupdates
| Schritt | Lieferantenschnittstelle | Eigene Verantwortung |
|---|---|---|
| Erkennen | Advisory, Meldestelle, Kundeninformation | Asset-/Produktzuordnung und Monitoring |
| Bewerten | technische Schwere, betroffene Versionen, Fix | Exposition, Dienstwirkung und Priorität |
| Entscheiden | Patch, Workaround, Support | Test, Freigabe, Kompensation, Risiko |
| Umsetzen | sichere Bereitstellung und Integritätsinformation | gestufte Verteilung, Rollback, Nachweis |
| Überprüfen | Fixbestätigung und Folgeinformation | Wirksamkeit, Restexposition und Abschluss |
Vertragliche Fristen werden risikobasiert ergänzt. Eine pauschale Herstellerbewertung ersetzt nicht die organisationsbezogene Expositionsanalyse.
¶ 26. Lieferantenvorfälle und NIS2-Meldeprüfung
| Phase | Erwartung an die Drittpartei | Eigene Aufgabe |
|---|---|---|
| Erstinformation | unverzügliche, sichere und verwertbare Meldung gemäß Vereinbarung | Eingang bestätigen, Lage eröffnen, Dienstbezug klären |
| Auswirkung | betroffene Produkte, Zeiten, Daten, Regionen und Kontrollen | eigene Systeme/Dienste untersuchen |
| Eindämmung | Maßnahmen, Workaround, Indikatoren und Unterstützung | Schutzmaßnahmen umsetzen und überwachen |
| Meldeprüfung | Fakten und Aktualisierungen bereitstellen | gesetzliche Erheblichkeit und Fristen eigenständig bewerten |
| Wiederherstellung | Fix, sichere Wiederaufnahme und Datenintegrität | Abnahme und kontrollierter Normalbetrieb |
| Nachbereitung | Ursache, Lessons Learned und Maßnahmen | Risiko, Vertrag, Nachweise und Kontrollen aktualisieren |
Die Verantwortung für eigene gesetzliche Meldungen kann nicht vollständig auf den Anbieter verlagert werden. Der Informationsfluss muss schnell genug sein, damit die Organisation ihre Fristen beurteilen und einhalten kann.
¶ 27. Ersatz, Portabilität und Exit
| Exit-Baustein | Leitfrage | Mindestnachweis |
|---|---|---|
| Auslöser | Welche Vorfälle, Änderungen, Vertrags- oder Risikoschwellen aktivieren den Exit? | genehmigte Kriterien |
| Datenexport | Welche Daten, Metadaten, Logs und Formate werden benötigt? | Probeexport und Vollständigkeitsprüfung |
| Konfiguration | Wie werden Regeln, Identitäten, Schnittstellen und Schlüssel überführt? | Migrations-/Wiederaufbauplan |
| Ersatz | Welche Alternative liefert welche Mindestleistung? | bewertete Option/Vertrag |
| Übergang | Wie lange laufen Alt und Neu parallel, wer entscheidet? | Termin-, Rollen- und Kommunikationsplan |
| Sicherheit | Wie werden Zugriffe, Geheimnisse und Integrität während Migration geschützt? | Übergangskontrollen |
| Löschung/Rückgabe | Wie werden Daten, Medien, Konten und Dokumente beendet? | Abschluss-/Löschbestätigung |
| Nachbetrieb | Welche Aufbewahrungs-, Support- und Prüfpflichten verbleiben? | Abschlussreview |
Exit-Fähigkeit wird vor Eintritt einer Krise vorbereitet und für kritische Beziehungen praktisch oder durch belastbare Teiltests geprüft.
¶ 28. Fünf aufklappbare Prüfpfade
Prüfpfad A – Scope und Kritikalität
- Relevanten Dienst, Produkt/Dienstleistung und internen Owner bestimmen.
- Vertragspartner, Hersteller, Betreiber und wesentliche Unterauftragnehmer unterscheiden.
- Daten, Privilegien, Systeme, Orte und Zeitabhängigkeit erfassen.
- Ausfallwirkung, Austauschbarkeit, Konzentration und Lieferkettentiefe bewerten.
- Kritikalitätsklasse und Prüftiefe begründen.
- Unklare Angaben als Lücke mit Owner und Termin dokumentieren.
Ergebnis: bestätigte Dienst-Lieferketten-Zuordnung und risikobasierte Prüftiefe.
Prüfpfad B – Due Diligence und Freigabe
- Auswahlkriterien und Sicherheitsanforderungen vor Angebotsentscheidung festlegen.
- konkrete Leistung, Produktversion, Region und Betriebsmodell prüfen.
- sichere Entwicklung, Zugriff, Schwachstellen, Vorfälle und Kontinuität bewerten.
- Nachweise auf Scope, Zeitraum, Ausnahmen und Kundenkontrollen untersuchen.
- Lücken kompensieren, befristen, eskalieren oder Anbieter ablehnen.
- Entscheidung, Restrisiko und nächsten Review dokumentieren.
Ergebnis: nachvollziehbare, entscheidungsbefugte Anbieter-/Produktfreigabe.
Prüfpfad C – Vertrag, Unterauftragnehmer und Abnahme
- Sicherheits-, SLA-, Vorfall-, Schwachstellen-, Audit- und Exit-Anforderungen abgleichen.
- Unterauftragnehmertransparenz, Änderungen und Flow-down festlegen.
- Abweichungen mit Risiko, Kompensation, Owner und Ablaufdatum dokumentieren.
- konkrete Architektur, Konfiguration, Identitäten und Schnittstellen abnehmen.
- Monitoring, Kontakte, Nachweise und Betriebsübergabe einrichten.
- Produktivsetzung erst nach genehmigtem Ergebnis oder befristeter Ausnahme.
Ergebnis: Vertrag und tatsächlicher Betrieb bilden dieselbe kontrollierte Beziehung ab.
Prüfpfad D – Überwachung, Änderung und Vorfall
- kritikalitätsbezogene Review- und Nachweisfrequenz festlegen.
- Leistung, Schwachstellen, Vorfälle, Zertifikate und Lebenszyklus überwachen.
- wesentliche Änderungen bei Produkt, Region, Eigentümer oder Unterauftragnehmer bewerten.
- bei Vorfällen eigenen Dienstbezug und gesetzliche Meldepflicht unabhängig prüfen.
- Abweichungen in Risiko- und Maßnahmensteuerung überführen.
- Wirksamkeit der Behandlung nachprüfen und Status aktualisieren.
Ergebnis: aktuelles Risikobild statt einmaliger Fragebogenprüfung.
Prüfpfad E – Portabilität, Ersatz und Exit
- Exit-Auslöser, Mindestleistung und maximal tolerierbare Übergangszeit festlegen.
- Daten, Konfiguration, Identitäten, Schnittstellen, Wissen und Lizenzen erfassen.
- Alternative auf Unabhängigkeit, Kapazität und Sicherheit bewerten.
- Export, Wiederherstellung oder Teilmigration kontrolliert testen.
- Übergang, Kommunikation, Zugriffsentzug, Rückgabe und Löschung planen.
- Ergebnis, Restlücke und Wiederholungstermin dokumentieren.
Ergebnis: belegte Exit-Fähigkeit oder transparent eskalierte Abhängigkeit.
¶ 29. Ampellogik und Datenqualität
| Status | Bedeutung | Zulässige Aussage |
|---|---|---|
| ● bestätigt | Scope vollständig, Owner bestätigt, Nachweis aktuell, keine überfällige wesentliche Lücke | im benannten Scope geprüft |
| ● eingeschränkt | begrenzte Lücke wirksam kompensiert und terminiert | nur mit dokumentierter Einschränkung |
| ● kritisch | wesentliche Anforderung, Kontrolle oder Exit-Fähigkeit fehlt | Eskalation/Behandlung erforderlich |
| ● ungeklärt | Scope, Daten oder Kriterien nicht belastbar | keine positive Bewertung möglich |
Status gilt nur für benannten Dienst, Produkt, Vertrag, Zeitraum und Prüftiefe. „Anbieter freigegeben“ ohne konkreten Scope ist zu vermeiden.
¶ 30. Review- und Triggerlogik
| Trigger | Erforderliche Reaktion |
|---|---|
| neuer relevanter Dienst oder neue Drittleistung | Scope, Kritikalität, Due Diligence und Vertrag |
| wesentliche Produkt-/Architekturänderung | technische und risikobezogene Neubewertung |
| neue Region/Unterauftragnehmer/Eigentümer | Abhängigkeit, Recht, Flow-down und Konzentration prüfen |
| Schwachstelle oder Sicherheitsvorfall | Exposition, Maßnahmen, Meldeprüfung und Nachweis |
| SLA-/Qualitätsverschlechterung | Dienstwirkung, Eskalation und Alternative bewerten |
| Zertifikats-/Berichtsablauf oder kritische Ausnahme | neuen Nachweis oder Kompensation anfordern |
| EOL/EOS, Preismodell- oder Lizenzänderung | Lebenszyklus, Lock-in und Exit aktualisieren |
| fehlgeschlagener Restore-/Exit-Test | Maßnahme, Restrisiko und Wiederholung |
| Vertragsverlängerung/Kündigungsfenster | vollständigen Review vor Bindung durchführen |
¶ 31. Musterregister – ausschließlich fiktive Datensätze
| Beziehungs-ID | Leistung/Produkt | Dienstbezug | Klasse | Hauptlücke | Exitstatus | Bewertung |
|---|---|---|---|---|---|---|
LIEF-M-01 |
Identitätsdienst | DIENST-M-01 |
ungeklärt | Unterauftragnehmer/Region | nicht getestet | Muster – offen |
LIEF-M-02 |
OT-Wartung | DIENST-M-02 |
ungeklärt | privilegierter Zugang | Ersatz offen | Muster – offen |
LIEF-M-03 |
Softwarekomponente | mehrere Systeme | ungeklärt | Support-/Updatekette | Migration offen | Muster – offen |
Die Musterzeilen sind keine Empfehlung und kein Nachweis. Reale Detaildaten gehören in geschützte Register und Akten.
¶ 32. Nützliche technische Bausteine in Wiki.js
| Baustein | Filter/Anzeige | Nutzen |
|---|---|---|
| Lieferketten-Cockpit | Klasse, Owner, Review, Vertrags-/Nachweislücke | Managementprioritäten |
| Dienst-Lieferanten-Matrix | Dienst, Produkt, Anbieter, Unterauftragnehmer | Scope und Kaskaden |
| Kritikalitätsfilter | Ausfallwirkung, Privileg, Daten, Austauschbarkeit | risikobasierte Prüftiefe |
| Vertragslücken-Explorer | Vorfall, Audit, Schwachstelle, Flow-down, Exit | Verhandlung und Maßnahmen |
| Konzentrationsansicht | Anbieter, Konzern, Plattform, Region, Komponente | kumulierte Risiken |
| Fälligkeitsliste | Review, Nachweis, EOL/EOS, Kündigungsfenster | operative Steuerung |
| Exit-Reifegrad | Export, Alternative, Test, Löschung, Restlücke | Kontinuitätsentscheidung |
Eine interaktive Fassung zeigt Ergebnisanzahl und aktive Filter, bietet einen Rücksetzknopf und bleibt ohne JavaScript als vollständige Tabelle nutzbar. Vertrauliche Datensätze werden nicht clientseitig versteckt, sondern nicht öffentlich ausgeliefert.
¶ 33. Kennzahlen und Managementaussagen
| Kennzahl | Aussage | Erforderlicher Kontext |
|---|---|---|
| Anteil kritischer Beziehungen mit bestätigtem Owner | Verantwortungsabdeckung | Grundgesamtheit und Stichtag |
| überfällige Due-Diligence-/Lieferantenreviews | Prüfdisziplin | Klasse und Fälligkeit |
| offene wesentliche Vertragslücken | rechtliche/operative Steuerbarkeit | betroffener Dienst und Kompensation |
| kritische Anbieter ohne aktuelle Nachweise | Unsicherheit im Kontrollstatus | Nachweistyp, Scope und Alter |
| Konzentrationsrisiken ohne Behandlung | Kaskadenrisiko | betroffene Dienste/Plattformen |
| Vorfälle/Schwachstellen nach Lieferant | reale Belastung und Reaktion | Schwere, Exposition und Trend |
| getestete Exit-/Ersatzszenarien | praktische Resilienz | Ergebnis, Mindestleistung und Restlücke |
| Maßnahmen über Fälligkeit | Behandlungsrisiko | Schwere, Owner und Eskalation |
„100 % Lieferanten geprüft“ ist ohne Scope, Kritikalität, Prüftiefe und Ergebnis keine belastbare Aussage.
¶ 34. Nachweise und geschützte Ablage
| Nachweisart | Wiki-/Registerangabe | Geschütztes Original |
|---|---|---|
| Due-Diligence-Bewertung | Datum, Scope, Ergebnis, Owner, Review | Antworten, Anlagen, technische Details |
| Vertrag/Sicherheitsanhang | Referenz, Laufzeit, Lückenstatus | Vertragsdokument und Verhandlung |
| Zertifikat/Prüfbericht | Typ, Scope, Zeitraum, Ergebnis, Fälligkeit | vollständiger Bericht |
| Schwachstellen-/Vorfallnachweis | Produkt, Status, Maßnahme, Abschluss | Advisories, Indikatoren, Kommunikation |
| Lieferantenreview | Datum, Kriterien, Ergebnis, Abweichungen | Protokoll und Stichproben |
| Restore-/Exit-Test | Szenario, Ziel, Ergebnis, Maßnahme | Ablauf, Daten und Schwachstellen |
| Unterauftragnehmerliste | Status, Änderung, Prüfdatum | Namen, Orte, Rollen und Vertragsdetails |
Nachweise sind versioniert, zugriffsgeschützt, auffindbar und mit Aufbewahrung geregelt. Ein Link ohne Berechtigung, Status oder eindeutiges Original ist kein belastbarer Nachweis.
¶ 35. Häufige Fehlannahmen
| Fehlannahme | Warum sie riskant ist | Bessere Steuerung |
|---|---|---|
| „Der Lieferant ist ISO-zertifiziert.“ | Scope und konkrete Leistung können abweichen | Bericht, Scope und eigene Kontrollen prüfen |
| „Der Vertrag enthält Datenschutz.“ | NIS2-Sicherheit, Vorfälle, Schwachstellen und Exit können fehlen | getrennte, abgestimmte Anforderungen |
| „Nur große Anbieter sind kritisch.“ | kleine Dienste/Komponenten können zentrale Abhängigkeit sein | Dienstwirkung statt Umsatz bewerten |
| „Unterauftragnehmer sind Sache des Anbieters.“ | sie können Leistung, Daten und Risiken wesentlich prägen | Transparenz, Flow-down und Änderung regeln |
| „Cloud ist automatisch redundant.“ | eigene Konfiguration, Identität oder Region kann Einzelpunkt sein | End-to-End-Architektur und Restore testen |
| „Der Anbieter meldet uns alles rechtzeitig.“ | Inhalt und Frist können unzureichend sein | klare Kriterien, Kanal und Eskalation vereinbaren |
| „Exit planen wir bei Kündigung.“ | Daten, Wissen und Zeit fehlen dann oft | Exit vor Beauftragung planen und testen |
| „Keine Vorfälle bedeutet wirksam.“ | fehlende Ereignisse belegen keine Kontrolle | Reviews, Tests und messbare Kriterien nutzen |
¶ 36. Qualitätsgate vor Freigabe
- Relevanter Dienst, Produkt/Dienstleistung und unmittelbarer Anbieter sind eindeutig verbunden.
- Hersteller, Betreiber, Integrator und wesentliche Unterauftragnehmer werden unterschieden.
- Kritikalität, Privilegien, Daten, Austauschbarkeit und Konzentration sind begründet bewertet.
- Due Diligence umfasst konkrete Leistung, Version, Region und Betriebsmodell.
- Sichere Entwicklung, Schwachstellen, Updates, Vorfälle und Lebenszyklus sind angemessen geprüft.
- Verantwortungs- und Kundenkontrollen sind eindeutig zugeordnet.
- Vertragsanforderungen, Abweichungen, Kompensationen und Ablaufdaten sind dokumentiert.
- Unterauftragnehmeränderungen und Flow-down sind geregelt.
- Monitoring, Nachweise, Eskalation und Reviewtrigger sind eingerichtet.
- Ersatz, Portabilität, Übergang und Löschung sind dem Risiko angemessen vorbereitet.
- Wesentliche Restrisiken sind entscheidungsbefugt akzeptiert oder behandelt.
- Vertrauliche Vertrags-, Schwachstellen- und Sicherheitsinformationen liegen geschützt.
¶ 37. Offene Entscheidungen vor produktiver Nutzung
- führendes Lieferanten-, Produkt-/Dienst- und Vertragsregister bestimmen,
- Kritikalitätsklassen und risikobasierte Prüftiefe genehmigen,
- Auswahl-, Due-Diligence- und Freigabeprozess mit Einkauf verzahnen,
- Vertragsmindestanforderungen und zulässige Abweichungen festlegen,
- Unterauftragnehmer-, Flow-down- und Änderungskriterien bestimmen,
- Nachweisarten, Gültigkeiten, Schutzklassen und Ablage freigeben,
- Schwachstellen- und Vorfallkommunikation an interne Meldewege anbinden,
- Konzentrations-, Vendor-Lock-in- und Exitkriterien genehmigen,
- Pilotbewertung einer kritischen Lieferanten-Produkt-Dienst-Beziehung durchführen,
- erkannte Risiken und Maßnahmen in die führenden Register überführen.
¶ 38. Nachfolgende Detailseiten dieses Bereichs
Die folgenden Vertiefungen sind in der Wiki-Struktur vorgesehen, aber zum Stand dieser Seite noch nicht als freigegebene Fachseiten vorausgesetzt:
| Geplanter Pfad | Schwerpunkt |
|---|---|
Kritische-Lieferanten-und-Dienste |
Kritikalitätsportfolio und Konzentration |
Sicherheitsanforderungen-in-Vertraegen |
Klausel- und Abweichungsmatrix |
Unterauftragnehmer-und-Flow-down |
Transparenz, Änderung und Weitergabe |
Lieferantenueberwachung |
Reviews, Nachweise und Kennzahlen |
Aenderungen-Vorfaelle-und-Eskalation |
Ereignis- und Eskalationssteuerung |
Exit-Portabilitaet-und-Ersatz |
Migration, Alternative und Beendigung |
Nicht angelegte Zielpfade werden bewusst nicht als anklickbare Links dargestellt.
¶ 39. Verknüpfte Seiten
| Thema | Interne Seite |
|---|---|
| relevante Dienste | Relevante Dienste und Prozesse |
| Systeme/Produkte | Asset- und Systeminventar |
| Abhängigkeit/Konzentration | Kritikalität und Abhängigkeiten |
| konkrete externe Services | Externe Dienste und Cloud |
| Risikoverfahren | NIS2-Risikomethodik |
| Risikoregister | NIS2-Risikoregister |
| Maßnahmen | Risikobehandlungsplan |
| Wirksamkeit | Wirksamkeitsprüfung |
| Nachweise | NIS2-Nachweisregister |
| ISMS-Lieferantenprozess | Lieferanten und Dienstleister |
| Lieferantenbewertungen | Lieferantenbewertungen |
| DSGVO-Auftragsverarbeitung | Auftragsverarbeitung |
| DSGVO-Lieferantenkontrollen/Exit | Lieferantenkontrollen und Exit |
¶ 40. Offizielle Quellen und fachliche Orientierung
- § 30 BSIG – Risikomanagementmaßnahmen und Sicherheit der Lieferkette
- Richtlinie (EU) 2022/2555 – insbesondere Artikel 21 Absätze 2 und 3
- Durchführungsverordnung (EU) 2024/2690 – insbesondere Nummer 5.1 zur Lieferkettensicherheit
- BSI und ZenDiS – Strategiepapier zu sicheren Softwarelieferketten
¶ 41. Weiterführende Informationen von SMCT MANAGEMENT
SMCT MANAGEMENT
Unterstützung bei NIS2, Lieferkettenrisiken, Lieferantensteuerung, Vertragsanforderungen und prüffähigen Nachweisen
NIS2-Beratung ansehen
Unterstützung bei NIS2, Lieferkettenrisiken, Lieferantensteuerung, Vertragsanforderungen und prüffähigen Nachweisen
NIS2-Beratung ansehen
¶ 42. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.1 | 09.08.2026 | Neue Musterseite mit Steuerungscockpit, End-to-End-Prozess, Lieferkettenregister, Kritikalität, Due Diligence, Vertrags- und Kontrollmatrizen, Unterauftragnehmern, Konzentration, Monitoring, Vorfällen, Exit, fünf Prüfpfaden, Kennzahlen und Qualitätsgate erstellt | Ausstehend |