Lieferkette und Informationsregister

Drittparteien, Assets, Datenflüsse

In Teil 1 dieser Serie standen Führung, Geltungsbereich und Risikolage im Mittelpunkt – die Entscheidungsübersicht, auf der für Ihre Kunden alles zusammenläuft. In Teil 2 haben wir gezeigt, wie aus Ereignissen strukturierte Vorfälle mit klaren Entscheidungen, Verantwortlichkeiten und Meldelogik werden.

Die dritte Dimension, auf die Aufsicht und regulierte Kunden zunehmend schauen, ist die Lieferkette und das Informationsregister:

Welche Unterauftragnehmer hängen an Ihren Leistungen und wie werden sie gesteuert?
Über welche Systeme, Standorte und Datenflüsse werden die Services für regulierte Kunden erbracht?
Wie fügt sich Ihr Bild von Drittparteien, Assets und Datenflüssen in die DORA- und NIS2-Logik Ihrer Kunden ein?

Entscheider wollen sehen: Drittparteien, Assets und Datenflüsse sind kein Flickenteppich, sondern strukturiert und prüffest abgebildet.

Genau das leisten die folgenden Bausteine.

1. Lieferkette beherrschbar machen – kritische Unterauftragnehmer und Leistungen

Worum es geht

DORA verlangt von Finanzunternehmen ein strukturiertes Management ihrer IKT-Drittparteirisiken, inklusive Register der IKT-Dienstleister, kritischer Abhängigkeiten und Anforderungen an Ausstiegsstrategien. NIS2 verpflichtet wichtige und besonders wichtige Einrichtungen, die Cybersicherheit ihrer Lieferanten und Dienstleister zu bewerten und angemessene Maßnahmen in der Lieferkette umzusetzen.

Dienstleister geraten damit doppelt in den Fokus:

als unmittelbare IKT-Dienstleister der regulierten Einrichtungen,
und dort, wo sie selbst Unterauftragnehmer einsetzen, als Steuerer ihrer eigenen Lieferkette.

Entscheider wollen sehen, dass Ihre Leistungen nicht an einer intransparenten Kette hängen, sondern auf einer gesteuerten Unterauftragnehmerlandschaft beruhen.

Belege, die zählen

Strukturierte Übersicht der eigenen IKT-Lieferkette, mindestens für:

alle Unterauftragnehmer, die an der Erbringung regulierter Kundenleistungen beteiligt sind (Cloud-Provider, Plattform-/Infrastruktur-Dienste, Security Operations, Entwicklungs- und Betriebsdienstleister),
zugeordnete Leistungen, Standorte, Rechenzentrumsregionen, genutzte Services,
Kennzeichnung kritischer Abhängigkeiten (z. B. zentrale Identity-, Logging- oder Storage-Dienste, Single-Provider-Exponierungen).

Risikobasierte Einstufung der Unterauftragnehmer:

Klassifizierung nach Kritikalität (z. B. „kritisch“, „wichtig“, „unterstützend“) bezogen auf Verfügbarkeit, Integrität, Vertraulichkeit und regulatorische Relevanz,
Bewertung der Informationssicherheit und Resilienz (z. B. ISO/IEC-27001-Zertifikate, SOC-Berichte, relevante Prüfungen, spezifische Anforderungen der jeweiligen Branchenaufsichten),
dokumentierte Kriterien, wann ein Lieferant als „kritisch“ eingestuft wird.

Vertragliche Absicherung der Sicherheits- und Resilienzanforderungen:

standardisierte Klauseln zu Informationssicherheit, Incident-Handling, Meldewegen, Audit- und Reportingrechten,
klare Regelungen zur Unterbeauftragung (Zustimmungs- und Informationspflichten, Transparenz über weitere Subdienstleister),
Exit- und Fallback-Regelungen für kritische Services, inklusive Fristen und Verantwortlichkeiten.

Nachweise zur regelmäßigen Überwachung der Lieferanten:

