24 Stunden für den Vorfall: Warum Software-Lieferketten klare Supplier-Governance brauchen

Kurze Meldefristen verändern die Bedeutung von Informationswegen.

Ein Unternehmen kann sich bei einem kritischen Vorfall nicht darauf verlassen, dass eine offene Frage im nächsten regulären Jour fixe mit dem Dienstleister geklärt wird.

Auch ein Reportingprozess, der normalerweise einige Tage für Konsolidierung benötigt, kann im Ernstfall zu langsam sein.

Entscheidend wird deshalb nicht nur, ob Informationen irgendwo vorhanden sind.

Entscheidend ist:

Wie schnell sind die richtigen Informationen bei der richtigen verantwortlichen Stelle?

Der Cyber Resilience Act ist an dieser Stelle ein besonders deutlicher Anlass.

Aber die zugrunde liegende Managementfrage kennt jedes komplexe Projekt:

Ein Problem tritt auf. Mehrere Parteien sind beteiligt. Daten liegen verteilt. Verantwortlichkeiten überschneiden sich. Und die Zeit für eine Entscheidung ist begrenzt.

Artikel 14 der Verordnung richtet die entsprechenden Meldepflichten an Hersteller. Daraus sollte nicht abgeleitet werden, jeder externe Softwaredienstleister oder Technologieanbieter unterliege automatisch derselben 24-Stunden-Pflicht. Ob und welche gesetzlichen oder vertraglichen Pflichten einen konkreten Akteur treffen, muss im Einzelfall geprüft werden.

Operativ entsteht trotzdem eine Abhängigkeit.

Ein Hersteller kann verantwortlich sein, ohne sämtliche technischen Leistungen selbst erbracht zu haben.

Ein Produkt kann beispielsweise enthalten oder abhängig sein von:

Diese Beispiele bedeuten nicht automatisch, dass jeder Beteiligte unter dieselben CRA-Pflichten fällt.

Sie zeigen ein anderes Problem:

Derjenige, der entscheiden oder melden muss, kann auf Informationen anderer Parteien angewiesen sein.

Damit wird Supplier Governance Teil der Reaktionsfähigkeit.

Viele Unternehmen dokumentieren ihre Dienstleisterbeziehungen kaufmännisch.

Procurement kennt Vertrag, Preis und Laufzeit.

IT kennt Systeme und technische Komponenten.

Das Projektteam kennt Ansprechpartner und offene Arbeitspakete.

Security kennt Schwachstellen und Incident-Prozesse.

Legal und Compliance kennen regulatorische Anforderungen.

Diese Aufteilung ist grundsätzlich sinnvoll.

Problematisch wird sie erst, wenn in einer zeitkritischen Situation niemand schnell genug die Verbindung herstellen kann.

Zum Beispiel:

Welches Produkt nutzt die betroffene Komponente? Welcher Dienstleister verantwortet sie? Wer ist dort der operative Ansprechpartner? Welcher Vertrag regelt Informations- oder Mitwirkungspflichten? Welche internen Verantwortlichen müssen eingebunden werden? Welche Kunden oder Märkte könnten betroffen sein? Wer entscheidet über nächste Schritte?

Wenn diese Zusammenhänge erst nach Eintritt eines Vorfalls rekonstruiert werden müssen, wird Zeit nicht für die Lösung verwendet, sondern für Informationssuche.

Wie groß der organisatorische Handlungsbedarf sein könnte, zeigt eine am 10. September veröffentlichte Bitkom-Erhebung.

67 Prozent der befragten Unternehmen kannten demnach den Begriff Cyber Resilience Act. Aber nur 29 Prozent gaben an, auch zu wissen, was das Gesetz für ihr eigenes Unternehmen bedeutet. 38 Prozent hatten davon gehört, konnten die Bedeutung für das eigene Unternehmen jedoch nicht einschätzen; 28 Prozent kannten den CRA überhaupt nicht.

Die Zahlen stammen aus einer telefonischen Befragung von 1.003 Unternehmen ab zehn Beschäftigten und mindestens einer Million Euro Jahresumsatz in Deutschland, durchgeführt zwischen Kalenderwoche 16 und 23 des Jahres 2026. Bitkom weist die Erhebung als repräsentativ aus. Gefragt wurde nach der Bekanntheit des CRA.

