Warum muss sich Ihr bestehender TPRM-Stack weiterentwickeln?

Das Management von Drittparteirisiken zählte schon immer zu den schwierigsten Aufgaben im Bereich GRC.

Doch wenn Sie heute ein TPRM-Programm durchführen, ist der Druck größer denn je. Vielleicht arbeiten Sie noch mit Tabellenkalkulationen und wissen, dass das nicht zukunftsfähig ist. Vielleicht haben Sie in eine Plattform investiert, die Abhilfe versprochen hat, aber die Arbeit stattdessen nur noch komplizierter gemacht hat. Oder vielleicht verfügen Sie über eine Reihe von Tools, die jeweils einen Teilbereich abdecken, aber keines davon ist mit den anderen kompatibel.

Im Kern bleibt das Problem dasselbe: Ihr TPRM-System wurde für eine langsamere, einfachere Anbieterlandschaft entwickelt. Eine Landschaft, in der Anbieter einmal jährlich bewertet wurden, Sicherheitsfragebögen irgendwann ausgefüllt wurden und Risikoprofile zwischen den Überprüfungen weitgehend unverändert blieben.

Diese Welt ist verschwunden.

Unternehmen binden Anbieter deutlich häufiger ein als noch vor zwei Jahren. Die Risikoprofile verändern sich rasant, da Anbieter KI in ihre Produkte integrieren. Und die regulatorischen Anforderungen steigen stetig.

Dieser Blogbeitrag erklärt, warum Ihre bestehende TPRM-Architektur weiterentwickelt werden muss. Falls Sie Schwachstellen in Ihren Prozessen bemerken oder das Gefühl haben, dass Ihre Tools nicht mehr mithalten können, hilft Ihnen dieser Beitrag, die Zusammenhänge und Gründe zu verstehen.

Und vor allem basiert dies alles auf realen Gesprächen, die wir mit Sicherheits- und GRC-Verantwortlichen auf der ganzen Welt geführt haben.

Das Tabellenkalkulationsproblem ist real, aber es ist nicht das einzige Problem

Auch heute noch verwalten viele Unternehmen ihr Lieferantenrisiko ausschließlich mit Excel, E-Mail-Vorlagen und manuellen Nachfassaktionen. Und das ist verständlich. Tabellenkalkulationen sind vertraut, einfach zu bedienen und erfordern keine Einarbeitungszeit. Der Prozess bleibt also gleich: eine vorgefertigte E-Mail versenden, auf die Antwort-Tabelle warten, diese analysieren und zwischendurch immer wieder nachfassen. 

Ein GRC-Verantwortlicher eines Logistikunternehmens drückte es so aus: „Wir schicken ihnen eine Tabelle, sie füllen sie aus, schicken sie zurück, und wir versuchen, das Beste daraus zu machen. Und dann gerät sie in Vergessenheit, und wir schicken ihnen im Folgejahr einfach keine mehr.“ Das dürfte vielen von Ihnen bekannt vorkommen.

Und es geht nicht nur darum, dass die Umsetzung scheitert; der Prozess selbst ist mühsam.

Ein Compliance-Beauftragter eines IT-Dienstleistungsunternehmens erklärte uns: „Alles läuft im Excel-Format. Die von uns hochgeladenen Nachweise sind alle Excel-basiert. Wir fügen unsere Kommentare hinzu, die anderen fügen ihre hinzu, und die anschließende Gap-Analyse erfolgt wieder manuell. Das ist enorm viel manuelle Arbeit.“

Tabellenkalkulationen sind bis zu einem gewissen Grad praktikabel. Bei größeren Datenmengen stoßen sie jedoch an ihre Grenzen. Da sie keine wiederkehrenden Termine integrieren, geraten Auswertungen schnell in Vergessenheit. Es gibt keine zentrale Überwachung, sodass niemand einen einheitlichen Überblick über den aktuellen Stand hat. Der Aufwand beschränkt sich aber nicht nur auf die reine Tabellenpflege. Es ist der ständige Abstimmungsaufwand mit Anbietern, internen Stakeholdern und der Führungsebene, die Berichte benötigen, die eine Tabellenkalkulation schlichtweg nicht liefern kann. Das Fehlerrisiko ist hoch. Und der manuelle Aufwand steigt mit jedem neuen Anbieter.