konsolidierte Lieferantenbewertung (z. B. jährlicher Review mit Risikoeinstufung, Maßnahmen und Beschlüssen),
dokumentierte Follow-ups auf Feststellungen (z. B. Sicherheitslücken, Verfügbarkeitsprobleme, SLA-Verletzungen),
Eskalationslogik bei Nichterfüllung (bis hin zu geordneten Exit-Szenarien).

Warum das überzeugt

Sie zeigen, dass Ihre kritischen Leistungen nicht zufällig auf externen Komponenten beruhen, sondern dass Unterauftragnehmer identifiziert, klassifiziert, vertraglich gebunden und überwacht werden.

Für Banken, Versicherungen, Energieversorger oder andere NIS2-pflichtige Einrichtungen wird erkennbar: Sie erfüllen die Logik, die diese Häuser selbst gegenüber der Aufsicht zu DORA und NIS2 nachweisen müssen, inklusive der Steuerung von Drittparteirisiken.

2. Informationsregister als Dreh- und Angelpunkt – Services, Systeme, Datenflüsse

Worum es geht

DORA verlangt von Finanzunternehmen ein Informationsregister, das IKT-Dienste, kritische Funktionen, unterstützende Systeme und deren Abhängigkeiten abbildet. NIS2 fordert ein belastbares Risikomanagement für Netz- und Informationssysteme, einschließlich Kenntnis über eingesetzte Assets, deren Verwundbarkeit und die damit verbundenen Datenflüsse.

Für Dienstleister ist das Informationsregister der Knotenpunkt, an dem sich technische Realität und Aufsichtsanforderungen treffen:

Welche Services bieten Sie,
über welche Systeme und Standorte werden sie erbracht,
welche Daten werden verarbeitet,
welche Datenflüsse entstehen, intern, zum Kunden und zu Unterauftragnehmern?

Belege, die zählen

Service-zentriertes Informationsregister für regulierte Kundenleistungen:

Beschreibung der einzelnen Services (z. B. Fachanwendung, API-Plattform, Betriebs-/Security-Services),
zugehörige technische Komponenten (Applikationen, Datenbanken, Middleware, Netzkomponenten),
zugeordnete Standorte und Betriebsmodelle (On-Premises, Private/Public Cloud, Hybrid).

Verknüpfung mit Datenklassifikation und Schutzbedarfen:

Zuordnung der verarbeiteten Datenarten je Service (z. B. Kundenstammdaten, Transaktionsdaten, Protokolle, Telemetrie),
Klassifizierung nach Vertraulichkeit, Integrität und Verfügbarkeit,
Schutzbedarfsstufen mit Bezug zu den Anforderungen der Kunden (z. B. auf Basis BSI-Standard, kundenspezifischer Schutzbedarfsmodelle oder sektorspezifischer Regelwerke).

Transparente Datenflüsse und Schnittstellen:

visualisierte Hauptdatenflüsse zwischen eigenen Systemen, Kundenumgebungen und Unterauftragnehmern,
Kennzeichnung externer Schnittstellen (z. B. APIs, sichere Dateiübertragungen, Message-Queues),
Abbildung der Verantwortlichkeiten an den Schnittstellen (wer betreibt, wer überwacht, wer meldet).

Verknüpfung mit technischen und organisatorischen Kontrollen:

Zuordnung der wesentlichen Sicherheits- und Resilienzmaßnahmen zu Services und Komponenten (Backup-/Recovery-Konzept, Logging-Umgebung, Access-Management, Hardening, Patch-Prozesse),
Darstellung, wie Schutzbedarfe und Risiken aus dem Informationsregister in konkrete Kontrollen und Maßnahmen überführt wurden,
Bezug zu relevanten Standards (insbesondere ISO/IEC 27001/27002, ggf. BSI-IT-Grundschutz).

Warum das überzeugt

Sie liefern nicht nur eine Asset-Liste, sondern ein service- und risikoorientiertes Informationsregister, das exakt die Fragen adressiert, die Aufsicht und Prüfer stellen:

