Third-Party Risk unter DORA: Wenn Ihr Dienstleister Ihr größtes Ausfallrisiko ist

Third-Party Risk unter DORA: Wenn Ihr Dienstleister Ihr größtes Ausfallrisiko ist

Wenn in der Praxis über DORA gesprochen wird, geht es oft zuerst um interne Themen: Prozesse, Rollen, Tests, Meldungen, Nachweise. Das ist nachvollziehbar, weil man dort „direkt“ gestalten kann. Der größte Hebel für die operative Stabilität liegt aber in vielen Unternehmen an einer anderen Stelle: bei externen Dienstleistern. Nicht, weil Dienstleister per se schlecht wären – im Gegenteil. Sondern weil moderne IT-Landschaften ohne Provider, SaaS, Plattformen, Rechenzentren, Integrationspartner und spezialisierte Services kaum noch sinnvoll betrieben werden können. Genau dadurch entsteht jedoch ein Risiko, das in Audits und im Ernstfall besonders sichtbar wird: Ihr Dienstleister kann Ihr größtes Ausfallrisiko sein – und zwar selbst dann, wenn Ihre interne Organisation sauber aufgestellt ist.

Third-Party Risk klingt als Begriff schnell nach „Vendor Management“. In der Realität ist es viel konkreter: Es geht um Abhängigkeiten, um Reaktionsfähigkeit, um Eskalationswege, um das Zusammenspiel im Incident – und um die Frage, ob Sie als Kunde die Steuerung wirklich in der Hand haben. DORA verschärft diese Perspektive, weil es nicht reicht, einen Vertrag zu haben oder einmal im Jahr eine Bewertung auszufüllen. DORA zielt auf laufende Beherrschung: wiederholbar, nachvollziehbar und im Betrieb sichtbar.

Dieser Beitrag ist deshalb bewusst praxisorientiert aufgebaut. Er zeigt Ihnen, wo Third-Party Risk in der Realität entsteht, warum „Risikobewertung“ allein nicht genügt und welche wenigen, aber wirkungsvollen Bausteine Sie etablieren sollten, damit Ihre Dienstleisterbeziehungen auch unter Druck stabil bleiben. Struktur bringe ich nur dezent ein – die Hauptarbeit soll der Fließtext leisten, damit Sie sich nicht durch ein Checklisten-Gewitter kämpfen müssen.

Warum Dienstleister so oft zum größten Ausfallrisiko werden

Es gibt einen Grund, warum Ausfälle externer Services so häufig besonders weh tun: Sie treffen Sie an zwei Stellen gleichzeitig. Erstens verlieren Sie technische Verfügbarkeit oder Funktionalität. Zweitens verlieren Sie Steuerungsmöglichkeiten, weil Sie nicht „einfach selbst reparieren“ können. Sie sind abhängig von der Priorisierung, Kommunikation und Problemlösung des Providers – und damit von dessen Betriebsmodell, dessen Personal, dessen Zulieferkette und dessen Krisenroutine. Selbst wenn Ihr Team exzellent ist, bleibt ein harter Kern: Sie können nur so schnell sein, wie der Dienstleister Ihnen erlaubt zu sein.

Im Alltag wird dieses Risiko gerne unterschätzt, weil die meisten Tage ruhig sind. Services laufen, SLAs werden eingehalten, Tickets werden irgendwann beantwortet. Das Problem zeigt sich in den Tagen, die Sie nicht planen können: bei größeren Incidents, bei Security-Ereignissen, bei Cloud-Störungen, bei fehlerhaften Releases, bei Zertifikatsproblemen, bei regionalen Ausfällen, bei Lieferketteneffekten – oder schlicht, wenn der Dienstleister in einer Krise mehr Kunden gleichzeitig hat, als er sauber bedienen kann. Dann wird sichtbar, ob Ihre Steuerung robust ist oder ob sie aus Hoffnung besteht.

Viele Unternehmen stellen erst im Audit oder nach dem ersten großen Incident fest, dass ihre „Third-Party Steuerung“ im Wesentlichen aus drei Dingen besteht: einer Vertragsakte, einem Onboarding-Formular und einer Risikoanalyse. Das klingt ordentlich, ist aber für DORA-Betriebsfähigkeit zu wenig. Denn weder Vertrag noch Risikoanalyse beantworten die wichtigste Frage: Was passiert in den ersten 60 Minuten, wenn es knallt?

Das Kernmissverständnis: „Bewertet“ ist nicht „gesteuert“