Aber das Problem ist: Wären Tabellenkalkulationen das einzige Problem, wäre die Lösung ganz einfach: ein entsprechendes Tool kaufen. Viele Organisationen haben genau das getan. Und sie kämpfen immer noch damit.

Auch dedizierte Plattformen lösen das Problem nicht.

Diese Nuance geht in den meisten Diskussionen über die Modernisierung von TPRM verloren. Man geht davon aus, dass der Wechsel von Tabellenkalkulationen zu einer speziell entwickelten Plattform alle Probleme löst. Doch die branchenweite Entwicklung zeichnet ein anderes Bild.

In einem Gespräch mit einem Compliance-Verantwortlichen eines mittelständischen Fintech-Unternehmens wurde uns geschildert, wie das Unternehmen in eine GRC-Plattform für das Compliance-Management investiert und zusätzlich ein separates Tool zur Lieferantenüberwachung für externe Risikosignale implementiert hatte. Die Datenerfassung der GRC-Plattform erwies sich jedoch als sehr aufwendig und wenig rentabel. Daher testete das Team die Plattform und verwarf sie. 

Nun verfügten sie über zwei Werkzeuge, von denen keines die Aufgabe vollständig erfüllte, und der operative Aufwand hatte sich nicht wirklich verringert. Er hatte sich lediglich verändert. 

In einem anderen Fall sahen wir ein Marktforschungsinstitut, das in eine spezielle GRC-Plattform für das TPRM-Management investiert hatte. Sie durchliefen den gesamten Evaluierungs- und Implementierungszyklus. Und danach kehrten sie zur manuellen Verwaltung mit Tabellenkalkulationen zurück. Denken Sie darüber nach, was das aussagt. Ein Team kam zu dem Schluss, dass der Aufwand für die Wartung eines eigens entwickelten Tools tatsächlich größer war als der Aufwand, gar keins zu haben.

In weiteren Gesprächen stellten wir fest, dass einige Organisationen von großen, etablierten GRC-Plattformen abgewandert waren, da deren Nutzung und Wartung für TPRM die Kosten nicht rechtfertigte. Andere wiederum setzten teure, ressourcenintensive Eigenentwicklungen ein, deren Instandhaltung kostspielig war. Doch eines hatten alle gemeinsam: Sie suchten nach einer grundlegend anderen Lösung. Nicht einfach nur nach einer anderen Variante desselben Ansatzes.

Und natürlich gibt es eine ganze Reihe von Organisationen, die Plattformen nutzen, die nie für das Lieferantenrisikomanagement konzipiert wurden. Sei es die Abwicklung des Einkaufs über ein ERP-System ohne jegliche Funktionen für das Lieferantenrisikomanagement oder die Verwaltung von Audits und TPRM über eine Kombination aus SharePoint und Excel. 

Eine der Personen, mit denen wir sprachen, tat genau das und beschrieb die bestehende Konfiguration schlicht als „für den operativen Betrieb unzureichend“. Diese Teams wählen nicht einmal die falsche TPRM-Plattform. Sie versuchen, ein Nicht-TPRM-Tool für TPRM-Aufgaben einzusetzen, weil im Unternehmen niemand das Budget oder die Befugnis für eine dedizierte Lösung bereitgestellt hat.

Die fragmentierte Architektur schafft ihre eigene Kategorie von Problemen

Zwischen den Lagern der Tabellenkalkulations- und der dedizierten Plattformbefürworter gibt es eine dritte Gruppe, die möglicherweise die häufigste von allen ist: Teams, die TPRM über mehrere voneinander unabhängige Tools betreiben.

Wir haben dies in verschiedenen Ausprägungen beobachtet. Organisationen haben mit Doppelarbeit und Prüfungsproblemen zu kämpfen, da Richtlinien, Risiken und Assets auf unterschiedlichen Plattformen verteilt sind. Teams nutzen externe Tools für Sicherheitsfragebögen, weil ihre primäre Plattform widersprüchliche Antworten nicht verarbeiten kann. Andere wiederum kämpfen mit Synchronisierungsproblemen in HR-Systemen und Hunderten von Risikofragen, die konsolidiert werden müssen, bevor alles reibungslos funktioniert. 

Die Details unterscheiden sich, aber das zugrundeliegende Problem ist immer dasselbe.

