Die Sicherheitsschuld von Lieferanten
Die Sicherheitsschuld von Lieferanten
Alle Entwickler kennen technische Schulden. Die Abkürzung, die man bewusst nimmt: ein schneller Fix, eine vereinfachte Architektur, ein aufgeschobener Test. Technische Schulden sind kein Fehler. Sie sind eine Abwägung. Das Problem ist nie, sie aufzunehmen, sondern sie zu vergessen. Denn sie verschwinden nicht. Sie schlummern, sie häufen sich an und melden sich irgendwann zurück – oft im schlechtesten Moment und immer auf einen Schlag.
Im Risikomanagement gibt es ein Gegenstück, über das viel weniger gesprochen wird. Ich nenne es die Sicherheitsschuld von Lieferanten.
Jedes Mal, wenn eine Organisation einen neuen Dienstleister einbindet, ohne ihn angemessen zu bewerten, nimmt sie einen Schuldposten auf. Ein Zugang, der ohne Prüfung gewährt wird. Ein Vertrag, der ohne Cyber-Anhang unterzeichnet wird. Ein Unterauftragnehmer, der drei weitere beschäftigt, deren Namen niemand kennt. Für sich genommen ist jede dieser Abkürzungen unsichtbar. Zusammengenommen, über mehrere Jahre und mehrere hundert Lieferanten, bilden sie ein erhebliches und nicht gemessenes Risiko. Ohne fundierte, klar strukturierte Methodik ist jeder neue Lieferant nicht bloß eine Geschäftsbeziehung. Er ist eine potenzielle Zeitbombe.
Warum sich die Schuld anhäuft: das verwaiste Risiko
Dass diese Schuld so unauffällig wächst, hat einen strukturellen Grund: Das Lieferantenrisiko hat meist keinen Eigentümer.
Sehen Sie sich an, wie es in den meisten Organisationen behandelt wird. Für den Einkauf ist es zu technisch – er verhandelt einen Vertrag, ohne eine Sicherheitslage beurteilen zu können. Für die Sicherheit ist es zu vertraglich und kommt zu spät – sie lernt den Dienstleister erst nach der Unterzeichnung kennen. Für die Fachbereiche ist es zu diffus – sie hängen täglich vom Lieferanten ab, ohne sich für dessen Cyberrisiko verantwortlich zu fühlen. Jeder sieht eine Seite davon. Niemand hat es als Ganzes im Griff.
Es ist ein Thema, dessen Häufigkeit zunimmt und dessen Komplexität ständig wächst – neue Services, neue SaaS-Abhängigkeiten, neue regulatorische Pflichten. Und genau dieses hochspezialisierte Thema erhält die wenigsten dedizierten Ressourcen. Das Ergebnis ist eine Anomalie, die man inzwischen für normal hält: Nicht spezialisierte, ohnehin ausgelastete Teams steuern nebenbei eines der technischsten Risiken des Unternehmens.
In einem Großkonzern fängt ein dediziertes TPRM-Team dieses Paradox auf. Doch die meisten Unternehmen sind keine Großkonzerne. In einem KMU oder mittelständischen Unternehmen gibt es kein TPRM-Team. Es gibt eine Person in der Sicherheit oder im Einkauf, die das Thema zusätzlich zu allem anderen erbt. Das Lieferantenrisiko fällt dort in einen organisatorischen toten Winkel. Niemand hat beschlossen, es zu ignorieren. Niemand nimmt die Schuld bewusst auf. Man erbt sie – mangels Struktur.
Die Rechnung ist fällig
Rund fünfzehn Jahre lang hat diese Vorgehensweise funktioniert. Man delegierte, man hoffte, man hakte das vertragliche Kästchen ab. Und das genügte, solange das Lieferantenrisiko weitgehend theoretisch blieb.
Das ist es nicht mehr. Der Data Breach Investigations Report 2025 von Verizon, der mehr als 22.000 Sicherheitsvorfälle analysiert, liefert eine eindeutige Zahl: Der Anteil der Sicherheitsverletzungen unter Beteiligung eines Dritten hat sich innerhalb eines Jahres verdoppelt – von 15 % auf 30 %. Jede dritte Kompromittierung erfolgt inzwischen über einen Dienstleister, einen Lieferanten, einen Partner.
Diese Verdopplung innerhalb von zwölf Monaten ist kein statistischer Zufall. Es ist der Markt, der kollektiv die Rechnung für ein Jahrzehnt mangelnder Priorisierung erhält. Die Sicherheitsschuld von Lieferanten schlummert nicht mehr. Sie wird eingefordert. Und die operative Feststellung ist einfach: Am Lieferantenrisiko führt kein Weg mehr vorbei.
Was das Problem nicht lösen wird
Angesichts dieser Erkenntnis sind die ersten Reflexe verständlich, aber größtenteils wirkungslos.
Ein dediziertes Team einstellen? Nur sehr wenige Organisationen haben das Budget dafür, und der Markt für TPRM-Spezialisten ist klein. Alle Lieferanten bewerten? Rechnerisch nicht machbar, operativ unrealistisch und vor allem nicht wünschenswert: Der überwiegende Teil eines Lieferantenportfolios rechtfertigt keine eingehende Bewertung. Sicherheitsfragebögen anhäufen? Damit verlagert man die Last auf den Lieferanten und auf die Teams, die die Antworten auswerten, ohne das tatsächliche Risiko je zu verringern.
Diesen Scheinlösungen ist gemeinsam, dass sie alle in Ressourcenvolumen denken. Das Problem ist jedoch kein Ressourcenproblem. Es ist ein Methodenproblem.
Der Ausweg besteht darin, die Schuld mit gleichbleibenden Ressourcen beherrschbar zu machen: den wirklich kritischen Teil des Lieferantenportfolios identifizieren – in der Regel deutlich kleiner als gedacht –, den Bewertungsaufwand darauf konzentrieren und die Bearbeitung des gesamten Rests industrialisieren. Genau diese Logik haben wir in einem kurzen, praxisnahen Priorisierungsleitfaden zusammengefasst: erst sortieren, dann bewerten, um dem Volumen nicht länger ausgeliefert zu sein.
Aufhören, Schulden zu machen
Eine Sicherheitsschuld bei Lieferanten tilgt man nie auf einen Schlag, und das ist auch nicht das Ziel. Das Ziel ist ein doppeltes: aufhören, blind neue Schulden aufzunehmen, und vorrangig die riskantesten Posten zurückzahlen.
Das erfordert kein Budget, das Sie nicht haben. Es erfordert eine einfache, klare und vertretbare Methodik: die eigenen kritischen Risiken identifizieren und sie in einem Bruchteil der Zeit behandeln, die ein klassisches Audit heute in Anspruch nimmt – ohne die Kosten explodieren zu lassen oder Teams zu erschöpfen, die dieses Thema nie allein tragen sollten.
Genau darüber sprechen wir am 10. Juni um 11:30 Uhr in einer gemeinsam moderierten Session mit unserem Partner Aprovall: wie Sie die Dauer von Cyber-Audits bei Lieferanten durch zehn teilen, ohne Ihre Teams zusätzlich zu belasten. Wenn Sie das Thema anspricht und Sie beim Lesen dieses Beitrags Ihre eigene Organisation wiedererkannt haben, sind Sie herzlich willkommen.
Étienne