Eine Bewertung ist ein Snapshot. Steuerung ist ein Takt. Viele Organisationen können sehr gut bewerten: Fragebögen, Zertifikate, Auditberichte, interne Einstufungen. Diese Informationen sind nützlich – aber sie geben Ihnen im Ernstfall nur begrenzt Handlungskraft. Steuerung bedeutet, dass Sie regelmäßig prüfen, ob Annahmen noch gelten, ob sich Abhängigkeiten verändert haben und ob der Dienstleister tatsächlich das liefert, was Sie für Ihre kritischen Services brauchen. Und es bedeutet, dass Sie klare Mechanismen haben, um Abweichungen zu adressieren: von Maßnahmen über Eskalation bis hin zu Fallback oder Exit.

Ein praktischer Indikator hilft, diese Unterscheidung schnell zu erkennen: Wenn Sie gefragt werden „Wie steuern Sie Provider X?“, und die Antwort lautet im Kern „Wir haben einen Vertrag, eine Bewertung und SLAs“, dann sind Sie vermutlich noch im Bewertungsmodus. Wenn die Antwort lautet „Wir haben einen regelmäßigen Review-Takt, definierte Eskalationen, dokumentierte Entscheidungen und getestete Alternativen“, dann sind Sie im Steuerungsmodus. DORA wird – spätestens im Audit – genau diese zweite Antwort sehen wollen.

Wo Third-Party Risk in der Praxis wirklich entsteht

Third-Party Risk ist nicht nur „Sicherheit“. Es ist ein Bündel aus ganz unterschiedlichen Risikotreibern, die im Alltag oft getrennt betrachtet werden. Die typischen Bruchstellen sind erstaunlich wiederkehrend:

Erstens: Intransparente Abhängigkeiten. Viele Provider liefern nicht nur einen Service, sondern sind Teil einer Kette. Der SaaS-Anbieter hängt an Cloud-Regionen, an DNS, an Identitätsdiensten, an eigenen Unterauftragnehmern. Im Incident sind diese Abhängigkeiten oft nicht sofort sichtbar. Wenn Sie nicht wissen, wovon der Service wirklich abhängt, können Sie weder Risiken sinnvoll priorisieren noch Fallbacks realistisch planen.

Zweitens: Unklare Servicegrenzen. Was genau ist der Service, den Sie beziehen? Welche Komponenten gehören dazu, welche nicht? Wer ist verantwortlich für Schnittstellen, für Integrationen, für Monitoring, für die End-to-end-Qualität? Viele Probleme entstehen an den Rändern. Im Vertrag steht „Service verfügbar“, im Betrieb heißt es aber „Integration kaputt, Datenfluss gestört“. Der Provider sieht sich nicht zuständig, Sie sind dennoch betroffen.

Drittens: Kommunikations- und Eskalationsschwächen. In ruhigen Zeiten reicht ein Standard-Supportkanal. In der Krise brauchen Sie einen anderen Modus: schnelle Statusupdates, klare Ansprechpartner, verlässliche Eskalationsstufen, abgestimmte Kommunikation. Wenn Sie erst im Incident herausfinden, wie man „P1“ tatsächlich auslöst, ist es zu spät.

Viertens: Änderungsrisiken. Provider verändern Services permanent: Releases, Konfigurationen, APIs, Security-Features, Zertifikate, Preis- und Leistungsmodelle. Das ist normal. Riskant wird es, wenn diese Änderungen Ihre kritischen Prozesse treffen und Sie keine Routine haben, Änderungen früh zu erkennen, zu bewerten und in Ihre Steuerung einzubauen.

Fünftens: Fehlende Alternativen. Ein Dienstleister kann noch so gut sein – wenn Sie keinen Fallback, keine Exit-Logik und keinen Notbetrieb haben, ist Ihr Risiko strukturell hoch. In vielen Fällen ist „Exit“ nicht realistisch kurzfristig machbar. Aber eine minimale Alternative (Notbetrieb, degradierter Betrieb, manuelle Workarounds, Datenexport, Ersatzprozess) ist fast immer möglich, wenn man sie früh durchdenkt.

Wenn Sie diese fünf Treiber im Griff haben, haben Sie 80% der Third-Party-Risiken im Griff – unabhängig davon, wie groß Ihr Provider-Portfolio ist.

Was DORA praktisch von Ihnen erwartet – ohne Paragrafenreiterei

