trustspace

Tag: Lieferkette

  • Informationssicherheit in der Automobilindustrie: TISAX, VDA ISA und NIS2 im Überblick

    Informationssicherheit in der Automobilindustrie: TISAX, VDA ISA und NIS2 im Überblick

    Das Wichtigste in Kürze

    • Marktzugang: Der Nachweis entscheidet in der Automobilindustrie darüber, ob ein Zulieferer angefragt wird und Entwicklungsdaten erhält.
    • Prüfkatalog: Grundlage ist der VDA ISA mit den Modulen Informationssicherheit, Prototypenschutz und Datenschutz. Aktuell gilt die Fassung 6.0.3.
    • Versionswechsel: Der Nachfolger ISA2027 wurde am 1. Juli 2026 veröffentlicht und ist Grundlage aller TISAX®-Assessments, die ab dem 1. Januar 2027 beauftragt werden.
    • Kein Zertifikat: TISAX ist ein Prüf- und Austauschverfahren der ENX Association. Ergebnis sind Labels, die Sie im ENX-Portal gezielt für Partner freigeben.
    • Prüftiefe: Hoher Schutzbedarf führt zu Assessment Level 2, sehr hoher zu Level 3 mit Vor-Ort-Prüfung. Labels gelten drei Jahre, ohne jährliche Überwachungsaudits.
    • Weitere Rahmen: UNECE R155/R156 und ISO/SAE 21434 betreffen die Fahrzeug-Cybersicherheit, NIS2 seit Dezember 2025 auch viele Teilehersteller.

     

    Kaum eine Branche tauscht so früh so sensible Daten aus wie die Automobilindustrie. Konstruktionsstände, Steuergeräte-Software und Stückzahlplanungen wandern zwischen OEM, Systemlieferant, Teilefertiger und Prüflabor, oft Jahre vor dem Serienstart. Deshalb ist Informationssicherheit in der Automobilindustrie längst keine reine IT-Frage mehr, sondern eine Bedingung für die Zusammenarbeit: Wer den geforderten Nachweis nicht vorlegt, wird in Ausschreibungen nicht berücksichtigt oder erhält die Daten schlicht nicht.

    Für mittelständische Zulieferer ist das eine spürbare Verschiebung. Die Anforderung kommt vom Kunden, sie kommt kurzfristig und sie ist konkret: ein gültiges TISAX-Label mit einem bestimmten Prüfziel, für einen bestimmten Standort, bis zu einem bestimmten Datum. Dieser Leitfaden ordnet die Rahmenwerke ein, erklärt die Logik hinter VDA ISA und TISAX, grenzt beides von der ISO 27001 ab und benennt die Lücken, die den Zeitplan sprengen.

     

    Warum Informationssicherheit in der Automobilindustrie den Marktzugang bestimmt

    Ein einzelnes Fahrzeugprojekt bindet mehrere hundert Partner ein, und jeder davon ist ein möglicher Zugangsweg zu den Daten des Herstellers. Da ein OEM sie nicht alle selbst auditieren kann, verlagert er die Nachweispflicht: Der Lieferant belegt sein Sicherheitsniveau in einer Form, die der Hersteller ohne eigenen Prüfaufwand anerkennt.

    Vier Treiber machen das Thema hier besonders scharf:

    • Vorserien- und Entwicklungsdaten: CAD-Modelle, Lastenhefte und Erprobungsergebnisse sind vor der Markteinführung hochsensibel.
    • Prototypenschutz: Bauteile, Erprobungsfahrzeuge und Fotoshootings verlangen physische Maßnahmen von der Zutrittskontrolle bis zum Fotografierverbot. Dafür gibt es im VDA ISA ein eigenes Modul.
    • Fertigung und OT: Produktionsanlagen laufen Jahrzehnte, oft mit Steuerungen ohne Sicherheitsupdates. Ein Stillstand trifft sofort die Bänder des Kunden.
    • Vernetzte Fahrzeuge: Software wird über die Luft aktualisiert, Fahrzeugdaten fließen in Backends. Damit wird der Update-Prozess selbst zum regulierten Gegenstand.

    Betroffen sind deshalb nicht nur Teilefertiger, sondern ebenso Ingenieur- und IT-Dienstleister, Prüflabore, Logistiker, Werkzeugbauer und Agenturen. Entscheidend ist nicht die Branche, sondern der Zugriff auf schützenswerte Informationen des Auftraggebers.

     

    VDA ISA und TISAX: der Branchenrahmen

    Hinter dem Nachweis stehen zwei Bausteine, die oft verwechselt werden. Der VDA ISA (Information Security Assessment) ist der Prüfkatalog des Verbands der Automobilindustrie, gegliedert in die Module Informationssicherheit, Prototypenschutz und Datenschutz. TISAX (Trusted Information Security Assessment Exchange) ist das Prüf- und Austauschverfahren der ENX Association: Es regelt, wer prüfen darf, wie geprüft wird und wie das Ergebnis mit Geschäftspartnern geteilt wird.

    Für die Planung wichtig ist der Versionswechsel. Gültige Katalogfassung ist die Version 6.0.3, maßgeblich für alle seit dem 1. April 2024 beauftragten Assessments. Am 1. Juli 2026 haben VDA und ENX den Nachfolger ISA2027 veröffentlicht, der für alle ab dem 1. Januar 2027 beauftragten Assessments gilt. Er bringt aktualisierte Zuordnungen zur ISO/IEC 27001:2022 und zum NIST Cybersecurity Framework 2.0, erweiterte Anforderungen an die Lieferkettensicherheit sowie ein neu strukturiertes Prototypenschutz-Modul mit Vorgaben zur Rückverfolgbarkeit geschützter Bauteile. Bereits erteilte Labels behalten ihre volle Laufzeit. Welche Anforderungen dahinterstehen, zeigen die TISAX-Anforderungen im Überblick.

    Assessment Level: Schutzbedarf bestimmt die Prüftiefe

    Wie tief geprüft wird, hängt nicht vom Wunsch des Unternehmens ab, sondern vom Schutzbedarf der verarbeiteten Informationen. Höhere Level schließen die niedrigeren mit ein.

    Assessment Level Schutzbedarf Prüfmethodik
    AL 1 intern Reine Selbsteinschätzung, der Prüfer kontrolliert nur die Vollständigkeit. Wegen geringer Aussagekraft im TISAX-Verfahren nicht genutzt.
    AL 2 hoch Selbsteinschätzung, Prüfung eingereichter Nachweise und Interview mit den Verantwortlichen, in der Regel als Webkonferenz.
    AL 3 sehr hoch Zusätzlich Vor-Ort-Prüfung: Begehung, Beobachtung laufender Prozesse sowie geplante und ungeplante Interviews mit Prozessbeteiligten.

    Der Sprung von Stufe 2 auf Stufe 3 ist der aufwendigste Schritt, weil dort gelebte Praxis statt Dokumenten geprüft wird. Was das für einen Standort bedeutet, zeigt der Beitrag zu den Anforderungen an TISAX Level 3.

    Labels, Reifegrad und Gültigkeit

    Am Ende steht kein Zertifikat, sondern ein Prüfbericht mit Labels, die sich immer auf einen definierten Scope aus Standorten und Prüfzielen beziehen. Das Teilnehmerhandbuch führt derzeit zwölf Labels in drei Bereichen: Informationssicherheit, unterschieden nach Vertraulichkeit (Confidential, Strictly confidential) und Verfügbarkeit (High availability, Very high availability), Prototypenschutz (Proto parts, Proto vehicles, Test vehicles, Proto events) sowie Datenschutz (Data, Special data). Die älteren Labels „Info high“ und „Info very high“ bleiben gültig, solange ihre Laufzeit reicht.

    Das Prüfergebnis ist drei Jahre gültig. Jährliche Überwachungsaudits gibt es nicht, die Verlängerung erfolgt über ein erneutes Assessment. Bei Abweichungen folgt ein Maßnahmenplan mit Nachprüfung, teils begleitet von einem temporären Label. Bewertet wird jedes Prüfziel über ein Reifegradmodell von 0 bis 5, Zielwert ist Reifegrad 3: ein etablierter, standardisiert angewendeter Prozess. Dokumentation allein genügt nicht.

     

    TrustSpace Profi-Tipp: Den Scope klären, bevor Sie beauftragen

    Der teuerste Fehler passiert vor dem ersten Audittag: ein zu weit gefasster Prüf-Scope. Wer vorsorglich alle Standorte und das höchste Prüfziel anmeldet, zahlt für Anforderungen, die kein Kunde verlangt. Klären Sie deshalb schriftlich mit dem Kunden, welches Prüfziel, welcher Standort und welches Assessment Level gefordert sind, und leiten Sie erst daraus den Umfang ab. Ein enger Scope lässt sich später erweitern, ein überdehnter nur schwer zurücknehmen.

     

    TISAX und ISO 27001: Abgrenzung und Zusammenspiel

    Viele Zulieferer sind bereits nach ISO/IEC 27001 zertifiziert und fragen zu Recht, ob damit nicht alles erledigt ist. Die Norm ist eine gute Grundlage, ersetzt das TISAX-Verfahren aber nicht. Der VDA ISA ist eng an sie angelehnt, geht in branchenspezifischen Punkten darüber hinaus und prüft zusätzlich die Verankerung im Alltag.

    Kriterium ISO/IEC 27001 TISAX
    Geltungsbereich Branchenübergreifend Automobilindustrie und ihre Lieferkette
    Ergebnis Zertifikat einer akkreditierten Stelle, frei vorzeigbar Prüfbericht und Labels, Freigabe gezielt über das ENX-Portal
    Prüfmaßstab Erfüllung der Normanforderungen und ausgewählten Maßnahmen Reifegrad je Prüfziel, Zielwert 3 (etabliert)
    Laufzeit Drei Jahre mit jährlichen Überwachungsaudits Drei Jahre ohne Überwachungsaudits, danach erneutes Assessment
    Zusatzthemen Keine branchenspezifischen Module Eigene Module für Prototypenschutz und Datenschutz

    In der Praxis ist die Kombination der Regelfall: Die ISO 27001 liefert Struktur, Risikoprozess, Rollen und Dokumentenlenkung, TISAX setzt die branchenspezifischen Anforderungen obendrauf. Eine ausführliche Gegenüberstellung bietet der Beitrag zum Unterschied zwischen TISAX und ISO 27001. Prüfen Sie parallel Ihr Lieferantenmanagement nach ISO 27001, denn dieselbe Nachweislogik reichen OEM und Systemlieferanten in die zweite und dritte Lieferantenebene weiter.

     

    UNECE R155/R156, ISO/SAE 21434 und NIS2 richtig einordnen

    Neben TISAX kursieren weitere Kürzel mit unterschiedlichen Adressaten. Die Unterscheidung erspart unnötige Projekte.

    Fahrzeug-Cybersicherheit: R155, R156 und ISO/SAE 21434

    Die UN-Regelungen R155 und R156 richten sich an die Typgenehmigung von Fahrzeugen. R155 verlangt ein Cyber Security Management System (CSMS) über den gesamten Fahrzeuglebenszyklus, R156 ein Software Update Management System (SUMS) für Aktualisierungen im Feld. Beide traten im Januar 2021 in Kraft, sind seit Juli 2022 für neue Fahrzeugtypen verbindlich und gelten seit dem 7. Juli 2024 für alle neu zugelassenen Fahrzeuge in der EU. Die ISO/SAE 21434 liefert dazu den technischen Umsetzungsrahmen für die Entwicklung.

    Adressat ist der Hersteller. Für Zulieferer entsteht die Pflicht mittelbar: Wer Steuergeräte, Software oder sicherheitsrelevante Komponenten liefert, muss belegen, dass die eigene Entwicklung den CSMS-Nachweis des OEM trägt. Ohne Elektronik- oder Softwareanteil im Produkt bleibt TISAX das maßgebliche Thema.

    NIS2: seit Dezember 2025 geltendes Recht

    Anders als die kundengetriebenen Anforderungen ist NIS2 eine gesetzliche Pflicht. Das deutsche NIS-2-Umsetzungsgesetz wurde am 5. Dezember 2025 verkündet und ist seit dem 6. Dezember 2025 in Kraft, ohne allgemeine Übergangsfrist. Das BSI schätzt den Kreis der erfassten Einrichtungen auf rund 29.500. Für die Branche entscheidend: Anlage 2 des BSIG führt unter Nummer 5.5 die Herstellung von Kraftwagen und Kraftwagenteilen nach NACE Rev. 2, Abteilung 29 als Sektor wichtiger Einrichtungen. Erfasst sind Unternehmen ab 50 Beschäftigten beziehungsweise mit mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme.

    Daraus folgen die Registrierung beim BSI über dessen Melde- und Informationsportal, das am 6. Januar 2026 geöffnet wurde, Risikomanagementmaßnahmen einschließlich Lieferkettensicherheit sowie eine gestufte Meldepflicht: Erstmeldung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats. Hinzu kommt die ausdrückliche Verantwortung der Geschäftsleitung. Ein funktionierendes Managementsystem deckt einen erheblichen Teil dieser Pflichten ab, Registrierung und Meldeprozesse müssen aber gesondert aufgesetzt werden.

     

    Produktion und OT: die zweite Baustelle

    Wer Informationssicherheit nur als Büro-IT denkt, übersieht bei Zulieferern den wirtschaftlich kritischsten Teil. In der Fertigung stehen Steuerungen aus einer Zeit, in der Netzwerkanbindung die Ausnahme war. Sie lassen sich nicht patchen, weil Herstellerfreigaben fehlen oder die Anlage stillstehen müsste.

    Bewährt haben sich Maßnahmen, die den Betrieb nicht anfassen, aber die Angriffsfläche verkleinern: Trennung von Office- und Produktionsnetz, Zonen und Übergänge nach dem Vorbild der Normenreihe IEC 62443, kontrollierte und protokollierte Fernwartungszugänge statt dauerhaft offener Verbindungen, ein vollständiges Anlageninventar samt Firmware-Ständen sowie getestete Wiederanlaufpläne. Letztere zahlen auf die Verfügbarkeits-Labels ein und liefern das Argument, das in der Geschäftsführung am schnellsten verfängt: Nicht der Datenabfluss, sondern der Bandstillstand beim Kunden ist das teuerste Szenario.

     

    TrustSpace Profi-Tipp: Nachweise entstehen im Betrieb, nicht im Audit

    Reifegrad 3 verlangt Prozesse, die nachweislich laufen. Daran scheitern Vorbereitungen, die auf Dokumente im Laufwerk setzen: Die Richtlinie existiert, der Beleg für ihre Anwendung fehlt. Eine TrustSpace ISMS-Software verknüpft Assets, Risiken und Maßnahmen, hinterlegt zu jeder Aufgabe Verantwortliche und Fristen und protokolliert die Erledigung fortlaufend. Damit ist der Nachweis am Audittag ein Auszug aus dem laufenden Betrieb statt einer Sammelaktion in den letzten vier Wochen.

     

    Typische Lücken bei Zulieferern

    Über Assessments hinweg wiederholen sich dieselben Befunde:

    1. Unvollständiges Informations- und Asset-Inventar:
    Ohne Übersicht über Systeme und die darauf verarbeiteten Kundendaten lässt sich weder ein Schutzbedarf begründen noch ein Scope abgrenzen.

    2. Prototypenschutz nur auf dem Papier:
    Zutrittsregelungen, Besucherbegleitung, Fotoverbote und die Absicherung von Transport und Entsorgung werden vor Ort geprüft, nicht in einer Richtlinie.

    3. Zugriffsrechte ohne Nachweis:
    Berechtigungen wachsen mit jeder Versetzung. Ohne dokumentierte Vergabe, regelmäßige Prüfung und sauberen Austrittsprozess ist der Befund sicher.

    4. Ungeregelte Weitergabe an Unterauftragnehmer:
    Kundendaten landen bei Konstruktionsbüros oder Cloud-Diensten, ohne dass Anforderungen vertraglich weitergereicht und überprüft werden.

    5. Ungetestete Notfallplanung:
    Ein Wiederanlaufplan, der nie geprobt wurde, ist im Ernstfall wertlos.

     

    Der Weg zum Nachweis in sechs Schritten

    • Anforderung klären: Prüfziel, Assessment Level, Standorte und Frist mit dem Kunden abstimmen.
    • Registrieren: Als Teilnehmer bei der ENX Association anmelden und den Prüf-Scope festlegen.
    • Selbsteinschätzung: Den VDA ISA durcharbeiten und je Prüfziel den Ist-Reifegrad ehrlich bewerten. Das ist die eigentliche Gap-Analyse.
    • Lücken schließen: Maßnahmen mit Verantwortlichen und Terminen umsetzen, zuerst dort, wo der Zielreifegrad verfehlt wird.
    • Assessment: Einen von der ENX zugelassenen Prüfdienstleister beauftragen; bei Abweichungen folgt der Maßnahmenplan mit Nachprüfung.
    • Freigeben und betreiben: Das Label im ENX-Portal für die anfragenden Partner freigeben und das Managementsystem im Regelbetrieb halten.

    Am häufigsten unterschätzt wird der vierte Schritt. Zwischen der ersten realistischen Selbsteinschätzung und einem prüffähigen Stand liegen typischerweise mehrere Monate, in denen Richtlinien nicht nur geschrieben, sondern eingeführt, geschult und angewendet werden. Wer diese Zeit wegen einer Kundenfrist nicht hat, holt sich Unterstützung: Die TISAX-Beratung von TrustSpace begleitet Scope-Definition, Gap-Analyse und Umsetzung bis zum Assessment.

     

    Fazit: Ein Managementsystem, mehrere Nachweise

    Informationssicherheit in der Automobilindustrie ist eine Marktzugangsfrage: Der Nachweis wird vom Kunden verlangt und entscheidet darüber, ob ein Zulieferer im Projekt bleibt. Der Rahmen ist klar abgesteckt: Der VDA ISA definiert die Anforderungen, TISAX organisiert Prüfung und Austausch, der Schutzbedarf bestimmt die Prüftiefe, der Reifegrad entscheidet über das Bestehen.

    Wer die Aufgabe strategisch angeht, baut nicht drei Projekte parallel, sondern ein Managementsystem, aus dem sich mehrere Nachweise bedienen lassen: die ISO 27001 als Struktur, TISAX als branchenspezifische Ergänzung, NIS2 als gesetzliche Pflicht mit eigenen Melde- und Registrierungsauflagen. Der Wechsel auf ISA2027 zum Jahresbeginn 2027 ist ein guter Anlass, den eigenen Stand zu prüfen, vor allem bei den erweiterten Anforderungen an die Lieferkette.

     

    Häufige Fragen (FAQ)

    Braucht jeder Automobilzulieferer ein TISAX-Label?

    Nein. Die Anforderung entsteht durch den Kunden, nicht durch ein Gesetz. Sie trifft alle Unternehmen, die auf schützenswerte Informationen, Prototypen oder personenbezogene Daten eines Herstellers oder Systemlieferanten zugreifen. Mit welchem Prüfziel ein Label gefordert wird, steht in der Anfrage oder im Vertrag des Auftraggebers.

    Ersetzt eine ISO-27001-Zertifizierung das TISAX-Assessment?

    Nein. Der VDA ISA ist eng an die ISO/IEC 27001 angelehnt, prüft aber zusätzlich branchenspezifische Themen wie Prototypenschutz sowie den Reifegrad der Prozesse. Ein bestehendes ISO-27001-Managementsystem verkürzt die Vorbereitung jedoch spürbar.

    Wie lange ist ein TISAX-Label gültig?

    Das Prüfergebnis ist drei Jahre gültig. Jährliche Überwachungsaudits wie bei der ISO 27001 gibt es nicht, die Verlängerung erfolgt über ein erneutes Assessment. Planen Sie den Wiederholungstermin ohne Lücke in der Gültigkeit.

    Was ändert sich mit ISA2027?

    ISA2027 wurde am 1. Juli 2026 veröffentlicht und gilt für alle Assessments, die ab dem 1. Januar 2027 beauftragt werden. Er löst die Version 6.0.3 ab, aktualisiert die Zuordnungen zur ISO/IEC 27001:2022 und zum NIST Cybersecurity Framework 2.0, erweitert die Lieferkettenanforderungen und strukturiert den Prototypenschutz neu. Bereits erteilte Labels behalten ihre Laufzeit.

    Betrifft NIS2 auch Automobilzulieferer?

    Ja, sofern sie unter die im BSIG genannten Sektoren fallen. Anlage 2 führt unter Nummer 5.5 die Herstellung von Kraftwagen und Kraftwagenteilen nach NACE Rev. 2, Abteilung 29 als Sektor wichtiger Einrichtungen auf. Hinzu kommen die Größenkriterien ab 50 Beschäftigten beziehungsweise mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme. Dienstleister ohne Fertigung sollten ihre Betroffenheit einzeln prüfen.

  • Cyber Resilience Act umsetzen: Roadmap in klaren Schritten

    Cyber Resilience Act umsetzen: Roadmap in klaren Schritten

    Das Wichtigste in Kürze

    • Rechtsnatur: Der Cyber Resilience Act ist die Verordnung (EU) 2024/2847 und gilt EU-weit unmittelbar. Eine nationale Umsetzung ist nicht nötig, in Deutschland überwacht das BSI die Einhaltung.
    • Zwei Fristen takten den Fahrplan: Die Melde- und Berichtspflichten greifen ab dem 11. September 2026, die volle Anwendung folgt am 11. Dezember 2027.
    • Roadmap in sechs Phasen: von Produktinventar über Risikobewertung und Security by Design bis zum laufenden Post-Market-Monitoring.
    • Konformitätsbewertung: Standardprodukte dürfen sich selbst bewerten, wichtige Produkte der Klasse II und kritische Produkte müssen zwingend über eine notifizierte Stelle.
    • Lieferkette: Lieferantenselbstauskunft und Komponenten-SBOM einfordern, denn fremder Code in Ihrem Produkt wird zu Ihrer Verantwortung.
    • Bußgeldrahmen: bis zu 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, was höher ist.

     

    Der Cyber Resilience Act, auf Deutsch auch Cyberresilienz-Verordnung genannt, verpflichtet erstmals alle Hersteller, Importeure und Händler von Produkten mit digitalen Elementen zu einem Mindestmaß an Cybersicherheit über den gesamten Produktlebenszyklus. Die Fristen laufen, und die eigentliche Frage lautet für die meisten Unternehmen längst nicht mehr ob, sondern wie sie den Cyber Resilience Act umsetzen. Ohne strukturierten Fahrplan zerfasert das Vorhaben schnell in eine unübersichtliche Sammlung von Einzelmaßnahmen.

    Dieser Leitfaden liefert genau diesen Fahrplan: eine Roadmap in sechs klaren Phasen, von der ersten Bestandsaufnahme bis zur laufenden Marktüberwachung, jeweils mit Ziel, konkreten Aufgaben, typischer Dauer und Verantwortlichen. Dazu klären wir die zwei Punkte, an denen sich die meisten Fragen entzünden: Selbstbewertung oder notifizierte Stelle sowie die Einbindung der Lieferkette. Wer eine strukturierte Unterstützung bei der CRA-Umsetzung sucht, findet hier die inhaltliche Grundlage.

     

    „Nationale Umsetzung“ des Cyber Resilience Act? Ein verbreitetes Missverständnis

    Ein häufig gesuchter Begriff ist die „nationale Umsetzung“ des Cyber Resilience Act. Er trifft die Rechtslage nicht ganz: Der CRA ist eine EU-Verordnung, keine Richtlinie. Verordnungen gelten in allen Mitgliedstaaten unmittelbar und müssen nicht erst durch ein nationales Gesetz in deutsches Recht überführt werden. Anders als bei der NIS2-Richtlinie, die auf ihr deutsches Umsetzungsgesetz wartet, gibt es beim CRA also keine nationale Umsetzung, auf die man warten könnte. Die Pflichten aus der Verordnung (EU) 2024/2847 gelten für jeden betroffenen Hersteller in der Union nach demselben Wortlaut.

    Was national sehr wohl geregelt wird, sind die Zuständigkeiten für Marktüberwachung und Durchsetzung. In Deutschland übernimmt das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine Doppelrolle: als Marktüberwachungsbehörde und als notifizierende Behörde, die ab 2026 die Konformitätsbewertungsstellen benennt. Es kann Korrekturmaßnahmen verlangen, Produkte einschränken, vom Markt nehmen oder zurückrufen und Bußgelder verhängen. Deutschland setzt die europäischen Vorgaben eins zu eins um und verzichtet auf nationale Sonderregeln. Sie richten sich also direkt nach dem Verordnungstext, nicht nach einem noch ausstehenden deutschen Gesetz.

     

    Zwei Fristen bestimmen die Reihenfolge

    Bevor die Roadmap beginnt, lohnt der Blick auf den Zeitplan, denn er entscheidet über die Priorisierung. Der CRA ist am 10. Dezember 2024 in Kraft getreten, seine Pflichten greifen aber gestaffelt.

    Datum Was gilt ab dann
    11. September 2026 Melde- und Berichtspflichten (Art. 14): aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen gemeldet werden, die erste Frühwarnung binnen 24 Stunden.
    11. Dezember 2027 Volle Anwendung: alle grundlegenden Anforderungen, Konformitätsbewertung, CE-Kennzeichnung und technische Dokumentation müssen erfüllt sein.

    Daraus folgt eine klare Priorisierung: Die Meldeprozesse kommen zuerst. Wer erst ab Ende 2027 an CE und Konformität denkt, übersieht, dass die 24-Stunden-Meldepflicht über ein Jahr früher scharf geschaltet wird und bereits im Sommer 2026 stehen muss.

     

    Die CRA-Roadmap in sechs Phasen

    Die folgende Roadmap gliedert die Umsetzung in sechs aufeinander aufbauende Phasen. Die Zeitangaben sind Erfahrungswerte für ein mittelständisches Portfolio und variieren mit Zahl und Komplexität der Produkte.

    Phase Ziel Typische Dauer Verantwortliche
    1. Produktinventar & Betroffenheit Alle Produkte mit digitalen Elementen erfassen, Betroffenheit und Risikoklasse bestimmen 2–3 Wochen Produktmanagement, Compliance
    2. Gap-Analyse (Annex I) Ist-Zustand gegen die grundlegenden Anforderungen abgleichen, Lücken dokumentieren 2–3 Wochen Security, Entwicklung
    3. Risikobewertung Cybersicherheitsrisiken je Produkt analysieren, Schutzmaßnahmen ableiten 2–4 Wochen Security, Produktmanagement
    4. Security by Design & Prozesse Schwachstellenmanagement, SBOM, Update- und Meldeprozesse aufbauen und in die Entwicklung integrieren 2–9 Monate Entwicklung, Security, DevOps
    5. Doku, Konformität & CE Technische Dokumentation erstellen, Konformität bewerten, EU-Konformitätserklärung und CE-Kennzeichnung 5–14 Wochen Compliance, QA, ggf. notifizierte Stelle
    6. Post-Market-Compliance Monitoring, Sicherheitsupdates, Meldepflichten dauerhaft erfüllen laufend Security, Support, PSIRT

    Phase 1: Produktinventar und Betroffenheitsanalyse

    Ziel der ersten Phase ist ein vollständiges Bild darüber, welche Ihrer Produkte überhaupt in den Anwendungsbereich fallen. Erfasst wird jedes Produkt mit digitalen Elementen, also Hardware und Software mit direkter oder indirekter Datenverbindung zu einem Gerät oder Netz. Zu jedem Produkt gehört die Einordnung in eine Risikoklasse (Standard, wichtig, kritisch), denn davon hängt der spätere Konformitätsweg ab. Eine erste Orientierung, ob und wie stark Ihr Portfolio betroffen ist, liefert der Betroffenheits-Check zum Cyber Resilience Act. Verantwortlich sind Produktmanagement und Compliance, die typische Dauer liegt bei zwei bis drei Wochen.

    Phase 2: Gap-Analyse gegen Annex I

    In Phase 2 wird jedes betroffene Produkt gegen die grundlegenden Cybersicherheitsanforderungen aus Annex I abgeglichen. Annex I hat zwei Teile: Teil I beschreibt die Produkteigenschaften (etwa sichere Standardkonfiguration, Schutz von Vertraulichkeit und Integrität, minimierte Angriffsfläche), Teil II den Umgang mit Schwachstellen über den Support-Zeitraum. Ergebnis ist eine dokumentierte Lückenliste je Produkt: Was ist erfüllt, was fehlt, wo besteht Handlungsbedarf. Welche Pflichten im Einzelnen dahinterstehen, führt der Beitrag zu den CRA-Pflichten aus Annex I aus. Zuständig sind Security und Entwicklung, üblich sind zwei bis drei Wochen.

    Phase 3: Risikobewertung je Produkt

    Die Verordnung verlangt, dass Hersteller eine Cybersicherheits-Risikobewertung durchführen und deren Ergebnis in die Gestaltung des Produkts einfließen lassen. In dieser Phase werden je Produkt die relevanten Bedrohungen modelliert, mögliche Angriffswege bewertet und daraus die notwendigen Schutzmaßnahmen abgeleitet. Die Risikobewertung ist kein Selbstzweck, sondern die Begründung für die gewählten Sicherheitsfunktionen, und wird Teil der technischen Dokumentation. Verantwortlich sind Security und Produktmanagement, die typische Dauer beträgt zwei bis vier Wochen.

    Phase 4: Security by Design und die Kernprozesse

    Phase 4 ist das Herzstück und regelmäßig die längste Etappe, weil hier aus Analyse konkrete Technik und gelebte Prozesse werden. Die Anforderungen aus Annex I werden in Produktentwicklung und Lieferkette verankert, inklusive secure defaults, Update-Mechanismen und Härtung. Drei Prozesse verdienen besondere Aufmerksamkeit:

    • Schwachstellenmanagement: ein fortlaufender Prozess, der Schwachstellen in eigenen und fremden Komponenten identifiziert, bewertet, behebt und die Behebung nachweist, über den gesamten Support-Zeitraum.
    • SBOM (Software Bill of Materials): eine Stückliste der Softwarekomponenten in einem gängigen, maschinenlesbaren Format, die laut Annex I mindestens die Abhängigkeiten oberster Ebene abdeckt und aktuell gehalten wird.
    • Meldeprozesse: ein einsatzbereiter Ablauf, um aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle fristgerecht zu melden. Dieser Prozess sollte wegen der Frist 11. September 2026 vorgezogen werden.

    Der Support-Zeitraum für Sicherheitsupdates bemisst sich an der erwarteten Nutzungsdauer und beträgt in der Regel mindestens fünf Jahre, sofern die Nutzung nicht kürzer ist. Verantwortlich sind Entwicklung, Security und DevOps, die Dauer reicht je nach Produkt von zwei bis neun Monaten.

    Phase 5: Technische Dokumentation, Konformitätsbewertung und CE

    In Phase 5 wird das Erreichte prüf- und nachweisbar gemacht. Zunächst entsteht die technische Dokumentation, die Risikobewertung, SBOM, Sicherheitsmaßnahmen und Testnachweise bündelt und der Marktüberwachung auf Verlangen vorgelegt wird. Darauf folgen die Konformitätsbewertung (Selbstbewertung oder notifizierte Stelle, siehe unten), die EU-Konformitätserklärung und die CE-Kennzeichnung, mit der das Produkt in Verkehr gebracht werden darf. Verantwortlich sind Compliance und QA, bei bewertungspflichtigen Produkten zusätzlich eine notifizierte Stelle. Rechnen Sie mit drei bis sechs Wochen für die Dokumentation und zwei bis acht Wochen für die Bewertung.

    Phase 6: Post-Market-Compliance

    Mit dem CE-Zeichen ist die Arbeit nicht beendet, sondern verlagert sich in den Dauerbetrieb. In Phase 6 überwachen Sie Ihre Produkte am Markt fortlaufend auf neue Schwachstellen, stellen kostenfreie Sicherheitsupdates über den Support-Zeitraum bereit und halten die Meldepflichten ein: die 24-Stunden-Frühwarnung an das zuständige CSIRT und ENISA über die zentrale Meldeplattform, gefolgt von einer Meldung binnen 72 Stunden und einem Abschlussbericht. Diese Phase läuft ohne Ende und braucht feste Zuständigkeiten, idealerweise ein Product Security Incident Response Team (PSIRT).

     

    TrustSpace Profi-Tipp: Meldeprozesse zuerst, nicht CE zuerst

    Viele Roadmaps stellen den Meldeprozess ans Ende, weil er in Phase 6 lebt. Das ist ein Fristen-Fehler, denn die 24-Stunden-Meldepflicht gilt ab dem 11. September 2026, mehr als ein Jahr vor der vollen Anwendung. Ziehen Sie den Aufbau eines belastbaren Melde-Workflows deshalb parallel zu Phase 4 vor: Wer meldet an wen, über welche Plattform, mit welchen Eskalationsstufen? So ist der zeitkritischste Baustein einsatzbereit, bevor der Rest der Konformitätsarbeit steht.

     

    Selbstbewertung oder notifizierte Stelle? Der Weg hängt von der Produktklasse ab

    Eine der meistgestellten Fragen betrifft den Konformitätsweg: selbst bewerten oder durch eine notifizierte Stelle prüfen lassen? Die Antwort ergibt sich aus Art. 32 und Annex VIII und hängt an der Risikoklasse des Produkts.

    Produktklasse Beispiele Konformitätsweg
    Standardprodukte (Mehrheit) Textverarbeitung, Foto-Apps, smarte Lautsprecher, Festplatten, Spiele Selbstbewertung über die interne Kontrolle (Modul A)
    Wichtige Produkte, Klasse I (Annex III) Passwort- und Identitätsmanager, Betriebssysteme, Router, VPN, Virenschutz, SIEM Selbstbewertung nur bei vollständiger Anwendung harmonisierter Normen, sonst notifizierte Stelle (Modul B+C oder H)
    Wichtige Produkte, Klasse II (Annex III) Firewalls, IDS/IPS, Hypervisoren, Container-Runtimes, manipulationssichere Mikroprozessoren Immer notifizierte Stelle (Modul B+C oder H) — harmonisierte Normen ändern das nicht
    Kritische Produkte (Annex IV) Hardware-Sicherheitsmodule, Smartcards, Smart-Meter-Gateways Höchste Stufe: gegebenenfalls verpflichtendes europäisches Cybersicherheits-Zertifizierungsschema

    Die drei Verfahren aus Annex VIII: Modul A ist die interne Kontrolle, also die reine Selbstbewertung ohne externe Beteiligung. Modul B+C kombiniert eine EU-Baumusterprüfung durch eine notifizierte Stelle (B) mit der Produktkonformität auf Basis interner Fertigungskontrolle (C). Modul H ist die umfassende Qualitätssicherung, bei der die notifizierte Stelle das Qualitätsmanagementsystem des Herstellers bewertet. Sobald ein Produkt in die Klasse II der wichtigen oder in die kritischen Produkte fällt, führt kein Weg an einer notifizierten Stelle vorbei, selbst bei vollständiger Anwendung harmonisierter Normen.

     

    Die Lieferkette einbinden: Selbstauskunft und Komponenten-SBOM

    Kaum ein Produkt besteht heute vollständig aus Eigenentwicklung. Fremde Bibliotheken, Open-Source-Komponenten und zugelieferte Module stecken in nahezu jeder Software. Der Cyber Resilience Act macht Sie als Hersteller des Endprodukts für dessen gesamte Cybersicherheit verantwortlich, einschließlich der Fremdkomponenten. Fremder Code wird damit zu Ihrer Verantwortung, und die Lieferkette ist ein eigener Arbeitsstrang der Umsetzung.

    Zwei Instrumente sind hier zentral. Erstens die Lieferantenselbstauskunft: eine strukturierte Abfrage bei jedem Zulieferer, wie er die CRA-relevanten Anforderungen erfüllt, ob und wie lange er Sicherheitsupdates liefert und wie er mit Schwachstellen umgeht. Zweitens die Komponenten-SBOM: eine maschinenlesbare Stückliste der in den zugelieferten Komponenten enthaltenen Softwarebestandteile. Nur so können Sie beim Bekanntwerden einer Schwachstelle in einer weit verbreiteten Bibliothek innerhalb von Stunden beantworten, ob und wo Ihr Produkt betroffen ist. Beides gehört vertraglich verankert, denn ohne Mitwirkung der Lieferanten bleiben blinde Flecken, für die am Ende Sie geradestehen.

     

    TrustSpace Profi-Tipp: Die Roadmap braucht ein System, keine Tabellensammlung

    Produktinventar, Gap-Analyse, Risikobewertung, Schwachstellen, SBOM, Meldeprozesse und Dokumentation lassen sich theoretisch in Tabellen führen, verlieren dort aber schnell den Zusammenhang. Genau diese Prozesse strukturiert die TrustSpace ISMS-Software: Sie verknüpft Assets mit Risiken, Schwachstellen und Maßnahmen, vergibt Verantwortlichkeiten samt Fristen und stellt Vorlagen für technische Dokumentation und Konformitätserklärung bereit. So wird aus der sechsphasigen Roadmap ein steuerbarer, jederzeit nachweisbarer Prozess, der den Dokumentationsaufwand spürbar senkt.

     

    Fazit: Umsetzung ist Prozess, nicht Projekt

    Den Cyber Resilience Act umzusetzen ist kein einmaliges Projekt mit Enddatum, sondern der Aufbau dauerhafter Fähigkeiten. Die sechs Phasen geben die Reihenfolge vor, doch sie ist nicht starr: Der Meldeprozess muss wegen der Frist 11. September 2026 vorgezogen werden, die volle Konformität mit CE-Kennzeichnung folgt bis zum 11. Dezember 2027. Wer früh mit einem vollständigen Produktinventar und einer sauberen Klassifizierung beginnt, verschafft sich den größten Vorteil, denn davon hängen Gap-Analyse, Risikobewertung und Konformitätsweg ab.

    Entscheidend ist, die Umsetzung als zusammenhängenden Prozess zu führen, nicht als Sammlung isolierter Aufgaben. Mit einer klaren Roadmap, vorgezogenen Meldeprozessen und werkzeuggestützter Steuerung wird aus einer regulatorischen Pflicht ein belastbarer Baustein Ihrer Produktsicherheit.

     

    Häufige Fragen (FAQ)

    Braucht der Cyber Resilience Act eine nationale Umsetzung in Deutschland?

    Nein. Der Cyber Resilience Act ist eine EU-Verordnung (Verordnung (EU) 2024/2847) und gilt in allen Mitgliedstaaten unmittelbar, ohne ein nationales Umsetzungsgesetz. National geregelt werden nur die Zuständigkeiten für Marktüberwachung und Durchsetzung. In Deutschland übernimmt das BSI die Rolle der Marktüberwachungs- und notifizierenden Behörde.

    Ab wann gelten welche Pflichten des Cyber Resilience Act?

    Der CRA ist am 10. Dezember 2024 in Kraft getreten. Die Melde- und Berichtspflichten gelten ab dem 11. September 2026, darunter die Pflicht, aktiv ausgenutzte Schwachstellen binnen 24 Stunden zu melden. Die volle Anwendung mit allen grundlegenden Anforderungen, Konformitätsbewertung und CE-Kennzeichnung folgt am 11. Dezember 2027.

    Wann darf ich mein Produkt selbst bewerten und wann muss eine notifizierte Stelle prüfen?

    Standardprodukte, also die große Mehrheit, dürfen sich per interner Kontrolle (Modul A) selbst bewerten. Wichtige Produkte der Klasse I dürfen das nur bei vollständiger Anwendung harmonisierter Normen, sonst ist eine notifizierte Stelle nötig. Wichtige Produkte der Klasse II und kritische Produkte müssen in jedem Fall über eine notifizierte Stelle beziehungsweise ein Zertifizierungsschema.

    Was ist eine SBOM und fordert der Cyber Resilience Act sie verpflichtend?

    Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste aller Softwarekomponenten eines Produkts. Der CRA verlangt in Annex I, dass Hersteller mindestens die Abhängigkeiten oberster Ebene in einem gängigen, maschinenlesbaren Format dokumentieren und aktuell halten. Die SBOM ist Teil der technischen Dokumentation und wird den Marktüberwachungsbehörden auf Verlangen vorgelegt, sie muss aber nicht zwingend öffentlich sein.

    Wie binde ich meine Lieferanten in die CRA-Umsetzung ein?

    Über zwei Instrumente: eine Lieferantenselbstauskunft zu den CRA-Anforderungen und zur Update-Versorgung sowie eine Komponenten-SBOM, die die Softwarebestandteile der zugelieferten Komponenten offenlegt. Beides gehört vertraglich verankert, denn als Hersteller des Endprodukts haften Sie auch für die integrierten Fremdkomponenten.

  • EU AI Act Risikostufen: Welche Pflichten gelten für welche KI-Kategorie?

    EU AI Act Risikostufen: Welche Pflichten gelten für welche KI-Kategorie?

    Das Wichtigste in Kürze

    • Der EU AI Act (Verordnung (EU) 2024/1689) ist das weltweit erste umfassende Gesetz zur Regulierung künstlicher Intelligenz und tritt stufenweise in Kraft.
    • Das Gesetz basiert auf einem risikobasierten Ansatz mit vier Risikostufen: verbotene Praktiken, Hochrisiko-KI, KI mit begrenztem Risiko und KI mit minimalem Risiko.
    • Für Hochrisiko-KI-Systeme gelten die umfangreichsten Pflichten: Risikomanagement, Datenqualität, technische Dokumentation, Transparenz und menschliche Aufsicht.
    • Verstöße gegen das Verbot bestimmter KI-Praktiken können mit Bußgeldern von bis zu 35 Millionen Euro oder 7 % des Jahresumsatzes geahndet werden.
    • Unternehmen sollten jetzt ihre KI-Systeme klassifizieren und Compliance-Maßnahmen einleiten.

     

    Der EU AI Act: Ein neues Regelwerk für künstliche Intelligenz

    Am 1. August 2024 ist der EU AI Act (Verordnung (EU) 2024/1689) in Kraft getreten. Mit diesem Gesetz hat die Europäische Union das weltweit erste umfassende Regelwerk für künstliche Intelligenz geschaffen. Das Ziel: Innovation fördern und gleichzeitig Grundrechte, Sicherheit und ethische Grundsätze schützen.

    Der AI Act verfolgt einen risikobasierten Regulierungsansatz. Je höher das Risiko eines KI-Systems für Gesundheit, Sicherheit oder Grundrechte, desto strenger die regulatorischen Anforderungen. Dieses Prinzip ist der Schlüssel zum Verständnis des gesamten Regelwerks – und der EU AI Act Risikostufen im Besonderen.

    Die Verordnung gilt unmittelbar in allen EU-Mitgliedstaaten und betrifft Anbieter, Betreiber (Deployer), Importeure und Händler von KI-Systemen, die auf dem EU-Markt bereitgestellt oder in der EU eingesetzt werden – unabhängig davon, wo der Anbieter seinen Sitz hat.

     

    Zeitplan: Wann gelten welche Vorschriften?

    Der EU AI Act tritt stufenweise in Kraft, um Unternehmen ausreichend Vorbereitungszeit zu geben:

    • Ab 2. Februar 2025: Verbote bestimmter KI-Praktiken (Kapitel II) und Vorschriften zur KI-Kompetenz (Artikel 4)
    • Ab 2. August 2025: Pflichten für Anbieter von General-Purpose-AI-Modellen (GPAI) und Einrichtung von Governance-Strukturen
    • Ab 2. August 2026: Transparenzpflichten für bestimmte KI-Systeme nach Artikel 50 (z. B. Chatbots, Deepfakes, KI-generierte Inhalte)
    • Ab 2. Dezember 2027: Pflichten für eigenständige Hochrisiko-KI-Systeme nach Anhang III – durch den EU Digital Omnibus (2026) vom ursprünglichen Termin 2. August 2026 verschoben
    • Ab 2. August 2028: Pflichten für Hochrisiko-KI-Systeme, die als Sicherheitskomponente unter bestehende EU-Produktsicherheitsvorschriften fallen (Anhang I) – durch den Digital Omnibus verschoben (zuvor 2. August 2027)

     

    Die vier EU AI Act Risikostufen im Überblick

    Das Herzstück des AI Act ist die Klassifizierung von KI-Systemen in vier AI Act Risikoklassen. Jede Stufe bringt unterschiedliche regulatorische Konsequenzen mit sich.

     

    Stufe 1: Verbotene KI-Praktiken (unannehmbares Risiko)

    Die höchste Risikostufe umfasst KI-Systeme, die als unvereinbar mit den Grundwerten der EU gelten. Diese Systeme sind vollständig verboten. Seit dem 2. Februar 2025 dürfen sie weder entwickelt, auf dem Markt bereitgestellt noch eingesetzt werden.

    Verbotene KI-Praktiken umfassen:

    • Manipulative und täuschende KI: Systeme, die unterschwellige Techniken, manipulative oder täuschende Methoden einsetzen, um das Verhalten von Personen wesentlich zu beeinflussen und ihnen dadurch erheblichen Schaden zuzufügen.
    • Ausnutzung von Vulnerabilitäten: KI-Systeme, die gezielt die Schutzbedürftigkeit bestimmter Personengruppen ausnutzen – etwa aufgrund von Alter, Behinderung oder sozialer Lage.
    • Social Scoring durch Behörden: KI-gestützte Bewertung oder Klassifizierung natürlicher Personen anhand ihres Sozialverhaltens, die zu ungerechtfertigter Benachteiligung führt.
    • Biometrische Echtzeit-Fernidentifizierung in öffentlich zugänglichen Räumen zu Strafverfolgungszwecken (mit eng definierten Ausnahmen für schwere Straftaten).
    • Emotionserkennung am Arbeitsplatz und in Bildungseinrichtungen (außer aus medizinischen oder sicherheitsrelevanten Gründen).
    • Biometrische Kategorisierung zur Ableitung sensibler Merkmale wie Rasse, politische Überzeugung, Gewerkschaftszugehörigkeit, religiöse Überzeugung oder sexuelle Orientierung.
    • Ungezielte Gesichtserkennung: Aufbau von Gesichtserkennungsdatenbanken durch ungezieltes Auslesen von Bildern aus dem Internet oder Überwachungskameras.
    • Prädiktive Polizeiarbeit: KI-Systeme, die ausschließlich auf Profiling basierend das Risiko einer natürlichen Person für die Begehung von Straftaten bewerten.

    Sanktionen: Verstöße gegen die Verbote können mit Bußgeldern von bis zu 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes geahndet werden – je nachdem, welcher Betrag höher ist.

     

    Stufe 2: Hochrisiko-KI-Systeme (AI Act High Risk)

    Die Kategorie der AI Act High Risk Systeme ist die regulatorisch am stärksten reglementierte Kategorie für zulässige KI-Systeme. Hochrisiko-KI-Systeme unterliegen umfassenden Pflichten vor und nach dem Inverkehrbringen.

    Wann gilt ein KI-System als Hochrisiko?

    Ein KI-System wird als Hochrisiko eingestuft, wenn es in einem der folgenden Bereiche eingesetzt wird:

    A) Sicherheitskomponenten regulierter Produkte (Anhang I):

    • Maschinen und Maschinenprodukte
    • Spielzeug
    • Sportboote und Wassermotorräder
    • Aufzüge
    • Geräte für explosionsgefährdete Bereiche
    • Funkanlagen
    • Druckgeräte
    • Medizinprodukte und In-vitro-Diagnostika
    • Zivile Luftfahrt
    • Kraftfahrzeuge

    B) Eigenständige KI-Anwendungen in kritischen Bereichen (Anhang III):

    • Biometrie: Biometrische Fernidentifizierung (nicht in Echtzeit), Emotionserkennung und biometrische Kategorisierung
    • Kritische Infrastrukturen: KI als Sicherheitskomponente im Management und Betrieb von Straßenverkehr, Wasser-, Gas-, Wärme- und Stromversorgung
    • Bildung und Berufsausbildung: Systeme zur Bestimmung des Zugangs zu Bildungseinrichtungen, zur Leistungsbewertung oder zur Überwachung von Prüfungen
    • Beschäftigung und Personalmanagement: KI für Bewerberauswahl, Stellenausschreibungen, Leistungsbewertung und Kündigungsentscheidungen
    • Zugang zu wesentlichen Dienstleistungen: Kreditwürdigkeitsbewertung, Risikobewertung bei Lebens- und Krankenversicherungen, Bewertung der Anspruchsberechtigung für Sozialleistungen
    • Strafverfolgung: Risikobewertungen als Opfer, Lügendetektoren, Bewertung der Zuverlässigkeit von Beweismitteln, Profiling
    • Migration und Grenzschutz: Risikobewertung, Unterstützung bei der Prüfung von Visumanträgen und Asylanträgen
    • Justiz und demokratische Prozesse: KI zur Unterstützung bei der Auslegung von Sachverhalten und Rechtsvorschriften, Beeinflussung von Wahlergebnissen

    Wichtige Ausnahme: Auch wenn ein KI-System in einen der genannten Bereiche fällt, gilt es nicht als Hochrisiko, wenn es keine erhebliche Gefahr für Gesundheit, Sicherheit oder Grundrechte darstellt – etwa weil es lediglich eine enge Verfahrensaufgabe erfüllt, ein früheres menschliches Handeln verbessert oder nur Muster erkennt, ohne menschliche Bewertungen zu ersetzen. Diese Ausnahme muss jedoch dokumentiert werden.

     

    Pflichten für Anbieter von Hochrisiko-KI-Systemen

    Anbieter (also die Entwickler oder Hersteller) von Hochrisiko-KI-Systemen müssen ein umfassendes Compliance-Programm umsetzen:

    • Risikomanagementsystem: Ein kontinuierliches, iteratives Risikomanagementsystem über den gesamten Lebenszyklus des KI-Systems, das Risiken identifiziert, bewertet und durch geeignete Maßnahmen minimiert.
    • Daten-Governance: Trainings-, Validierungs- und Testdaten müssen relevanten Qualitätskriterien entsprechen. Datensätze müssen repräsentativ, fehlerfrei und vollständig sein, um Verzerrungen (Bias) zu minimieren.
    • Technische Dokumentation: Umfassende Dokumentation des Systems vor dem Inverkehrbringen, die eine Bewertung der Konformität ermöglicht.
    • Protokollierung (Logging): Automatische Aufzeichnung von Ereignissen während des Betriebs zur Nachvollziehbarkeit und Auditierbarkeit.
    • Transparenz: Betreibern müssen Gebrauchsanweisungen mit klaren, verständlichen Informationen bereitgestellt werden.
    • Menschliche Aufsicht: Das System muss so gestaltet sein, dass eine wirksame menschliche Kontrolle möglich ist – einschließlich der Möglichkeit, das System jederzeit zu übersteuern oder abzuschalten.
    • Genauigkeit, Robustheit und Cybersicherheit: Das System muss ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit aufweisen.
    • Qualitätsmanagementsystem: Implementierung eines umfassenden QMS, das alle genannten Anforderungen abdeckt.
    • Konformitätsbewertung: Vor dem Inverkehrbringen muss eine Konformitätsbewertung durchgeführt werden – je nach Bereich als Selbstbewertung oder durch eine benannte Stelle (Notified Body).
    • CE-Kennzeichnung und EU-Konformitätserklärung: Hochrisiko-KI-Systeme müssen die CE-Kennzeichnung tragen.
    • Registrierung: Registrierung in der EU-Datenbank für Hochrisiko-KI-Systeme.

    Sanktionen: Verstöße gegen die Pflichten für Hochrisiko-KI können mit Bußgeldern von bis zu 15 Millionen Euro oder 3 % des Jahresumsatzes geahndet werden.

     

    Pflichten für Betreiber (Deployer) von Hochrisiko-KI

    Auch Unternehmen, die Hochrisiko-KI-Systeme einsetzen (Betreiber/Deployer), haben spezifische Pflichten:

    • Einsatz des Systems gemäß der Gebrauchsanweisung des Anbieters
    • Sicherstellung der menschlichen Aufsicht durch ausreichend geschultes Personal
    • Überwachung des Betriebs und Meldung von Fehlfunktionen an den Anbieter
    • Durchführung einer Grundrechte-Folgenabschätzung vor dem Einsatz (für bestimmte Betreiber wie öffentliche Einrichtungen, Kreditinstitute, Versicherungen)
    • Aufbewahrung der vom System automatisch generierten Protokolle

     

    Stufe 3: KI-Systeme mit begrenztem Risiko (Transparenzpflichten)

    Bestimmte KI-Systeme unterliegen spezifischen Transparenzpflichten, unabhängig von ihrer Risikoeinstufung. Diese Stufe betrifft vor allem KI-Anwendungen, bei denen Nutzer wissen müssen, dass sie mit einer KI interagieren oder dass Inhalte KI-generiert sind.

    Betroffene Systeme und ihre Pflichten:

    • Chatbots und KI-Interaktionssysteme: Nutzer müssen darüber informiert werden, dass sie mit einem KI-System interagieren – es sei denn, dies ist aus dem Kontext offensichtlich.
    • Emotionserkennung und biometrische Kategorisierung: Betroffene Personen müssen über den Einsatz solcher Systeme informiert werden.
    • Deepfakes und synthetische Inhalte: KI-generierte oder manipulierte Bild-, Audio- oder Videoinhalte müssen als solche gekennzeichnet werden (maschinenlesbares Format).
    • KI-generierte Texte: Wenn Texte zu Themen von öffentlichem Interesse veröffentlicht werden und KI-generiert sind, muss dies offengelegt werden (mit Ausnahmen für redaktionell überprüfte Inhalte).

    Die Transparenzpflichten sollen sicherstellen, dass Menschen informierte Entscheidungen treffen können und nicht unwissentlich von KI-Systemen beeinflusst werden.

     

    Stufe 4: KI-Systeme mit minimalem Risiko

    Die große Mehrheit der heute eingesetzten KI-Systeme fällt in die Kategorie minimales Risiko. Für diese Systeme sieht der EU AI Act keine spezifischen regulatorischen Pflichten vor. Beispiele sind:

    • Spam-Filter
    • KI-gestützte Empfehlungssysteme (in den meisten Anwendungsfällen)
    • KI in Videospielen
    • Automatische Textvervollständigung
    • Bildoptimierung in Kameras
    • Inventarmanagement-Systeme

    Unternehmen, die KI-Systeme mit minimalem Risiko einsetzen oder anbieten, werden jedoch ermutigt, freiwillige Verhaltenskodizes zu entwickeln und anzuwenden – etwa in Bezug auf Transparenz, Fairness und Nachhaltigkeit.

     

    General-Purpose AI (GPAI): Sonderregelungen für Basismodelle

    Der EU AI Act enthält zusätzlich Regelungen für KI-Modelle mit allgemeinem Verwendungszweck (General-Purpose AI Models, GPAI) – etwa große Sprachmodelle wie GPT oder Claude. Diese Modelle lassen sich keiner einzelnen Risikostufe zuordnen, da sie für vielfältige Zwecke eingesetzt werden können.

    Pflichten für alle GPAI-Anbieter:

    • Erstellung und Aktualisierung technischer Dokumentation
    • Bereitstellung von Informationen für nachgelagerte Anbieter
    • Einrichtung einer Strategie zur Einhaltung des EU-Urheberrechts
    • Veröffentlichung einer Zusammenfassung der Trainingsdaten

    Zusätzliche Pflichten für GPAI mit systemischem Risiko:

    • Durchführung von Modellbewertungen (einschließlich Adversarial Testing)
    • Bewertung und Minderung systemischer Risiken
    • Meldepflichten bei schwerwiegenden Vorfällen
    • Gewährleistung eines angemessenen Cybersicherheitsniveaus

    Ein GPAI-Modell gilt als systemisches Risiko, wenn es über hohe Wirkungsfähigkeit verfügt – derzeit definiert durch einen Schwellenwert von 10^25 FLOPs an Rechenleistung für das Training.

     

    Praktische Schritte zur Klassifizierung und Compliance

    Schritt 1: KI-Systeme inventarisieren

    Erstellen Sie ein vollständiges Inventar aller KI-Systeme, die Ihr Unternehmen entwickelt, bereitstellt oder einsetzt. Dazu gehören auch eingebettete KI-Komponenten in Drittanbieter-Software und SaaS-Lösungen.

    Schritt 2: Risikostufe bestimmen

    Prüfen Sie für jedes System systematisch:

    • Fällt es unter die verbotenen Praktiken (Artikel 5)?
    • Ist es eine Sicherheitskomponente eines regulierten Produkts (Anhang I)?
    • Wird es in einem der Hochrisiko-Bereiche eingesetzt (Anhang III)?
    • Unterliegt es Transparenzpflichten (Artikel 50)?

    Schritt 3: Rolle bestimmen

    Klären Sie Ihre Rolle im Sinne des AI Act: Sind Sie Anbieter (Provider), Betreiber (Deployer), Importeur oder Händler? Die jeweilige Rolle bestimmt den Umfang Ihrer Pflichten.

    Schritt 4: Compliance-Maßnahmen ableiten

    Leiten Sie auf Basis der Risikostufe und Ihrer Rolle die erforderlichen Maßnahmen ab und priorisieren Sie deren Umsetzung entsprechend der gestaffelten Fristen des EU AI Act. Für die praktische Umsetzung empfiehlt es sich, das KI-Risikomanagement strukturiert aufzubauen und in bestehende Governance-Strukturen einzubetten.

    Plattformen wie TrustSpace unterstützen Unternehmen bei der systematischen Erfassung, Klassifizierung und Dokumentation von KI-Systemen. Durch die Integration mit bestehenden Compliance-Rahmenwerken wie ISO 27001 oder der DSGVO lassen sich Synergien nutzen und Doppelarbeit vermeiden.

     

    Zusammenspiel mit anderen Regulierungen

    Der EU AI Act steht nicht isoliert, sondern ergänzt bestehende Regelwerke:

    • DSGVO: KI-Systeme, die personenbezogene Daten verarbeiten, müssen weiterhin die DSGVO einhalten. Besonders relevant sind automatisierte Einzelentscheidungen (Art. 22 DSGVO), Datenschutz-Folgenabschätzungen und die Prinzipien Privacy by Design und by Default.
    • EU-Produktsicherheitsrecht: Für Hochrisiko-KI-Systeme in regulierten Produkten gelten die Anforderungen des AI Act zusätzlich zu den jeweiligen sektoralen Vorschriften.
    • EU Cyber Resilience Act: Für KI-Systeme in vernetzten Produkten sind auch die Cybersicherheitsanforderungen des CRA zu beachten.
    • Haftungsrichtlinien: Die KI-Haftungsrichtlinie und die neue Produkthaftungsrichtlinie schaffen ergänzende zivilrechtliche Haftungsregeln für KI-Schäden.

     

    Fazit: EU AI Act Risikostufen als Leitplanke für verantwortungsvolle KI

    Die EU AI Act Risikostufen schaffen einen klaren, proportionalen Rahmen für den Einsatz künstlicher Intelligenz in Europa. Der risikobasierte Ansatz stellt sicher, dass innovative KI-Anwendungen weiterhin möglich sind, während Systeme mit hohem Schadenspotenzial streng reguliert werden.

    Für Unternehmen im DACH-Raum bedeutet dies: Handeln Sie jetzt. Die Verbote gelten bereits seit Februar 2025 und die Transparenzpflichten nach Artikel 50 ab August 2026; die umfassenden Pflichten für eigenständige Hochrisiko-KI-Systeme (Anhang III) wurden durch den EU Digital Omnibus auf Dezember 2027 verschoben. Eine frühzeitige Klassifizierung Ihrer KI-Systeme und die systematische Vorbereitung auf die Compliance-Anforderungen sind entscheidend, um Bußgelder zu vermeiden und das Vertrauen von Kunden und Geschäftspartnern zu stärken.

    Wer die AI Act Risikoklassen versteht und die entsprechenden Pflichten strukturiert umsetzt, verwandelt regulatorische Anforderungen in einen Wettbewerbsvorteil – als Ausweis verantwortungsvoller und transparenter KI-Nutzung. Eine zentrale ISMS-Software wie TrustSpaceOS hilft, betroffene KI-Systeme zu inventarisieren, ihrer Risikostufe zuzuordnen und die geforderten Nachweise revisionssicher zu dokumentieren.

  • NIS 2 Lieferkette: Anforderungen an die Supply Chain Security und wie Unternehmen sich absichern

    NIS 2 Lieferkette: Anforderungen an die Supply Chain Security und wie Unternehmen sich absichern

    Die NIS-2-Richtlinie stellt nicht nur Anforderungen an die IT-Sicherheit einzelner Unternehmen – sie nimmt erstmals die gesamte Lieferkette in den Blick. Wer als wesentliche oder wichtige Einrichtung unter NIS-2 fällt, muss die Cybersicherheitsrisiken seiner Zulieferer systematisch bewerten und steuern. Das betrifft direkte Lieferanten ebenso wie deren Unterauftragnehmer.

    Dieser Artikel erklärt die NIS-2-Anforderungen an die Lieferkette, zeigt praxisnahe Ansätze für die Risikobewertung der Supply Chain und gibt konkrete Empfehlungen zur vertraglichen Absicherung. Wer sich zunächst einen Überblick über Anwendungsbereich und Pflichtenkatalog verschaffen möchte, findet ihn in unserer Zusammenfassung der NIS-2-Richtlinie.

    Das Wichtigste in Kürze:

    • NIS-2 verpflichtet betroffene Unternehmen, Cybersicherheitsrisiken in der gesamten Lieferkette zu bewerten und zu managen (Art. 21 Abs. 2 lit. d).
    • Die Anforderungen betreffen direkte Lieferanten und deren Unterauftragnehmer – die Verantwortung endet nicht beim Erstlieferanten.
    • Unternehmen müssen vertragliche Sicherheitsanforderungen, Audit-Rechte und Incident-Reporting-Pflichten mit Lieferanten vereinbaren.
    • Die Europäische Kommission kann für bestimmte Sektoren koordinierte Risikobewertungen der Lieferkette durchführen.
    • Unternehmen, die ihre Supply Chain Security nicht nachweisen können, riskieren Bußgelder und Haftung der Geschäftsführung.

     

    NIS 2 Lieferkette: Was fordert die Richtlinie konkret?

    Artikel 21 der NIS-2-Richtlinie definiert die Risikomanagementmaßnahmen, die betroffene Einrichtungen umsetzen müssen. Absatz 2 lit. d nennt explizit:

    „Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern”

    Seit dem 6. Dezember 2025 steht diese Pflicht auch im deutschen Recht: § 30 Absatz 2 Nummer 4 BSIG verlangt die “Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern”. Die Lieferantenbewertung ist damit kein Vorbereitungsthema mehr, sondern eine prüfbare Pflicht neben Registrierung, Risikomanagement und Meldewesen. Wie sich die einzelnen Anforderungen priorisieren lassen, ordnet unsere NIS-2-Checkliste für den Mittelstand ein.

    Die vier Kernelemente der NIS-2-Lieferkettensicherheit

    1. Risikobewertung der Lieferantenbeziehungen

    Jedes Unternehmen muss die spezifischen Schwachstellen seiner Lieferanten identifizieren und die Gesamtqualität der Produkte und Cybersicherheitspraktiken bewerten. Dabei sind zu berücksichtigen:

    • Die Cybersicherheitspraktiken des Lieferanten (Sicherheitsentwicklungsverfahren, Schwachstellenmanagement)
    • Die Qualität und Resilienz der gelieferten IKT-Produkte und -Dienste
    • Die Fähigkeit des Lieferanten zur Erkennung und Behebung von Schwachstellen

    2. Berücksichtigung der gesamten Lieferkette

    NIS-2 beschränkt sich nicht auf direkte Lieferanten. Die Richtlinie fordert die Berücksichtigung der gesamten Kette – einschließlich der Unterauftragnehmer des Lieferanten:

    • Tier 1: Direkte Lieferanten (z. B. Cloud-Provider, Softwareanbieter)
    • Tier 2: Unterauftragnehmer des Lieferanten (z. B. Rechenzentren des Cloud-Providers)
    • Tier 3+: Weitere nachgelagerte Zulieferer (z. B. Hardware-Hersteller der Rechenzentrumskomponenten)

    3. Koordinierte Sicherheitsrisikobewertungen

    Die NIS-2-Richtlinie sieht vor, dass die Europäische Kommission in Zusammenarbeit mit den Mitgliedstaaten koordinierte Sicherheitsrisikobewertungen kritischer Lieferketten durchführen kann – analog zur 5G-Toolbox-Bewertung. Unternehmen müssen die Ergebnisse solcher Bewertungen in ihr Risikomanagement einfließen lassen.

    4. Verhältnismäßigkeit der Maßnahmen

    Alle Maßnahmen müssen den Stand der Technik berücksichtigen und verhältnismäßig sein. Das bedeutet: Die Kosten der Sicherheitsmaßnahmen müssen in einem angemessenen Verhältnis zum Risiko stehen. Ein Kleinunternehmen muss nicht dieselben Maßnahmen umsetzen wie ein DAX-Konzern.

     

    Supply Chain Security NIS 2: Risikobewertung in der Praxis

    Die systematische Bewertung der Lieferkettenrisiken ist das Kernstück der NIS-2-Compliance im Bereich Supply Chain. Der folgende Prozess hat sich in der Praxis bewährt:

    Schritt 1: Kritische Lieferanten identifizieren

    Nicht jeder Lieferant ist gleich relevant. Konzentrieren Sie sich zunächst auf diejenigen, die für Ihre IT-Sicherheit tatsächlich bedeutsam sind:

    Fragen zur Identifikation kritischer Lieferanten:

    • Hat der Lieferant Zugang zu Ihren IT-Systemen (Remote-Zugriff, VPN, API-Schnittstellen)?
    • Verarbeitet der Lieferant sensible oder personenbezogene Daten in Ihrem Auftrag?
    • Liefert der Lieferant Software oder Hardware, die in Ihren kritischen Systemen eingesetzt wird?
    • Könnte ein Ausfall des Lieferanten zu einer Betriebsunterbrechung führen?
    • Ist der Lieferant Teil einer kritischen IKT-Lieferkette (z. B. Cloud-Infrastruktur)?

    Schritt 2: Risikoanalyse durchführen

    Für jeden identifizierten kritischen Lieferanten sollte eine strukturierte Risikoanalyse erfolgen:

    Risikodimension Bewertungskriterien Beispiel
    Cyberrisiko Sicherheitszertifizierungen, Schwachstellenmanagement, Incident-Historie Cloud-Provider ohne ISO 27001 = hohes Risiko
    Abhängigkeitsrisiko Substituierbarkeit, Lock-in-Effekte, Marktmacht Single-Source-Anbieter für kritische Software
    Geopolitisches Risiko Standort des Lieferanten, Jurisdiktion, Datentransfer Anbieter in Drittstaaten ohne Angemessenheitsbeschluss
    Konzentrationsrisiko Viele Unternehmen nutzen denselben Anbieter Dominante Cloud-Hyperscaler
    Subunternehmerrisiko Transparenz über Sub-Supplier, Kontrollmöglichkeiten Lieferant outsourct an unbekannte Dritte

    Schritt 3: Risikobewertungsmatrix erstellen

    Bewerten Sie jeden Lieferanten anhand von Eintrittswahrscheinlichkeit und Auswirkung eines Sicherheitsvorfalls:

    Geringe Auswirkung Mittlere Auswirkung Hohe Auswirkung Kritische Auswirkung
    Wahrscheinlich Mittel Hoch Kritisch Kritisch
    Möglich Niedrig Mittel Hoch Kritisch
    Unwahrscheinlich Niedrig Niedrig Mittel Hoch
    Sehr unwahrscheinlich Niedrig Niedrig Niedrig Mittel

     

    TrustSpace Profi-Tipp: Beginnen Sie nicht mit dem Versuch, alle Lieferanten gleichzeitig zu bewerten. Starten Sie mit den Top-10-Lieferanten nach Kritikalität und arbeiten Sie sich systematisch durch. TrustSpaceOS unterstützt Sie mit vorkonfigurierten Risikobewertungsvorlagen, die speziell auf die NIS-2-Anforderungen an die Supply Chain Security zugeschnitten sind.

     

     

    Vertragliche Absicherung der Lieferkette unter NIS-2

    Neben der Risikobewertung ist die vertragliche Verankerung von Sicherheitsanforderungen ein zentrales Element der NIS-2-Lieferkettensicherheit.

    Mindestanforderungen an Lieferantenverträge

    Sicherheitsanforderungen:

    • Definition der Mindest-Sicherheitsstandards, die der Lieferant einhalten muss
    • Verpflichtung zur Einhaltung des Stands der Technik
    • Anforderungen an Verschlüsselung, Zugangskontrollen und Netzwerksegmentierung
    • Pflicht zur regelmäßigen Durchführung von Sicherheitstests (Penetrationstests, Schwachstellenscans)

    Incident-Reporting:

    • Pflicht zur unverzüglichen Meldung von Sicherheitsvorfällen (empfohlen: innerhalb von 24 Stunden)
    • Definition, welche Vorfalltypen meldepflichtig sind
    • Festlegung der Kommunikationswege und Ansprechpartner
    • Pflicht zur Kooperation bei der Vorfalluntersuchung

    Der Zeitdruck ist dabei kein Selbstzweck: Ihre eigene Erstmeldung an die Behörde ist nach 24 Stunden fällig, gerechnet ab Kenntnis vom Vorfall. Meldet Ihr Dienstleister erst nach drei Tagen, ist Ihre Frist längst verstrichen. Welche Angaben auf welcher Stufe erwartet werden, führt unsere Übersicht der NIS-2-Meldefristen aus.
    Audit- und Kontrollrechte:

    • Recht zur Durchführung von Sicherheitsaudits (angekündigt und unangekündigt)
    • Einsichtnahme in Audit-Berichte, Zertifikate und Penetrationstest-Ergebnisse
    • Recht zur Beauftragung externer Prüfer
    • Zugang zu relevanten Dokumentationen und Nachweisen

    Unterauftragnehmermanagement:

    • Genehmigungspflicht für den Einsatz von Unterauftragnehmern
    • Verpflichtung, gleichwertige Sicherheitsanforderungen an Unterauftragnehmer weiterzugeben
    • Transparenzpflicht über die gesamte Lieferkette
    • Recht zur Ablehnung bestimmter Unterauftragnehmer

    Vertragsende und Exit:

    • Regelungen zur Datenrückgabe und -löschung
    • Definierte Übergangsfristen für den Anbieterwechsel
    • Mitwirkungspflichten des Lieferanten bei der Migration
    • Fortgeltung der Vertraulichkeitspflichten über das Vertragsende hinaus

     

    NIS-2-Lieferkette: Besondere Herausforderungen und Lösungen

    Herausforderung 1: Transparenz über mehrstufige Lieferketten

    Problem: Viele Unternehmen haben keinen vollständigen Überblick über ihre Lieferkette – insbesondere nicht über Tier-2- und Tier-3-Lieferanten.

    Lösung:

    • Vertraglich absichern: Lieferanten verpflichten, Transparenz über ihre eigenen Unterauftragnehmer herzustellen
    • Standardisierte Fragebögen: Einheitliche Selbstauskunft für alle Lieferantenstufen
    • Zertifizierungen bevorzugen: Lieferanten mit ISO 27001 oder vergleichbaren Zertifizierungen haben diese Prozesse bereits etabliert

    Herausforderung 2: Machtgefälle bei großen Anbietern

    Problem: Gegenüber großen Cloud-Providern oder Softwarekonzernen haben KMU wenig Verhandlungsmacht. Individuelle Audit-Rechte oder maßgeschneiderte Vertragsklauseln sind oft nicht durchsetzbar.

    Lösung:

    • SOC-2-Berichte und ISO-27001-Zertifikate als Audit-Ersatz akzeptieren
    • Shared-Responsibility-Modelle klar dokumentieren und eigene Verantwortlichkeiten wahrnehmen
    • Anbieterdiversifikation prüfen, um Konzentrationsrisiken zu reduzieren
    • Branchenverbände als Multiplikatoren nutzen, um gemeinsam Sicherheitsstandards einzufordern

    Herausforderung 3: Kontinuierliche Überwachung

    Problem: Eine einmalige Lieferantenbewertung reicht nicht. Risiken verändern sich, Lieferanten wechseln Unterauftragnehmer, Bedrohungslagen entwickeln sich weiter.

    Lösung:

    • Automatisiertes Monitoring der Lieferanten (Security Ratings, Threat Intelligence)
    • Regelmäßige Neubewertung in definierten Zyklen (jährlich für kritische Lieferanten)
    • Anlassbezogene Reviews bei Sicherheitsvorfällen, Medienmeldungen oder Vertragsänderungen
    • Integration in das ISMS: Lieferantenüberwachung als kontinuierlicher Prozess im Informationssicherheitsmanagementsystem verankern

     

    TrustSpace Profi-Tipp: Verknüpfen Sie Ihre NIS-2-Lieferkettensicherheit mit einem bestehenden oder geplanten ISO-27001-ISMS. Die Anforderungen überschneiden sich erheblich (ISO 27001 Annex A.5.19–A.5.23). Wer ein zertifiziertes ISMS betreibt, erfüllt einen großen Teil der NIS-2-Supply-Chain-Anforderungen bereits. TrustSpace unterstützt Sie dabei, beide Anforderungsrahmen in einem integrierten System abzubilden.

     

     

    Praxis-Checkliste: NIS-2-Lieferkettensicherheit umsetzen

    Bestandsaufnahme und Klassifizierung

    • ☐ Vollständiges Lieferantenverzeichnis mit Bezug zur IT-Sicherheit erstellen
    • ☐ Lieferanten nach Kritikalität klassifizieren (kritisch / hoch / mittel / niedrig)
    • ☐ Tier-2- und Tier-3-Lieferanten identifizieren (soweit möglich)
    • ☐ Abhängigkeiten und Konzentrationsrisiken dokumentieren

    Risikobewertung

    • ☐ Risikobewertungsmethodik festlegen und dokumentieren
    • ☐ Erstbewertung aller kritischen Lieferanten durchführen
    • ☐ Risikobewertungsmatrix erstellen und regelmäßig aktualisieren
    • ☐ Ergebnisse ins ISMS-Risikomanagement integrieren

    Vertragliche Absicherung

    • ☐ Bestehende Verträge auf NIS-2-Konformität prüfen
    • ☐ Sicherheitsanforderungen in alle relevanten Verträge aufnehmen
    • ☐ Audit-Rechte und Incident-Reporting-Pflichten vereinbaren
    • ☐ Unterauftragnehmermanagement vertraglich regeln

    Laufende Überwachung

    • ☐ Überwachungsprozess für Lieferanten definieren und implementieren
    • ☐ Regelmäßige Neubewertung im Kalender verankern
    • ☐ Incident-Response-Prozess auf Lieferantenvorfälle erweitern
    • ☐ Management-Reporting über Supply-Chain-Risiken einrichten

     

    Fazit: Supply Chain Security als strategische Aufgabe

    Die NIS-2-Richtlinie macht die Sicherheit der Lieferkette zu einer Compliance-Pflicht – aber sie sollte weit mehr sein als das. In einer zunehmend vernetzten Wirtschaft sind Lieferkettenangriffe (Supply Chain Attacks) eine der größten Bedrohungen für Unternehmen. Wer seine Supply Chain Security proaktiv managt, schützt nicht nur sich selbst, sondern wird auch zum bevorzugten Partner für sicherheitsbewusste Kunden.

    Der Schlüssel liegt in einem systematischen, risikobasierten Ansatz: Kritische Lieferanten identifizieren, Risiken bewerten, vertragliche Sicherheitsnetze spannen und die Überwachung als kontinuierlichen Prozess etablieren. Praxiseinblicke dazu, wie Zulieferer NIS2 und TISAX® gemeinsam angehen, gibt unser Podcast mit Expertenwissen zu NIS2 und TISAX. Wer diesen Nachweis nicht führen kann, riskiert mehr als einen Ausfall: Die Aufsicht kann Lücken im Lieferantenmanagement als eigenständigen Verstoß ahnden – mit den vollen Bußgeld- und Haftungsfolgen für die Geschäftsleitung.

     

    Sie möchten Ihre Lieferkette NIS-2-konform absichern? TrustSpace bietet mit TrustSpaceOS eine integrierte Plattform zur Überwachung Ihrer Supply Chain Security – von der automatisierten Lieferantenbewertung bis zum Echtzeit-Compliance-Dashboard. In Kombination mit unserer NIS2-Beratung begleiten wir Sie von der Betroffenheitsanalyse bis zur vollständigen Umsetzung.

    Jetzt kostenlose Erstberatung vereinbaren →