Wer heute über 5G spricht, landet oft reflexartig bei Messwerten: Gigabit-Downloads, einstellige Millisekunden, funkelnde Balkendiagramme im Smartphone. Doch genau diese Fixierung auf die Zahl rechts unten im Speedtest verdeckt den eigentlichen Umbruch. 5G ist weniger ein schnelleres Funkprotokoll als vielmehr ein modularer Baukasten für verlässliche, planbare und differenzierte Konnektivität. Die ersten produktiven Use-Cases im Business zeigen das sehr konkret: autonome Transportfahrzeuge in Fabriken, die ohne Kabelzug und Funkabbrüche funktionieren; Häfen, die Kräne, Sensoren und Kameras in einem einzigen privaten 5G-Campusnetz orchestrieren; Kliniken, die Bilddaten nahezu verzögerungsfrei an Befund-Workflows weitergeben; Energieversorger, die Fleckennetze (Edge) für Netzzustand und Lastverteilung aufbauen; Event-Veranstalter, die Besucherströme, Kassen- und Zutrittssysteme ohne Überlastungen in temporären 5G-Slices betreiben.

Geschwindigkeit ist hierfür nur der Türöffner. Der eigentliche Mehrwert entsteht, weil 5G Qualität garantieren kann – und zwar Anwendung für Anwendung. Mit Network Slicing, Ultra Reliable Low Latency Communication (URLLC), Massive Machine Type Communication (mMTC) und Edge Computing wird aus einem Funknetz eine Plattform, in der man Kapazität, Latenz, Verfügbarkeit und Sicherheit pro Geschäftsprozess zuschneiden kann. Genau diese Planbarkeit fehlte bisherigen Mobilfunkgenerationen.

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 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.

Es gibt Momente, in denen Regulierung nicht nur Regeln setzt, sondern eine ganze Organisation in den Spiegel schauen lässt. DORA und NIS2 sind genau solche Momente. Die eine Verordnung richtet sich mitten ins Herz der Finanzwelt und macht digitale Resilienz zur Chefsache. Die andere spannt den Bogen über große Teile der europäischen Wirtschaft und hebt Cybersicherheit auf ein neues, sektorübergreifendes Niveau. Zusammen erzeugen sie einen Druck, der weit über Checklisten hinausreicht: Governance wird zur Bewährungsprobe. Nicht mehr die Frage, ob Richtlinien existieren, sondern ob Steuerung messbar wirkt, entscheidet darüber, wie belastbar ein Unternehmen wirklich ist.

Der Doppeldruck: Zwei Wellen, ein Kernproblem

Viele Häuser erleben gerade zwei Wellen gleichzeitig. Von DORA her rollt die Erwartung, digitale Betriebsfähigkeit selbst unter Störung nachweislich zu sichern – mit Risikomanagement, Meldung, Tests und streng geführter Lieferkette. Von NIS2 her wächst der Anspruch, Cyberrisiken querschnittlich zu beherrschen – vom Vorstand über Technik bis hin zu Partnern und Dienstleistern. Auf den ersten Blick zwei Welten; in Wahrheit ein Kernproblem: Führung unter Unsicherheit. Wer beide Rahmen ernst nimmt, erkennt schnell: Governance ist nicht die Summe von Einzelanforderungen, sondern ein lebendes System, das Ziele, Risiken, Kontrollen, Daten und Entscheidungen miteinander verzahnt – und zwar so, dass man es jederzeit belegen kann.

Man hört es inzwischen auf fast jeder Konferenz und liest es in beinahe jeder Vorstandsvorlage: NIS2 und DORA sind gekommen, um zu bleiben. Zwei europäische Regelwerke, zwei unterschiedliche juristische Instrumente, ein gemeinsames Ziel: Europas digitale Widerstandskraft deutlich erhöhen. Auf den ersten Blick wirken beide wie Geschwister – beide verlangen strukturiertes Risikomanagement, Meldeprozesse, technische und organisatorische Schutzmaßnahmen, Verantwortlichkeit des Managements sowie einen klaren Blick auf die Lieferkette. Wer aber tiefer einsteigt, merkt schnell: Es sind keine Zwillinge, sondern eher zwei präzise Werkzeuge mit unterschiedlicher Klinge. NIS2 spannt den großen Bogen über viele Sektoren und Kategorien kritischer und wichtiger Einrichtungen; DORA wählt den chirurgischen Schnitt in das Betriebssystem der Finanzbranche und ihrer ICT-Dienstleister – inklusive Aufsicht über kritische Drittanbieter. Wer beides gleichzeitig erfüllen muss, steht vor der Aufgabe, Überschneidungen klug zu nutzen und Unterschiede bewusst zu adressieren. Genau darum geht es in diesem Beitrag: Was unterscheidet NIS2 und DORA, wo überlappen sie, und wie setzt man sie mit möglichst wenig Reibungsverlusten um?

Warum jetzt? Das gemeinsame „Warum“ hinter NIS2 und DORA

Beide Regelwerke sind Antworten auf eine Realität, die niemand mehr wegdiskutieren kann: Cyberangriffe sind zum Betriebsrisiko Nummer eins geworden, Lieferketten sind verwundbar, kritische Dienste hängen an digitaler Infrastruktur, die teils über Jahre zu wenig priorisiert wurde. Dazu kommt eine europäische Zielsetzung, Abhängigkeiten zu reduzieren und Mindeststandards hochzuziehen, damit ein Ausfall nicht zum Dominoeffekt wird. NIS2 setzt dabei in der Breite an und will, dass jeder kritische oder wichtige Player in Europa ein Mindestniveau erreicht – von Energie bis Gesundheit, von Verkehr bis Digitalinfrastruktur. DORA nimmt die Finanzbranche in den Fokus, weil operationale Resilienz dort unmittelbar systemrelevant ist: Ein stundenlanger Ausfall von Zahlungsverkehr, Börsenhandel oder Marktinfrastruktur ist weit mehr als eine Unannehmlichkeit.