Was tun Sie für den Kunden?
Über welche Systeme und Datenflüsse wird das abgewickelt?
Wie sind Schutzbedarf und Risiken in Kontrollen übersetzt?

Regulierte Kunden können Ihr Register mit überschaubarem Aufwand in ihr eigenes Informationsregister integrieren, ein spürbarer Vorteil in Sorgfaltsprüfungen und bei der Vorbereitung auf DORA- und NIS2-Prüfungen.

3. Verbindung von Lieferkette und Informationsregister – vom Einzelbeleg zur konsistenten Sicht

Worum es geht

Aufsicht und Prüfer wollen keine isolierten Listen sehen, sondern eine konsistente Gesamtsicht, die Lieferkette, Informationsregister, Risiko- und Incident-Management verbindet. DORA und NIS2 legen genau diese Verbindung zugrunde: kritische Funktionen, abhängige IKT-Dienstleister, Assets, Datenflüsse, Vorfälle – alles in einem steuerbaren Rahmen.

Dienstleister überzeugen, wenn klar erkennbar ist:

wie Services auf Systeme und Unterauftragnehmer abgebildet sind,
wie daraus Risiken und Incident-Szenarien abgeleitet werden,
und wie Informationen aus Lieferkette und Register im Vorfall in die Meldepflichten der Kunden einfließen.

Belege, die zählen

Integriertes Mapping:

Zuordnung je Service: Service → technische Komponenten → Unterauftragnehmer → Datenarten/Datenflüsse,
Kennzeichnung kritischer Pfade (Single Points of Failure, zentrale Infrastruktur- oder Security-Dienste),
Verknüpfung mit Wiederanlaufzielen (RTO/RPO) und typischen Incident-Szenarien.

Abgleich mit Risiko- und Incident-Prozessen:

sichtbare Verbindung zwischen Risikoregister, Informationsregister und Lieferantenübersicht,
Beispiele, wie konkrete Risiken (z. B. Ausfall eines Cloud-Providers, Sicherheitsvorfall beim Subdienstleister) im Incident-Playbook, in Klassifizierungslogik und Kundenkommunikation abgebildet sind,
Darstellung, welche Informationen aus Ihrem Register und Ihrer Lieferantensteuerung in DORA-/NIS2-Meldungen der Kunden einfließen können (Zeitlinien, betroffene Services/Kundenkreise, Auswirkungen auf CIA, Root Cause, Maßnahmen).

Aktualitäts- und Pflegeprozess:

definierte Verantwortlichkeiten für die Pflege von Informationsregister und Lieferantenübersicht (z. B. Service Owner, Informationssicherheit, Einkauf),
Aktualisierungszyklen und Trigger (neue Services, neue Unterauftragnehmer, relevante Änderungen an Datenflüssen oder Standorten),
Nachweise durch mindestens einen aktuellen Pflegezyklus (z. B. Protokoll eines Review-Termins mit festgehaltenen Änderungen).

Warum das überzeugt

Ihre Belege ergeben ein prüffestes Gesamtbild:

Lieferkette, Assets und Datenflüsse sind nicht isoliert dokumentiert,
Risiken und Vorfälle werden daran ausgerichtet,
und die Meldefähigkeit Ihrer Kunden nach DORA und NIS2 wird durch Ihre Informationen unterstützt, nicht behindert.

Das reduziert Rückfragen in Sorgfaltsprüfungen, schafft Vertrauen bei Leitung, Informationssicherheit, Einkauf und Aufsicht und zeigt, dass Sie die Logik des europäischen und nationalen Rechtsrahmens verstanden und praktisch umgesetzt haben.

Der 14-Tage-Plan für eine prüfsichere Lieferkette und Informationsregister

Tage 1 bis 4 – Ist-Sicht zusammentragen