Wichtig ist die Evidenzgrenze:

Die Umfrage misst Bekanntheit und Selbsteinschätzung.

Sie beweist nicht, dass 71 Prozent der deutschen Unternehmen regulatorisch unvorbereitet sind, und sie untersucht auch nicht die Qualität ihrer Supplier-Governance.

Sie zeigt aber, dass selbst unmittelbar vor Beginn der Meldepflicht erhebliche Unsicherheit über die Bedeutung des CRA bestand.

Unternehmen sollten deshalb nicht erst im Vorfall prüfen, wie ihre Supplier-Landschaft funktioniert.

Sie können vorab sieben organisatorische Fragen beantworten:

Ein allgemeines Lieferantenverzeichnis reicht dafür nicht.

Relevant ist die Verbindung:

Produkt → Komponente → Projekt → Supplier → verantwortliche Leistung

Erst damit wird sichtbar, bei welchem externen Partner Informationen eingeholt werden müssen, wenn eine konkrete Komponente betroffen ist.

Ein Vertriebsansprechpartner allein reicht für einen technischen Vorfall möglicherweise nicht.

Für kritische Leistungen sollten operative Verantwortliche und Eskalationskontakte bekannt sein – idealerweise einschließlich Vertretungen.

Denn ein Eskalationsweg, der nur funktioniert, wenn eine bestimmte Person erreichbar ist, ist kein belastbarer Eskalationsweg.

Die Frage sollte nicht erst im Ernstfall gestellt werden.

Unternehmen können im Vorfeld klären, welche Informationen sie benötigen, um technische und organisatorische Entscheidungen treffen zu können.

Zum Beispiel:

betroffene Komponente, bekannte Auswirkungen, Zeitpunkt der Kenntnis, betroffene Versionen, bereits eingeleitete Maßnahmen und verfügbare Korrekturen.

Welche Daten gesetzlich oder vertraglich im Einzelfall erforderlich sind, muss fachlich beziehungsweise rechtlich geprüft werden.

Ein Incident kann technisch erkannt und trotzdem organisatorisch zu spät eskaliert werden.

Das passiert beispielsweise, wenn eine Meldung zunächst an den normalen Projektkontakt geht, von dort an einen Teamleiter, anschließend an IT, dann an Security und erst danach an die verantwortliche Stelle.

Jeder einzelne Schritt kann nachvollziehbar sein.

In Summe kostet die Kette trotzdem Zeit.

Eine Eskalation ohne Entscheidungsrecht bleibt ein Informationsprozess.

Deshalb sollte klar sein:

Wer beurteilt die Relevanz? Wer aktiviert weitere Fachbereiche? Wer fordert zusätzliche Informationen vom Supplier an? Wer entscheidet über operative Gegenmaßnahmen? Wer trägt die regulatorische Verantwortung?

Das sind nicht zwingend dieselben Personen.

Ein Vertrag kann umfangreiche Sicherheits- und Informationspflichten enthalten.

Entscheidend ist trotzdem, ob der operative Prozess diese Pflichten praktisch unterstützt.

Wenn ein Supplier laut Vertrag informieren muss, intern aber kein klarer Empfänger, Eskalationskanal oder Prozess definiert ist, löst die Vertragsklausel das operative Problem nicht allein.

Procurement, Legal, IT und operative Projektverantwortung müssen deshalb dieselbe Supplier-Beziehung aus unterschiedlichen Blickwinkeln betrachten.

Komplexität endet nicht beim direkten Vertragspartner.

Der beauftragte Dienstleister kann wiederum Komponenten oder Leistungen Dritter einsetzen.

Nicht jede Unterbeauftragung ist gleichermaßen kritisch.

Aber bei geschäfts- oder produktsicherheitsrelevanten Abhängigkeiten sollte das Management wissen, wo zusätzliche Informationsketten entstehen können.

Klassisches Supplier Management bewertet Anbieter häufig entlang von Kriterien wie Kosten, Qualität, Liefertreue, Leistungsfähigkeit oder wirtschaftlicher Stabilität.