Aus DORA-Sicht ist entscheidend, dass Sie für kritische IKT-Dienstleistungen nicht nur einkaufen, sondern beherrschen. „Beherrschen“ heißt in der Praxis: Sie können zeigen, dass Sie Dienstleisterrisiken identifizieren, vertraglich adressieren, laufend überwachen und im Ereignisfall wirksam steuern. Prüfer schauen dabei typischerweise weniger auf Ihre Absichtserklärungen und mehr auf die Betriebsspur: Wo sind Reviews, wo sind Entscheidungen, wo sind Maßnahmen, wo sind Tests, wo sind Nachweise aus realen Fällen?

Wenn Sie eine Orientierung brauchen, ist eine einfache Kette hilfreich: Auswahl → Vertrag → Betrieb → Krise → Lernen. Viele Organisationen sind stark in Auswahl und Vertrag. DORA bewertet aber, ob Betrieb, Krise und Lernen wirklich funktionieren. Das ist die unangenehme Wahrheit – und zugleich Ihre Chance, weil genau dort ein gutes Setup sehr schnell Wirkung entfaltet.

Die pragmatischen Bausteine, die in der Praxis wirklich tragen

Sie brauchen kein Monsterprogramm, um Third-Party Risk unter DORA stabil aufzusetzen. Sie brauchen wenige Standards, die konsequent greifen. Ich beschreibe sie bewusst als Bausteine – weil Sie sie schrittweise einführen können, ohne das Tagesgeschäft zu blockieren.

Baustein 1: Kritikalität sauber festziehen. Nicht jeder Dienstleister ist gleich kritisch. Das Problem ist nicht, dass Unternehmen das nicht wissen – das Problem ist, dass sie es nicht einheitlich definieren. Legen Sie deshalb eine klare Schwelle fest: Welche Provider hängen an kritischen Services? Welche Provider sind Single Points of Failure? Welche Provider haben Einfluss auf Verfügbarkeit oder Sicherheit in einer Weise, die Sie nicht schnell kompensieren können? Je klarer diese Einstufung ist, desto besser wird Ihr Fokus. DORA verlangt nicht, dass Sie alles gleich tief steuern. DORA verlangt, dass Sie bei den wirklich relevanten Abhängigkeiten keine blinden Flecken haben.

Baustein 2: Ein fester Steuerungstakt für kritische Provider. Ohne Takt wird Steuerung zu „bei Bedarf“. Und „bei Bedarf“ ist der Modus, in dem man zu spät ist. Ein quartalsweiser Review reicht in vielen Fällen bereits, wenn er gut strukturiert ist. Wichtig ist die Wiederholbarkeit. Der Review muss nicht lang sein, aber er muss belastbar sein. Ein bewährtes Muster ist: Leistung/Verfügbarkeit, relevante Änderungen, Security-Ereignisse, offene Maßnahmen – und am Ende eine klare Entscheidung. Diese Entscheidung ist wichtig, weil sie zeigt, dass Sie nicht nur Informationen sammeln, sondern steuern.

Baustein 3: Eskalation, die wirklich funktioniert. Eskalation ist nicht „eine Telefonnummer“. Eskalation ist ein Mechanismus, der im Ernstfall Zeit spart. Sie brauchen einen definierten Kontaktweg für schwere Vorfälle, klare Reaktionszeiten, einen Ansprechpartner auf Entscheiderebene und ein abgestimmtes Kommunikationsverfahren. In der Praxis ist es sinnvoll, genau einen „Krisenkanal“ zu definieren (z. B. ein bestimmter Weg, den beide Seiten kennen) und ihn mindestens einmal zu testen. Das ist kein Luxus. Das ist die Differenz zwischen geordnetem Incident und chaotischem Hinterhertelefonieren.

Baustein 4: Änderungen als Risikotreiber ernst nehmen. Viele Provider-Ausfälle sind indirekt: Eine Änderung löst Folgeprobleme aus, die erst später sichtbar werden. Deshalb sollte Ihr Vendor-Setup einen einfachen Mechanismus enthalten, um wesentliche Änderungen zu erkennen und zu bewerten. Das kann über Provider-Release-Informationen, über technische Monitoring-Signale oder über Change-Absprachen erfolgen. Entscheidend ist: Wenn ein Provider etwas Wesentliches ändert, muss das bei Ihnen einen kleinen, klaren Bewertungsprozess auslösen – nicht erst dann, wenn es brennt.

