Wenn der Dienstleister stolpert, fällt dein Unternehmen mit: Warum Third-Party Risk Management Pflicht ist

Früher klang „Third-Party Risk Management“ für mich ein bisschen nach Schublade ganz hinten im Compliance-Schrank. Ja, wichtig. Aber selten der Star der IT-Party.

Inzwischen sieht die Sache anders aus.

Moderne Unternehmen funktionieren nicht mehr als hermetisch geschlossene IT-Burgen mit Zugbrücke, Burggraben und einem Admin namens Uwe, der alles im Blick hat.

Heute läuft fast alles über Cloud-Dienste, Plattformen, Integrationen, APIs, externe Tools, Managed Services, Zahlungsanbieter, CRM-Systeme, Lernplattformen, Shopsysteme und Support-Portale.

Kurz gesagt: Deine IT ist nicht nur deine IT. Sie ist ein Netzwerk aus Abhängigkeiten.

Und das macht es spannend. Oder, etwas weniger freundlich formuliert: gefährlich.

Die jüngsten Fälle rund um Canvas und Zara/Inditex zeigen ziemlich deutlich, warum Third-Party Risk Management kein „Nice to have“ mehr ist. Es ist Pflichtprogramm.

Nicht, weil Compliance-Teams gerne Tabellen ausfüllen, sondern weil Angreifer längst verstanden haben: Der einfachste Weg in ein Unternehmen führt durch den Seiteneingang eines Dienstleisters.

Der neue Normalzustand: Du bist nur so sicher wie dein schwächstes Tool

Viele IT-Entscheider kennen die klassische Sicherheitslogik: Wir schützen unsere Systeme. Wir sichern unsere Accounts. Wir härten unsere Infrastruktur. Wir schulen unsere Mitarbeitenden. 

Alles richtig.

Aber was passiert, wenn nicht dein Unternehmen direkt angegriffen wird, sondern ein Anbieter, dem du Daten, Zugänge oder Integrationen anvertraut hast?

Dann bist du plötzlich betroffen, obwohl bei dir intern alles ordentlich aussieht. Es ist ein bisschen wie in einem Mehrfamilienhaus: Du kannst deine Wohnungstür mit fünf Schlössern sichern. Wenn aber der Kellerzugang offensteht und dort alle Ersatzschlüssel hängen, wird es trotzdem ungemütlich.

Genau das ist das Grundproblem bei Third-Party Risks: Unternehmen lagern Funktionen aus, aber sie tragen trotzdem die Verantwortung für die Auswirkungen.

Beispiel Canvas: Wenn eine Plattform zum Risiko-Multiplikator wird

Ein aktuelles Beispiel ist der Sicherheitsvorfall rund um Instructure Canvas, eine weit verbreitete Lernplattform.Der Instructure-CEO Steve Daly wurde vom US House Committee on Homeland Security zur Aussage aufgefordert. Thema: der Canvas-Angriff, das Ausmaß der betroffenen Daten, die Eindämmungsmaßnahmen und die Benachrichtigung der Betroffenen.

Laut TechRadar bekannte sich ShinyHunters zu dem Vorfall, bei dem von tausenden betroffenen Schulen sowie 275 Millionen Personen die Rede war. 

Trend Micro ordnet den Vorfall als besonders kritisch ein, weil Canvas nicht einfach irgendein Tool ist. Die Plattform wird von Bildungseinrichtungen genutzt, enthält persönliche Informationen, Kommunikation, Kontext zu Kursen und teilweise sehr sensible Inhalte. Trend Micro nennt unter anderem medizinische Anfragen, private Gespräche mit Beratenden und institutionellen Kontext als mögliche Risikofaktoren für hochgradig glaubwürdige Folgeangriffe. 

Das ist der eigentliche Knackpunkt: Bei solchen Breaches geht es nicht nur um „Daten sind weg“. Es geht darum, dass Angreifer Kontext bekommen.

Kontext ist im Cybercrime Gold wert.

