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.

Es gab eine Ära, in der „Governance“ der Stoff für Policies, Organigramme und Audit-Agenden war. Man schrieb Richtlinien, legte Rollen fest, dokumentierte Risiken – und hoffte, dass all das im Ernstfall trägt. Diese Ära endet. Mit dem AI Act und dem Cyber Resilience Act (CRA) rückt die EU Governance an den Ort, an dem sich Wahrheit nicht vertuschen lässt: in die Produktentwicklung und den Betrieb. Plötzlich zählt nicht mehr, ob eine Regel existiert, sondern ob Ihr Produkt – Hardware, Software, Service, Modell – unter Last das hält, was Ihr Governance-Papier verspricht. Governance wird zur Produktprüfung. Wer das als Bürokratie empfindet, hat den Kern verfehlt. Wer es als Chance begreift, baut die Brücke zwischen Recht, Risiko und Ingenieursarbeit – und gewinnt Geschwindigkeit, Vertrauen und Marktzugang.

Der Kipppunkt: Von Papier-Governance zu Prüf-Governance

Warum dieser Bruch? Weil zwei Bewegungen zusammentreffen. Erstens KI-basierte Funktionen durchdringen Produkte quer durch alle Branchen – vom Risiko-Scoring in der Bank über visuelle Inspektionen in der Fertigung bis zu generativen Assistenten in SaaS-Plattformen. Zweitens zwingt die Digitalisierung der Lieferketten praktisch jedes Produkt, „mit dem Internet“ zu sprechen – und damit angreifbar zu sein. Wenn Fehlentscheidungen eines Modells diskriminieren können und eine Schwachstelle im Update-Mechanismus Hunderttausende Geräte trifft, dann reichen schöne Policies nicht mehr. Die EU schlägt daraus zwei Fäden: AI Act (Fokus: verantwortliche KI) und CRA (Fokus: durchgängig sichere Produkte mit digitalen Elementen). Beide Fäden laufen in derselben Mechanik zusammen: Konformität = Fähigkeit + Nachweis. Fähigkeit entsteht in Architektur, Code, Daten und Betrieb. Nachweis entsteht in Tests, Telemetrie und technischer Dokumentation.

Backups gelten als Sicherheitsgurt der IT. Sie beruhigen, wenn alles andere schiefgeht, sie legitimieren mutige Veränderungen und sie sind – so die bequeme Erzählung – die letzte Verteidigungslinie gegen Ransomware, Fehlkonfigurationen und menschliche Irrtümer. Doch genau in dieser Bequemlichkeit steckt ein Risiko. Wer Backups nur als „haben wir“ verbucht, übersieht, dass sie selbst zu Angriffsfläche, Compliance-Falle, Kostenbremse und Operations-Risiko werden können. Dieses Paradoxon begegnet man erst dann, wenn es weh tut: im Incident Room, wenn Wiederherstellungen scheitern; im Audit, wenn Aufbewahrungsfristen und Löschpflichten kollidieren; in der Lieferkette, wenn ein Dienstleister die Telemetrie nicht liefert; im Budget, wenn Zombie-Backups in der Cloud unbemerkt Millionen verschlingen. Zeit, hinzusehen: Wann werden Backups zur Gefahr – und wie baut man sie so, dass sie nicht zum Problem, sondern zum Beweis der eigenen Handlungsfähigkeit werden?

Das Backup-Paradoxon

Je erfolgreicher die Datensicherung, desto unsichtbarer wird sie. Sie läuft nachts, sie meldet „grün“, sie erzeugt beruhigende Reports. Doch Sichtbarkeit ist nicht gleich Wirksamkeit. „Job erfolgreich“ bedeutet nicht, dass sich eine kritische Anwendung konsistent wiederherstellen lässt. „Immutability aktiv“ bedeutet nicht, dass Angreifer nicht doch Löschbefehle platzieren können – über die falschen Adminrechte, die richtige API oder einen Delegationsfehler. „Replikation aktiv“ bedeutet nicht, dass man ein sicheres Restore-Zeitfenster hat; Replikation multipliziert auch Korruption und Verschlüsselung in Rechenzeit, nicht in Tagen. Was zählt, ist nicht die Existenz von Kopien, sondern die Fähigkeit, gezielt, schnell und integer zu rekonstruieren – und das nachweisbar.

