Es beginnt oft mit einem Formular: zweihundert Fragen, die jeder Lieferant ausfüllen soll; Häkchen bei „ja/nein“, Freitextfelder für „bitte beschreiben“, angeheftet ein PDF mit Zertifikaten. Man schickt es an zehn, fünfzig, hundert Drittparteien – und spürt Erleichterung, wenn die Antwort im Posteingang landet. Doch die Erleichterung ist trügerisch. Spätestens beim ersten Lieferkettenvorfall zeigt sich: Fragebögen sind keine Feuerlöschanlage. Third-Party Risk Management (TPRM), das vor allem aus Kontrolle, Formalitäten und verspäteter Dokumentation besteht, liefert die Illusion von Sicherheit – aber nicht die Fähigkeit, Risiken zu verhindern, zu erkennen und gemeinsam zu bewältigen.

2026 markiert in vielen Häusern einen Wendepunkt. Die Schlagzahl von NIS2-Pflichten, DORA-Anforderungen, Branchennormen, Audit-Nachweisen, SBOM-Erwartungen und KI-Integrationen hat TPRM aus der Compliance-Ecke geholt und in die operative Führung geschoben. Aus „kontrollieren“ wird „kooperieren“. Aus „prüfen“ wird „prüfen und beweisen“. Aus „Dienstleister“ wird „Mitgestalter“. Diese Verlagerung ist kein weicher Kulturwunsch, sondern harte Ökonomie: Nur wer Lieferanten zur Partnerschaft befähigt, erhält die Geschwindigkeit, Transparenz und Resilienz, die moderne Geschäftsmodelle benötigen.

Es gibt Jahre, in denen Governance wie ein gepflegter Maschinenraum wirkt: saubere Schaltbilder, klare Zuständigkeiten, geölte Prozesse, Prüfzeichen am richtigen Ort. Und es gibt Jahre, in denen das gleiche Bild plötzlich alt aussieht. 2026 ist so ein Jahr. Die Architektur der Kontrolle – Regeln, Freigaben, Checklisten – bewährt sich weiterhin, aber sie reicht nicht mehr aus, um Organisationen durch eine Welt zu steuern, in der digitale Abhängigkeiten unübersichtlich, Lieferketten fragil, regulatorische Erwartungen dynamisch und Technologien wie KI, Cloud und vernetzte Produkte zum Taktgeber geworden sind. Der Satz „Kontrolle allein reicht nicht“ klingt wie eine Plattitüde. In Wahrheit markiert er einen Wendepunkt: Governance verschiebt sich von der Frage „Ist es freigegeben?“ zu „Hält es unter Last – und können wir das beweisen, während wir uns anpassen?“

Der Bruch mit der Kontrolllogik

Die Klassik der Governance wurde von zwei Grundgedanken getragen: Erstens lässt sich Risiko durch Regeln und Rollen beherrschen. Zweitens genügt es, die Einhaltung in Zyklen zu prüfen – Jahresabschluss, Auditplan, Projektgate. Das funktionierte, solange Veränderung langsam und Abhängigkeiten überschaubar waren. Heute kollidieren beide Annahmen mit der Praxis. Veränderungen passieren kontinuierlich (Feature-Rollouts, Infrastruktur-Drifts, Datenströme), und Abhängigkeiten ziehen systemische Effekte nach sich (ein Ausfall in der Lieferkette, ein Software-Bug, eine kompromittierte Identität). Kontrolle bleibt nötig – aber sie ist nicht mehr die Königsdisziplin. Die neue Frage lautet: Wie bleibt die Organisation handlungsfähig, obwohl Kontrolle versagen kann – und wie lernt sie schneller als die Welt sich ändert?

In der Welt der Informationssicherheit gab es immer wieder Schlagworte, die als „Must-have“ galten: Firewalls, Virenscanner, ISO 27001, Cloud Security, Zero Trust. Jedes dieser Themen hatte seine Zeit im Rampenlicht. Heute ist der Begriff, der in Vorträgen, Strategiepapiere und Gesetzesentwürfe gleichermaßen auftaucht, Cyber-Resilienz. Er klingt modern, fast schon schick – und genau deshalb wird er oft oberflächlich behandelt. Aber hinter diesem Schlagwort steckt weit mehr als ein Marketingtrend. Cyber-Resilienz ist nicht nur eine Erweiterung klassischer IT-Sicherheit, sondern ein strategischer Ansatz, der Unternehmen widerstandsfähig gegen digitale Angriffe, technische Störungen und sogar komplexe Krisen macht. Kurz gesagt: Es geht nicht mehr nur darum, Angriffe zu verhindern, sondern darum, auch dann handlungsfähig zu bleiben, wenn sie unvermeidlich eintreten.

