ISO 27001 und Lieferantenbeziehungen: Anforderungen, Nachweise und Monitoring
Dieser Text wurde mit künstlicher Intelligenz (KI) erstellt.
Lieferanten verarbeiten Informationen, betreiben Plattformen, entwickeln Software und erhalten Zugänge zu Systemen. Ein Informationssicherheits-Managementsystem muss die daraus entstehenden Risiken in seinen Geltungsbereich und seine Risikobehandlung einordnen. ISO/IEC 27001:2022 definiert Anforderungen an ein ISMS. ISO/IEC 27002:2022 bietet dazu Umsetzungshinweise für Informationssicherheitskontrollen.
Die Normen schreiben nicht für jede Organisation denselben Lieferantenprozess vor. Auswahl und Ausgestaltung der Kontrollen folgen dem eigenen Kontext und den bewerteten Risiken. Dieser Beitrag paraphrasiert öffentlich belegbare Kontrollthemen. Er gibt weder Normtext wieder noch ersetzt er eine lizenzierte Normausgabe, Zertifizierungsberatung oder Rechtsberatung.
Das Wichtigste in Kürze
ISO/IEC 27001 behandelt Lieferantenrisiken im Rahmen des risikobasierten ISMS; ISO/IEC 27002 gibt praktische Orientierung zu den zugehörigen Kontrollen.
Die Controls 5.19 bis 5.23 betreffen Lieferantenbeziehungen, Vereinbarungen, ICT-Lieferketten, Überwachung und Änderungen sowie Cloud-Nutzung.
Ein belastbarer Prozess begleitet Auswahl, Vertrag, Betrieb, wesentliche Änderungen und Beendigung der Beziehung.
Zertifikate und Fragebögen sind mögliche Nachweise, aber kein automatischer Beleg für jede benötigte Kontrolle im konkreten Scope.
Technisches Monitoring ergänzt organisatorische Evidenz. Eine externe Bewertung kann interne Prozesse und vertragliche Pflichten nicht abschließend beurteilen.
ISO/IEC 27001, 27002 und 27036 richtig einordnen
ISO/IEC 27001 ist der zertifizierbare Anforderungsstandard für Informationssicherheits-Managementsysteme. Nach Angaben der ISO soll ein konformes ISMS Risiken für Vertraulichkeit, Integrität und Verfügbarkeit mit einem an Größe und Bedarf angepassten Risikomanagementprozess behandeln. Die Zertifizierung bezieht sich auf den festgelegten ISMS-Scope einer Organisation, nicht automatisch auf jedes Produkt, jeden Standort oder jeden Lieferanten.
ISO/IEC 27002 ist kein eigenständig zertifizierbarer Standard. ISO beschreibt ihn als Leitfaden mit bewährten Vorgehensweisen und Kontrollzielen für Informationssicherheit. Die Controls 5.19 bis 5.23 bilden in der Ausgabe 2022 einen zusammenhängenden Bereich für Lieferanten und Cloud-Nutzung. Ein Unternehmen muss ihre Relevanz im eigenen Risikokontext bewerten und die gewählte Behandlung nachvollziehbar dokumentieren.
Die Reihe ISO/IEC 27036 vertieft Lieferantenbeziehungen. Teil 1 erläutert Überblick und Konzepte aus Sicht von Beschaffer und Lieferant. Teil 2 enthält grundlegende Anforderungen für Definition, Betrieb, Überwachung, Überprüfung, Pflege und Verbesserung solcher Beziehungen. Teil 3 gibt Leitlinien für mehrstufige Lieferketten von Hardware, Software und Services. Teil 4 behandelt Risiken bei Beschaffung und Bereitstellung von Cloud-Diensten.
ISO/IEC 27036 ersetzt ISO/IEC 27001 nicht. Die Reihe kann Verantwortlichen helfen, Lieferantenprozesse und ICT-Lieferketten detaillierter zu gestalten. Welche Teile angewendet werden, hängt von Produkten, Diensten, Vertragsrollen und Risiken ab.
Die Controls 5.19 bis 5.23 als Prozesskette
Die Kontrollnummern allein sind keine Checkliste für pauschale Konformität. Sie markieren Themen, die in der Risikobehandlung miteinander verbunden werden sollten. Die folgende Tabelle verwendet sinngemäße Kurzbeschreibungen und enthält keinen Normtext.
Control
Thema in sinngemäßer Kurzform
Praktische Leitfrage
Mögliche Evidenz
5.19
Sicherheitsrahmen für die Zusammenarbeit mit Lieferanten
Wie werden Risiken, Rollen und Regeln für unterschiedliche Lieferantentypen festgelegt?
Richtlinie, Inventar, Kritikalität und Risikobewertung
5.20
Verbindliche Sicherheitsregeln für den Leistungsbezug
Welche Anforderungen und Verantwortungen sind verbindlich vereinbart?
Vertrag, Sicherheitsanlage, Leistungs- und Meldepflichten
5.21
Risikosteuerung über mehrere ICT-Lieferstufen
Wie werden Risiken aus Komponenten, Unterauftragnehmern und mehreren Lieferstufen behandelt?
Lieferkettenangaben, Entwicklungs- und Änderungsnachweise
5.22
Laufende Kontrolle und Umgang mit Leistungsänderungen
Wie werden Leistung, Sicherheit, Abweichungen und wesentliche Änderungen verfolgt?
Reviews, Kennzahlen, Vorfälle, Maßnahmen und Änderungsfreigaben
5.23
Sichere Auswahl und Nutzung von Cloud-Diensten
Wie werden Auswahl, Nutzung, Betrieb und Beendigung eines Cloud-Dienstes sicher gesteuert?
Cloud-Risikobewertung, Rollenmodell, Konfiguration und Exit-Plan
Control 5.19 schafft den organisatorischen Rahmen. Daraus folgen risikogerechte Anforderungen für 5.20. Bei ICT-Produkten und -Diensten erweitert 5.21 den Blick über den direkten Vertragspartner hinaus. 5.22 hält die Bewertung während des Betriebs aktuell. 5.23 ergänzt cloud-spezifische Fragen, etwa geteilte Verantwortungen, Administration, Datenorte, Änderungen und Beendigung.
Die Evidenzspalte zeigt mögliche Nachweise, keine verbindliche Mindestliste. Auditoren beurteilen, ob die gewählten Kontrollen zum Risiko passen, umgesetzt sind und im festgelegten Scope wirken. Ein vorhandener Vertrag ohne gelebte Überwachung reicht dafür ebenso wenig wie ein technischer Messwert ohne verantwortlichen Prozess.
Vom Lieferanteninventar zu Anforderungen und Vertrag
Der Lebenszyklus beginnt mit einem gepflegten Inventar. Es ordnet Vertragspartner, bezogene Leistung, internen Eigentümer, Laufzeit, Datenarten, Systemzugriffe, Unterauftragnehmer und unterstützte Geschäftsprozesse zu. Die Kritikalität entscheidet über Prüftiefe und Freigabe. Kriterien können Auswirkung eines Ausfalls, Zugriff auf sensible Informationen, Austauschbarkeit, Konzentration und technische Abhängigkeit sein.
Vor Vertragsabschluss prüft das Unternehmen, ob ein Anbieter die risikobezogenen Anforderungen erfüllen kann. Selbstauskünfte, Zertifikate, Auditberichte, technische Informationen, Referenzen und Gespräche liefern unterschiedliche Evidenz. Ein ISO/IEC-27001-Zertifikat ist nur im dokumentierten Geltungsbereich und Zeitraum aussagekräftig. Prüfen Sie deshalb zertifizierte Organisation, Scope, Standorte, Ausschlüsse und Gültigkeit.
Die Vereinbarung übersetzt relevante Anforderungen in Verantwortungen und nachprüfbare Regeln. Typische Themen sind zulässige Nutzung und Schutz von Informationen, Zugriffskontrolle, Sicherheitsvorfälle, Schwachstellen, Unterauftragnehmer, Prüf- und Informationsrechte, Rückgabe oder Löschung von Daten sowie Unterstützung beim Exit. Die konkrete Vertragsgestaltung gehört in die Hände der zuständigen Rechts- und Fachfunktionen.
Ein Standardkatalog erleichtert die Beschaffung, darf aber Kritikalität und Leistungsart nicht verdecken. Für einen Cloud-Betreiber mit administrativem Zugriff sind andere Evidenzen und Eskalationen angemessen als für einen Lieferanten ohne System- oder Datenzugriff. Abweichungen vom Standard benötigen eine dokumentierte Risikobewertung, Entscheidung und gegebenenfalls kompensierende Maßnahmen.
Ein strukturierter Third-Party-Risk-Management-Prozess kann Inventar, Kritikalität, Due Diligence, Maßnahmen und Freigaben verbinden. Er muss mit dem ISMS-Risikoprozess abgestimmt sein, damit Lieferantenrisiken nicht in einer getrennten Datenbank ohne Risikoeigentümer verbleiben.
ICT-Lieferkette und Cloud-Dienste vertiefen
ICT-Lieferketten sind mehrstufig. Der direkte Anbieter kann Softwarekomponenten, Plattformdienste, Rechenzentren oder Supportleistungen weiterer Parteien nutzen. ISO/IEC 27036-3:2023 adressiert ausdrücklich Risiken aus räumlich verteilten und mehrstufigen Lieferketten für Hardware, Software und Services. Ziel ist bessere Sicht auf Abhängigkeiten und ein angemessener Umgang mit Risiken, nicht die Behauptung einer jederzeit bekannten Lieferkette.
Praktisch sollte der Beschaffer klären, welche Unterauftragnehmer oder Komponenten für die bezogene Leistung relevant sind, wie Änderungen mitgeteilt werden und wer Schwachstellen behandelt. Bei Software können Entwicklungs- und Updateprozesse, Herkunft von Komponenten, Supportzeiträume und Sicherheitsmeldungen relevant sein. Welche Detailtiefe erreichbar und angemessen ist, hängt von Marktposition, Kritikalität und Vertragsmodell ab.
Cloud-Dienste erfordern eine klare Aufteilung der Verantwortungen. Der Provider sichert die von ihm kontrollierten Ebenen; der Kunde bleibt je nach Dienstmodell unter anderem für Identitäten, Berechtigungen, Konfigurationen, Daten und eigene Anwendungen verantwortlich. ISO/IEC 27036-4 gibt Orientierung für Risiken bei Erwerb und Bereitstellung von Cloud-Services. ISO/IEC 27017 ergänzt Kontrollhinweise für Cloud-Kunden und Cloud-Anbieter.
Für die Auswahl sind Datenverarbeitung, administrative Zugänge, Protokollierung, Verschlüsselung, Backup, Wiederherstellung, Portabilität und Exit zu prüfen. Auch schnelle Funktions- und Vertragsänderungen brauchen einen Prozess. Eine Freigabe zu Beginn sagt wenig über einen später wesentlich erweiterten Dienst aus.
Eine externe technische Bewertung kann öffentlich erreichbare Ressourcen und beobachtbare Sicherheitsmerkmale eines Anbieters ergänzen. Ein Security Rating macht ausgewählte Signale und Trends vergleichbar. Es erkennt weder jeden Unterauftragnehmer noch zwangsläufig die konkret verwundbare Softwareversion und bestätigt keine internen Cloud-Kontrollen.
Nachweise, Monitoring und Änderungen im Betrieb
Nach dem Onboarding verändert sich das Lieferantenrisiko. Leistungen werden erweitert, Unterauftragnehmer wechseln, Zertifikate laufen ab und neue technische Exponierungen entstehen. Monitoring verbindet deshalb organisatorische Ereignisse, Leistungsdaten, Sicherheitsmeldungen und technische Signale. Rhythmus und Tiefe richten sich nach Kritikalität und Veränderungsgeschwindigkeit.
Geeignete Nachweise können aktuelle Zertifikate, Audit- oder Prüfberichte, Service Reviews, Kennzahlen, Vorfallberichte, Maßnahmenpläne und technische Bewertungen sein. Jeder Nachweis hat Grenzen. Ein Prüfbericht bezieht sich auf einen definierten Zeitraum und Scope. Ein Fragebogen zeigt eine Selbstauskunft. Eine Außensicht erfasst öffentlich beobachtbare Merkmale. Eine belastbare Bewertung dokumentiert Quelle, Datum, Reichweite und offene Fragen.
Änderungsmanagement benötigt Auslöser. Dazu zählen neue Datenarten, zusätzliche Systemzugriffe, Standort- oder Kontrollwechsel, neue Unterauftragnehmer, erhebliche Störungen, Sicherheitsvorfälle und geänderte Leistungen. Der interne Eigentümer bewertet gemeinsam mit Informationssicherheit, Einkauf, Datenschutz und Recht, ob eine neue Risikobewertung, Vertragsänderung oder Freigabe erforderlich ist.
Technisches Monitoring sollte keinen automatischen Schuldnachweis erzeugen. Ein neuer Befund wird zuerst attribuiert und validiert. Danach folgen Rückfrage, Maßnahme, Frist und Nachprüfung. Der Ansatz von Vendor Risk Management mit LocateRisk kann die externe Beobachtung skalieren. Organisatorische Nachweise, Vertragsentscheidungen und interne Freigaben bleiben separate Aufgaben.
Steuerungskennzahlen unterscheiden Prozess und Risiko. Prozesskennzahlen zeigen überfällige Reviews, fehlende Eigentümer oder abgelaufene Nachweise. Risikokennzahlen betrachten offene hohe Befunde, wiederkehrende Abweichungen oder Konzentrationen. Ein Durchschnittswert darf kritische Einzelbeziehungen nicht verdecken.
Exit sowie Abgrenzung zu NIS2 und DORA
Eine Lieferantenbeziehung endet nicht mit der Kündigung. Zugänge, Schlüssel, Zertifikate, Schnittstellen, Datenkopien und Weiterleitungen müssen kontrolliert behandelt werden. Der Vertrag und der Exit-Plan klären Datenrückgabe, Löschung, Übergabe, Restpflichten und Unterstützung bei einem Anbieterwechsel. Bei kritischen Diensten sollte die Umsetzbarkeit des Exits vor einer Störung geprüft werden.
ISO/IEC 27001 ist ein freiwillig nutzbarer Managementsystemstandard und kein Ersatz für anwendbares Recht. Die NIS2-Richtlinie verlangt für betroffene wesentliche und wichtige Einrichtungen unter anderem Sicherheit der Lieferkette einschließlich der Beziehungen zu direkten Lieferanten und Dienstleistern. Welche deutschen Pflichten für eine konkrete Organisation gelten, muss anhand des jeweils aktuellen Rechts und der Betroffenheit geprüft werden. Der Beitrag zur NIS2-Lieferkettensicherheit erläutert den regulatorischen Kontext.
DORA gilt für die in ihrem Artikel 2 erfassten Finanzunternehmen und behandelt das IKT-Drittparteirisiko mit detaillierten Anforderungen an Governance, Vertragslebenszyklus, Register, Überwachung und Exit. Die Delegierte Verordnung (EU) 2024/1773 konkretisiert die Policy für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen. Ein ISO-basiertes Lieferantenprogramm kann Evidenz und Prozesse beitragen, belegt aber nicht automatisch DORA-Konformität. Weitere Einzelheiten bietet der Artikel zum IKT-Drittparteirisiko unter DORA.
Für die Praxis empfiehlt sich eine gemeinsame Prozessbasis mit regulatorischen Erweiterungen. Inventar, Kritikalität, Risikobewertung, Vertrag, Monitoring und Exit werden zentral gesteuert. Zusätzliche Rechts- oder Branchenanforderungen ergänzen Felder, Freigaben, Fristen und Nachweise. So bleiben Verantwortungen konsistent, ohne ISO-Zertifizierung und Rechtskonformität gleichzusetzen.
Ein wirksamer Lieferantenprozess zeigt im Audit nicht nur Dokumente. Er kann erklären, warum eine Drittpartei kritisch ist, welche Anforderungen vereinbart wurden, wie Veränderungen erkannt werden und wie offene Risiken behandelt sind. Genau diese Verbindung von Entscheidung, Evidenz und Betrieb macht die Kontrollen belastbar.
In der Ausgabe 2022 behandeln die Controls 5.19 bis 5.23 Lieferantenbeziehungen, Sicherheitsanforderungen in Vereinbarungen, die ICT-Lieferkette, Überwachung und Änderungen von Lieferantenleistungen sowie die sichere Nutzung von Cloud-Diensten.
Nicht allein. Prüfen Sie Organisation, Scope, Standorte, Gültigkeit und Bezug zur bezogenen Leistung. Je nach Risiko sind weitere Evidenzen wie Auditberichte, technische Informationen, Verträge, Service Reviews oder Maßnahmenpläne erforderlich.
Die Normenreihe vertieft Informationssicherheit in Lieferantenbeziehungen. Sie behandelt Grundlagen, Anforderungen an Beziehungen zwischen Beschaffer und Lieferant, mehrstufige Lieferketten für Hardware, Software und Services sowie Cloud-Dienste.
Die Frequenz sollte sich nach Kritikalität, Risiko und Veränderung richten. Zusätzlich zu geplanten Reviews eignen sich Auslöser wie neue Leistungen oder Zugriffe, Sicherheitsvorfälle, Unterauftragnehmerwechsel, ablaufende Nachweise und auffällige technische Veränderungen.
Nein. Ein ISMS kann relevante Prozesse und Evidenzen unterstützen. NIS2 und DORA haben jedoch eigene Anwendungsbereiche und rechtliche Anforderungen. Betroffenheit und Umsetzung müssen gesondert geprüft werden.
Sie möchten die externe Sicherheitslage Ihrer Lieferanten wiederkehrend beobachten und als Evidenz in Ihr ISMS einbinden? Erfahren Sie mehr über Vendor Risk Management mit LocateRisk.
We use cookies to optimize our website and our service.
Functional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistics
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
Deutsch 
English 
Français