Baustein 5: Minimaler Fallback statt Illusion von „Exit jederzeit“. Viele Organisationen schreiben Exit-Klauseln, aber testen sie nie. Realistisch ist Exit oft komplex und dauert Monate. Für Resilienz zählt deshalb der Minimalfallback: Was tun wir, wenn der Provider für Stunden oder Tage nicht liefert? Können wir in einen Notbetrieb gehen? Können wir die Funktion degradieren? Können wir auf manuelle Workarounds umstellen? Können wir Daten exportieren? Können wir zumindest den Schaden begrenzen? Wenn Sie diese Fragen einmal sauber beantworten und dokumentieren, steigt Ihre tatsächliche Widerstandskraft deutlich – auch wenn ein vollständiger Exit weiterhin langfristig bleibt.

Diese fünf Bausteine sind kein theoretisches Ideal. Sie sind praktisch so gewählt, dass sie sich in bestehende Abläufe integrieren lassen. Genau dadurch werden sie tragfähig.

Evidenz, die nicht nervt: Wie Nachweise „nebenbei“ entstehen

Im Audit zeigt sich schnell, ob Ihre Third-Party-Steuerung wirklich lebt. Gleichzeitig ist es kontraproduktiv, wenn Teams das Gefühl bekommen, sie müssten neben dem Betrieb noch eine zweite Nachweiswelt pflegen. Deshalb lohnt sich ein einfacher Grundsatz: Jeder Steuerungsbaustein muss ein natürliches Artefakt erzeugen. Das Artefakt ist nicht „für Prüfer“, sondern für Ihre eigene Steuerung – und wird dadurch automatisch auditierbar.

Ein Beispiel: Wenn Sie einen quartalsweisen Provider-Review durchführen, ist das Ergebnis nicht nur ein Gespräch. Es ist eine kurze, klare Dokumentation: Was war relevant, welche Abweichungen gab es, welche Maßnahmen sind offen, welche Entscheidung wurde getroffen. Ob das als Ticket, als Protokoll oder als One-Pager passiert, ist zweitrangig. Wichtig ist, dass es immer in derselben Struktur abgelegt wird und in wenigen Minuten auffindbar ist.

Ein zweites Beispiel: Wenn ein Provider einen Incident hat, brauchen Sie am Ende ein Incident-Paket, in dem die Provider-Kommunikation, Ihre Entscheidungspunkte und die abgeleiteten Maßnahmen zusammengeführt sind. Viele Organisationen haben alle Bestandteile, aber verteilt. Prüfbarkeit entsteht, wenn Sie die Teile als Paket standardisieren. Das kostet am Anfang etwas Disziplin – spart aber bei jedem Audit und bei jedem Folgeincident massiv Zeit.

Wenn Sie die Nachweise so gestalten, dass sie aus dem Prozess entstehen, dann sinkt die „Compliance-Reibung“. Und genau darum geht es: DORA soll den Betrieb stabiler machen, nicht schwerer.

Typische Auditfragen – und was eine gute Antwort ausmacht

Ohne Sie mit einem Fragenkatalog zu erschlagen, gibt es ein paar Klassiker, die fast immer kommen. Sie erkennen eine gute Organisation daran, dass sie nicht „erzählt“, sondern „zeigt“. Die folgenden Fragen dienen Ihnen als Orientierung, welche Evidenzpakete Sie wirklich brauchen:

• Welche Dienstleister sind kritisch – und warum? Gute Antwort: klare Kriterien, klare Liste, klare Owner.
• Wie steuern Sie kritische Dienstleister laufend? Gute Antwort: wiederkehrender Takt, dokumentierte Reviews, Entscheidungen, Maßnahmenverfolgung.
• Wie stellen Sie Eskalation und Krisenkommunikation sicher? Gute Antwort: definierte Wege, getestete Kontaktlogik, nachvollziehbare Kommunikationsspur in realen Fällen oder Übungen.
• Wie gehen Sie mit wesentlichen Änderungen beim Dienstleister um? Gute Antwort: Trigger, Bewertungsroutine, dokumentierte Entscheidungen, Anpassung von Kontrollen/Notbetrieb.
• Welche Alternativen haben Sie, wenn der Dienstleister ausfällt? Gute Antwort: realistischer Minimalfallback, Notbetrieb, klare Grenzen, idealerweise getestet oder zumindest plausibel durchdacht.

Diese Fragen sind nicht „gemein“. Sie sind die Essenz dessen, was DORA im Kern will: Abhängigkeiten beherrschbar machen.