Von Prävention zu Anpassungsfähigkeit: Was Cyber-Resilienz wirklich bedeutet

Der zentrale Unterschied zwischen traditioneller IT-Sicherheit und Cyber-Resilienz liegt in der Perspektive. Klassische Sicherheitskonzepte fokussieren stark auf Prävention – also darauf, Angriffe zu blockieren, Schwachstellen zu schließen und Risiken zu minimieren. Das ist wichtig, aber in einer Welt, in der Angreifer immer schneller neue Taktiken entwickeln und selbst hochgesicherte Systeme kompromittieren können, reicht Prävention allein nicht mehr aus. Cyber-Resilienz ergänzt diesen Ansatz um Detektion, Reaktion, Wiederherstellung und Lernen. Das bedeutet: Wir akzeptieren, dass ein Angriff oder Ausfall passieren kann, und sorgen dafür, dass wir schnell erkennen, angemessen reagieren und uns effizient erholen – ohne dass der Geschäftsbetrieb vollständig zum Erliegen kommt.

Es beginnt selten mit einem direkten Angriff auf das eigene Haus. Häufiger startet die Kettenreaktion einige Sprünge entfernt: ein „Minor Incident“ bei einem SaaS-Anbieter, eine Schwachstelle in einer File-Transfer-Lösung, ein überprivilegierter Account beim Managed Service Provider, ein Update, das im Build-Prozess eines Partners kompromittiert wurde. Für die Öffentlichkeit sind das zunächst nur Randnotizen. Für Betreiber kritischer oder wichtiger Dienste können es jedoch die Sekunden sein, in denen aus einem Fremdproblem eine eigene Meldepflicht wird. Spätestens mit NIS2 ist klar: Wer auf Lieferketten setzt (und wer tut das nicht?), trägt Verantwortung – und zwar nicht nur für die Prävention, sondern auch für die Meldung. Dieses „NIS2 im Nacken“-Gefühl ist kein Aktionismus, sondern Ausdruck einer Realität, in der Abhängigkeiten Teil des Kernbetriebs sind.

Dieser Beitrag erklärt, warum Lieferkettenereignisse unter NIS2 meldepflichtig werden können, wie sich Meldewege, Schwellen und Verantwortlichkeiten in der Praxis anfühlen, welche Governance-Bausteine jetzt zählen – und wie man den Spagat schafft zwischen Transparenz, Tempo und Verlässlichkeit. Nicht als trockene Gesetzeslektüre, sondern als Betriebsanleitung für den Ernstfall.

Bis gestern haben Sie Features priorisiert, als ginge es um die Frage „Was bringt den nächsten großen Kunden, was begeistert die Presse, was macht den Vertrieb glücklich?“. Ab morgen steht eine andere Frage im Raum: „Welche dieser Funktionen können wir überhaupt noch verantworten, ohne gegen den Cyber Resilience Act (CRA) zu verstoßen – und wer haftet, wenn wir es trotzdem tun?“ Das mag dramatisch klingen, ist aber nüchtern betrachtet die neue Realität für alle, die Produkte mit digitalen Komponenten bauen, betreiben oder vertreiben. Der CRA dreht die Blickrichtung von außen nach innen: Weg von der Feature-Show, hin zur belastbaren Fähigkeit, ein Produkt über seinen gesamten Lebenszyklus sicher zu halten. Und genau deshalb sprengt er klassische Roadmap-Rituale – nicht aus Bosheit, sondern aus Notwendigkeit.

Was sich verändert, ist nicht nur eine Liste von Pflichten, sondern die Logik, nach der Sie Entscheidungen treffen. Der CRA macht Sicherheit zu einer Marktzulassungsbedingung und verknüpft sie mit nachweisbarer Sorgfalt. Wo bislang „Security“ ein Arbeitspaket im Projektplan war, wird sie zur architektonischen Grundannahme und zur Managementaufgabe, an der sich Budgets, Zeitpläne, Vertragswerke und sogar Marketingclaims ausrichten müssen. Wer Roadmaps weiterhin wie Wunschzettel behandelt, produziert in Zukunft nicht Innovationen, sondern Haftungsrisiken.