Produktstand · geprüft am 01.11.2026

Dienstleister und Lieferkette steuern, nicht nur auflisten.

Ein Rechenzentrum, ein SaaS-Anbieter, dahinter dessen Unterauftragnehmer: Ein großer Teil der Sicherheit liegt heute bei Dienstleistern. Eine Liste mit Vertragsnummern beantwortet aber nicht, welche Anforderungen sie für euch erfüllen, ob ihre Zusicherung noch gilt und was ein Risiko bei einem Subdienstleister für euren Prozess bedeutet. BlueProceedings ISMS verbindet Dienstleister mit Komponenten, Anforderungen, Nachweisen und Prozessen.

  • Arbeitsweise: welches Problem die Funktion löst und wie der Ablauf zusammenhängt
  • Produktstand: was heute in der Pre-Alpha vorhanden ist und wo ihre Grenzen liegen

BIA und Wiederanlauf auf denselben Abhängigkeiten.

Die Business-Impact-Analyse (BIA) bewertet die Auswirkungen eines Ausfalls auf die Geschäftsprozesse. Wiederanlaufzeit (RTO), tolerierbarer Datenverlust (RPO) und benötigte Komponenten machen die Planung konkret. Hängt der Prozess an einem externen Dienst, gehört auch die Dienstleisterkette dazu.

Der berechnete Wiederanlauf bleibt ein Vorschlag auf Basis der erfassten Annahmen und Mittel. Während einer Übung oder eines Vorfalls wird der tatsächliche Verlauf dokumentiert. Daraus kann Folgearbeit für Risiken und die Wirksamkeitsprüfung entstehen. Eine vollständige Abdeckung von BSI-Standard 200-4 oder ISO 22301 wird damit nicht zugesagt.

Eine Zusicherung muss zum betroffenen Prozess passen.

Hängt ein Prozess an einem Dienstleister und dessen Unterauftragnehmern, gehört eine Sicherheitszusage zu dieser Abhängigkeit. Welche Leistung ist gemeint, welche Anforderung betrifft sie und bis wann gilt der Nachweis? Die Anwendung hält diese Bezüge zusammen.

Eine importierte Erklärung allein bestätigt keine Umsetzung. Die zuständigen Rollen prüfen ihre Aussagekraft. Offene Fragen führen zum Nachweismanagement oder zur Risikobetrachtung. Für den Ausfall derselben Leistung nutzt das Notfallmanagement die erfassten Abhängigkeiten.

Neue Katalogversion: erst vergleichen, dann wechseln.

Die Vorschau unterscheidet übertragbare, geänderte und entfallene Regeln sowie neue Anforderungen. Bei Parametern zeigt sie, welche Werte weiter nutzbar sind und wo eine Entscheidung nötig ist. So wird der Arbeitsbedarf vor dem Wechsel sichtbar.

Eine Blaupause hilft, eine Auswahl wiederzuverwenden; ihre Voraussetzungen und Herkunft müssen zum neuen Kontext passen. Die OSCAL-Einordnung erklärt die Formate. Warum ein Katalogwechsel etwas anderes ist als die Übernahme eines alten Sicherheitskonzepts, steht unter Umstieg und Migration.

Aktueller Nachweis und aufbewahrter Bericht sind zwei Stände.

Ein Nachweis kann inzwischen ergänzt oder neu geprüft sein, während ein bereits erzeugter Bericht den damaligen Stand festhält. Für die Vorbereitung eines Audits braucht ihr beides: den nachvollziehbaren Berichtsstand und den Blick auf die Änderungen seit seiner Erstellung.

Die Anwendung zeigt erkannte Änderungen an den Berichtsgrundlagen. Die Verantwortlichen prüfen, ob eine neue Ausgabe erforderlich ist. Welche Aussagen hinter den Dateien stehen, erklärt das Nachweismanagement; den fachlichen Anlass hält die Risikoakte fest.

Nachweise verwalten, ein Audit vorbereiten.

Bei einer Maßnahme zur Speicherverschlüsselung muss erkennbar sein, welche Systeme geprüft wurden, für welchen Zeitraum die Aussage gilt und wer den Nachweis akzeptiert hat. Die Datei bleibt mit ihrem Gegenstand verbunden; der Prüfstatus ist eine eigene Aussage.

Für die Auditvorbereitung werden daraus nachvollziehbare Zusammenhänge: Risiko und Behandlung, Maßnahme, Nachweis und Freigabe. Das Berichtswesen hält einen Stand für den Austausch mit Prüfenden fest. Es ersetzt deren fachliche Prüfung nicht.

Eine offene Anforderung, ein nachvollziehbarer Weg.