Denn eine Phishing-Mail mit „Bitte klicken Sie hier“ ist nervig. Eine Phishing-Mail, die sich auf deine echte Hochschule, deinen echten Kurs, deine echte Rolle, deine echte Anfrage oder ein reales internes System bezieht, ist gefährlich.

Das ist dann nicht mehr die berühmte schlecht übersetzte Mail vom nigerianischen Prinzen. Das ist Social Engineering mit Maßanzug.

Check Point Research berichtet, dass neben Student- und Staff-Daten auch private Nachrichten betroffen gewesen sein sollen. Außerdem seien Hunderte Schul-Login-Portale mit Ransom-Nachrichten verunstaltet worden. 

Für IT-Entscheider ist daran besonders wichtig: Canvas ist kein klassischer „interner Server im Keller“. Es ist ein externer Plattformanbieter, der tief in die Arbeitsprozesse vieler Organisationen eingebunden ist. Wenn so ein Dienst kompromittiert wird, entsteht nicht ein einzelnes Loch. Es entsteht eine ganze Lochsammlung. Quasi Schweizer Käse, nur ohne Genuss.

Beispiel Zara/Inditex: Auch Retail hängt am Dienstleister-Faden

Der zweite Fall kommt aus dem Handel: Inditex, der Konzern hinter Marken wie Zara und Bershka. Laut Check Point Research erlebte Zara einen Datenvorfall mit Bezug zu einem Drittanbieter-Technologieprovider. Dabei sollen unter anderem 197.400 eindeutige E-Mail-Adressen, Order IDs, Kaufhistorien und Customer-Support-Tickets offengelegt worden sein. 

Laut UpGuard ging es dabei um Kundentransaktionsdaten; Inditex habe erklärt, dass keine sensiblen persönlichen oder Bankdaten kompromittiert worden seien. Trotzdem weist UpGuard auf ein wichtiges Risiko hin: Selbst Kaufhistorien können für sehr gezielte Phishing- und Social-Engineering-Angriffe genutzt werden.

Hier liegt ein Denkfehler, den viele Unternehmen machen: „Es waren ja keine Passwörter und keine Zahlungsdaten betroffen.“

Das klingt beruhigend. Ist es aber nur halb.

Angreifer brauchen nicht immer Kreditkartennummern, um Schaden anzurichten. Manchmal reicht es, wenn sie wissen, was jemand gekauft hat, wann eine Bestellung lief, welches Support-Problem es gab oder welcher Kommunikationskanal genutzt wurde. Daraus lässt sich eine sehr glaubwürdige Nachricht bauen:

„Hallo, wir melden uns zu deiner Bestellung vom 14. April. Aufgrund eines Problems mit unserem System bitten wir dich, deine Lieferdaten erneut zu bestätigen.“

Klingt plausibel. Ist gefährlich. Und landet im Zweifel genau dort, wo es wirken soll.

Warum Third-Party Risk Management kein Papiermonster sein darf

Third-Party Risk Management bedeutet nicht: Wir schicken jedem Anbieter einmal im Jahr einen Fragebogen mit 83 Fragen und hoffen, dass jemand ehrlich „Ja, wir patchen regelmäßig“ ankreuzt.

Das ist wie beim Zahnarztbesuch: Einmal jährlich kurz den Mund aufmachen ist besser als nichts. Aber wenn dazwischen alles weh tut, hilft auch das schönste Bonusheft nicht.

Gutes Third-Party Risk Management ist ein lebender Prozess. Es beantwortet unter anderem diese Fragen:

• Welche Dienstleister haben Zugriff auf unsere Daten?

• Welche Anbieter sind kritisch für unseren Betrieb?

• Welche Systeme sind über Schnittstellen miteinander verbunden?

• Welche Daten liegen wo?

• Welche Sicherheitsanforderungen gelten für welchen Anbieter?

• Wie schnell erfahren wir von einem Vorfall?

• Was passiert, wenn ein Anbieter ausfällt oder kompromittiert wird?

• Wie trennen wir uns sauber von einem Dienstleister?

• Und wer bei uns ist eigentlich verantwortlich, wenn es brennt?