Unterauftragnehmerliste und relevante Lieferantenverträge für regulierte Kundenleistungen zusammentragen.
bestehende Asset-/Systeminventare, Architekturübersichten und Datenflussdarstellungen sichten.
vorhandene Datenklassifikationen und Schutzbedarfsbewertungen für kritische Services zusammenführen.

Tage 5 bis 9 – Soll-Bild strukturieren und Belege kuratieren

kritische Services identifizieren und eine servicezentrierte Informationsregister-Ansicht erstellen.
Unterauftragnehmer risikobasiert klassifizieren (Kritikalität, Sicherheitsnachweise, Standorte, Exponierungen).
vertragliche Klauseln zu Informationssicherheit, Incident-Handling, Unterbeauftragung und Exit nachschärfen, wo erforderlich.
Kern-Datenflüsse und externe Schnittstellen visualisieren – mit Verantwortlichkeiten und Schutzbedarfen.

Tage 10 bis 14 – Verbindung herstellen und Wirkung zeigen

Mapping zwischen Services, Komponenten, Unterauftragnehmern und Datenflüssen fertigstellen.
Verknüpfung mit Risiko- und Incident-Prozessen dokumentieren (inkl. Bezug zu Meldepflichten nach DORA/NIS2).
Pflegeprozess mit Rollen, Zyklen und Triggern definieren und mindestens einen Review-Durchgang protokollieren.
eine kompakte Entscheidungsübersicht erstellen:
Lieferkette mit kritischen Unterauftragnehmern,
servicezentriertes Informationsregister mit Assets und Datenflüssen,
Verbindung zu Risiko-, Incident- und Meldeprozessen.

Selbstcheck vor der nächsten Sorgfaltsprüfung

Können wir unsere kritischen Services, deren technische Komponenten und Unterauftragnehmer konsistent und übersichtlich darstellen?
Haben wir eine risikobasierte Klassifizierung unserer Unterauftragnehmer mit klaren Anforderungen, Nachweisen und Eskalationswegen?
Ist unser Informationsregister servicezentriert, mit Schutzbedarfen, Datenflüssen und zugeordneten Kontrollen und lässt es sich plausibel in das Register unserer regulierten Kunden integrieren?
Sind Lieferkette, Informationsregister, Risiko- und Incident-Prozesse nachvollziehbar miteinander verknüpft, inklusive Bezug zu den DORA- und NIS2-Meldepflichten unserer Kunden?

Wie wir Sie unterstützen

Pragmatisch und ohne Overhead hinterfragen wir mit Ihnen in einem fokussierten Austausch:

ob Ihre Lieferkette für regulierte Kundenleistungen vollständig und risikobasiert erfasst ist,
ob Ihr Informationsregister Services, Assets und Datenflüsse so abbildet, wie DORA- und NIS2-Erwartungen es nahelegen,
wie gut Ihre Unterauftragnehmersteuerung und Ihr Register mit Risiko-, Incident- und Meldeprozessen verzahnt sind.

Im Anschluss erhalten Sie ein priorisiertes Maßnahmenboard für Lieferkette und Informationsregister.

In einem zehntägigen Sprint kuratieren wir gemeinsam mit Ihnen die entscheidenden Belege, schließen Lücken in Lieferkette, Register und Verträgen und bereiten eine prüfsichere Gesamtsicht für die nächste Sorgfaltsprüfung vor, inklusive einer praxisnahen Durchsprache typischer DORA-/NIS2-Fragestellungen aus Sicht von Einkauf, Informationssicherheit, Leitung und Aufsicht.

Ausblick auf Teil 4 – Resilienztests und Wirksamkeitsnachweise

Im nächsten Teil zeigen wir, wie Sie Resilienztests und Wirksamkeitsnachweise so strukturieren, dass Sie DORA- und NIS2-Anforderungen zu Tests, Übungen und Verbesserungsprozessen mit wenigen, gezielt ausgewählten Belegen adressieren, anschlussfähig an Ihre Entscheidungsübersicht, Ihre Vorfallskette und Ihr Informationsregister.