Es gab eine Zeit, in der Cybersecurity vor allem als Schutzdisziplin verstanden wurde: Systeme härten, Angriffe blockieren, Daten vor unerlaubtem Zugriff bewahren. Überschaubare Perimeter, klar definierte Netzgrenzen, ein Katalog an „Best Practices“ – und möglichst wenige Überraschungen. Diese Zeit ist vorbei. Je stärker digitale Infrastrukturen miteinander verflochten sind, desto offensichtlicher wird: Perfekter Schutz existiert nicht. Angriffe werden erfolgreicher, Lieferketten komplexer, Abhängigkeiten enger – und der Schaden, wenn etwas schiefgeht, größer. Die Aufsicht reagiert: Nicht mehr reiner Schutz, sondern Resilienz steht im Mittelpunkt. Widerstandsfähigkeit wird zur eigentlichen Währung der digitalen Governance. Das ist kein semantischer Wechsel, sondern ein Paradigmenbruch mit tiefen Folgen für Strategie, Organisation, Technik und Kultur.

Warum Schutz allein nicht mehr reicht

Die altbekannte Verteidigungslogik – verhindern, abwehren, abschotten – bleibt wichtig, aber sie stößt an harte physikalische Grenzen. Erstens, weil die Angriffsfläche exponentiell wächst: Cloud, SaaS, APIs, mobile Arbeit, OT/IoT, Datenökosysteme. Zweitens, weil Angreifer industrialisiert vorgehen: Toolkits, Ransomware-as-a-Service, Initial Access Broker, Supply-Chain-Taktiken. Drittens, weil digitale Abhängigkeiten zu systemischen Effekten führen: Fällt ein zentraler Dienstleister aus, trifft das in Stunden ganze Wertschöpfungsketten. Resilienz stellt daher eine andere Frage als klassischer Schutz: Wie bleibt das Unternehmen handlungsfähig, obwohl Schutzmaßnahmen versagen können? Die Antwort betrifft Architektur (Entkopplung, Redundanz), Organisation (Entscheidungsrechte, Eskalationsregeln), Menschen (Kompetenz, Übung) und Evidenz (Nachweis, dass es im Ernstfall funktioniert).

Es gibt Frameworks, die man aus Pflichtgefühl pflegt – und es gibt solche, die den Alltag wirklich verändern. Die CIS Controls gehören zur zweiten Kategorie. Sie sind längst kein Poster mehr an der Bürowand, keine Prüfliste, die man kurz vor einem Audit abhakt, und auch kein exotischer „Nice-to-have“-Standard. Sie sind eine Betriebsanleitung für gelebte Sicherheit: priorisiert, messbar, anschlussfähig an bestehende Governance – und robust genug, um in hybriden Realitäten aus Cloud, SaaS, Remote Work und komplexen Lieferketten zu tragen. Spätestens mit der jüngsten Evolutionsstufe haben die Controls die Grenze zwischen „Security-Projekt“ und „Security-Betrieb“ endgültig verwischt. Wer sie ernst nimmt, arbeitet anders: transparenter, wiederholbarer, nachweisbarer – und vor allem wirksamer.

Vom Poster zur Betriebsanleitung

Die ursprüngliche Stärke der Controls war immer ihre Frechheit der Priorisierung: Statt alles für gleich wichtig zu erklären, benennen sie wenige Hebel, die die meisten Angriffe früh stoppen oder schnell sichtbar machen. Dieses Grundprinzip ist erhalten geblieben – aber die Controls sind erwachsen geworden. Die aktuelle Fassung versteht unter „Asset“ nicht mehr nur die Maschine unterm Schreibtisch, sondern den ganzen Zoo moderner Unternehmens-IT: Cloud-Workloads, containerisierte Dienste, SaaS-Komponenten, mobile Endgeräte, Identitäten und Konfigurationen als eigene Schutzgüter. Dass die offizielle Controls-Liste heute konsequent von 18 Themenfeldern spricht, ist kein Modedetail, sondern die logische Folge dieser Realität. Damit spiegeln die Controls eine Gegenwart, in der Angriffsflächen nicht mehr am Rechenzentrumszaun enden.