Jedes Werkzeug im System erfüllt seinen Teilbereich zufriedenstellend. Doch die Lücken zwischen den Werkzeugen führen zu Problemen. Und die Person, die für den reibungslosen Ablauf verantwortlich ist – wahrscheinlich allein –, verbringt mehr Zeit mit der Systemintegration als mit der eigentlichen Risikobewertung.

Diese Fragmentierung macht es der Führungsebene nahezu unmöglich, sich ein klares Bild von der Lieferantenrisikosituation zu verschaffen. Wenn Sie jemals versucht haben, einem Vorstandsmitglied Ihre Lieferantenrisikosituation zu erläutern und dabei feststellen mussten, dass Sie drei Tabellenblätter und eine Tabelle zusammensuchen mussten, um die Antwort zusammenzutragen, kennen Sie das Problem bereits. 

Ein Compliance-Leiter, mit dem wir sprachen, formulierte es so: „Es gibt keine zentrale Stelle, an der man im Grunde alles kontinuierlich überwachen kann. Niemand hat einen zentralen Überblick über den Fortschritt von allem.“ 

Wenn das Beste, was man vorweisen kann, eine Tabelle mit Fortschrittsanzeige ist, wird TPRM als operative Pflichtaufgabe und nicht als strategische Funktion dargestellt. Und das erschwert die Budgetbeschaffung. 

Kleine Teams, große Aufgaben, kein Raum für Fehler

Zu all diesen Herausforderungen im Bereich der Tools kommt nun noch die Personalsituation hinzu. Ihr GRC-Manager jongliert neben TPRM mit zahlreichen weiteren Aufgaben. Er beantwortet Sicherheitsfragebögen von Kunden, bereitet sich auf anstehende Audits vor, verwaltet Richtlinienaktualisierungen, verfolgt Risikoausnahmen und koordiniert die Zusammenarbeit zwischen den Teams.

Wie viele von Ihnen wahrscheinlich nachvollziehen können, berichtete uns ein Sicherheitschef eines schnell wachsenden SaaS-Unternehmens, dass er die gesamte GRC-Funktion praktisch im Alleingang leitet: „Ich bin ein Ein-Mann-Betrieb. Ich sorge für die reibungslose Durchführung aller Audits, beantworte Sicherheitsfragebögen, betreibe das Drittanbieter-Risikomanagement, nehme an Kundengesprächen teil und entwickle Strategien für zukünftige Zertifizierungen. Trust-Center-Wartung, Richtlinienverwaltung und Risikomanagement – ​​ich habe alle Hände voll zu tun.“

Wenn Sie im GRC tätig sind, stehen die Chancen gut, dass Sie sich bereits in genau dieser Situation befunden haben oder sich gerade jetzt darin befinden.

Bei einer anderen Organisation, mit der wir sprachen, bestand die gesamte Compliance-Abteilung aus nur zwei Personen: einem Compliance-Leiter und einem Rechtsanwaltsgehilfen. Einer kümmerte sich um die Einhaltung der Vorschriften, der andere um die rechtlichen Belange, und gemeinsam arbeiteten sie daran, die Lieferantenprüfung so schnell wie möglich abzuschließen. Das war das gesamte Team.

Bei so einem kleinen Team wird TPRM automatisch reaktiv. Man kümmert sich um das, was gerade ansteht. Der Lieferant, dessen SOC-2-Zertifizierung vor drei Monaten abgelaufen ist? Darum kümmert man sich, wenn ein Kunde danach fragt. Das neue KI-Tool, das Ihr Entwicklungsteam letzte Woche eingeführt hat? Davon erfährt man, wenn es überhaupt bei der nächsten Zugriffsprüfung auftaucht.

Dies ist ein grundlegendes Kapazitätsproblem. Wenn man sich auf Tabellenkalkulationen oder Tools verlässt, die nicht für den Umfang und die Geschwindigkeit des modernen Lieferantenrisikos ausgelegt sind, sind die Möglichkeiten eines kleinen Teams begrenzt. Genau deshalb muss sich der Fokus verlagern. Nicht hin zu Tools, die die Arbeit beschleunigen, sondern hin zu Systemen, die wesentliche Teile der Arbeit übernehmen können.

Die Explosion der KI-Anbieter übertrifft jedes bestehende System.