Ist etwa die Speicherverschlüsselung noch nicht umgesetzt, wird die Lücke im Zusammenhang mit dem betroffenen Objekt betrachtet. Die Risikoakte hält Ursache, Bewertung, Behandlung und Restrisiko zusammen. Die Maßnahme bekommt Verantwortung, Frist und Kriterien für die Wirksamkeitsprüfung.

Ob die Maßnahme wirkt, braucht einen geeigneten, geprüften Nachweis. Was zu einem bestimmten Zeitpunkt dokumentiert und freigegeben war, zeigt ein Berichtsstand. Eine erledigte Aufgabe allein beantwortet diese Fragen nicht.

Wo der BSI-Standard 300-1 Dienstleister nennt.

Der Standard hat kein eigenes Kapitel zur Dienstleistersteuerung. Dienstleister tauchen aber in mehreren Teilschritten auf; links, was dort steht, rechts, was die Anwendung daraus macht.

AnwendungsbereichKapitel 2.3
Veröffentlicht

Bei der Festlegung des Anwendungsbereichs ist zu klären, welche externen Partner oder Dienstleister vom ISMS berücksichtigt werden.

Auslegung in BlueProceedings ISMS

Dienstleister liegen wie jedes Objekt im Geltungsbereich, außer sie sind begründet ausgeschlossen. Betreibt ein ausgeschlossener Dienstleister eine Komponente innerhalb, oder hat ein Dienstleister keinen Bezug, meldet die Anwendung das. Die Entscheidungsvorlage für die Leitung nennt die Dienstleister-Abhängigkeiten.

Outsourcing-AbgrenzungKapitel 3.1
Veröffentlicht

Für den Informationsverbund ist zu dokumentieren, welche organisatorischen, technischen und infrastrukturellen Teile lokal betrieben und welche ausgelagert werden und welche Cloud-Dienste genutzt werden.

Auslegung in BlueProceedings ISMS

An der Komponente steht, wer sie betreibt und nach welchem Leistungsmodell (IaaS, PaaS, SaaS oder Outsourcing). Eine Verantwortungsvorlage ordnet jede Praktik „wir“, „Dienstleister“ oder „geteilt“ zu; organisatorische Praktiken bleiben immer bei euch. Abweichungen je Anforderung brauchen eine Begründung.

Vertragliche VerpflichtungenKapitel 2.2
Veröffentlicht

Vertragliche Verpflichtungen sind zusammenzustellen; die daraus folgenden Anforderungen gehören ins Anforderungspaket.

Auslegung in BlueProceedings ISMS

Eine Compliance-Verpflichtung am Dienstleister gilt direkt für ihn. „Was fehlt noch?“ nennt Dienstleister mit vertraglichen Verpflichtungen ohne gültigen, akzeptierten Nachweis.

Nachweis der UmsetzungKapitel 4.3
Veröffentlicht

Die zur Beurteilung herangezogenen Nachweise sind der Maßnahme eindeutig zuzuordnen, damit die Umsetzung nachvollzogen werden kann.

Auslegung in BlueProceedings ISMS

Was ein Dienstleister übernimmt, gilt erst mit gültiger Zusicherung als umgesetzt. Die Zusicherung nennt Komponenten und Anforderungen oder ganze Praktiken, Gültigkeit und Vertrauensstufe: Selbstauskunft, Vertragsklausel oder unabhängiges Testat.

Interessierte Parteien und KontextKapitel 2.1.1, 2.4
Veröffentlicht

Dienstleister sind externe interessierte Parteien; Abhängigkeiten von Lieferketten sind ein Beispiel für äußere Einflussfaktoren.

Auslegung in BlueProceedings ISMS

„Dienstleister“ ist eine Standardgruppe der Stakeholder-Landkarte. Ein Faktor zur Lieferkette lässt sich mit den Entscheidungen verbinden, die auf ihm beruhen, etwa einem Wechsel des Anbieters.

Vom Vertrag bis zur Wirkung auf euren Prozess.

  1. Verantwortung festlegenKomponente, Betreiber und Leistungsmodell wählen; die Vorlage verteilt die Praktiken. Neue Vorlagenversionen ändern nichts still: Sie erzeugen einen Prüfhinweis mit Vorher und Nachher je Anforderung.
  2. Zusicherung erfassenVersioniert: Eine Verlängerung oder ein neues Testat ersetzt die Vorgängerversion, die alte bleibt lesbar. Läuft sie ab, fallen die übernommenen Anforderungen auf „nicht zugesichert“ zurück.
  3. Kette abbildenSubdienstleister und deren Unterauftragnehmer bis zu 15 Stufen tief. Zyklen werden abgelehnt; derselbe Subdienstleister über mehrere Pfade zählt einmal, die Pfade bleiben sichtbar.
  4. Risikomeldungen übernehmenDie Risikoerklärung des Dienstleisters kommt manuell, als JSON oder CSV oder als OSCAL-Dokument (POA&M oder Assessment Results). Vorschau und Abgleich mit der Vorfassung zeigen, was neu ist.
  5. Wirkung bewertenEin Risiko auf einer tieferen Stufe wirkt auf alle Dienstleister darüber und über deren Betrieb auf eure Komponenten und Prozesse. Je betroffenem Prozess bewertet eine Person Wirkung und Begründung.