NIST beschreibt Cybersecurity Supply Chain Risk Management als Ansatz, um Risiken in der Lieferkette auf allen Organisationsebenen zu identifizieren, zu bewerten und zu reduzieren. Dazu gehören Strategie, Richtlinien, Pläne und Risikobewertungen für Produkte und Services. (csrc.nist.gov)

NIST und ENISA empfehlen, ein unternehmensweites Supply-Chain-Management-System auf Basis von Third-Party Risk Management aufzubauen. Dazu zählen Risikobewertung, Lieferantenmanagement, Schwachstellenmanagement sowie die Qualität von Produkten und Praktiken der Anbieter.

Übersetzt in normales Deutsch: Du brauchst einen Überblick. Regeln. Technische Kontrolle. Und du brauchst jemanden, der nicht erst beim Vorfall fragt: „Moment, nutzen wir diesen Anbieter überhaupt?“

Das Problem ist die Bequemlichkeit

Frage: Warum werden Drittanbieter-Risiken so oft unterschätzt?

Die Antwort: Weil Cloud und SaaS wunderbar einfach geworden sind. Ein Tool ist schnell gebucht, ein Account schnell erstellt, eine Integration schnell aktiviert. Das ist ja das Schöne daran. Cloud soll einfach sein. Sonst könnten wir alle wieder Disketten beschriften und Serverräume mit zu kalter Klimaanlage betreuen.

Aber einfache Nutzung darf nicht bedeuten, dass die Kontrolle verloren geht.

In mittelständischen Unternehmen wachsen Tool-Landschaften oft organisch. Ein Fachbereich nutzt ein Projektmanagement-Tool. Das Marketing verbindet eine Plattform mit dem CRM. HR testet ein Bewerbertool. Der Vertrieb bindet ein Analysewerkzeug an. Irgendwann sieht die IT-Landschaft aus wie eine Besteckschublade nach einem Umzug: Alles ist irgendwie da, aber niemand weiß genau, warum der Kartoffelschäler im Löffel-Fach liegt.

Das Problem ist nicht die Nutzung externer Dienste, sondern fehlende Transparenz.

Third-Party Risk beginnt vor dem Einkauf

Ein häufiger Fehler: Sicherheitsprüfung beginnt erst, wenn der Vertrag schon unterschrieben ist.

Dann wird es unangenehm. Wenn der Fachbereich das Tool bereits liebt, die Daten schon migriert sind und die Integration produktiv läuft, klingt jede Sicherheitsfrage wie Spielverderberei. Die IT wird dann zum Türsteher, der erst nach der Party auftaucht und fragt, wer eigentlich eingeladen war.

Security gehört in den Auswahlprozess.

Das muss nicht kompliziert sein. Aber es sollte klar sein:

• Welche Daten verarbeitet der Anbieter?

• Wo werden sie gespeichert?

• Welche Zertifizierungen oder Sicherheitsnachweise gibt es?

• Wie sieht das Berechtigungskonzept aus?

• Gibt es MFA?

• Wie werden Schnittstellen abgesichert?

• Wie schnell meldet der Anbieter Sicherheitsvorfälle?

• Was steht dazu im Vertrag?

• Wie funktioniert die Datenlöschung nach Vertragsende?

• Gibt es Subdienstleister, also Fourth Parties?

Dieser letzte Punkt ist besonders wichtig. Denn dein Drittanbieter nutzt oft selbst wieder Dienstleister. Und diese Dienstleister nutzen vielleicht ebenfalls Dienste. Das ist nicht automatisch schlecht. Aber es muss sichtbar sein.

Nicht jeder Anbieter ist gleich kritisch

Third-Party Risk Management bedeutet nicht, jeden Lieferanten gleich streng zu prüfen. Der Anbieter für Bürokaffee ist wichtig für die Stimmung, aber vermutlich nicht kritisch für deine Kundendaten. Obwohl man über Kaffeeabhängigkeit in IT-Abteilungen sicher diskutieren könnte.

Entscheidend ist eine Risikoklassifizierung.

Ein Anbieter, der nur öffentliche Marketingmaterialien druckt, braucht eine andere Bewertung als ein Cloud-Dienstleister, der Kundendaten verarbeitet oder Zugriff auf Microsoft 365, Azure, Identitäten oder zentrale Prozesse hat.