Hier wird die Dringlichkeit unübersehbar. Ihr Lieferantennetzwerk verändert sich schneller, als Ihre aktuellen Tools mithalten können. Ob Sie nun mit einer Tabellenkalkulation oder einer Plattform arbeiten, spielt dabei keine Rolle.

Wenn Sie schon einmal das ungute Gefühl hatten, als Sie feststellten, dass Ihr Entwicklungsteam ohne Ihr Wissen ein neues KI-Tool eingeführt hat, sind Sie nicht allein. Ein CISO eines mittelständischen Kommunikationsunternehmens beschrieb es so: „Unsere KI-Entwicklungsabteilung ist auf Einkaufstour, und das bereitet mir große Sorgen. Manche Anbieter haben gerade mal drei Monate Erfahrung und einen Auditor, dessen Website nicht existiert. Wir müssen natürlich genau prüfen, welche Daten wir diesen Drittanbietern anvertrauen.“

Derselbe Branchenführer brachte den umfassenderen Wandel in einem einzigen Satz auf den Punkt: „Im Hintergrund entwickelt sich jeder Anbieter zu einem KI-Anbieter. Sie wollen wissen, welches KI-Tool er einsetzt und ob er meine Daten zum Trainieren seiner Modelle verwendet oder nicht.“ Kommt Ihnen das bekannt vor?

Es geht hier nicht nur um neue KI-Startups, die in Ihr Ökosystem eintreten. Es geht auch darum, dass etablierte Anbieter still und leise KI-Funktionen in bereits von Ihnen freigegebene Produkte integrieren. Ihr CRM-System verfügt nun über einen KI-Assistenten. Ihr HR-Tool nutzt KI für das Screening. Und so weiter.

Das traditionelle TPRM geht davon aus, dass die Sicherheitsprüfung vor der Einführung neuer Anbieter erfolgt. In den meisten Unternehmen findet sie heute erst danach statt, manchmal sogar erst Monate später. Der eigentliche Wandel besteht jedoch in der Erkenntnis, dass die Prüfung kontinuierlich erfolgen sollte. Ihre IT-Infrastruktur muss diese Umkehrung berücksichtigen und die fortlaufende Qualitätssicherung von Anfang an in den Workflow integrieren.

Warum die Antwort nicht nur „bessere Werkzeuge“, sondern autonomes TPRM lautet

Betrachtet man die aktuelle Praxis des TPRM, zeichnet sich ein Muster ab. Tabellenkalkulationen scheitern, weil sie rein manuell sind und keine Speicherung ermöglichen. Spezielle Plattformen scheitern, weil sie die manuelle Arbeit verlagern, anstatt sie zu eliminieren. Und fragmentierte Systeme scheitern, weil sie Datensilos und einen hohen Aufwand für die Datenabgleichung erzeugen. Doch all diese Ansätze haben eine strukturelle Schwäche gemeinsam: Sie gehen davon aus, dass bei jeder Entscheidung, jeder Nachverfolgung und jeder Bewertung stets ein Mensch involviert ist.

Diese Annahme trifft nicht mehr zu. Wenn schlanke Teams Hunderte von Lieferanten betreuen, wöchentlich neue KI-Tools eingeführt werden und sich die Risikoprofile der Lieferanten zwischen den Bewertungen ändern, benötigen Sie ein System, das mit einem gewissen Grad an Autonomie arbeiten kann. 

Das ist der Unterschied zwischen Automatisierung und Autonomie. Und er ist wichtig. Automatisiertes TPRM deckt Probleme auf und liefert wichtige Daten. Das ist definitiv besser als Tabellenkalkulationen. 

Autonomes TPRM geht mit kontextbezogener Entscheidungsfindung noch einen Schritt weiter. Es erkennt neue Anbieter durch SSO-Aktivitäten, Browsererweiterungen und die Erkennung von Endpunkt-Apps über ein MDM-System, noch bevor eine Anfrage gestellt wird. Es analysiert hochgeladene SOC-2-Berichte und kennzeichnet Lücken, abgelaufene Zertifizierungen und fehlende Kontrollen, ohne dass Sie das Dokument lesen müssen. Es führt Live-Risikobewertungen, die interne Bewertungsdaten mit externen Informationen kombinieren und sich bei veränderten Bedingungen aktualisieren. Es verfolgt automatisch Fragebögen von Anbietern, eskaliert bei verspäteten Antworten und plant wiederkehrende Neubewertungen, die auch tatsächlich durchgeführt werden.