Ein realistisches Szenario: Wenn der Provider ausfällt, aber niemand die Führung hat

Stellen Sie sich vor, ein kritischer SaaS-Dienst fällt am Nachmittag aus. Die Fachseite merkt es, weil Prozesse hängen. IT sieht Fehlermeldungen, kann aber intern wenig tun, weil der Dienst extern liegt. Es wird ein Ticket eröffnet. Der Provider antwortet mit einer Standardmeldung: „We are investigating.“ Minuten später fragt das Management: „Wie lange dauert das? Müssen wir Kunden informieren? Was ist unser Notbetrieb?“

In vielen Unternehmen beginnt jetzt ein hektisches Suchen: Wer ist der Ansprechpartner beim Provider? Wie eskalieren wir? Haben wir eine Alternative? Was ist unsere Kommunikationslinie? Und wo dokumentieren wir diese Entscheidungen, ohne parallel Protokolle zu pflegen? Das Team arbeitet – aber ohne klare Struktur. Nach zwei Stunden ist der Dienst wieder verfügbar. Am nächsten Tag sind alle erleichtert. Zwei Wochen später, im Audit oder in der Revision, wirkt das Ereignis plötzlich wie ein Beleg für fehlende Steuerung, weil die Spur nicht geschlossen ist.

Mit einem guten Third-Party-Setup läuft dasselbe Szenario spürbar anders. Es gibt einen klaren Eskalationsweg, der in Minuten greift. Es gibt definierte Entscheidungspunkte, wer wann informiert und wer externe Kommunikation freigibt. Es gibt einen Minimalfallback, der zumindest zentrale Prozesse in einem Notmodus ermöglicht. Und es gibt ein Incident-Paket, das die komplette Spur enthält: Provider-Updates, interne Entscheidungen, Auswirkungen, Kommunikation, Maßnahmen. Das Team muss nicht mehr arbeiten – aber es arbeitet geordneter. Genau das ist Resilienz im Alltag.

Wie Sie ohne Großprojekt starten: Ein 30-Tage-Ansatz, der wirklich machbar ist

Wenn Sie das Thema jetzt pragmatisch aufsetzen oder nachschärfen wollen, empfehle ich einen fokussierten Start. Nicht „alle Dienstleister“, sondern die wichtigsten Abhängigkeiten. Ein Ansatz, der in der Praxis gut funktioniert, sieht so aus:

• Woche 1: Top-10 kritische Provider identifizieren und je Provider einen Owner festlegen. Dazu pro Provider ein kurzes Bild: Welche kritischen Services hängen dran, was ist der Haupt-Schmerz bei Ausfall?
• Woche 2: Eskalations- und Kommunikationswege festziehen (P1-Kontakt, Entscheidungswege intern, Minimalinfos, die im Incident immer gebraucht werden).
• Woche 3: Den quartalsweisen Review-Takt definieren und für zwei Provider testweise durchführen. Ergebnis als kompaktes Paket ablegen.
• Woche 4: Minimalfallback pro Provider beschreiben (Notbetrieb/Workaround) und eine kurze Tabletop-Übung machen: „Provider down“ – 60 Minuten reichen, wenn der Fokus stimmt.

Nach diesen 30 Tagen haben Sie keinen perfekten Endzustand. Aber Sie haben das Entscheidende: Sie können Steuerung zeigen. Und Sie haben eine Struktur, die sich schrittweise auf weitere Provider ausrollen lässt.

Schlussgedanke

Third-Party Risk ist kein Spezialthema für Einkauf oder Security. Es ist eine Frage der Betriebsfähigkeit. Unter DORA wird es deshalb zu einem der wichtigsten Felder, weil externe Abhängigkeiten heute so tief in den Kernprozessen stecken, dass ein Provider-Ausfall schnell zum Business-Ausfall wird. Wenn Sie hier nur „bewerten“, werden Sie im Ernstfall reagieren müssen, ohne echte Handlungsfreiheit. Wenn Sie dagegen wenige, stabile Steuerungsbausteine etablieren, gewinnen Sie etwas, das in vielen Organisationen selten ist: operative Ruhe unter Druck.

Im nächsten Beitrag können wir daran anknüpfen und den Blick noch stärker auf die praktische Verzahnung richten: Wie Third-Party-Steuerung, Incident-Ablauf und Evidenz so zusammenpassen, dass Audits keine Sonderveranstaltung mehr sind, sondern ein kurzer Blick in ein System, das ohnehin funktioniert.