Eine einfache Einteilung kann helfen:

• Niedriges Risiko: kein Zugriff auf sensible Daten, keine Systemintegration, keine kritischen Prozesse.

• Mittleres Risiko: begrenzter Zugriff auf geschäftliche Daten oder einzelne Prozesse.

• Hohes Risiko: Zugriff auf personenbezogene Daten, Kundendaten, Identitäten, Schnittstellen oder kritische Systeme.

• Kritisches Risiko: zentrale Plattformen, produktionsrelevante Dienste, Sicherheitsanbieter, Identity Provider, Cloud- und Infrastrukturpartner.

Je höher das Risiko, desto wichtiger werden Nachweise, Verträge, technische Kontrollen, Monitoring und Notfallpläne.

Der Vertrag ist kein Schutzschild, aber ein Sicherheitsgurt

Natürlich verhindert ein Vertrag keinen Angriff. Cyberkriminelle lesen selten Auftragsverarbeitungsverträge und sagen dann: „Oh, Paragraf 7.2, dann lassen wir das lieber.“

Aber Verträge regeln, was im Ernstfall passiert.

Dazu gehören Meldefristen, Ansprechpartner, Audit-Rechte, Mindeststandards, Verschlüsselung, Datenlöschung, Subdienstleister, Incident Response, Exit-Prozesse und Haftungsfragen.

Wichtig ist: Diese Punkte sollten nicht als juristisches Deko-Element irgendwo im PDF schlummern. Sie müssen operativ funktionieren. Wenn ein Anbieter einen Vorfall hat, brauchst du nicht nur eine Vertragsklausel. Du brauchst einen Kontakt, einen Prozess und klare interne Verantwortlichkeiten.

Sonst stehst du im Ernstfall da wie jemand, der zwar einen Feuerlöscher gekauft hat, aber erst im Brandfall die Bedienungsanleitung googelt.

Technische Kontrolle: Vertrauen ist gut, Sichtbarkeit ist besser

Third-Party Risk Management ist nicht nur Einkauf, Recht und Compliance. Es ist auch technische Governance.

Dazu gehören zum Beispiel:

• SaaS-Übersicht und Shadow-IT-Erkennung

• MFA und Conditional Access

• Least-Privilege-Prinzip für externe Zugriffe

• Regelmäßige Prüfung von App-Registrierungen und API-Berechtigungen

• Logging und Monitoring von Integrationen

• Automatisiertes Offboarding von Dienstleistern

• Überprüfung von Admin- und Service-Accounts

• Bewertung von Datenflüssen

• Notfallpläne für kritische Anbieter

In Microsoft-365- und Azure-Umgebungen ist das Thema besonders relevant. Viele externe Tools wollen Zugriff auf Kalender, E-Mails, Dateien, Nutzerprofile, Teams, SharePoint oder Entra ID. Einmal schnell „Berechtigung erteilen“ kann später sehr viel Spaß machen. Also ungefähr so viel Spaß wie ein Druckerproblem kurz vor Feierabend.

Deshalb braucht es Governance: Wer darf Apps freigeben? Welche Berechtigungen sind erlaubt? Welche Integrationen werden regelmäßig geprüft? Welche externen Accounts existieren? Welche Rechte haben sie? Wann werden sie wieder entfernt?

Das heißt eben nicht: Jeder klickt alles frei und wir hoffen auf das Beste. Es heißt: Die Cloud wird so gestaltet, dass sie sicher nutzbar bleibt.

Einfach für die Menschen.
Kontrolliert für die Organisation.
Persönlich begleitet, wenn es komplex wird.

Incident Response muss Drittanbieter mitdenken

Viele Unternehmen haben Notfallpläne für eigene Systeme. Aber was passiert, wenn ein externer Anbieter betroffen ist?

Dann brauchst du Antworten auf Fragen wie:

• Welche internen Systeme sind verbunden?

• Welche Daten könnten betroffen sein?

• Welche Schnittstellen müssen deaktiviert werden?