Bei digitalen Produkten kommt eine weitere Dimension hinzu:

Wie schnell kann ein Supplier bei einem kritischen Ereignis belastbare Informationen liefern und an einem gemeinsamen Entscheidungsprozess mitwirken?

Das ist keine abstrakte Compliance-Frage.

Es ist eine operative Leistungsanforderung.

Ein Anbieter kann technisch hervorragend arbeiten und trotzdem zu einem Governance-Risiko werden, wenn:

Dienstleistersteuerung umfasst deshalb nicht nur was ein Partner liefert, sondern auch wie steuerbar die Zusammenarbeit in einer Ausnahmesituation ist.

Cybersecurity und Procurement verfolgen unterschiedliche Aufgaben.

Das ist sinnvoll.

Security beurteilt technische Risiken. Procurement steuert kommerzielle Beziehungen. Legal bewertet Verpflichtungen. Projekt- oder Produktmanagement steuert Umsetzung und Abhängigkeiten.

Die Herausforderung entsteht an ihren Schnittstellen.

Wenn Security ein Problem mit einer Komponente erkennt, muss möglicherweise Procurement wissen, welcher Vertrag betroffen ist.

Wenn Procurement einen Providerwechsel vorbereitet, muss das Produktteam wissen, welche Abhängigkeiten bestehen.

Wenn ein Dienstleister eine kritische Information meldet, muss klar sein, welches Produkt, Projekt und welche verantwortlichen Personen betroffen sind.

Dafür benötigen die Funktionen keine identischen Fachsysteme.

Aber sie benötigen einen konsistenten Zusammenhang.

An dieser Stelle ist die Grenze wichtig.

Supplier- und Project-Intelligence-Systeme ersetzen weder Schwachstellenmanagement noch Security Operations, Incident Response oder juristische CRA-Compliance.

Und aus diesem Beitrag folgt ausdrücklich nicht, dass Ramp7 Sicherheitsvorfälle erkennt, CRA-Meldungen erstellt, gesetzliche Fristen überwacht oder Security-Systeme integriert.

Die Ramp7-Perspektive liegt an einer anderen Stelle:

Welche Projekte, externen Leistungen, Verantwortlichkeiten und Abhängigkeiten müssen für eine Managemententscheidung zusammengeführt werden?

Die CRA-Meldefristen zeigen lediglich besonders deutlich, warum diese Frage relevant ist.

Denn unter Zeitdruck wird aus fehlender Transparenz sehr schnell ein operatives Problem.

Auch unabhängig von einem konkreten CRA-Projekt können CIO, Procurement und Produktverantwortliche ihre Steuerungsfähigkeit mit sieben Fragen prüfen:

Mehrere Nein-Antworten sind zunächst kein Beweis für einen CRA-Verstoß.

Sie zeigen aber eine Governance-Lücke.

Und genau diese Lücke wird bei einer Frist von 24 Stunden wesentlich relevanter als im normalen Tagesgeschäft.

Der Cyber Resilience Act setzt seit dem 11. September 2026 einen klaren Zeitrahmen für bestimmte Meldungen von Herstellern: Frühwarnung innerhalb von 24 Stunden, weitergehende Meldung grundsätzlich innerhalb von 72 Stunden.

Diese Fristen sind eine regulatorische Vorgabe.

Die Managementlektion dahinter ist allgemeiner:

Ein Unternehmen kann nur so schnell entscheiden, wie es seine Abhängigkeiten versteht.

Wer erst im Incident herausfinden muss, welcher Dienstleister welche Komponente verantwortet, welcher Vertrag gilt und wer intern zuständig ist, beginnt die eigentliche Reaktion mit Informationssuche.

Supplier Governance sollte deshalb nicht erst dann funktionieren, wenn alles planmäßig läuft.

Ihre Qualität zeigt sich vor allem dann, wenn wenig Zeit bleibt.

Die entscheidende Frage lautet folglich nicht nur:

„Ist unser Supplier vertraglich verpflichtet zu reagieren?“

Sondern:

„Sind Produkt, Projekt, Supplier, Abhängigkeit, Information und Entscheidungsverantwortung so miteinander verbunden, dass wir tatsächlich rechtzeitig handeln können?“