D ie Ära der wohlgeordneten Checklisten ist vorbei. Was lange als erstrebenswerter Zustand galt – „prüfungsreif“, „compliant“, „auditfähig“ – wirkt 2025 wie ein Raster aus einer anderen Zeit. Nicht, weil Gesetze unwichtiger geworden wären. Im Gegenteil: Nie zuvor griffen so viele Regelwerke gleichzeitig ineinander. Aber Compliance ist nicht mehr das Ziel, sondern die Einstiegshürde. Die wirkliche Führungsaufgabe heißt heute Governance: sichtbar steuern, wirksam priorisieren, unterbrechungsfrei reagieren – und das auf Basis von Evidenzen, die täglich entstehen. Wer 2025 nur Vorgaben abarbeitet, hat verloren. Wer Governance als Produktionsfaktor begreift, gewinnt Geschwindigkeit, Vertrauen und Krisenfestigkeit.

Dieser Beitrag beleuchtet, was sich im Kern verschoben hat: von Pflichten zu Fähigkeiten, von Papier zu Prozessen, von Kontrollen zu Kompetenz. Er zeigt, warum DORA, NIS2, AI Act, CRA, CSRD & Co. kein Wirrwarr sind, sondern ein einziger, klarer Imperativ: Bau dir eine Organisation, die beweisen kann, was sie kann. Und zwar nicht im Jahresbericht, sondern wenn es darauf ankommt.

Es beginnt selten mit einem direkten Angriff auf das eigene Haus. Häufiger startet die Kettenreaktion einige Sprünge entfernt: ein „Minor Incident“ bei einem SaaS-Anbieter, eine Schwachstelle in einer File-Transfer-Lösung, ein überprivilegierter Account beim Managed Service Provider, ein Update, das im Build-Prozess eines Partners kompromittiert wurde. Für die Öffentlichkeit sind das zunächst nur Randnotizen. Für Betreiber kritischer oder wichtiger Dienste können es jedoch die Sekunden sein, in denen aus einem Fremdproblem eine eigene Meldepflicht wird. Spätestens mit NIS2 ist klar: Wer auf Lieferketten setzt (und wer tut das nicht?), trägt Verantwortung – und zwar nicht nur für die Prävention, sondern auch für die Meldung. Dieses „NIS2 im Nacken“-Gefühl ist kein Aktionismus, sondern Ausdruck einer Realität, in der Abhängigkeiten Teil des Kernbetriebs sind.

Dieser Beitrag erklärt, warum Lieferkettenereignisse unter NIS2 meldepflichtig werden können, wie sich Meldewege, Schwellen und Verantwortlichkeiten in der Praxis anfühlen, welche Governance-Bausteine jetzt zählen – und wie man den Spagat schafft zwischen Transparenz, Tempo und Verlässlichkeit. Nicht als trockene Gesetzeslektüre, sondern als Betriebsanleitung für den Ernstfall.

Es knirscht selten laut, wenn es passiert. Kein großer Knall, keine rot blinkenden Warnlampen. Stattdessen: eine kleine Konfigurationsänderung bei einem Dienstleister, ein unscheinbares Update, eine freundliche E-Mail eines „Partners“, ein Browser-Plugin aus einem Hersteller-Marketplace. Wochenlang wirkt alles normal, die Dashboards bleiben grün. Und doch hat sich die Risikolage grundlegend verschoben – nur eben nicht dort, wo das eigene SOC hinschaut. Die Schwachstelle liegt außerhalb des Perimeters, außer Reichweite der üblichen Telemetrie und häufig auch jenseits der eigenen Zuständigkeiten. Genau dort, wo moderne Wertschöpfung in der Praxis stattfindet: bei Third Parties.

Dass Drittparteien zur Achillesferse werden, ist keine überraschende Schlagzeile – aber die Mechanik dahinter wird in vielen Unternehmen unterschätzt. Third Parties stehen mitten in unseren Prozessen, tragen weitreichende Berechtigungen, hosten Daten, signieren Updates, verwalten Identitäten, triagieren Tickets, betreiben Infrastruktur und liefern das, was Kundinnen und Kunden direkt erleben: Verfügbarkeit, Geschwindigkeit, Qualität. In dieser Rolle sind sie nicht „außen“, sondern innen – oft mit mehr Rechten, mehr Einblick und mehr Steuerungsmacht als das, was wir im eigenen Haus für selbstverständlich halten.

Third-Party-Risk-Management (TPRM) galt lange als Pflichtfach: Fragebogen verschicken, Zertifikate einsammeln, Auditberichte abheften – fertig. Spätestens mit dem Digital Operational Resilience Act (DORA) ist dieses Verständnis Geschichte. TPRM wird vom statischen Kontrollpunkt zum dynamischen Kern der digitalen Widerstandsfähigkeit. Nicht mehr das „Ob“ einer Maßnahme zählt, sondern das „Hält es im Ernstfall?“. Governance rückt damit näher an den operativen Puls; Lieferantenbeziehungen werden zu gemeinsam verantworteten Resilienz-Systemen – gemessen, getestet, nachweisbar.

Dieser Beitrag zeigt, wie sich TPRM unter DORA grundlegend verschiebt: weg von Dokumentation, hin zu belastbarer Operations-Resilienz. Er ordnet die neuen Erwartungen, skizziert ein modernes Operating Model, gibt konkrete Leitplanken für Verträge, Technik und Monitoring – und benennt Anti-Patterns, die heute noch zu häufig zu sehen sind.

Die Digitalisierung der Finanzwelt hat in den letzten Jahren einen klaren Trend hervorgebracht: Immer mehr Leistungen werden an externe Partner ausgelagert. Cloud-Computing, spezialisierte IT-Dienstleister, externe Rechenzentren, Software-as-a-Service-Lösungen oder Managed Security Services – kaum ein Finanzunternehmen betreibt heute noch seine gesamte IT selbst. Diese Entwicklung hat enorme Vorteile: schnellere Innovation, flexiblere Skalierung, Zugang zu Spezialwissen und oft auch Kostenvorteile. Doch sie hat eine Schattenseite, die spätestens mit dem Inkrafttreten von DORA in den Mittelpunkt rückt: Die Abhängigkeit von Drittanbietern kann zur Achillesferse werden, wenn Risiken nicht konsequent gemanagt werden. DORA macht deshalb das Management von IKT-Drittparteien zu einer eigenen Säule der digitalen Resilienz – mit klaren Vorgaben, die deutlich über das hinausgehen, was bisher viele Unternehmen praktiziert haben.

Der Grundsatz: Auslagerung hebt Verantwortung nicht auf

Der Kern der DORA-Vorgaben ist einfach: Unternehmen bleiben auch dann vollständig verantwortlich, wenn sie kritische Funktionen an externe Partner auslagern. Es gibt kein „Das macht unser Dienstleister, darum kümmern wir uns nicht“ mehr. Vielmehr muss jedes Unternehmen sicherstellen, dass auch ausgelagerte Services den gleichen Resilienz- und Sicherheitsstandards entsprechen wie interne Leistungen. Das bedeutet, dass die Auswahl, Überwachung und vertragliche Absicherung von Drittanbietern einen zentralen Platz im Risikomanagement bekommt. Schon vor Vertragsabschluss muss geprüft werden, ob ein Anbieter die technischen, organisatorischen und finanziellen Voraussetzungen erfüllt, um die ausgelagerten Leistungen sicher und stabil zu erbringen. Diese Prüfung ist keine reine Formalität, sondern muss dokumentiert, nachvollziehbar und auf die kritischen Funktionen des Unternehmens zugeschnitten sein.