Der Unterschied zeigt sich in den Ergebnissen. Wenn das System die Lieferantensuche, Dokumentenanalyse, Risikobewertung und Nachverfolgung übernimmt, können Sie sich auf die Aufgaben konzentrieren, die Ihr Urteilsvermögen erfordern: die Interpretation von Sonderfällen, die Beratung des Unternehmens zu Risikoabwägungen und die Entscheidungen, die ein System allein nicht treffen kann.

Das Ziel des autonomen TPRM ist nicht, Sie aus dem Prozess zu entfernen. Es geht vielmehr darum, Sie von den Teilen zu entlasten, die Ihre Expertise von vornherein nicht benötigten, damit Sie mehr Zeit für die Teile aufwenden können, die sie benötigen.

Wo soll man anfangen

Wenn Sie Ihre aktuelle Situation betrachten und einige dieser Muster erkennen, finden Sie hier eine praktische Möglichkeit, über die nächsten Schritte nachzudenken.

Seien Sie zunächst ehrlich, wo Sie aktuell stehen. Dokumentieren Sie den gesamten Prozess von der Anfrage bis zur Genehmigung eines Anbieters in Ihrem Unternehmen. Erfassen Sie jede E-Mail, jede Tabelle, jede Tool-Übergabe und jeden manuellen Schritt. Wenn Sie eine Plattform nutzen, verfolgen Sie, wie viel Zeit Sie mit der Pflege der Plattform verbringen, anstatt tatsächlich Risiken zu bewerten. Diese Ausgangsbasis ist entscheidend. Sie zeigt Ihnen, ob Ihr nächster Schritt eine Konsolidierung, ein Austausch oder ein grundlegend anderer sein sollte.

Zweitens sollten Sie quantifizieren, was durchs Raster fällt. Wie viele Ihrer Lieferanten wurden in den letzten zwölf Monaten bewertet? Wie viele haben seit ihrer letzten Überprüfung KI-Funktionen hinzugefügt? Wie hoch ist Ihre Rücklaufquote beim Sicherheitsfragebogen? Manche Organisationen berichten von Quoten von nur 18 Prozent. Wenn Ihre Zahlen ähnlich aussehen, brauchen Sie keinen besseren Prozess zur Lieferantenverfolgung. Sie brauchen ein System, das diese Aufgabe für Sie übernimmt.

Drittens: Bewerten Sie Ihr nächstes Tool anhand seiner Autonomie, nicht anhand seines Funktionsumfangs. Die nächste Plattform sollte nicht einfach nur einen längeren Funktionsumfang als Ihre aktuelle haben. Sie sollte die Anzahl der Entscheidungen, die Ihr direktes Eingreifen erfordern, reduzieren. Bitten Sie den Anbieter, Ihnen zu zeigen, was passiert, wenn das System eine Woche lang nicht bedient wird. Wenn nichts passiert, ist das Tool nicht autonom, sondern lediglich automatisiert.

Viertens: Reduzieren Sie den Umfang, bevor Sie skalieren. Sie müssen nicht Ihr gesamtes Lieferantenprogramm auf einmal umstellen. Konzentrieren Sie sich auf die risikoreichsten Lieferanten aus Schritt eins, integrieren Sie sie in einen neuen Workflow und beweisen Sie dort zunächst den Nutzen. Wenn das in Schritt drei ausgewählte Tool tatsächlich autonom arbeitet, sollte dies schnell Kapazitäten freisetzen, anstatt Ihre Arbeitsbelastung zu erhöhen. Sobald Sie dies erkennen, ist eine Erweiterung unkompliziert.

Die Landschaft des Drittanbieter-Risikomanagements (TPRM) hat sich so stark verändert, dass kein bisheriger Ansatz darauf vorbereitet war. Unternehmen, die dies erkennen und auf autonomes, KI-gestütztes Lieferantenrisikomanagement umstellen, sind dem Problem nicht nur einen Schritt voraus. Sie verändern die Art und Weise, wie Drittanbieterrisiken mit schlanken Teams in einem dynamischen Umfeld gemanagt werden. Und der Abstand zwischen diesen Unternehmen und allen anderen wird sich weiter vergrößern.