• Welche Tokens, Secrets oder API-Keys müssen rotiert werden?

• Welche Nutzer müssen informiert werden?

• Welche Fachbereiche sind betroffen?

• Welche Kundenkommunikation ist nötig?

• Welche Meldepflichten greifen?

• Welche Alternativen gibt es, falls der Dienst ausfällt?

Beim Canvas-Fall zeigte sich, dass API-Integrationen die Auswirkungen verstärken können, weil Institutionen externe Integrationen neu autorisieren mussten und dadurch Abhängigkeiten sichtbar wurden, die im Alltag selbstverständlich wirken.

Genau deshalb sollte Third-Party Risk Management nicht erst beim Vorfall beginnen. Das wäre Incident Response im Panikmodus. Besser ist Vorbereitung mit ruhiger Hand. Oder anders gesagt: Man zieht den Fallschirm nicht erst während des Sprungs an.

Was IT-Entscheider jetzt konkret tun sollten

Der Einstieg muss nicht riesig sein. Du brauchst kein 400-Seiten-Framework, das in SharePoint verstaubt und nur von sehr motivierten Auditoren gelesen wird.

Starte pragmatisch.

1. Erstelle eine Liste deiner wichtigsten Drittanbieter. Nicht perfekt. Aber ehrlich. Welche SaaS-Tools, Cloud-Dienste, Managed Services, Plattformen und Integrationen nutzt ihr wirklich?

2. Bewerte, wie kritisch die Anbieter sind. Wer hat Zugriff auf sensible Daten, Identitäten, zentrale Systeme oder geschäftskritische Prozesse?

3. Prüfe die Berechtigungen. Gerade App-Integrationen, API-Zugänge, Service-Accounts und externe Admins verdienen Aufmerksamkeit.

4. Definiere Mindeststandards. MFA, Verschlüsselung, Incident-Meldung, Datenlöschung, Subdienstleister-Transparenz und regelmäßige Sicherheitsnachweise sollten je nach Risikoklasse klar geregelt sein.

5. Baue Offboarding-Prozesse. Wenn ein Dienstleister geht, müssen Zugänge, Tokens, Daten, Accounts und Schnittstellen sauber entfernt werden. „Der Kollege ist nicht mehr da, aber der API-Key lebt weiter“ ist digitale Archäologie.

6. Teste den Ernstfall. Was passiert, wenn dein wichtigster SaaS-Anbieter morgen einen Vorfall meldet? Wer entscheidet was? Wer spricht mit wem? Welche Systeme werden getrennt?

7. Und ganz wichtig: Mach es verständlich. Third-Party Risk Management darf kein reines Security-Spezialthema bleiben. Fachbereiche müssen verstehen, warum es wichtig ist. Nicht als Bremse. Sondern als Sicherheitsgurt.

Die Lieferkette ist Teil deiner Sicherheitsarchitektur

Die Vorfälle bei Canvas und Zara/Inditex zeigen: Drittanbieter-Vorfälle sind keine Randnotiz. Sie treffen Organisationen mitten in ihren Prozessen, Datenflüssen und Kundenbeziehungen. Und sie zeigen, wie schnell aus einem Anbieterproblem ein eigenes Sicherheits-, Kommunikations- und Vertrauensproblem wird.

Die gute Nachricht: Man kann viel tun.

Klare Governance. Sichtbarkeit. Risikobewertung. Technische Kontrolle. Gute Verträge. Saubere Prozesse. Partner, die nicht nur Produkte verkaufen, sondern Verantwortung mitdenken.

Cloud ist großartig. Cloud macht Unternehmen beweglicher, effizienter und innovativer. Aber Cloud braucht Ordnung. Sicherheit und Menschen, die sich kümmern.

Hier liegt der Unterschied zwischen „Wir nutzen halt viele Tools“ und „Wir haben unsere digitale Lieferkette im Griff“.

Oder kürzer gesagt: Drittanbieter sind wie Mitbewohner in deiner IT-WG. Du musst nicht misstrauisch unter jedes Bett schauen. Aber du solltest wissen, wer einen Schlüssel hat.