Nichts wird automatisch bewertet. Eine Risikomeldung wird erst durch ausdrückliche Übernahme zum Risikokandidaten, nie direkt zum Risiko. Die Einstufung des Dienstleisters bleibt Quellenangabe.

Was die Anwendung dafür hat.

Dienstleister-Cockpit

Je Dienstleister: betriebene Komponenten, übernommene Anforderungen mit und ohne gültige Zusicherung, geteilte Anforderungen, Zusicherungen mit Ablauf, Vertragsende, was ihr selbst noch tun müsst, und die betroffenen Prozesse.

Fristen im Blick

Vertragsende und Ablauf einer Zusicherung erscheinen als Fälligkeitshinweise, mit dem Vorschlag einer Maßnahme mit Bezug zum Dienstleister.

Eigene Lage bleibt ehrlich

An Dienstleister abgegebene Anforderungen tragen das Kennzeichen „durch Dienstleister“ und zählen nicht in die Kennzahlen zur eigenen Lage; geteilte Verantwortung bleibt in der eigenen Zählung.

Delegationskette im Prüfpaket

Das Prüfpaket enthält je Prozess die benötigten Dienstleister, ihre Subdienstleister, die abgegebenen Anforderungen und die gültigen Zusicherungen. Fehlt eine gültige Zusicherung, steht das ausdrücklich dabei.

Angebotsvergleich

Der aktuelle Dienstleister neben bis zu zwei Angeboten: Leistungsmodell, Zusicherungen, Auditrecht, Meldefrist, Exit-Regelung, Rechtsraum, Standorte, Subdienstleister, erklärte Risiken und Kosten. Bewusst ohne Gesamtzahl und Rangfolge; die Entscheidung trägt eine Begründung.

Wechsel nachvollziehbar

Entscheidet sich die Institution für ein Angebot, entsteht daraus ein neuer Dienstleister; der bisherige bleibt mit seiner Geschichte bestehen.

Fragen zur Dienstleistersteuerung.

Was verlangt NIS2 zur Lieferkette?

Die NIS-2-Richtlinie nennt in Artikel 21 Absatz 2 Buchstabe d die Sicherheit der Lieferkette, einschließlich der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern, als eine der Risikomanagementmaßnahmen. Wie eine Institution das umsetzt und ob es genügt, beurteilt sie selbst; BlueProceedings ISMS macht dazu keine Konformitätsaussage.

Bewertet die Anwendung Dienstleister automatisch?

Nein. Sie zeigt Zusicherungen, Fristen, Ketten und gemeldete Risiken nebeneinander. Ob ein Risiko auf euch wirkt und welches Angebot besser passt, entscheiden Menschen mit Begründung.

Was ist eine Zusicherung?

Die Erklärung oder der Nachweis eines Dienstleisters, dass er bestimmte Anforderungen für bestimmte Komponenten erfüllt, mit Gültigkeit und Vertrauensstufe: Selbstauskunft, Vertragsklausel oder unabhängiges Testat. Ohne gültige Zusicherung zählt eine abgegebene Anforderung nicht als umgesetzt.

Wie kommen Risiken eines Dienstleisters in die Anwendung?

Manuell, als JSON- oder CSV-Datei mit Spaltenzuordnung oder als OSCAL-Dokument (Plan of Action and Milestones oder Assessment Results). Was sich nicht abbilden lässt, steht als Hinweis in der Vorschau.

Verantwortung lässt sich nicht auslagern.

Ein Dienstleister kann Anforderungen umsetzen, die Verantwortung für das ISMS bleibt bei der Institutionsleitung (BSI-Standard 300-1, Kapitel 2.10). Die Anwendung macht sichtbar, was abgegeben ist und worauf ihr euch dabei stützt. Bilder aus der Pre-Alpha folgen.

Das ist noch nicht alles.

Weitere Funktionen sind bereits umgesetzt: alle Funktionen nach den fünf Prozessschritten, Dienstleister und Lieferkette und was sonst noch in der Pre-Alpha steckt.

Weiterlesen

Quellen

Geschrieben von Xhoan Qazimi, BlueProceedings, zuletzt am 01.11.2026 mit den Quellen abgeglichen. Die Funktionsbeschreibung gibt den Stand der Pre-Alpha wieder; methodische Aussagen sind als solche benannt und belegt.

Die Lieferkette gehört ins ISMS.

Dienstleister, Zusicherungen und gemeldete Risiken stehen beim selben Bestand wie Prozesse, Risiken und Nachweise.