trustspace

Author: admin@trustspace.io

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

  • Business Continuity Management: Der Leitfaden für den Mittelstand

    Business Continuity Management: Der Leitfaden für den Mittelstand

    Das Wichtigste in Kürze

    • Definition: Business Continuity Management (BCM), deutsch Betriebliches Kontinuitätsmanagement, sichert die Fortführung zeitkritischer Geschäftsprozesse bei schweren Störungen und steuert die Rückkehr in den Normalbetrieb.
    • Abgrenzung: BCM ist der Rahmen, Disaster Recovery die technische Wiederherstellung der IT, Incident Response die Bearbeitung einzelner Vorfälle, Krisenmanagement die Führungsebene im Ausnahmezustand.
    • Herzstück: Die Business Impact Analyse legt je Prozess fest, wie lange ein Ausfall tragbar ist (MTPD), wie schnell wiederangelaufen werden muss (RTO) und wie viel Datenverlust akzeptabel ist (RPO).
    • Normen: ISO 22301:2019 ist der zertifizierbare BCMS-Standard, der BSI-Standard 200-4 (Juni 2023) liefert die deutschsprachige Methodik mit dreistufigem Einstiegsmodell.
    • Recht: NIS2 verlangt über § 30 Absatz 2 Nummer 3 BSIG die „Aufrechterhaltung des Betriebs”, DORA in Artikel 11 eine IKT-Geschäftsfortführungsleitlinie samt jährlicher Tests; im ISMS greifen die Controls A.5.29, A.5.30, A.8.13 und A.8.14 der ISO 27001:2022.

     

    Ein Ransomware-Angriff legt die Auftragsbearbeitung lahm, ein Rechenzentrumsausfall trennt den Zugriff auf alle Fachanwendungen: In solchen Lagen entscheidet nicht die Firewall über den Schaden, sondern die Vorbereitung. Genau hier setzt Business Continuity Management an. Es klärt vorab, welche Prozesse wie lange ausfallen dürfen, wer entscheidet und wie der Betrieb mit reduzierten Mitteln weiterläuft.

    Für den Mittelstand ist das Thema vom freiwilligen Reifegrad-Merkmal zur regulatorischen Pflicht geworden: NIS2 und DORA verlangen ausdrücklich Vorkehrungen zur Aufrechterhaltung des Betriebs, und auch eine ISO-27001-Zertifizierung ist ohne belastbare Kontinuitätsplanung nicht zu halten. Dieser Leitfaden erklärt, was BCM umfasst, wie es sich von benachbarten Disziplinen abgrenzt, wie der Lebenszyklus abläuft, welche Normen und Gesetze gelten und wie ein Einstieg mit begrenzten Ressourcen aussieht.

     

    Was ist Business Continuity Management?

    Business Continuity Management ist der Managementprozess, mit dem eine Organisation ihre zeitkritischen Geschäftsprozesse identifiziert, deren Ausfallrisiken bewertet und Vorkehrungen trifft, um diese Prozesse bei einer schweren Störung auf einem definierten Mindestniveau fortzuführen. Er umfasst Vorbereitung, Bewältigung im Ereignisfall und Rückkehr in den Normalbetrieb.

    Entscheidend ist die Perspektive: BCM denkt nicht vom System her, sondern vom Geschäftsprozess. Nicht „Welcher Server ist ausgefallen?” ist die Leitfrage, sondern „Welche Wertschöpfung steht still, ab wann wird es existenzbedrohend, und was ist der kleinste akzeptable Notbetrieb?”. Daraus folgt, dass BCM eine Aufgabe der Geschäftsführung ist und nicht der IT allein zugeordnet werden kann. Organisiert wird es in einem Business Continuity Management System (BCMS), das demselben Plan-Do-Check-Act-Zyklus folgt wie ein ISMS und sich mit diesem verzahnen lässt.

     

    BCM, Notfallmanagement, Disaster Recovery und Incident Response im Vergleich

    Die Begriffe werden häufig vermischt, bezeichnen aber unterschiedliche Ebenen. Wer sie trennt, vermeidet Lücken zwischen den Plänen und doppelte Zuständigkeiten im Ernstfall.

    Disziplin Fokus Einordnung
    Business Continuity Management Fortführung zeitkritischer Geschäftsprozesse auf definiertem Mindestniveau Übergreifender Rahmen, prozessorientiert
    Notfallmanagement Vorbereitung und Bewältigung von Notfällen und Krisen Klassische deutsche Bezeichnung, weitgehend deckungsgleich mit BCM
    Disaster Recovery Technische Wiederherstellung von IT-Systemen, Daten und Infrastruktur Teilmenge des BCM, technikorientiert
    Krisenmanagement Entscheidungs- und Kommunikationsstrukturen der Leitungsebene im Ausnahmezustand Führungsprozess, greift bei Eskalation
    Incident Response Erkennung, Analyse und Eindämmung einzelner Sicherheitsvorfälle Operativer Prozess der Informationssicherheit

    Das Zusammenspiel zeigt ein Ransomware-Fall: Incident Response isoliert die betroffenen Systeme, Disaster Recovery spielt Daten aus den Sicherungen zurück, das Krisenmanagement entscheidet über Kommunikation und Meldungen, und BCM hält Auftragsannahme und Versand über einen geplanten Notbetrieb am Laufen. Fehlt eine Ebene, entsteht dort die Verzögerung, die den Schaden vergrößert.

     

    Der BCM-Lebenszyklus in sechs Schritten

    ISO 22301 und der BSI-Standard 200-4 beschreiben BCM als Kreislauf. Die Bezeichnungen unterscheiden sich, die Logik ist dieselbe.

    1. Kontext und Geltungsbereich festlegen

    Am Anfang steht die Abgrenzung: Welche Standorte, Bereiche und Dienstleistungen fallen in den Geltungsbereich, welche rechtlichen und vertraglichen Anforderungen gelten? Dazu kommen eine von der Leitung verabschiedete Leitlinie, benannte Rollen und ein Budget. Ohne diesen Rahmen bleibt BCM ein Nebenprojekt der IT.

    2. Business Impact Analyse durchführen

    Die Business Impact Analyse (BIA) ist das Herzstück. Sie bewertet je Geschäftsprozess die finanziellen, rechtlichen und reputationsbezogenen Folgen eines Ausfalls über die Zeit. Daraus werden die zentralen Zeitparameter abgeleitet:

    • MTPD (Maximum Tolerable Period of Disruption): die maximal tolerierbare Ausfallzeit, ab der die Folgen nicht mehr hinnehmbar sind. Der BSI-Standard 200-4 nutzt dafür die Abkürzung MTA.
    • RTO (Recovery Time Objective): die Zielzeit für den Wiederanlauf. Sie liegt zwingend unterhalb der MTPD, damit ein Puffer bleibt.
    • RPO (Recovery Point Objective): der maximal akzeptable Datenverlust, gemessen ab der letzten nutzbaren Sicherung. Der RPO bestimmt die notwendige Backup-Frequenz.
    • Mindestbetriebsniveau: die Leistung, die im Notbetrieb zu erbringen ist, etwa „50 Prozent des Versandvolumens” statt „so viel wie möglich”.

    Ergänzend erfasst die BIA die Abhängigkeiten jedes Prozesses von Anwendungen, Personal, Gebäuden und Dienstleistern. Erst diese Kette zeigt, dass ein RTO von vier Stunden für den Versand wertlos ist, wenn das ERP-System erst nach zwei Tagen wiederhergestellt ist.

    3. Risiken beurteilen

    Die BIA sagt, was ein Ausfall kostet, die Risikobeurteilung, wie wahrscheinlich er ist und wodurch er ausgelöst wird. Betrachtet werden Szenarien wie Cyberangriff, Ausfall von Strom, Netz oder Rechenzentrum, Gebäudeschaden, Personalausfall und Wegfall kritischer Dienstleister. Methodisch ist das derselbe Ansatz wie bei der Risikobewertung nach ISO 27001, weshalb sich beide Analysen aus einem gemeinsamen Prozess- und Assetinventar speisen sollten.

    4. Kontinuitätsstrategien auswählen

    Für jeden zeitkritischen Prozess wird festgelegt, wie die Vorgaben aus der BIA erreicht werden. Typische Optionen sind Redundanz (zweites Rechenzentrum, gespiegelte Systeme, Ersatzstandort), Auslagerung, manuelle Ersatzverfahren oder die bewusste Entscheidung, ein Risiko zu tragen. Nicht jeder Prozess braucht Hochverfügbarkeit, aber jeder zeitkritische Prozess eine dokumentierte Entscheidung.

    5. Pläne erstellen und Verantwortliche benennen

    Aus den Strategien werden Geschäftsfortführungs-, Wiederanlauf- und Wiederherstellungspläne. Ein brauchbarer Plan ist knapp und auch ohne IT nutzbar: Auslösekriterien, Alarmierungs- und Eskalationswege, Erreichbarkeiten, Aufgaben je Rolle, Reihenfolge des Wiederanlaufs, Kriterien für die Rückkehr in den Normalbetrieb. Ein Notfallplan, der ausschließlich im verschlüsselten Fileserver liegt, ist im Ernstfall keiner.

    6. Testen, üben und verbessern

    Ungetestete Pläne sind Annahmen. Bewährt hat sich eine Staffelung von Planbesprechungen über Schreibtischübungen und technische Wiederherstellungstests bis zur Vollübung mit Krisenstab. Jede Übung liefert Feststellungen, die als Maßnahmen mit Verantwortlichen und Fristen den Zyklus von vorn beginnen lassen.

     

    TrustSpace Profi-Tipp: Erst die BIA, dann die Technik

    Der häufigste Fehler beim Einstieg ist die Reihenfolge: Es wird in Redundanz und Backup-Technik investiert, bevor jemand die zeitkritischen Prozesse bestimmt hat. Das Ergebnis sind teure Hochverfügbarkeitslösungen für unkritische Systeme und ein ungeschützter Kernprozess. Beginnen Sie mit einer schlanken Business Impact Analyse und leiten Sie erst daraus RTO, RPO und Investitionsbedarf ab. Das spart meist mehr Budget, als der Analyseaufwand kostet.

     

    Normen und Rechtsrahmen für Business Continuity Management

    BCM bewegt sich zwischen freiwilligen Normen (ISO 22301, BSI-Standard 200-4, ISO 27001) und gesetzlichen Vorgaben (NIS2 beziehungsweise BSIG, DORA), deren Verbindlichkeit von Branche und Unternehmensgröße abhängt.

    ISO 22301 und BSI-Standard 200-4

    ISO 22301 in der Fassung von 2019 („Security and resilience — Business continuity management systems — Requirements”) ist der zertifizierbare internationale Maßstab für ein BCMS. Sie folgt der einheitlichen Struktur für Managementsysteme mit den Kapiteln 4 bis 10, was die Integration in ein bestehendes ISMS erleichtert. Für den Mittelstand ist die Zertifizierung selten der erste Schritt, die Norm als Strukturvorlage aber sofort nutzbar.

    Der BSI-Standard 200-4 vom 14. Juni 2023 löst den Standard 100-4 ab und ist mit ISO 22301 kompatibel. Sein Vorzug ist das dreistufige Modell: Das Reaktiv-BCMS schafft mit wenig Aufwand eine erste Bewältigungsfähigkeit, das Aufbau-BCMS führt schrittweise Analysen und Prozesse ein, das Standard-BCMS entspricht einem vollwertigen Managementsystem.

    Business Continuity in der ISO 27001:2022

    Wer bereits ein ISMS betreibt, hat mehr BCM-Substanz im Haus als vermutet. Der Anhang A der ISO 27001:2022 adressiert das Thema an vier Stellen: Control A.5.29 verlangt, die Informationssicherheit auch während einer Störung aufrechtzuerhalten, statt Schutzmaßnahmen im Ausnahmezustand stillschweigend auszusetzen. Das 2022 neu aufgenommene Control A.5.30 fordert die IKT-Bereitschaft für die Geschäftskontinuität, also die Fähigkeit der IT, die in der BIA festgelegten Zeitziele einzuhalten. Ergänzt wird das durch A.8.13 zur Datensicherung und A.8.14 zur Redundanz von informationsverarbeitenden Einrichtungen. Wie sich diese vier der 93 Maßnahmen des Anhangs A in Scoping, Risikoanalyse und Anwendbarkeitserklärung einfügen, zeigt der Leitfaden zum Aufbau eines ISMS nach ISO 27001.

    NIS2: Betriebskontinuität wird gesetzliche Pflicht

    Die NIS2-Richtlinie (EU) 2022/2555 verlangt in Artikel 21 Absatz 2 Buchstabe c Maßnahmen zur „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement”. Umgesetzt ist das im NIS2-Umsetzungsgesetz, das am 6. Dezember 2025 in Kraft getreten ist; die Pflicht steht in § 30 Absatz 2 Nummer 3 BSIG. Betroffen sind besonders wichtige und wichtige Einrichtungen der geregelten Sektoren; für wichtige Einrichtungen greift die Schwelle grundsätzlich ab 50 Beschäftigten beziehungsweise mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme. Hinzu kommen die Meldefristen nach § 32 BSIG: Erstmeldung binnen 24 Stunden, Folgemeldung binnen 72 Stunden, Abschlussmeldung binnen eines Monats. Ohne vorbereitete Meldewege im Notfallplan sind sie kaum zu halten. Welche Schritte anstehen, fasst die NIS-2-Checkliste für KMU zusammen.

    DORA für Finanzunternehmen

    Für den Finanzsektor gilt seit dem 17. Januar 2025 die Verordnung (EU) 2022/2554 (DORA). Artikel 11 verpflichtet zu einer umfassenden IKT-Geschäftsfortführungsleitlinie als Bestandteil der allgemeinen Geschäftsfortführungsleitlinie, zu IKT-Reaktions- und Wiederherstellungsplänen sowie zu Tests mindestens jährlich und bei wesentlichen Änderungen an den IKT-Systemen; größere Unternehmen brauchen zusätzlich eine Krisenmanagementfunktion. Artikel 12 ergänzt Vorgaben zu Backup-Richtlinien und Wiederherstellungsverfahren. Details fassen die DORA-Anforderungen für Finanzunternehmen zusammen. Relevant ist das auch für IT-Dienstleister, denen die Anforderungen vertraglich weitergereicht werden.

     

    BCM im Mittelstand: pragmatisch starten

    Der Aufwand eines vollständigen BCMS schreckt viele mittelständische Unternehmen ab, für den Einstieg ist er nicht nötig. Bewährt hat sich dieses Vorgehen:

    • Geltungsbereich klein halten: Beginnen Sie mit den Prozessen, deren Ausfall Umsatz, Lieferfähigkeit oder rechtliche Pflichten gefährdet.
    • BIA im Workshop statt per Fragebogen: Zwei bis drei moderierte Termine mit den Prozessverantwortlichen liefern belastbarere Zeitparameter als ein Fragebogen.
    • Backups tatsächlich zurückspielen: Ein dokumentierter Restore-Test pro Quartal deckt mehr auf als jedes Konzeptpapier.
    • Offline-Fassung der Pläne: Notfallpläne, Kontaktlisten und Wiederanlaufreihenfolgen gehören zusätzlich in eine getrennt gespeicherte Version.
    • Dienstleister einbeziehen: Gleichen Sie die vertraglich zugesicherten Wiederherstellungszeiten Ihrer Dienstleister mit Ihren RTO-Vorgaben ab.

    Ebenso wichtig ist die Nachweisführung. Ein Auditor prüft nicht, ob Pläne existieren, sondern ob sie aktuell, freigegeben und getestet sind. Erwartet werden BCM-Leitlinie, BIA-Ergebnisse mit RTO und RPO je Prozess, Risikobeurteilung, Notfall- und Wiederanlaufpläne, Übungsprotokolle, Restore-Nachweise und Managementbewertung. Fehlt der Übungsnachweis, gilt die Kontinuitätsplanung im Zweifel als nicht wirksam umgesetzt.

     

    TrustSpace Profi-Tipp: Nachweise dort führen, wo die Risiken liegen

    BCM scheitert im Mittelstand selten am Konzept, sondern an der Pflege: Pläne veralten, Übungstermine verschieben sich, Zuständigkeiten wechseln, und im Audit fehlt der aktuelle Nachweis. Eine TrustSpace ISMS-Software hält Prozesse, Assets, Risiken und Maßnahmen an einer Stelle zusammen, verknüpft die BIA-Ergebnisse mit Systemen und Verantwortlichen und erinnert an fällige Tests. So werden die Anforderungen aus ISO 27001, NIS2 und DORA aus einem gemeinsamen Datenbestand belegbar, statt in getrennten Ablagen zu verwaisen.

     

    Typische Fehler im Business Continuity Management

    1. BCM als IT-Projekt:
    Ohne die Fachbereiche bilden die Zeitziele technische Machbarkeit ab statt geschäftlicher Notwendigkeit.

    2. Zeitziele ohne Deckung:
    Ein RTO von vier Stunden im Plan, aber ein Restore, der zwei Tage dauert: Solche Widersprüche fallen erst im Ernstfall auf, wenn niemand die Vorgaben gegen die reale Wiederherstellungsdauer prüft.

    3. Pläne ohne Übung:
    Ein nie erprobter Plan enthält verlässlich veraltete Kontaktdaten.

    4. Dienstleister ausgeblendet:
    Der eigene Notbetrieb nützt wenig, wenn ein zentraler Cloud-Dienst ohne Ersatzverfahren ausfällt.

     

    Fazit: Vorbereitung schlägt Improvisation

    Business Continuity Management beantwortet eine Frage, die sich früher oder später jedem Unternehmen stellt: Was passiert, wenn ein zentraler Prozess ausfällt, und wie lange halten wir das aus? Der Wert liegt weniger im Dokument als in der Klarheit, die es erzeugt: definierte Zeitziele, benannte Verantwortliche, geprüfte Wiederherstellungsverfahren, geübte Abläufe.

    Regulatorisch ist das Thema entschieden: NIS2 und DORA machen die Aufrechterhaltung des Betriebs zur Pflicht, ISO 27001 verankert sie im ISMS, ISO 22301 und der BSI-Standard 200-4 liefern die Methodik. Der sinnvolle Weg für den Mittelstand ist der stufenweise Aufbau: schlanke BIA, realistische Zeitziele, wenige gepflegte Pläne, regelmäßige Tests, saubere Nachweisführung.

     

    Häufige Fragen (FAQ)

    Was ist der Unterschied zwischen Business Continuity Management und Disaster Recovery?

    BCM ist der übergeordnete Rahmen und betrachtet den gesamten Geschäftsprozess samt Personal, Standorten, Lieferanten und Ersatzverfahren. Disaster Recovery ist eine Teilmenge davon und meint die technische Wiederherstellung von IT-Systemen und Daten: notwendig, aber allein nicht ausreichend, weil es den Notbetrieb der Fachbereiche nicht regelt.

    Ist Business Continuity Management gesetzlich vorgeschrieben?

    Im Anwendungsbereich von NIS2 ja: § 30 Absatz 2 Nummer 3 BSIG verlangt Maßnahmen zur Aufrechterhaltung des Betriebs einschließlich Backup-Management, Wiederherstellung und Krisenmanagement. Für Finanzunternehmen gelten seit dem 17. Januar 2025 zusätzlich die Artikel 11 und 12 der DORA-Verordnung. Alle übrigen Unternehmen trifft keine direkte Pflicht, für sie wird BCM über Kundenanforderungen und die ISO-27001-Zertifizierung relevant.

    Was bedeuten RTO, RPO und MTPD?

    Die MTPD ist die maximal tolerierbare Ausfallzeit, ab der die Folgen nicht mehr hinnehmbar sind. Das RTO ist die Zielzeit für den Wiederanlauf und liegt immer unterhalb der MTPD. Das RPO beschreibt den maximal akzeptablen Datenverlust und bestimmt die Sicherungsfrequenz. Alle drei Werte legt die Business Impact Analyse je Prozess fest.

    Welche Norm gilt für Business Continuity Management?

    Der internationale Standard ist ISO 22301 in der Fassung von 2019, nach dem sich ein BCMS zertifizieren lässt. Im deutschsprachigen Raum kommt der BSI-Standard 200-4 vom Juni 2023 hinzu, der eine kompatible Methodik mit dreistufigem Einstieg bietet. Wer ein ISMS betreibt, deckt Teile der Anforderungen über die Controls A.5.29, A.5.30, A.8.13 und A.8.14 der ISO 27001:2022 ab.

    Wie startet ein mittelständisches Unternehmen mit BCM?

    Mit einem eng gefassten Geltungsbereich und einer schlanken Business Impact Analyse für die fünf bis zehn wichtigsten Prozesse. Daraus ergeben sich Zeitziele, daraus die Strategien und erst danach die Technikinvestitionen. Ein Restore-Test und eine Schreibtischübung schaffen in wenigen Wochen mehr Sicherheit als ein Konzept, das niemand erprobt hat.

  • Die wichtigsten ISO 27001 Anforderungen für erfolgreiche IT-Sicherheit

    Die wichtigsten ISO 27001 Anforderungen für erfolgreiche IT-Sicherheit

    Die ISO 27001 ist ein international anerkannter Standard für Informationssicherheit und IT-Sicherheit. Die Entwicklung der ISO 27001 ist ein kontinuierlicher Prozess, bei dem die Norm regelmäßig an neue Sicherheitsanforderungen angepasst und weiterentwickelt wird.

    Die Norm stellt Anforderungen an Unternehmen und Organisationen für das Informationssicherheits-Managementsystem (ISMS) und das Berechtigungsmanagement, wobei verschiedene Aspekte wie organisatorische, technische und menschliche Faktoren berücksichtigt werden.

    Die Implementierung von ISO 27001 hilft Unternehmen, ein robustes ISMS zu etablieren und Sicherheitsmaßnahmen zu implementieren, wobei Best Practices im Berechtigungsmanagement, wie die Funktionstrennung und der Least Privilege Ansatz, angewendet werden.

    Die Zertifizierung nach ISO 27001 unterstützt die Einhaltung gesetzlicher Vorgaben und die Verbesserung der Informationssicherheit, indem der Bereich (Geltungsbereich) des ISMS klar definiert und abgegrenzt wird.

    Der Schutz von Informationen in allen relevanten Bereichen ist das zentrale Ziel der ISO 27001.

    ‍

    Einführung in die ISO 27001

    Die ISO 27001 ist Teil der ISO 27000-Familie und regelt die Einführung, Umsetzung, Aufrechterhaltung und Verbesserung des ISMS. Die Entwicklung der ISO Norm 27001 begann in den frühen 2000er Jahren und wurde seither durch zahlreiche Entwicklungen und Anpassungen an neue Bedrohungen und regulatorische Anforderungen kontinuierlich weiterentwickelt.

    Die Norm basiert auf der High Level Structure (HLS), die auch in anderen Managementsystemnormen wie ISO 9001 und ISO 14001 Anwendung findet, und legt besonderen Wert auf die Grundlagen und den strukturierten Aufbau der Anforderungen.

    Die ISO 27001 definiert Anforderungen an die Informationssicherheit und fordert die Bewertung und das Management von Informationssicherheitsrisiken, wobei der Kontext der Organisation und die Bedeutung des Kontextes für die Implementierung des Managementsystems hervorgehoben werden.

    Darüber hinaus werden verschiedene Aspekte der Informationssicherheit betrachtet und die Basis für die Entwicklung, Umsetzung und kontinuierliche Verbesserung des ISMS geschaffen.

    Die ISO Norm 27001 bildet die Grundlage für verschiedene Managementsysteme und beschreibt die Anforderungen an ein wirksames Managementsystems zur Informationssicherheit.

    Die Norm unterstützt die kontinuierliche Verbesserung des ISMS und die Einhaltung von Sicherheitsstandards. Ergänzend dazu dient die ISO 27002 als Leitfaden für die Umsetzung spezifischer Sicherheitsmaßnahmen und unterstützt die ISO 27001 bei der praktischen Anwendung.

    ‍

    Informationssicherheits-Managementsystem

    Ein Informationssicherheits-Managementsystem (ISMS) ist ein systematischer Ansatz zur Informationssicherheit. Informationssicherheitsmanagementsysteme stellen ein international anerkanntes Rahmenwerk dar, das Anforderungen an die Einrichtung, Umsetzung und kontinuierliche Verbesserung von Sicherheitsmanagementsystemen im Bereich der Informationssicherheit definiert.

    Das ISMS umfasst die Identifikation, Bewertung und Behandlung von Informationssicherheitsrisiken, wobei die Einrichtung des ISMS gemäß den Anforderungen der Norm erfolgt.

    Die Implementierung eines ISMS hilft Unternehmen, ihre Informationssicherheit zu verbessern und die Einhaltung von Sicherheitsstandards zu gewährleisten, wobei das Managements die Verantwortung für die Bereitstellung der Ressourcen und die Festlegung der organisatorischen Verantwortlichkeiten trägt.

    Das ISMS ist ein wichtiger Bestandteil der ISO 27001-Zertifizierung, wobei Methoden zur Bewertung der Wirksamkeit des ISMS eingesetzt werden, um die Effektivität und kontinuierliche Verbesserung des Managementsystems sicherzustellen.

    Die Dokumentation, die Erstellung und Verwaltung von Dokumenten sowie die Pflege des Dokuments mit Kernrichtlinien sind essenziell, um den Nachweis der Einhaltung der ISO 27001-Anforderungen zu erbringen und die kontinuierliche Verbesserung des Managementsystems zu unterstützen.

    ‍

    Anforderungen der ISO 27001

    • Die ISO 27001 stellt die zentrale Anforderung an die Informationssicherheit und das ISMS dar, wobei die Einhaltung internationaler Standards für den Schutz von Daten und Information im gesamten Bereich der Organisation essenziell ist.
    • Die Norm fordert die Identifikation und Bewertung von Informationssicherheitsrisiken sowie die Implementierung von Kontrollen, wobei die Dokumentation von Information und Daten eine wichtige Rolle spielt.
    • Die Anforderungen der ISO 27001 umfassen die Einhaltung von Sicherheitsstandards, die Implementierung und regelmäßige Überprüfung von Kontrollen zum Schutz sensibler Daten und zur Identifikation von Sicherheitsrisiken.
    • Die Norm unterstützt die Einhaltung von gesetzlichen Vorgaben und die Verbesserung der Informationssicherheit, indem sie kontinuierliche Verbesserungen, die Berücksichtigung verschiedener Bereiche und Themen sowie eine regelmäßige Risikoanalyse fordert.

    ‍

    ISO 27001 Zertifizierung

    Die ISO 27001-Zertifizierung ist ein Prozess, der die Einhaltung der Anforderungen der ISO 27001 überprüft und auf die Erlangung einer ISO Zertifizierung als Nachweis für ein wirksames Informationssicherheitsmanagementsystem (ISMS) abzielt. Welche Nachweise dabei konkret verlangt werden und ab wann sich der Schritt betriebswirtschaftlich rechnet, ordnet der Grundlagenbeitrag dazu ein, was eine ISO 27001-Zertifizierung ausmacht.

    Die Zertifizierung unterstützt die Einhaltung von Sicherheitsstandards und die Verbesserung der Informationssicherheit, wobei sie insbesondere für Kunden und verschiedene Branchen von Bedeutung ist, da sie Vertrauen schafft und branchenspezifische Anforderungen berücksichtigt.

    Die ISO 27001-Zertifizierung ist ein wichtiger Schritt zur Gewährleistung der Informationssicherheit in Unternehmen und Organisationen, wobei der Bereich der Zertifizierung klar definiert werden muss, um den Geltungsbereich und die betroffenen Unternehmensbereiche festzulegen. Ob Ihr Unternehmen dazugehört, klärt unser Beitrag Welche Unternehmen brauchen ISO 27001.

    Die Zertifizierung kann durch eine akkreditierte Zertifizierungsstelle durchgeführt werden. Wie viel Budget und Auditzeit dafür einzuplanen sind, hängt vor allem von Mitarbeiterzahl und Geltungsbereich ab; eine belastbare Orientierung geben die Audit-Kosten einer ISO 27001-Zertifizierung im Mittelstand. Die ISO 27001-Norm ist in Kapitel und Unterabschnitte gegliedert, die die einzelnen Anforderungen und Schritte im Zertifizierungsprozess systematisch strukturieren.

    ‍

    ISO IEC 27001

    Die ISO Norm 27001 ist eine internationale Norm und ein weltweit anerkannter Standard, der die Anforderungen an die Informationssicherheit und das ISMS regelt.

    Die Norm ist Teil der ISO 27000-Familie und basiert auf der High Level Structure (HLS), wodurch sie sich nahtlos in verschiedene Managementsysteme integrieren lässt und einen klaren Aufbau für die Umsetzung vorgibt.

    Die ISO IEC 27001 unterstützt die kontinuierliche Verbesserung des ISMS und die Einhaltung von Sicherheitsstandards, wobei aktuelle Entwicklungen, IT Grundschutz, branchenspezifische Vorgaben für KRITIS und die Sicherheit von Cloud Diensten berücksichtigt werden.

    Ein wichtiger Bestandteil der ISO 27001-Zertifizierung ist zudem die Berücksichtigung der ISO 27002 als Leitfaden für Sicherheitsmaßnahmen sowie die strukturierte Dokumentation aller relevanten Prozesse und Dokumenten im Rahmen der ISO IEC 27001.

    ‍

    Risikomanagement

    Das Risikomanagement ist ein wichtiger Bestandteil des ISMS, wobei die regelmäßige Risikoanalyse und der Einsatz geeigneter Methoden zur Bewertung der Wirksamkeit des Risikomanagements eine zentrale Rolle spielen.

    Die Identifikation, Bewertung und Behandlung von Informationssicherheitsrisiken sind wichtige Schritte im Risikomanagement, wobei insbesondere Information und Daten zur Erkennung und Bewertung von Sicherheitsrisiken herangezogen werden. Voraussetzung dafür ist ein vollständiges Verzeichnis der schützenswerten Werte: Ohne belastbares Asset Management nach ISO 27001 bleibt jede Risikobewertung eine Schätzung, weil unklar ist, welche Systeme und Daten überhaupt betroffen sind.

    Die Implementierung von Sicherheitsmaßnahmen hilft Unternehmen, ihre Informationssicherheit zu verbessern, den Schutz sensibler Daten zu gewährleisten und auf kontinuierliche Entwicklungen im Bereich der Informationssicherheit zu reagieren.

    Das Risikomanagement unterstützt die kontinuierliche Verbesserung des ISMS, indem es gezielte Verbesserungen im Risikomanagementprozess ermöglicht.

    ‍

    Betriebliche Planung und Steuerung

    Die betriebliche Planung und Steuerung sind wichtige Bestandteile des ISMS, wobei die Identifikation und Abgrenzung von Bereichen sowie des Geltungsbereichs eine zentrale Rolle für die Wirksamkeit des Managementsystems spielen.

    Die Planung und Steuerung von Prozessen und Aktivitäten helfen Unternehmen, ihre Informationssicherheit zu verbessern und die Einhaltung von Sicherheitsstandards zu gewährleisten, wobei das Managementsystem und verschiedene Methoden zur systematischen Planung und Steuerung eingesetzt werden.

    Die Implementierung von Sicherheitskontrollen und die Überwachung von Prozessen, einschließlich regelmäßiger Kontrolle und Anpassung der Kontrollen, unterstützen die kontinuierliche Verbesserung des ISMS.

    Die betriebliche Planung und Steuerung sind wichtige Schritte zur Gewährleistung der Informationssicherheit.

    ‍

    Überwachung und Bewertung

    Die Überwachung und Bewertung sind wichtige Bestandteile des ISMS, wobei insbesondere die Kontrolle und die Bewertung der Wirksamkeit der Überwachungsmaßnahmen eine zentrale Rolle spielen.

    Die Überwachung von Prozessen und Aktivitäten hilft Unternehmen, ihre Informationssicherheit zu verbessern und die Einhaltung von Sicherheitsstandards zu gewährleisten, wobei verschiedene Methoden und eine umfassende Dokumentation zur systematischen Bewertung eingesetzt werden.

    Die Bewertung von Prozessen und Aktivitäten unterstützt die kontinuierliche Verbesserung des ISMS, indem gezielt Verbesserungen im Überwachungs- und Bewertungsprozess umgesetzt werden.

    Die Überwachung und Bewertung sind wichtige Schritte zur Gewährleistung der Informationssicherheit.

    ‍

    Internes Audit

    Das interne Audit ist ein wichtiger Bestandteil des ISMS, da es die regelmäßige Kontrolle und die Überprüfung der implementierten Kontrollen im Rahmen des Informationssicherheits-Managementsystems sicherstellt.

    Das interne Audit hilft Unternehmen, ihre Informationssicherheit zu verbessern und die Einhaltung von Sicherheitsstandards zu gewährleisten, wobei die sorgfältige Verwaltung von Dokumenten und die vollständige Dokumentation aller Auditprozesse eine zentrale Rolle spielen.

    Die Durchführung von internen Audits unterstützt die kontinuierliche Verbesserung des ISMS, wobei verschiedene Methoden eingesetzt werden, um die Effektivität und Wirksamkeit des Audits zu erhöhen.

    Das interne Audit ist ein wichtiger Schritt zur Gewährleistung der Informationssicherheit.

    ‍

    Nichtkonformität und Korrekturmaßnahmen

    Die Nichtkonformität und Korrekturmaßnahmen sind wichtige Bestandteile des ISMS, wobei insbesondere die Kontrolle und die regelmäßige Überprüfung der Kontrollen eine zentrale Rolle bei der Identifikation von Nichtkonformitäten spielen.

    Die Identifikation und Behandlung von Nichtkonformitäten hilft Unternehmen, ihre Informationssicherheit zu verbessern und die Einhaltung von Sicherheitsstandards zu gewährleisten, wobei Dokumente und eine umfassende Dokumentation als Nachweis und zur systematischen Erfassung aller Maßnahmen dienen.

    Die Implementierung von Korrekturmaßnahmen unterstützt die kontinuierliche Verbesserung des ISMS, wobei geeignete Methoden, gezielte Verbesserungen und die Überprüfung der Wirksamkeit der Maßnahmen entscheidend für den nachhaltigen Erfolg sind.

    Die Nichtkonformität und Korrekturmaßnahmen sind wichtige Schritte zur Gewährleistung der Informationssicherheit.

    ‍

    Fortlaufende Verbesserung

    Die fortlaufende Verbesserung ist ein zentrales Prinzip der ISO 27001 und bildet die Grundlage für ein wirksames Informationssicherheits-Managementsystem (ISMS). Die Norm fordert von jeder Organisation, regelmäßig ihre Prozesse, Verfahren und Sicherheitsmaßnahmen zu überprüfen und weiterzuentwickeln. Dies bedeutet, dass Schwachstellen und Risiken kontinuierlich identifiziert, bewertet und durch gezielte Maßnahmen adressiert werden müssen. Die Implementierung neuer Technologien, die Anpassung an aktuelle Bedrohungen und die Optimierung bestehender Abläufe sind entscheidend, um den Anforderungen der ISO 27001 gerecht zu werden. Durch diesen kontinuierlichen Verbesserungsprozess bleibt das Managementsystem stets auf dem neuesten Stand und gewährleistet ein hohes Niveau an Informationssicherheit. So können Unternehmen und Organisationen sicherstellen, dass ihr ISMS nicht nur den aktuellen Normen entspricht, sondern auch langfristig wirksam bleibt und die Informationssicherheit nachhaltig gestärkt wird.

    ‍

    Kosten und Ressourcen

    Die Einführung und Aufrechterhaltung eines Informationssicherheitsmanagementsystems nach ISO 27001 erfordert eine sorgfältige Planung der benötigten Ressourcen. Organisationen müssen sicherstellen, dass sie über ausreichend qualifiziertes Personal, wie beispielsweise einen Informationssicherheitsbeauftragten, verfügen. Auch finanzielle Mittel für die Implementierung und Wartung von Sicherheitsmaßnahmen, Technologien und Schulungen sind notwendig, um die Anforderungen der Norm zu erfüllen. Die Investition in ein ISMS nach ISO 27001 kann zunächst mit höheren Kosten verbunden sein, bietet jedoch langfristig erhebliche Vorteile: Durch die Verbesserung der Informationssicherheit und die Einhaltung gesetzlicher und regulatorischer Vorgaben werden Risiken minimiert und potenzielle Schäden vermieden. So trägt ein gut aufgestelltes ISMS nicht nur zur Einhaltung der ISO 27001 bei, sondern auch zur nachhaltigen Sicherung der Unternehmenswerte. Wo die Ressourcen knapp sind, entscheidet vor allem die Inventarisierung über den Aufwand: Wie sich das mit einem kleinen IT-Team stemmen lässt, zeigt der Beitrag zum Asset Management im Mittelstand.

    ‍

    Mitarbeiterakzeptanz und Kommunikation

    Die erfolgreiche Implementierung und Aufrechterhaltung eines ISMS nach ISO 27001 hängt maßgeblich von der Akzeptanz und dem Engagement der Mitarbeiter ab. Es ist entscheidend, dass alle Beschäftigten die Anforderungen und Vorteile der ISO 27001 verstehen und aktiv in die Umsetzung eingebunden werden. Eine offene und transparente Kommunikation über Ziele, Maßnahmen und Verantwortlichkeiten fördert das Bewusstsein für Informationssicherheit in der gesamten Organisation. Schulungen und regelmäßige Informationsveranstaltungen helfen, das notwendige Wissen und die erforderlichen Fähigkeiten zu vermitteln, damit die Mitarbeiter die Sicherheitsrichtlinien und -prozesse konsequent einhalten. Durch die Förderung einer gelebten Sicherheitskultur und die Einbindung aller Mitarbeitenden kann die Organisation sicherstellen, dass das ISMS nicht nur formal existiert, sondern auch im täglichen Betrieb wirksam ist und die Informationssicherheit nachhaltig unterstützt.

    ‍

    ISO 27001 Checkliste: die Vorbereitung in acht Phasen

    Die Vorbereitung auf die Zertifizierung scheitert selten am fehlenden Willen, sondern an der Reihenfolge. Wer mit der Auswahl technischer Maßnahmen beginnt, bevor Anwendungsbereich und Risiken feststehen, arbeitet doppelt. Die folgende ISO 27001 Checkliste ordnet den Weg deshalb in acht Phasen, die aufeinander aufbauen: Erst wenn eine Phase belegbar abgeschlossen ist, lohnt sich die nächste.

    1. Projekt aufsetzen (Kapitel 5): Auftrag der Leitung, verabschiedete Informationssicherheitspolitik, benannte Rollen, freigegebenes Budget.
    2. Kontext und Anwendungsbereich (Kapitel 4): interne und externe Themen, interessierte Parteien, schriftlich abgegrenzter Scope samt begründeter Ausschlüsse. Seit dem Amendment 1:2024 gehört auch die Bewertung dazu, ob der Klimawandel ein relevantes Thema ist.
    3. Risiken beurteilen und behandeln (Kapitel 6.1): festgelegte Methode, bewertete Risiken, gewählte Behandlungsoptionen, Risikobehandlungsplan mit Verantwortlichen und Fristen.
    4. Maßnahmen auswählen (Anhang A): alle 93 Maßnahmen geprüft, Anwendbarkeit je Maßnahme entschieden und begründet, Erklärung zur Anwendbarkeit erstellt.
    5. Dokumentation aufbauen (Kapitel 7): die von der Norm geforderten dokumentierten Informationen liegen aktuell, versioniert und freigegeben vor.
    6. Umsetzung im Betrieb (Kapitel 8): die Prozesse laufen im Alltag, Änderungen werden gesteuert, die Risikobeurteilung wird wiederholt.
    7. Wirksamkeit prüfen (Kapitel 9): internes Audit durch unabhängige Prüfer, dokumentierte Managementbewertung, definierte Kennzahlen.
    8. Abweichungen schließen und zertifizieren (Kapitel 10): Nichtkonformitäten mit Ursachenanalyse behoben, Stufe 1 und Stufe 2 des Zertifizierungsaudits vorbereitet.

    Der zeitliche Rahmen hängt vor allem am Anwendungsbereich und am Reifegrad der bestehenden IT-Organisation. Wie sich diese acht Phasen zu einem dauerhaft betriebenen Managementsystem zusammenfügen, zeigt der Leitfaden zum Aufbau eines ISMS nach ISO 27001 im Detail; die methodische Grundlage für Phase 3 liefert die Risikobewertung nach ISO 27001 in der Praxis.

     

    Kostenlose ISO 27001 Checkliste als PDF

    Alle acht Phasen mit abhakbaren Prüfpunkten, die vollständige Liste der geforderten dokumentierten Informationen mit Klauselbezug und eine Übersicht der 93 Maßnahmen des Anhangs A: Die ausführliche Checkliste steht als PDF zum Herunterladen bereit.

    ISO 27001 Checkliste herunterladen (PDF, 8 Seiten)

     

    Eine Checkliste zeigt, was zu tun ist, ersetzt aber nicht die Nachweisführung im laufenden Betrieb. Genau dort scheitern Erstaudits am häufigsten: Richtlinien existieren, doch es fehlt der Beleg, dass danach gehandelt wird. Eine ISMS-Software wie TrustSpaceOS verknüpft Assets, Risiken, Maßnahmen und Nachweise miteinander, sodass die Erklärung zur Anwendbarkeit aus gepflegten Daten entsteht statt aus einer separaten Tabelle. Wer den Weg begleitet gehen möchte, findet in der ISO 27001-Zertifizierung mit TrustSpace die passende Unterstützung bis ins Audit.

    Ablauf der Zertifizierung

    Der Ablauf der Zertifizierung ist ein wichtiger Bestandteil des ISMS, wobei insbesondere die Erstellung und Pflege von Dokumenten sowie eine umfassende Dokumentation eine zentrale Rolle für den Nachweis der Einhaltung der Anforderungen spielen.

    Die Durchführung von Audits und die Bewertung von Prozessen, bei denen verschiedene Methoden eingesetzt werden und gezielt unterschiedliche Bereiche sowie relevante Themen des ISMS betrachtet werden, helfen Unternehmen, ihre Informationssicherheit zu verbessern und die Einhaltung von Sicherheitsstandards zu gewährleisten.

    Die Zertifizierung unterstützt die kontinuierliche Verbesserung des ISMS.

    Der Ablauf der Zertifizierung ist ein wichtiger Schritt zur Gewährleistung der Informationssicherheit.

    ‍

    Fazit

    • Die ISO 27001 ist ein wichtiger Standard für die Informationssicherheit und das ISMS, wobei die Wirksamkeit und kontinuierliche Verbesserungen des Systems im Fokus stehen.
    • Die Implementierung von Sicherheitsmaßnahmen und die Überwachung von Prozessen unterstützen die kontinuierliche Verbesserung des ISMS, indem sie den Schutz von Informationen und Daten sicherstellen.
    • Die Zertifizierung nach ISO 27001 ist ein wichtiger Schritt zur Gewährleistung der Informationssicherheit, da sie gegenüber Kunden Vertrauen schafft und die Einhaltung hoher Sicherheitsstandards belegt.
    • Die kontinuierliche Verbesserung des ISMS ist ein wichtiger Bestandteil der ISO 27001-Zertifizierung, um die Wirksamkeit der Maßnahmen zu erhöhen und den Schutz sensibler Daten und Informationen dauerhaft zu gewährleisten.

    FAQ – Häufig gestellte Fragen

    Was ist das Hauptziel eines ISMS nach ISO 27001?

    Das primäre Ziel ist der Schutz von Informationen hinsichtlich ihrer Vertraulichkeit, Integrität und Verfügbarkeit. Durch einen systematischen Ansatz werden Informationssicherheitsrisiken identifiziert, bewertet und durch gezielte Maßnahmen minimiert, um die Unternehmenswerte nachhaltig zu sichern.

    Welche Bedeutung hat der “Least Privilege” Ansatz im Berechtigungsmanagement?

    Der “Least Privilege” Ansatz (Prinzip der minimalen Rechtevergabe) stellt sicher, dass Mitarbeiter nur auf die Informationen und Systeme Zugriff erhalten, die sie für ihre spezifische Tätigkeit zwingend benötigen. Dies reduziert das Risiko von Datenmissbrauch und die Auswirkungen potenzieller Sicherheitsvorfälle erheblich.

    Wie unterscheiden sich ISO 27001 und ISO 27002?

    Die ISO 27001 definiert die Anforderungen an das Managementsystem (das “Was”) und ist die Grundlage für eine Zertifizierung. Die ISO 27002 dient hingegen als ergänzender Leitfaden, der detaillierte Empfehlungen und Best Practices für die Umsetzung der spezifischen Sicherheitsmaßnahmen (das “Wie”) bereitstellt.

    Warum ist die High Level Structure (HLS) für Unternehmen vorteilhaft?

    Da die ISO 27001 auf der High Level Structure basiert, nutzt sie dieselbe Grundstruktur, Terminologie und Definitionen wie andere Normen (z. B. ISO 9001 für Qualitätsmanagement). Dies erleichtert Unternehmen die Integration mehrerer Managementsysteme in eine gemeinsame Unternehmensstruktur erheblich.

    Was passiert bei einer Nichtkonformität während des Audits?

    Eine Nichtkonformität bedeutet, dass eine Anforderung der Norm nicht erfüllt wurde. In diesem Fall muss die Organisation Ursachenforschung betreiben und Korrekturmaßnahmen festlegen. Die Wirksamkeit dieser Maßnahmen wird anschließend überprüft, um sicherzustellen, dass das ISMS den Standard wieder vollständig erfüllt und kontinuierlich verbessert wird.

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

  • Cyber Resilience Act Bußgelder & Sanktionen: Was Verstöße kosten

    Cyber Resilience Act Bußgelder & Sanktionen: Was Verstöße kosten

    Das Wichtigste in Kürze

    • Höchststrafe: Verstöße gegen die grundlegenden Cybersicherheitsanforderungen des Cyber Resilience Act (CRA) können mit bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist.
    • Drei Bußgeldstufen: Artikel 64 der Verordnung (EU) 2024/2847 staffelt die Geldbußen nach Schwere der Pflichtverletzung (15/2,5 %, 10/2 %, 5/1 %).
    • Oft teurer als das Bußgeld: Marktrücknahme, Verkaufsverbot und der Verlust der CE-Kennzeichnung schneiden ein Produkt vom EU-Markt ab, unabhängig von jeder Geldstrafe.
    • Zuständigkeit in Deutschland: Vollzug und Bußgelder liegen bei den nationalen Marktüberwachungsbehörden; laut CRA-Durchführungsgesetz (Gesetzgebungsverfahren 2026) soll das BSI zentrale Marktüberwachungsbehörde werden.
    • Fristen: Der CRA gilt seit dem 10.12.2024, die Meldepflichten greifen ab dem 11.09.2026, die volle Anwendung inklusive Sanktionen ab dem 11.12.2027.
    • KMU: Behörden berücksichtigen die Unternehmensgröße, doch Verhältnismäßigkeit ist keine Entwarnung. Die Pflichten gelten auch für kleine und mittlere Hersteller.

     

    Für die Geschäftsführung ist der Cyber Resilience Act zunächst eine Zahl: Bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes kann ein Verstoß kosten. Diese Obergrenze allein bewegt Budgets, doch sie erzählt nur die halbe Geschichte. Die neue Cyberresilienz-Verordnung verknüpft Bußgelder mit einer Reihe weiterer Konsequenzen, die einen Hersteller oder Importeur oft härter treffen als jede Geldstrafe: Ein Produkt darf schlicht nicht mehr verkauft werden.

    Dieser Beitrag ordnet die Sanktionen sachlich ein. Er erklärt die Bußgeldstaffelung nach Artikel 64, benennt, wer die Strafen verhängt, und zeigt die nicht-monetären Folgen, die in der Risikobetrachtung häufig unterschätzt werden. Ein Rechenbeispiel stellt den möglichen Bußgeldrahmen den Kosten einer proaktiven Vorbereitung gegenüber. Wer die zeitliche Dimension einordnen will, findet die Details in der Übersicht der Fristen und Stichtage des Cyber Resilience Act.

     

    Wie hoch sind die Bußgelder unter dem Cyber Resilience Act?

    Der CRA ist eine EU-Verordnung und gilt damit unmittelbar in allen Mitgliedstaaten, ohne dass es einer nationalen Umsetzung bedarf. Die konkrete Höhe der Geldbußen legt Artikel 64 der Verordnung (EU) 2024/2847 fest. Er unterscheidet drei Stufen, abhängig davon, gegen welche Pflicht verstoßen wurde. Bei Unternehmen gilt jeweils der höhere der beiden genannten Werte, also entweder der feste Eurobetrag oder der prozentuale Anteil am weltweiten Jahresumsatz des vorangegangenen Geschäftsjahres.

    Art des Verstoßes Maximales Bußgeld
    Grundlegende Anforderungen
    Verstoß gegen die grundlegenden Cybersicherheitsanforderungen (Anhang I) sowie gegen die Pflichten der Hersteller aus Artikel 13 und 14 (u. a. Schwachstellenbehandlung und Meldepflichten)    		 bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes
    Sonstige Pflichten
    Verstoß gegen andere Pflichten der Verordnung (u. a. bestimmte Pflichten von Importeuren, Händlern und notifizierten Stellen)    		 bis 10 Mio. € oder 2 % des weltweiten Jahresumsatzes
    Falschauskünfte
    Erteilung falscher, unvollständiger oder irreführender Auskünfte gegenüber notifizierten Stellen und Marktüberwachungsbehörden    		 bis 5 Mio. € oder 1 % des weltweiten Jahresumsatzes

    Die genaue Bußgeldhöhe im Einzelfall ist kein Automatismus. Artikel 64 verpflichtet die Behörden, alle relevanten Umstände zu würdigen, insbesondere Art, Schwere und Dauer des Verstoßes und seiner Folgen, etwaige frühere Verstöße desselben Wirtschaftsakteurs sowie dessen Größe und Marktanteil. Ausdrücklich genannt ist dabei die Rücksichtnahme auf Kleinstunternehmen sowie kleine und mittlere Unternehmen einschließlich Start-ups. Eine Sonderstellung nehmen Verwalter quelloffener Software (Open-Source-Software-Stewards) ein: Sie sind von den Geldbußen des Artikels 64 ausgenommen, auch wenn andere Pflichten für sie fortbestehen.

    Wichtig für die Risikobewertung ist, dass ein Bußgeld nicht isoliert steht. Es kann zusätzlich zu anderen korrigierenden oder einschränkenden Maßnahmen verhängt werden, welche die Marktüberwachungsbehörden für denselben Verstoß anordnen. Genau diese begleitenden Maßnahmen sind es, die betriebswirtschaftlich oft schwerer wiegen.

     

    Wer verhängt die Bußgelder?

    Weil der CRA nur den Rahmen setzt und die konkreten Sanktionsregeln den Mitgliedstaaten überlässt, verhängen nationale Behörden die Bußgelder. Zuständig ist die jeweilige Marktüberwachungsbehörde, die auch die Konformität der Produkte am Markt kontrolliert. Anders als bei einer zentralen EU-Aufsicht gibt es also 27 nationale Vollzugsstränge, die sich untereinander abstimmen.

    In Deutschland wird der nationale Rahmen über das CRA-Durchführungsgesetz geschaffen, das sich Mitte 2026 im Gesetzgebungsverfahren befindet (erste Lesung im Bundestag am 11.06.2026). Nach dem vorliegenden Entwurf soll das Bundesamt für Sicherheit in der Informationstechnik (BSI) die zentrale Marktüberwachungs- und notifizierende Behörde werden. Eine Ausnahme ist vorgesehen für Produkte, die zugleich als Hochrisiko-KI-System unter die KI-Verordnung fallen; hier soll die für die KI-Aufsicht benannte Behörde zuständig sein, in Deutschland voraussichtlich die Bundesnetzagentur. Da das Gesetz noch nicht final verabschiedet ist, sollten Hersteller die Zuständigkeit vor einer konkreten Meldung oder Anfrage gegenprüfen. Am Grundsatz ändert das nichts: Der Vollzug erfolgt national, und die Behörden erhalten weitreichende Prüf- und Anordnungsbefugnisse.

     

    Was oft mehr schmerzt: die Folgen jenseits des Bußgeldes

    Ein Bußgeld ist eine einmalige, wenn auch schmerzhafte Belastung. Die folgenden Konsequenzen greifen tiefer in das Geschäftsmodell ein, weil sie die Marktfähigkeit des Produkts selbst betreffen. Für die Geschäftsführung sind sie deshalb der eigentliche Kern der CRA-Risikobetrachtung.

    Marktrücknahme und Verkaufsverbot

    Stellt die Marktüberwachungsbehörde ein nicht konformes Produkt mit digitalen Elementen fest, kann sie den Wirtschaftsakteur verpflichten, die Nichtkonformität zu beheben. Bleibt das aus oder besteht ein erhebliches Cybersicherheitsrisiko, reichen die Befugnisse bis zur Anordnung, das Produkt vom Markt zu nehmen oder zurückzurufen und die Bereitstellung auf dem Markt einzuschränken oder zu untersagen. Ein solcher Rückruf trifft nicht nur den Umsatz mit dem betroffenen Produkt, sondern verursacht Logistik-, Nachbesserungs- und Kommunikationskosten und bindet Ressourcen über Monate.

    Die CE-Kennzeichnung als Voraussetzung für den Marktzugang

    Mit dem CRA wird Cybersicherheit erstmals zu einer grundlegenden Produkteigenschaft und damit zur Bedingung für die CE-Kennzeichnung. Ein Produkt mit digitalen Elementen darf nur dann auf dem EU-Markt bereitgestellt werden, wenn es die Anforderungen erfüllt und die Konformitätsbewertung bestanden hat; erst danach darf die CE-Kennzeichnung angebracht werden (Artikel 30). Fehlt sie oder wurde sie zu Unrecht angebracht, ist das Produkt nicht verkehrsfähig. Der Marktzugang zum gesamten Europäischen Wirtschaftsraum hängt damit unmittelbar an der CRA-Konformität, nicht erst an der Frage eines möglichen Bußgeldes.

    Reputations- und Lieferkettenfolgen

    Der wirtschaftlich unterschätzte Hebel liegt in der Lieferkette. Wer Komponenten oder Software an andere Hersteller liefert, wird zunehmend erleben, dass seine B2B-Kunden die CRA-Konformität vertraglich einfordern, denn deren eigene Konformität hängt an den zugelieferten Bausteinen. Ein Hersteller, der die Anforderungen nicht nachweisen kann, verliert damit nicht nur Endkunden, sondern fällt als Zulieferer aus. Eine öffentlich gewordene Marktrücknahme oder ein gemeldeter, schlecht behandelter Sicherheitsvorfall wirkt zudem als Reputationsschaden weit über den unmittelbaren Fall hinaus.

    Zivilrechtliche Haftungsrisiken

    Parallel zum CRA hat die EU die Produkthaftung modernisiert. Die neue Produkthaftungsrichtlinie (Richtlinie (EU) 2024/2853, in Kraft seit dem 08.12.2024, umzusetzen bis zum 09.12.2026) definiert Software ausdrücklich als Produkt, unabhängig davon, ob sie auf einem Gerät gespeichert, aus der Cloud bezogen oder als Software-as-a-Service betrieben wird. Verfehlt ein Produkt den einschlägigen Sicherheitsstandard, wie ihn etwa der CRA vorgibt, kann das die Annahme eines Produktfehlers stützen. Ausdrücklich erfasst wird auch das Fehlen sicherheitsrelevanter Updates. Neben dem verwaltungsrechtlichen Bußgeld kann also ein zivilrechtliches Haftungsrisiko treten, das bis zum Ersatz von Schäden an Daten reicht.

     

    Rechenbeispiel: Was 2,5 Prozent für einen Mittelständler bedeuten

    Ein Zahlenbeispiel macht die Dimension greifbar. Angenommen, ein mittelständischer Hersteller vernetzter Geräte erzielt 50 Millionen Euro Jahresumsatz. 2,5 Prozent davon sind 1,25 Millionen Euro. Weil Artikel 64 aber den höheren der beiden Werte ansetzt, ist für dieses Unternehmen nicht der Prozentwert, sondern die feste Obergrenze von 15 Millionen Euro der maßgebliche Rahmen. Der prozentuale Deckel greift erst bei sehr großen Konzernen mit einem Jahresumsatz oberhalb von rund 600 Millionen Euro, ab denen 2,5 Prozent die 15 Millionen übersteigen.

    Das ist die für viele Geschäftsführer kontraintuitive Pointe: Gerade der Mittelstand haftet nicht nur mit einem kleinen Prozentsatz, sondern potenziell mit einem festen Betrag, der ein Vielfaches des Jahresgewinns ausmachen kann. Selbst wenn die Behörde die Verhältnismäßigkeit wahrt und deutlich unter dem Höchstmaß bleibt, kann ein Bußgeld im einstelligen Millionenbereich die Jahresrendite eines margenschwachen Betriebs übersteigen. Hinzu kommen die oben genannten nicht-monetären Folgen.

    Dem steht der Aufwand einer geordneten Vorbereitung gegenüber. Der Aufbau von Security-by-Design-Prozessen, einer Software-Stückliste (SBOM), einer nachweisbaren Schwachstellenbehandlung und der Konformitätsdokumentation bewegt sich für einen Mittelständler typischerweise im niedrigen sechsstelligen Bereich, verteilt über die Vorlaufzeit bis zur vollen Anwendung, und schafft zugleich einen Marktvorteil. Der Vergleich fällt eindeutig aus: Proaktive Compliance ist regelmäßig um eine Größenordnung günstiger als das Risiko, das sie abwendet. Eine strukturierte Herangehensweise beschreibt der Leitfaden dazu, wie sich die CRA-Anforderungen jetzt umsetzen lassen.

     

    TrustSpace Profi-Tipp: Sanktionsrisiko als Budgetargument nutzen

    Der wirksamste Hebel gegen das Bußgeldrisiko ist kein Rechtsgutachten, sondern ein belegbarer Prozess: dokumentierte Konformitätsbewertung, gepflegte SBOM, gelebte Schwachstellenbehandlung und funktionierende Meldewege. Wer diese Nachweise vorhält, entzieht dem höchsten Bußgeldtatbestand die Grundlage und ist zugleich lieferkettenfähig. Eine ISMS-Plattform bündelt Anforderungen, Verantwortlichkeiten und Nachweise an einem Ort. So lässt sich die CRA-Compliance mit TrustSpace umsetzen und im Audit wie gegenüber B2B-Kunden belastbar dokumentieren.

     

    Was bedeutet das für KMU?

    Der CRA nimmt kleine und mittlere Unternehmen nicht aus der Pflicht, mildert aber an mehreren Stellen ab. Bei der Bußgeldbemessung ist die Unternehmensgröße ausdrücklich zu berücksichtigen, und die Verordnung sieht für bestimmte Nachweise vereinfachte Formate vor. Das ist Verhältnismäßigkeit, keine Ausnahme: Die grundlegenden Anforderungen an sichere Produkte, die Konformitätsbewertung und die Meldepflichten gelten auch für den kleinen Hersteller.

    Für KMU liegt der entscheidende Vorteil im frühen Start. Wer die Prozesse bis zur vollen Anwendung schrittweise aufbaut, verteilt den Aufwand und vermeidet den teuren Endspurt kurz vor dem Stichtag. Die Sanktionslogik ähnelt darin der Regulierung im NIS-2-Umfeld; wer den Beitrag Bußgelder und Haftung unter NIS 2 kennt, erkennt das Muster: gestaffelte Bußgelder, persönliche Verantwortung der Leitungsebene und ein starker Anreiz, Nachweise vorab zu strukturieren statt reaktiv zu erklären.

     

    Fazit: Das Bußgeld ist nur die sichtbare Spitze

    Die Bußgelder des Cyber Resilience Act sind mit bis zu 15 Millionen Euro oder 2,5 Prozent des Weltumsatzes bewusst abschreckend gestaltet, und für den Mittelstand ist es die feste Obergrenze, die den Rahmen setzt. Doch die eigentliche Steuerungswirkung entfaltet der CRA über die Konsequenzen jenseits des Bußgeldes: Marktrücknahme, Verkaufsverbot, der Verlust der CE-Kennzeichnung als Eintrittskarte in den EU-Markt und die zivilrechtliche Haftung. Zusammengenommen entscheiden sie darüber, ob ein Produkt überhaupt verkäuflich bleibt.

    Für die Geschäftsführung folgt daraus eine klare Priorisierung. Das Sanktionsrisiko ist real, aber beherrschbar, sofern die Konformität frühzeitig und nachweisbar aufgebaut wird. Die Kosten dafür sind planbar und liegen deutlich unter dem Schaden, den ein Verstoß auslösen kann. Bis zur vollen Anwendung am 11.12.2027 bleibt Zeit, diese Nachweise zu strukturieren; genutzt sein will sie jetzt.

     

    Häufige Fragen (FAQ)

    Wie hoch ist das maximale Bußgeld unter dem Cyber Resilience Act?

    Bei Verstößen gegen die grundlegenden Cybersicherheitsanforderungen (Anhang I) sowie gegen die Herstellerpflichten aus Artikel 13 und 14 drohen Geldbußen von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes des Vorjahres, je nachdem, welcher Betrag höher ist. Für sonstige Pflichtverletzungen liegt die Grenze bei 10 Millionen Euro oder 2 Prozent, für Falschauskünfte bei 5 Millionen Euro oder 1 Prozent.

    Wer verhängt die Bußgelder in Deutschland?

    Der CRA überlässt die Sanktionsregeln den Mitgliedstaaten; zuständig sind die nationalen Marktüberwachungsbehörden. In Deutschland soll nach dem CRA-Durchführungsgesetz, das sich 2026 im Gesetzgebungsverfahren befindet, das BSI zentrale Marktüberwachungsbehörde werden. Für Produkte, die zugleich Hochrisiko-KI-Systeme sind, ist voraussichtlich die Bundesnetzagentur zuständig.

    Ab wann können Bußgelder verhängt werden?

    Der CRA gilt seit dem 10.12.2024, doch die Pflichten greifen gestaffelt. Die Melde- und Berichtspflichten gelten ab dem 11.09.2026, die volle Anwendung mit den durchsetzbaren Produktanforderungen und den zugehörigen Sanktionen ab dem 11.12.2027. Bis dahin sollten Hersteller die Konformität aufgebaut haben.

    Sind kleine und mittlere Unternehmen von den Bußgeldern ausgenommen?

    Nein. KMU müssen die Anforderungen des CRA erfüllen. Die Verordnung sieht jedoch Erleichterungen vor: Bei der Bußgeldbemessung ist die Unternehmensgröße zu berücksichtigen, und für bestimmte Nachweise gelten vereinfachte Formate. Verhältnismäßigkeit bedeutet also Abmilderung, nicht Befreiung.

    Was ist schlimmer als das Bußgeld selbst?

    Häufig die begleitenden Maßnahmen. Marktüberwachungsbehörden können anordnen, ein nicht konformes Produkt vom Markt zu nehmen oder zurückzurufen. Ohne CE-Kennzeichnung ist ein Produkt nicht verkehrsfähig, und B2B-Kunden verlangen in der Lieferkette den Konformitätsnachweis. Diese Folgen können ein Produkt vollständig vom Markt drängen, unabhängig von der Höhe einer Geldstrafe.

  • CRA vs. NIS2, DORA, ISO 27001 & RED: Wie die Regularien zusammengreifen

    CRA vs. NIS2, DORA, ISO 27001 & RED: Wie die Regularien zusammengreifen

    Das Wichtigste in Kürze

    • Zwei Welten plus ein Fundament: Der Cyber Resilience Act (CRA) und die Radio Equipment Directive (RED) regulieren Produkte, NIS2 und DORA regulieren Organisationen, und die ISO 27001 ist der freiwillige Standard, auf dem beide Welten aufsetzen.
    • CRA: Verordnung (EU) 2024/2847, unmittelbar geltend für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen. Vollanwendung ab 11. Dezember 2027.
    • NIS2 und DORA: Sie verpflichten Organisationen zu Cyber-Risikomanagement und Meldepflichten, NIS2 branchenübergreifend, DORA speziell im Finanzsektor.
    • RED läuft aus: Die Cybersicherheitspflichten der delegierten Verordnung (EU) 2022/30 werden zum 11. Dezember 2027 vom CRA abgelöst und aufgehoben.
    • Kernpunkt: Wer NIS2-pflichtig ist und Produkte herstellt, braucht beides. Ein sauber aufgesetztes ISMS liefert die Nachweise für CRA, NIS2, DORA und ISO 27001 aus einer Quelle, statt vier getrennter Compliance-Silos.

     

    Kaum ein Unternehmen wird heute nur von einer einzigen Cybersicherheits-Regulierung erfasst. Ein mittelständischer Maschinenbauer, der vernetzte Anlagen ausliefert, fällt unter den Cyber Resilience Act und ab 2027 unter die neue Maschinenverordnung, ist als Unternehmen einer kritischen Branche zugleich NIS2-pflichtig und zertifiziert sich für Ausschreibungen nach ISO 27001. Vier Regelwerke, vier Fristen, vier Bußgeldregime, die auf den ersten Blick nichts miteinander zu tun haben. Die Folge ist oft ein teurer Reflex: Für jede Vorschrift wird ein eigenes Projekt aufgesetzt, mit eigener Dokumentation, eigenem Verantwortlichen und eigenem Audit-Kalender.

    Dieser Vergleich ordnet das Dickicht. Er erklärt die eine Grundunterscheidung, die alles verständlich macht, stellt die fünf zentralen Regelwerke in einer Übersicht gegenüber und geht jede Paarung mit dem CRA einzeln durch. Am Ende steht die entscheidende Erkenntnis für die Planung: Wo sich die Regularien überschneiden, entstehen nicht zwangsläufig mehr Silos, sondern die Chance, ein einziges Managementsystem als gemeinsames Fundament zu nutzen. Die deutsche Bezeichnung Cyberresilienz-Verordnung meint dasselbe wie der englische Begriff Cyber Resilience Act, unter dem gesucht und international kommuniziert wird.

     

    Produkt, Organisation oder freiwilliger Standard: die eine Grundunterscheidung

    Der Schlüssel zum Verständnis liegt in einer simplen Frage: Was genau reguliert das jeweilige Regelwerk? Sobald diese Achse klar ist, sortieren sich alle Überschneidungen von selbst.

    Produkt-Regulierung setzt am einzelnen Gerät oder der einzelnen Software an. Der Cyber Resilience Act, die Radio Equipment Directive und die kommende Maschinenverordnung schreiben vor, welche Cybersicherheitseigenschaften ein Produkt haben muss, bevor es in den EU-Markt kommt. Adressat ist der, der das Produkt bereitstellt: Hersteller, Importeur, Händler. Der Nachweis erfolgt über CE-Kennzeichnung und Konformitätsbewertung.

    Organisations-Regulierung setzt am Unternehmen als Ganzem an. NIS2 und DORA fragen nicht, ob ein bestimmtes Produkt sicher ist, sondern ob die Organisation ihre Risiken beherrscht: Gibt es Risikomanagement, Meldeprozesse, Business Continuity, Lieferantensteuerung? Adressat ist die Geschäftsführung der betroffenen Einrichtung.

    Der freiwillige Standard ISO/IEC 27001 steht quer zu beiden. Er zwingt niemanden per Gesetz, liefert aber die international anerkannte Blaupause für genau das Managementsystem, das die organisatorischen Pflichten aus NIS2 und DORA und die Prozessanforderungen des CRA in geordnete Bahnen lenkt. Deshalb ist er kein vierter Konkurrent, sondern das gemeinsame Fundament.

     

    Die fünf Regelwerke im direkten Vergleich

    Die folgende Übersicht stellt die zentralen Merkmale nebeneinander. Sie zeigt auf einen Blick, warum sich die Regularien nicht ausschließen, sondern ineinandergreifen.

    Regelwerk Typ Reguliert was Gilt für wen Zentrale Fristen Sanktionen (Höchststufe)
    Cyber Resilience Act (EU) 2024/2847 Produkt-Verordnung, unmittelbar geltend Cybersicherheit von Produkten mit digitalen Elementen über den Lebenszyklus Hersteller, Importeure, Händler In Kraft 10.12.2024, Meldepflichten ab 11.09.2026, Vollanwendung 11.12.2027 bis 15 Mio. € oder 2,5 % Weltumsatz
    NIS2-Richtlinie (EU) 2022/2555 Richtlinie, nationale Umsetzung nötig Risikomanagement und Meldepflichten von Organisationen in kritischen Sektoren Wesentliche und wichtige Einrichtungen in 18 Sektoren (ab 50 Mitarbeitende oder 10 Mio. € Umsatz) EU-Frist 17.10.2024, in Deutschland seit 06.12.2025 bis 10 Mio. € oder 2 % Weltumsatz (wesentlich)
    DORA (EU) 2022/2554 Verordnung, sektorspezifisch Digitale operationale Resilienz im Finanzsektor Rund 22.000 Finanzunternehmen und ihre kritischen IKT-Drittdienstleister Gilt seit 17.01.2025 aufsichtsrechtliche Maßnahmen, Zwangs- und Bußgelder
    ISO/IEC 27001:2022 Freiwilliger internationaler Standard Aufbau und Betrieb eines Informationssicherheits-Managementsystems (ISMS) Jede Organisation freiwillig, oft vom Kunden oder Vertrag gefordert Keine gesetzliche Frist, Zertifikat drei Jahre gültig Keine gesetzlichen, Verlust der Zertifizierung
    RED 2014/53/EU + del. VO (EU) 2022/30 Produkt-Richtlinie (Funkanlagen) Cybersicherheit vernetzter Funkanlagen (Art. 3.3 d, e, f) Hersteller von Funk- und Funknetz-Produkten Cyber-Pflichten seit 01.08.2025, Ablösung durch CRA am 11.12.2027 national geregelte Marktüberwachung

    Die Maschinenverordnung (EU) 2023/1230 gehört als sechstes Regelwerk in die Spalte der Produkt-Regulierung, dazu weiter unten mehr. Wichtig ist das Muster: Zwei der fünf greifen am Produkt, zwei an der Organisation, eines ist freiwillig. Wer diese Sortierung verinnerlicht hat, versteht jede einzelne Paarung in Sekunden.

     

    CRA vs. NIS2: Produkt trifft Organisation

    Diese beiden werden am häufigsten verwechselt, weil beide „Cybersicherheit” und „EU” im Titel tragen. Tatsächlich stehen sie nebeneinander, nicht gegeneinander. Der CRA verlangt, dass ein Produkt sicher ist. NIS2 verlangt, dass eine Organisation ihre IT-Risiken beherrscht, unter anderem indem sie in ihrer Lieferkette auf die Sicherheit eingesetzter Produkte achtet.

    Damit greifen sie ineinander: Der CRA sorgt für ein höheres Grundniveau bei genau den Produkten, die NIS2-pflichtige Unternehmen einkaufen und betreiben. Wer die Grundzüge der Organisationspflicht nachlesen will, findet sie in der Zusammenfassung der NIS-2-Richtlinie. Der praktische Knackpunkt entsteht bei Unternehmen, die beides sind: NIS2-pflichtige Einrichtung und Hersteller von Produkten mit digitalen Elementen. Ein Energieversorger, der eigene Steuerungshardware baut, oder ein Industriebetrieb, der vernetzte Sensoren vertreibt, muss die Organisationspflichten aus NIS2 und die Produktpflichten aus dem CRA parallel erfüllen. Beide teilen sich denselben Unterbau aus Risikoanalyse, Schwachstellenmanagement und Vorfallmeldung, nur mit unterschiedlichem Bezugsobjekt. Ob Ihr Unternehmen produktseitig überhaupt in den Anwendungsbereich fällt, lässt sich vorab klären, indem Sie die Betroffenheit vom Cyber Resilience Act prüfen.

     

    CRA vs. DORA: der Finanzsektor als Sonderfall

    DORA (Digital Operational Resilience Act, Verordnung (EU) 2022/2554) ist die Organisations-Regulierung des Finanzsektors und gilt bereits seit dem 17. Januar 2025. Sie verpflichtet rund 22.000 Banken, Versicherer, Wertpapier- und Kryptodienstleister sowie ihre kritischen IKT-Drittanbieter zu striktem IKT-Risikomanagement, Vorfallmeldungen, regelmäßigen Resilienztests und einer engmaschigen Steuerung von Drittparteienrisiken. Ein Überblick über die Einzelpflichten findet sich in den DORA-Anforderungen für Finanzunternehmen.

    Zum CRA verhält sich DORA nach dem Grundsatz lex specialis: Das speziellere Gesetz geht dem allgemeineren vor. Für Belange, die DORA für den Finanzsektor bereits abschließend regelt, tritt der CRA zurück. Das entbindet ein Finanzunternehmen aber nicht generell: Stellt es selbst Produkte mit digitalen Elementen für den Markt her, gelten für diese Produkte weiterhin die CRA-Regeln, während DORA die organisatorische Resilienz des Unternehmens adressiert. Auch hier ist die Trennlinie wieder das Bezugsobjekt: DORA schaut auf die Organisation, der CRA auf das Produkt.

     

    CRA vs. ISO 27001: Pflicht trifft freiwilligen Standard

    Der CRA ist geltendes EU-Recht mit empfindlichen Bußgeldern. Die ISO/IEC 27001 ist ein freiwilliger Standard ohne gesetzliche Sanktion. Trotzdem ist die ISO 27001 das nützlichste Werkzeug, um den CRA praktisch zu erfüllen, denn ihr Kern ist ein Informationssicherheits-Managementsystem mit genau den Prozessen, die der CRA für Hersteller voraussetzt: Risikomanagement, Schwachstellenbehandlung, dokumentierte Verantwortlichkeiten, Umgang mit Sicherheitsvorfällen und kontinuierliche Verbesserung.

    Der CRA fordert diese Prozesse produktbezogen und verlangt zusätzlich technische Nachweise wie eine Software-Stückliste (SBOM), einen definierten Support-Zeitraum und die konkreten Anforderungen aus Annex I des Cyber Resilience Act. Die ISO 27001 wiederum liefert den organisatorischen Rahmen, in dem sich diese Nachweise sauber führen lassen. Eine bestehende ISO-27001-Zertifizierung erfüllt den CRA nicht automatisch, verkürzt aber den Weg dorthin erheblich, weil das Managementsystem bereits steht und nur um die produktspezifischen Bausteine ergänzt werden muss.

     

    TrustSpace Profi-Tipp: Erst die Prozesse, dann die Produkte

    Unternehmen, die schon ein ISMS nach ISO 27001 betreiben, sollten den CRA nicht als neues Projekt aufsetzen, sondern als Erweiterung des bestehenden Systems. Schwachstellenmanagement, Incident Response und Risikobewertung existieren dann bereits, sie müssen nur vom Organisations- auf den Produktkontext ausgeweitet werden. Wo dieser Rahmen noch fehlt oder der Zeithorizont bis zur Vollanwendung 2027 knapp wird, hilft eine strukturierte Beratung zum Cyber Resilience Act, die vorhandene Nachweise auf die Produktpflichten abbildet, statt alles neu aufzubauen.

     

    CRA vs. RED: vom Funkgeräte-Sonderweg zur einheitlichen Produktregel

    Die Radio Equipment Directive (RED, Richtlinie 2014/53/EU) war der erste EU-Rechtsakt, der verbindliche Cybersicherheitsanforderungen an Produkte stellte, allerdings nur an Funkanlagen. Über die delegierte Verordnung (EU) 2022/30 wurden die grundlegenden Anforderungen des Artikels 3 Absatz 3 Buchstaben d, e und f für bestimmte vernetzte Funkgeräte aktiviert, etwa zum Schutz des Netzes, personenbezogener Daten und vor Betrug. Diese Cybersicherheitspflichten gelten seit dem 1. August 2025, nachdem der ursprüngliche Termin um ein Jahr verschoben worden war. Die einschlägige harmonisierte Norm ist die EN 18031.

    Dieser Sonderweg für Funkgeräte ist eine Übergangslösung. Ab dem 11. Dezember 2027, mit der Vollanwendung des CRA, wird die delegierte Verordnung (EU) 2022/30 nicht mehr angewendet und von der Europäischen Kommission aufgehoben. Der CRA übernimmt die Cybersicherheitsziele der RED vollständig in seinem Annex I, aber eben nicht mehr nur für Funkanlagen, sondern für alle Produkte mit digitalen Elementen. Für Funkgeräte, die zwischen dem 1. August 2025 und dem 10. Dezember 2027 in Verkehr gebracht werden, bleiben die RED-Cybersicherheitsanforderungen weiterhin durchsetzbar. Praktisch bedeutet das: Wer heute in RED-Konformität investiert, arbeitet bereits auf das CRA-Zielbild hin, muss aber den Übergang aktiv planen, weil ab 2027 die CRA-Konformität nachzuweisen ist.

     

    Maschinenverordnung (EU) 2023/1230: Cybersicherheit wird Maschinensicherheit

    In dieselbe Familie der Produkt-Regulierung gehört die neue Maschinenverordnung (EU) 2023/1230, die ab dem 20. Januar 2027 unmittelbar in allen Mitgliedstaaten gilt und die bisherige Maschinenrichtlinie 2006/42/EG ersetzt. Erstmals enthält sie Cybersicherheit als grundlegende Sicherheitsanforderung: Maschinen mit digitalen Elementen müssen so konstruiert sein, dass ihre Sicherheitsfunktionen nicht durch unbefugte digitale Zugriffe manipuliert werden können.

    Für Maschinenbauer heißt das, dass sich CRA und Maschinenverordnung überlappen. Der CRA adressiert die Cybersicherheit der digitalen Elemente an sich, die Maschinenverordnung verknüpft sie mit der klassischen Betriebs- und Personensicherheit der Maschine. Beide fordern dieselbe Denkweise von Security by Design, Risikobeurteilung und Dokumentation, nur unter unterschiedlicher rechtlicher Flagge. Auch hier zahlt ein einmal aufgesetzter, produktbezogener Sicherheitsprozess doppelt ein.

     

    Der gemeinsame Nenner: ein ISMS als Fundament für alle vier

    Stellt man die Regelwerke nebeneinander, fällt auf, wie stark sich ihre inhaltlichen Bausteine gleichen. Risikomanagement, Schwachstellenbehandlung, Umgang mit Sicherheitsvorfällen, Lieferantensteuerung und lückenlose Nachweisführung tauchen in jedem einzelnen auf, nur mit verschobenem Bezugsobjekt und unterschiedlicher Frist.

    Gemeinsamer Baustein CRA NIS2 DORA ISO 27001
    Risikomanagement produktbezogen organisationsweit IKT-bezogen Kern des ISMS
    Schwachstellenmanagement Pflicht (Annex I) Teil der Maßnahmen Teil des IKT-Risikos Control A.8.8
    Vorfallmeldung an ENISA/CSIRT an Behörde/CSIRT an Aufsicht Managementprozess
    Lieferanten-/Drittparteirisiko Komponenten, SBOM Lieferkette IKT-Drittanbieter Control-Bereich A.5.19 ff.
    Nachweis und Dokumentation technische Doku, CE Nachweispflicht Aufsichts-Reporting Auditnachweise

    Genau darin liegt die eigentliche Botschaft dieses Vergleichs: Kein Unternehmen sollte für CRA, NIS2, DORA und ISO 27001 vier getrennte Compliance-Silos aufbauen. Ein einmal sauber aufgesetztes Informationssicherheits-Managementsystem bildet das gemeinsame Fundament. Aus ihm heraus werden dieselben Kernprozesse für jede Regulierung nur passend zugeschnitten und mit dem jeweils geforderten Nachweis bedient, statt sie viermal parallel zu pflegen. Das spart nicht nur Aufwand, sondern verhindert auch Widersprüche zwischen den Dokumentationen, die in Audits regelmäßig auffallen.

     

    Fazit: unterschiedliche Flaggen, gemeinsames Fundament

    Der Cyber Resilience Act, NIS2, DORA, die ISO 27001, die RED und die Maschinenverordnung wirken auf den ersten Blick wie sechs unverbundene Baustellen. Der Blick auf die eine Achse ordnet alles: CRA, RED und Maschinenverordnung regulieren Produkte, NIS2 und DORA regulieren Organisationen, und die ISO 27001 ist der freiwillige Standard, der beiden Welten ihren methodischen Rahmen gibt. Überall dort, wo ein Unternehmen von mehreren Regelwerken gleichzeitig erfasst wird, überlappen sich die inhaltlichen Anforderungen weit stärker, als es die getrennten Gesetzestexte vermuten lassen.

    Wer das erkennt, plant nicht mehr in Einzelprojekten, sondern baut ein Managementsystem, das mehrere Regularien zugleich bedient. Die Fristen bis 2027 sind eng genug, um jetzt mit dieser Konsolidierung zu beginnen, statt später vier getrennte Nachweisketten nachträglich zusammenzuführen.

     

    Häufige Fragen (FAQ)

    Was ist der Unterschied zwischen CRA und NIS2?

    Der Cyber Resilience Act reguliert Produkte: Er schreibt Herstellern, Importeuren und Händlern vor, welche Cybersicherheitseigenschaften ein Produkt mit digitalen Elementen haben muss. NIS2 reguliert Organisationen: Es verpflichtet Unternehmen kritischer Sektoren zu Risikomanagement und Meldeprozessen. Ein Unternehmen kann beide Pflichten gleichzeitig haben, wenn es einer NIS2-Branche angehört und zugleich Produkte herstellt.

    Gilt der CRA zusätzlich zu DORA für Finanzunternehmen?

    DORA ist für den Finanzsektor das speziellere Recht (lex specialis) und geht dem CRA vor, soweit es die Belange abschließend regelt. Stellt ein Finanzunternehmen aber selbst Produkte mit digitalen Elementen für den Markt her, gelten für diese Produkte weiterhin die Anforderungen des CRA. DORA adressiert die organisatorische Resilienz, der CRA das Produkt.

    Ersetzt der Cyber Resilience Act die ISO 27001?

    Nein. Der CRA ist verpflichtendes EU-Recht, die ISO 27001 ein freiwilliger Standard. Eine ISO-27001-Zertifizierung erfüllt den CRA nicht automatisch, liefert aber das Managementsystem mit genau den Prozessen, die der CRA voraussetzt. Ein bestehendes ISMS verkürzt den Weg zur CRA-Konformität deutlich, weil nur die produktspezifischen Bausteine ergänzt werden müssen.

    Was passiert mit den RED-Cybersicherheitsanforderungen?

    Die Cybersicherheitspflichten der delegierten Verordnung (EU) 2022/30 gelten seit dem 1. August 2025 für vernetzte Funkanlagen. Mit der Vollanwendung des CRA am 11. Dezember 2027 werden sie aufgehoben und vom CRA abgelöst, der dieselben Ziele in seinem Annex I für alle Produkte mit digitalen Elementen übernimmt. Für Funkgeräte, die vorher in Verkehr gebracht wurden, bleiben die RED-Anforderungen durchsetzbar.

    Kann ein Managementsystem mehrere dieser Regularien gleichzeitig abdecken?

    Ja, das ist der wirtschaftlich sinnvollste Weg. Risikomanagement, Schwachstellenbehandlung, Vorfallmeldung, Lieferantensteuerung und Nachweisführung sind in CRA, NIS2, DORA und ISO 27001 dieselben Kernprozesse, nur mit anderem Bezugsobjekt. Ein einmal aufgesetztes ISMS liefert diese Nachweise für alle Regularien aus einer Quelle und macht vier getrennte Compliance-Silos überflüssig.

  • Cyber Resilience Act Anforderungen: Die Pflichten aus Annex I verständlich erklärt

    Cyber Resilience Act Anforderungen: Die Pflichten aus Annex I verständlich erklärt

    Das Wichtigste in Kürze

    • Rechtsgrundlage: Die materiellen Pflichten des Cyber Resilience Act (Verordnung (EU) 2024/2847) stehen gebündelt in Anhang I (Annex I) — er ist das Herzstück jeder CRA-Konformität.
    • Zwei Teile: Teil I definiert die sicherheitsbezogenen Produkteigenschaften (Security by Design), Teil II acht Prozessanforderungen an die Schwachstellenbehandlung über den gesamten Support-Zeitraum.
    • Kernpflichten: sichere Standardkonfiguration, keine bekannten ausnutzbaren Schwachstellen, eine Software-Stückliste (SBOM) sowie kostenlose, zeitnahe Sicherheitsupdates.
    • Nachweis: technische Dokumentation (Anhang VII), Risikobewertung, Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung belegen die Einhaltung.
    • Betriebspflicht: Ab dem 11.09.2026 gelten die Meldepflichten nach Art. 14 — eine aktiv ausgenutzte Schwachstelle ist binnen 24 Stunden als Frühwarnung an CSIRT und ENISA zu melden.
    • ISMS als Rahmen: Viele Annex-I-Pflichten (Prozesse, Dokumentation, Schwachstellenmanagement) lassen sich strukturiert über ein Informationssicherheits-Managementsystem abbilden.

     

    Wer festgestellt hat, dass sein Produkt unter den Cyber Resilience Act fällt, steht sofort vor der eigentlichen Frage: Was genau muss ich jetzt tun? Die Antwort steht nicht verteilt über die gesamte Verordnung, sondern konzentriert in einem einzigen Dokument — dem Anhang I. Dort listet der Gesetzgeber die grundlegenden Cybersicherheitsanforderungen auf, die jedes Produkt mit digitalen Elementen erfüllen muss, bevor es in der EU auf den Markt kommt.

    Dieser Leitfaden übersetzt Anhang I in Praxis-Sprache: Er gliedert die Anforderungen in ihre zwei Teile, erklärt zu jeder Pflicht, was operativ dahintersteht, und zeigt, wie Sie die Einhaltung nachweisen — von der technischen Dokumentation über die Konformitätsbewertung bis zur CE-Kennzeichnung. Am Ende ordnen wir ein, welche Pflichten Hersteller, Importeure und Händler jeweils treffen.

     

    Anhang I: das Herzstück der CRA-Anforderungen

    Der Cyber Resilience Act, im Deutschen auch Cyberresilienz-Verordnung genannt, gilt EU-weit unmittelbar — es gibt kein nationales Umsetzungsgesetz. Die Pflichten ergeben sich aus dem Verordnungstext selbst, und die inhaltlich zentralen stehen in Anhang I unter der Überschrift „Grundlegende Cybersicherheitsanforderungen”.

    Anhang I ist in zwei Teile geteilt, und diese Trennung ist der Schlüssel zum Verständnis der Verordnung. Teil I beschreibt Eigenschaften, die das Produkt selbst mitbringen muss — sicheres Design und sichere Entwicklung. Teil II beschreibt Prozesse, die der Hersteller dauerhaft betreiben muss — den Umgang mit Schwachstellen, nachdem das Produkt auf dem Markt ist. Vereinfacht: Teil I ist eine Momentaufnahme des Produkts, Teil II eine laufende Verpflichtung über den gesamten Lebenszyklus.

    Der CRA ist dabei nur eine von mehreren Regulierungen, die parallel auf Unternehmen einwirken. Wie er sich zu verwandten Rahmenwerken verhält, erläutert der Beitrag Cyber Resilience Act im Vergleich zu NIS2, DORA und ISO 27001 im Detail — für die konkreten Produktpflichten bleibt jedoch Anhang I der maßgebliche Text.

     

    Annex I Teil I: sichere Produkteigenschaften (Security by Design)

    Teil I verlangt, dass ein Produkt mit digitalen Elementen so konzipiert, entwickelt und hergestellt wird, dass es ein angemessenes Cybersicherheitsniveau bietet. Aus einer vorgeschalteten Risikobewertung leitet der Hersteller ab, welche der folgenden Anforderungen relevant sind. Die folgende Tabelle übersetzt sie in ihre praktische Bedeutung.

    Anforderung (Annex I, Teil I) Was das operativ bedeutet
    Keine bekannten ausnutzbaren Schwachstellen Bekannte Lücken sind vor Markteinführung geschlossen; ein Produkt mit offenem, bekanntem CVE darf nicht ausgeliefert werden.
    Sichere Standardkonfiguration Sicher voreingestellter Auslieferungszustand (Secure by Default) mit Reset-Möglichkeit — keine Standardpasswörter, keine unnötig offenen Dienste.
    Behebbarkeit über Sicherheitsupdates Schwachstellen lassen sich per Update beheben, wo sinnvoll automatisch; die Update-Fähigkeit ist technisch von Anfang an eingeplant.
    Schutz vor unbefugtem Zugriff Angemessene Zugangskontrolle über Authentifizierung und Identitäts- bzw. Zugriffsmanagement.
    Vertraulichkeit der Daten Schutz gespeicherter und übertragener Daten durch Verschlüsselung nach dem Stand der Technik (at rest und in transit).
    Integrität Schutz von Daten, Befehlen, Programmen und Konfiguration gegen unbefugte Manipulation.
    Datenminimierung Verarbeitet werden nur die für den vorgesehenen Zweck erforderlichen Daten.
    Verfügbarkeit und DoS-Resilienz Wesentliche Funktionen bleiben auch nach einem Vorfall verfügbar; Widerstand gegen Denial-of-Service-Angriffe.
    Minimierte Angriffsfläche Reduktion externer Schnittstellen und nicht benötigter Funktionen auf das Notwendige.
    Wirkungsbegrenzung (Exploitation Mitigation) Technische Mechanismen begrenzen den Schaden, falls es doch zu einem Vorfall kommt.
    Sicherheitsrelevante Protokollierung Aufzeichnung und Überwachung interner Aktivitäten wie Datenzugriffe und -änderungen.
    Sichere Datenlöschung Nutzer können alle Daten und Einstellungen sicher und dauerhaft entfernen.

    Keine dieser Anforderungen gilt für jedes Produkt gleich. Der CRA folgt einem risikobasierten Ansatz: Welche Maßnahmen in welcher Tiefe nötig sind, ergibt sich aus der Cybersicherheits-Risikobewertung, die der Hersteller ohnehin durchführen und dokumentieren muss — ein einfacher Sensor braucht andere Vorkehrungen als eine industrielle Steuerung.

     

    Annex I Teil II: Pflichten zum Schwachstellenmanagement

    Teil II wird von vielen Herstellern unterschätzt, weil er nicht mit dem Verkauf endet, sondern dann erst richtig beginnt: Er verlangt einen dauerhaften Prozess zur Behandlung von Schwachstellen über den gesamten Support-Zeitraum. Acht Anforderungen bilden diesen Prozess:

    • Software-Stückliste (SBOM): Der Hersteller dokumentiert die Komponenten seines Produkts in einer maschinenlesbaren Software Bill of Materials, die zumindest die wichtigsten Abhängigkeiten abdeckt (etablierte Formate: CycloneDX, SPDX). Ohne diese Transparenz lässt sich nicht sagen, welche Fremdkomponente von einer neuen Schwachstelle betroffen ist.
    • Schwachstellen unverzüglich beheben: Bekannt gewordene Lücken werden ohne unnötige Verzögerung adressiert, insbesondere durch Sicherheitsupdates.
    • Regelmäßige Tests und Prüfungen: Die Produktsicherheit wird wirksam und wiederkehrend getestet und überprüft, nicht nur einmalig vor dem Launch.
    • Offenlegung behobener Schwachstellen: Ist ein Update verfügbar, werden Informationen zu den behobenen Schwachstellen geteilt und öffentlich bereitgestellt, samt Beschreibung.
    • Policy zur koordinierten Offenlegung: Der Hersteller etabliert und lebt eine Coordinated-Vulnerability-Disclosure-Policy, die den geordneten Umgang mit gemeldeten Lücken regelt.
    • Kontaktadresse für Meldungen: Es gibt eine benannte Anlaufstelle, an die Sicherheitsforscher und Dritte potenzielle Schwachstellen melden können.
    • Sichere Update-Verteilung: Updates werden über sichere Mechanismen ausgeliefert, damit Lücken zeitnah und ohne neue Risiken geschlossen werden.
    • Kostenlose Sicherheitsupdates: Verfügbare Sicherheitsupdates werden unverzüglich und — sofern nicht anders vereinbart — kostenlos bereitgestellt, getrennt von reinen Funktionsupdates.

    Wer ein gelebtes Schwachstellenmanagement mit klaren Phasen bereits betreibt, hat den Kern von Teil II schon abgedeckt — der CRA gibt diesem Prozess lediglich einen verbindlichen gesetzlichen Rahmen und ergänzt die Melde- und Offenlegungspflichten.

     

    TrustSpace Profi-Tipp: SBOM ist kein Einmal-Dokument

    Die häufigste Fehlannahme lautet, die Software-Stückliste sei ein Nachweis, den man einmal erstellt und ablegt. Tatsächlich verlangt Anhang I, dass die SBOM über den gesamten Support-Zeitraum aktuell gehalten wird. Sinnvoll ist deshalb, sie in die CI/CD-Pipeline zu integrieren und automatisiert gegen Schwachstellendatenbanken abzugleichen. So wird aus einer statischen Liste ein Frühwarnsystem, das genau die Meldepflichten aus Art. 14 bedienbar macht.

     

    Der Support-Zeitraum: wie lange Sie liefern müssen

    Eine der praktisch folgenreichsten Vorgaben betrifft den Support-Zeitraum. Der Hersteller muss festlegen, wie lange er Sicherheitsupdates bereitstellt, und diesen Zeitraum an der realistisch erwarteten Nutzungsdauer des Produkts ausrichten. Als Faustregel gilt ein Zeitraum von mindestens fünf Jahren — kürzer nur, wenn das Produkt erkennbar für eine kürzere Nutzung bestimmt ist.

    Das Ende des Support-Zeitraums muss bereits zum Kaufzeitpunkt klar angegeben werden, mindestens mit Monat und Jahr. Für die Produktplanung heißt das, Update-Fähigkeit und Wartungsbudget über Jahre einzukalkulieren — eine Verpflichtung, die weit über den Verkaufsmoment hinausreicht.

     

    Wie weise ich die Konformität nach?

    Die Anforderungen aus Anhang I zu erfüllen ist das eine — sie belegen zu können das andere. Der CRA verlangt einen durchgängigen Nachweis, der auf drei Säulen ruht.

    1. Risikobewertung und technische Dokumentation. Grundlage ist eine dokumentierte Cybersicherheits-Risikobewertung, aus der hervorgeht, welche Anforderungen aus Anhang I für das Produkt gelten und wie sie umgesetzt wurden. Sie fließt in die technische Dokumentation ein, deren Mindestinhalt Anhang VII vorgibt: Produktbeschreibung, Design- und Entwicklungsinformationen, Bewertung der grundlegenden Anforderungen, SBOM und Angaben zum Support-Zeitraum. Diese Unterlagen sind mindestens zehn Jahre nach dem Inverkehrbringen — oder für die Dauer des Support-Zeitraums, je nachdem was länger ist — für die Marktüberwachungsbehörden bereitzuhalten.

    2. Konformitätsbewertung. Anschließend wird die Übereinstimmung mit den Anforderungen in einem geregelten Verfahren bewertet. Welches Verfahren zulässig ist, hängt von der Risikoklasse des Produkts ab:

    Produktkategorie Zulässiges Bewertungsverfahren
    Standardprodukte (nicht gesondert gelistet) Interne Selbstbewertung (Modul A) durch den Hersteller ausreichend.
    Wichtige Produkte, Klasse I (Anhang III) Selbstbewertung nur bei vollständiger Anwendung harmonisierter Normen oder eines Cybersicherheitsschemas; sonst notifizierte Stelle.
    Wichtige Produkte, Klasse II (Anhang III) Verpflichtende Drittprüfung durch eine notifizierte Stelle.
    Kritische Produkte (Anhang IV) Gegebenenfalls europäisches Cybersicherheits-Zertifizierungsschema erforderlich.

    3. EU-Konformitätserklärung und CE-Kennzeichnung. Ist die Bewertung positiv, stellt der Hersteller die EU-Konformitätserklärung aus (Muster in Anhang V) und bringt die CE-Kennzeichnung an. Erst sie signalisiert, dass das Produkt die Anforderungen des CRA und aller weiteren einschlägigen EU-Vorschriften erfüllt. Wie sich diese Nachweisschritte in einen Gesamtfahrplan einordnen, zeigt der Leitfaden zur CRA-Umsetzung in klaren Schritten.

     

    Meldepflichten nach Art. 14 als laufende Betriebspflicht

    Anhang I regelt Produkt und Prozesse — die Meldepflichten nach Art. 14 kommen als eigenständige Betriebspflicht hinzu und greifen früher als die Vollanwendung: bereits ab dem 11.09.2026. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gestaffelt nach Fristen an das CSIRT ihres Hauptniederlassungs-Mitgliedstaats und an die EU-Agentur ENISA melden.

    Frist Meldung bei aktiv ausgenutzter Schwachstelle
    24 Stunden Frühwarnung an CSIRT und ENISA.
    72 Stunden Vollständigere Meldung mit ersten Bewertungen und, soweit verfügbar, Korrekturmaßnahmen.
    14 Tage Abschlussbericht, nachdem eine Korrektur- oder Abhilfemaßnahme bereitsteht.

    Für schwerwiegende Sicherheitsvorfälle gilt dieselbe 24- und 72-Stunden-Taktung, der Abschlussbericht ist hier binnen eines Monats fällig. Diese enge Taktung macht das Schwachstellenmanagement aus Teil II zum operativen Bereitschaftsprozess — 24 Stunden lassen keinen Raum für erst dann aufzubauende Strukturen.

     

    Hersteller, Importeur, Händler: wer trägt welche Pflicht?

    Die Hauptlast trägt der Hersteller, doch der CRA nimmt die gesamte Lieferkette in die Verantwortung. Wer als Importeur oder Händler ein Produkt unter eigenem Namen vermarktet oder wesentlich verändert, gilt rechtlich selbst als Hersteller und übernimmt dessen volle Pflichten aus Art. 13 und 14.

    Rolle Kernpflichten
    Hersteller Anhang I erfüllen, Risikobewertung und technische Dokumentation erstellen, Konformitätsbewertung durchführen, CE anbringen, Support-Zeitraum festlegen, Schwachstellen behandeln und melden.
    Importeur Nur konforme Produkte in Verkehr bringen; prüfen, dass Konformitätsbewertung, CE-Kennzeichnung, EU-Konformitätserklärung und Dokumentation vorliegen; Risiken an Hersteller und Behörden melden.
    Händler Mit gebotener Sorgfalt prüfen, dass CE-Kennzeichnung und erforderliche Unterlagen vorhanden sind; keine erkennbar nicht-konformen Produkte bereitstellen; bei Kenntnis von Schwachstellen informieren.

     

    Von der Anforderung zum Prozess: Annex I über ein ISMS abdecken

    Bei genauem Hinsehen sind viele Annex-I-Pflichten keine reinen Produktthemen, sondern Managementaufgaben: dokumentiertes Schwachstellenmanagement, gepflegte Komponenten- und Asset-Übersicht, definierte Verantwortlichkeiten, wiederkehrende Tests, nachvollziehbare Risikobewertungen und belastbare Nachweise. Genau das ist der Gegenstand eines Informationssicherheits-Managementsystems (ISMS).

    Ein ISMS — etwa nach ISO 27001 — liefert die Struktur, um diese Pflichten nicht als lose Einzelmaßnahmen, sondern als ineinandergreifende, auditierbare Prozesse zu betreiben. Das Schwachstellenmanagement aus Teil II deckt sich weitgehend mit der ISO-Control zur Handhabung technischer Schwachstellen; Dokumentation und Risikobewertung sind ohnehin Kern jedes Managementsystems. Wer bereits ein ISMS betreibt, fängt für den CRA nicht bei null an, sondern erweitert seine vorhandenen Prozesse gezielt um die produktbezogenen Anforderungen.

    Genau an dieser Schnittstelle setzt die CRA-Compliance-Beratung von TrustSpace an: Sie verbindet die Anforderungen aus Anhang I mit einem strukturierten Managementsystem, sodass Nachweisführung, Schwachstellenprozess und Meldepflichten aus einer Hand belegbar werden — statt in verstreuten Dokumenten und Ad-hoc-Reaktionen.

     

    TrustSpace Profi-Tipp: mit der Risikobewertung starten, nicht mit der Checkliste

    Viele Unternehmen arbeiten Anhang I als Abhakliste von oben nach unten ab. Wirksamer ist der umgekehrte Weg: zuerst die Cybersicherheits-Risikobewertung für das konkrete Produkt, denn sie bestimmt, welche Anforderungen in welcher Tiefe greifen. Aus ihr leiten sich Maßnahmen, Konformitätsroute und Support-Zeitraum ab — und der Aufwand fließt dorthin, wo das Risiko tatsächlich liegt.

     

    Fazit: Anhang I ist die To-do-Liste des CRA

    Der Cyber Resilience Act wirkt umfangreich, doch die eigentlichen Pflichten lassen sich auf einen klaren Kern eindampfen. Anhang I Teil I definiert, wie das Produkt beschaffen sein muss: sicher konfiguriert, frei von bekannten Lücken, aktualisierbar, verschlüsselt, mit minimierter Angriffsfläche. Teil II definiert den Prozess dahinter: Schwachstellen dokumentieren, beheben, offenlegen und über den Support-Zeitraum begleiten, gestützt auf eine aktuelle SBOM.

    Nachgewiesen wird all das über Risikobewertung, technische Dokumentation, Konformitätsbewertung und CE-Kennzeichnung, ergänzt um die laufenden Meldepflichten nach Art. 14. Wer diese Anforderungen nicht als Einzelaufgaben, sondern als zusammenhängenden, in ein Managementsystem eingebetteten Prozess versteht, verwandelt eine regulatorische Pflicht in einen belastbaren Nachweis von Produktsicherheit — und erspart sich die Hektik, kurz vor der Vollanwendung am 11.12.2027 Strukturen aufzubauen, die längst hätten laufen sollen.

     

    Häufige Fragen (FAQ)

    Was steht konkret in Annex I des Cyber Resilience Act?

    Anhang I enthält die grundlegenden Cybersicherheitsanforderungen des CRA in zwei Teilen. Teil I beschreibt sicherheitsbezogene Produkteigenschaften wie sichere Standardkonfiguration, Verschlüsselung, minimierte Angriffsfläche und die Freiheit von bekannten ausnutzbaren Schwachstellen. Teil II beschreibt acht Prozessanforderungen zur Schwachstellenbehandlung, darunter die Erstellung einer SBOM, die unverzügliche Behebung von Schwachstellen und kostenlose Sicherheitsupdates.

    Was ist eine SBOM und warum verlangt der CRA sie?

    Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste aller Softwarekomponenten und Abhängigkeiten eines Produkts. Anhang I Teil II verlangt sie, damit Hersteller jederzeit nachvollziehen können, welche Komponente von einer neu bekannt gewordenen Schwachstelle betroffen ist. Gängige Formate sind CycloneDX und SPDX; die Liste muss über den gesamten Support-Zeitraum aktuell gehalten werden.

    Wie weise ich die Einhaltung der CRA-Anforderungen nach?

    Der Nachweis ruht auf einer dokumentierten Risikobewertung, der technischen Dokumentation nach Anhang VII, einer Konformitätsbewertung, der EU-Konformitätserklärung und der CE-Kennzeichnung. Je nach Risikoklasse des Produkts genügt eine Selbstbewertung oder es ist die Prüfung durch eine notifizierte Stelle erforderlich. Die Unterlagen sind mindestens zehn Jahre bereitzuhalten.

    Gelten die CRA-Pflichten auch für Importeure und Händler?

    Ja. Importeure dürfen nur konforme Produkte in Verkehr bringen und müssen prüfen, dass CE-Kennzeichnung, Konformitätserklärung und Dokumentation vorliegen. Händler prüfen mit gebotener Sorgfalt das Vorhandensein der CE-Kennzeichnung und der Unterlagen. Wer ein Produkt unter eigenem Namen vermarktet oder wesentlich verändert, gilt als Hersteller und trägt dessen volle Pflichten.

    Ab wann gelten die Meldepflichten nach Art. 14?

    Die Meldepflichten greifen ab dem 11.09.2026 und damit vor der Vollanwendung des CRA am 11.12.2027. Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle sind binnen 24 Stunden als Frühwarnung, binnen 72 Stunden als Meldung und mit Abschlussbericht (14 Tage bei Schwachstellen, ein Monat bei Vorfällen) an das zuständige CSIRT und an ENISA zu melden.

  • Cyber Resilience Act Fristen & Zeitplan: Diese Deadlines zählen

    Cyber Resilience Act Fristen & Zeitplan: Diese Deadlines zählen

    Das Wichtigste in Kürze

    • Rechtsgrundlage: Der Cyber Resilience Act (Verordnung (EU) 2024/2847, deutsch Cyberresilienz-Verordnung) ist am 10. Dezember 2024 in Kraft getreten und gilt EU-weit unmittelbar, ganz ohne nationale Umsetzung.
    • Drei entscheidende Stichtage: 11. Juni 2026 (Regelungen zu notifizierten Stellen), 11. September 2026 (Melde- und Berichtspflichten nach Art. 14) und 11. Dezember 2027 (Vollanwendung aller übrigen Pflichten).
    • 24-Stunden-Meldepflicht ab 11.09.2026: Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle binnen 24 Stunden als Frühwarnung an den zuständigen CSIRT und die ENISA melden.
    • Vollanwendung ab 11.12.2027: Ab diesem Tag greifen CE-Kennzeichnung, Konformitätsbewertung, grundlegende Sicherheitsanforderungen und die technische Dokumentation.
    • Handlungsdruck: Wer 2027 konform sein will, muss 2026 starten. Gap-Analyse, Security by Design, Dokumentation und Konformitätsbewertung brauchen realistisch zwölf bis achtzehn Monate Vorlauf.

     

    Der Cyber Resilience Act ist keine ferne Ankündigung mehr, sondern ein laufender Countdown. Die Verordnung ist bereits in Kraft, und die erste harte Frist greift in wenigen Wochen: Ab dem 11. September 2026 gilt die 24-Stunden-Meldepflicht für aktiv ausgenutzte Schwachstellen. Damit ist der CRA für Hersteller, Importeure und Händler von Produkten mit digitalen Elementen keine Frage des Ob mehr, sondern des Wann und Wie schnell. Wer die Stichtage kennt und rückwärts plant, behält die Kontrolle. Wer wartet, gerät unter Zeitdruck bei einem Vorhaben, das sich nicht in Wochen erledigen lässt.

    Dieser Beitrag ordnet die Fristen des Cyber Resilience Act chronologisch, erklärt für jeden Stichtag konkret, was gilt und wer handeln muss, und rechnet vor, warum der Startpunkt für die meisten Unternehmen im Jahr 2026 liegt. Einen vollständigen Überblick zum Cyber Resilience Act mit Scope, Produktklassen und Sanktionen finden Sie auf unserer Themenseite. Hier steht der Zeitplan im Mittelpunkt.

     

    Cyber Resilience Act: Ab wann gilt was?

    Der Cyber Resilience Act ist am 20. November 2024 im Amtsblatt der EU veröffentlicht worden und zwanzig Tage später, am 10. Dezember 2024, in Kraft getreten. Damit begann die gestaffelte Übergangsfrist. Anders als bei einer Richtlinie mussten die Mitgliedstaaten den CRA nicht erst in nationales Recht überführen: Als Verordnung gilt er in allen 27 EU-Staaten unmittelbar und einheitlich. Für Unternehmen heißt das, dass die Termine fest stehen und nicht von einer nationalen Umsetzung abhängen.

    Die Verordnung wird nicht auf einen Schlag wirksam, sondern in drei Stufen. Diese Staffelung ist bewusst gewählt: Zuerst muss die Infrastruktur für die Konformitätsbewertung stehen, dann greifen die Meldepflichten, und erst am Ende folgt die volle Produktverantwortung. Die folgende Timeline zeigt die vier zentralen Daten im Überblick.

    Datum Was gilt ab diesem Tag Wer muss handeln
    10.12.2024 Der Cyber Resilience Act tritt in Kraft, die Übergangsfrist beginnt. Alle Wirtschaftsakteure: Der Countdown läuft, die Vorbereitung sollte anlaufen.
    11.06.2026 Die Regelungen zu notifizierten Stellen (Kapitel IV) gelten. Konformitätsbewertungsstellen können benannt werden; Hersteller kritischer Produkte sichern sich Prüfkapazität.
    11.09.2026 Die Melde- und Berichtspflichten nach Art. 14 gelten. Hersteller: 24-Stunden-Frühwarnung an CSIRT und ENISA bei aktiv ausgenutzten Schwachstellen und schweren Vorfällen.
    11.12.2027 Vollanwendung aller übrigen Pflichten des Cyber Resilience Act. Hersteller, Importeure und Händler: CE-Kennzeichnung, Konformitätsbewertung, grundlegende Anforderungen, Dokumentation.

    Ob und wie stark diese Termine Sie treffen, hängt von Ihrer Rolle in der Lieferkette ab. Der erste Schritt zur Einordnung ist deshalb die Frage, wer vom Cyber Resilience Act betroffen ist: vom Hersteller physischer Geräte mit Software über den Anbieter reiner Softwareprodukte bis zum Importeur, der Produkte aus Drittländern in den EU-Markt bringt.

     

    11. Juni 2026: Die notifizierten Stellen gehen an den Start

    Der erste operative Stichtag betrifft nicht die Hersteller direkt, ist für sie aber trotzdem wichtig. Ab dem 11. Juni 2026 gelten die Vorschriften des Kapitels IV zur Benennung von Konformitätsbewertungsstellen. Das sind die unabhängigen Prüforganisationen, die bei bestimmten Produktkategorien die Konformität mit dem CRA bewerten und die dafür von den Mitgliedstaaten offiziell notifiziert, also autorisiert, werden müssen.

    Für Hersteller von Produkten der höheren Risikoklassen, die eine Bewertung durch eine solche Stelle brauchen, ist das ein leises, aber wichtiges Signal: Die Prüfinfrastruktur baut sich erst ab Mitte 2026 auf. Erfahrungsgemäß sind die Kapazitäten notifizierter Stellen zu Beginn knapp und die Nachfrage vor einer großen EU-Frist hoch. Wer eine externe Konformitätsbewertung einplanen muss, sollte den Prüfweg früh klären und sich nicht darauf verlassen, kurz vor Ende 2027 noch kurzfristig einen Termin zu bekommen.

     

    11. September 2026: Was die 24-Stunden-Meldepflicht konkret bedeutet

    Der Stichtag mit der höchsten Dringlichkeit ist der 11. September 2026. Ab diesem Tag gelten die Melde- und Berichtspflichten nach Artikel 14 des Cyber Resilience Act, und zwar unabhängig davon, ob die übrigen Produktpflichten schon greifen. Hersteller müssen ab dann zwei Arten von Ereignissen aktiv melden: aktiv ausgenutzte Schwachstellen in ihren Produkten mit digitalen Elementen und schwere Sicherheitsvorfälle, die die Sicherheit dieser Produkte beeinträchtigen.

    Die Meldung folgt einer festen, mehrstufigen Kaskade mit engen Fristen. Sie läuft über eine einheitliche Meldeplattform an den zuständigen nationalen CSIRT (Computer Security Incident Response Team), der die Information zeitgleich der EU-Cybersicherheitsagentur ENISA zur Verfügung stellt:

    • Frühwarnung binnen 24 Stunden: Innerhalb eines Tages, nachdem der Hersteller von einer aktiv ausgenutzten Schwachstelle oder einem schweren Vorfall Kenntnis erlangt, muss eine erste Frühwarnung abgesetzt werden.
    • Meldung binnen 72 Stunden: Spätestens nach drei Tagen folgt eine ausführlichere Meldung mit einer ersten Bewertung des Vorfalls und, soweit verfügbar, Angaben zu Korrektur- oder Abhilfemaßnahmen.
    • Abschlussbericht: Bei aktiv ausgenutzten Schwachstellen ist spätestens 14 Tage nach Bereitstellung einer Korrekturmaßnahme ein Abschlussbericht fällig, bei schweren Vorfällen innerhalb eines Monats.

    Der Kern dieser Regelung ist die 24-Stunden-Frist. Sie zwingt Unternehmen dazu, Erkennung, Bewertung und Meldeweg vorher organisiert zu haben, denn 24 Stunden reichen nicht, um erst im Ernstfall Zuständigkeiten zu klären. Wer bis September 2026 keinen definierten Prozess hat, wer eine relevante Schwachstelle erkennt, wer die Meldung verantwortet und über welchen Kanal sie erfolgt, riskiert im Vorfall einen Fristverstoß. Diese Pflicht greift zudem für Produkte, die bereits im Markt sind, nicht nur für neu in Verkehr gebrachte. Genau deshalb ist der 11. September 2026 für viele Hersteller die eigentlich erste harte CRA-Frist.

     

    TrustSpace Profi-Tipp: Den Meldeprozess vor dem Ernstfall proben

    Ein Meldeprozess, der nur auf dem Papier existiert, hält der 24-Stunden-Frist nicht stand. Definieren Sie vor September 2026 klar, wer eine aktiv ausgenutzte Schwachstelle bewertet, wer die Meldung an den CSIRT freigibt und wer sie technisch absetzt, und halten Sie einen Kontakt- und Eskalationsplan bereit. Ein kurzer Trockenlauf mit einem fiktiven Vorfall zeigt schneller als jede Richtlinie, wo die Kette hakt, und macht aus einer abstrakten Pflicht einen belastbaren Ablauf.

     

    11. Dezember 2027: Die Vollanwendung des Cyber Resilience Act

    Der 11. Dezember 2027 ist der Stichtag, an dem der Cyber Resilience Act in vollem Umfang gilt. Ab diesem Tag dürfen Produkte mit digitalen Elementen nur noch auf dem EU-Markt bereitgestellt werden, wenn sie die grundlegenden Cybersicherheitsanforderungen erfüllen, eine Konformitätsbewertung durchlaufen haben, mit der CE-Kennzeichnung versehen sind und über eine vollständige technische Dokumentation verfügen. Damit wird Cybersicherheit zur Marktzugangsvoraussetzung, vergleichbar mit anderen CE-Anforderungen an die Produktsicherheit.

    Hinter diesem einen Datum steht die Masse der Arbeit. Security by Design über den gesamten Produktlebenszyklus, ein Schwachstellen-Handling mit Bereitstellung von Sicherheitsupdates über einen definierten Supportzeitraum, eine Software-Stückliste (SBOM) und die lückenlose Dokumentation der Sicherheitsmaßnahmen gehören dazu. Welche Pflichten und Anforderungen des CRA im Einzelnen bis zu diesem Termin erfüllt sein müssen, entscheidet maßgeblich über den Aufwand und damit über den nötigen Vorlauf.

     

    Warum Sie 2026 starten müssen, um 2027 konform zu sein

    Bis Dezember 2027 klingt nach viel Zeit. Rechnet man den typischen Projektverlauf jedoch rückwärts, schrumpft der Puffer schnell. Ein CRA-Konformitätsprojekt durchläuft für die meisten Hersteller vier Phasen, die aufeinander aufbauen und sich nur begrenzt parallelisieren lassen:

    • Gap-Analyse und Produktklassifizierung (1 bis 3 Monate): Bestandsaufnahme aller Produkte mit digitalen Elementen, Einordnung in die CRA-Kategorien und Abgleich des Ist-Zustands mit den grundlegenden Anforderungen.
    • Umsetzung von Security by Design und Prozessen (6 bis 12 Monate): technische Anpassungen an den Produkten, Aufbau des Schwachstellen-Handlings, Update-Mechanismen, SBOM-Erstellung und die Verankerung im Entwicklungsprozess.
    • Technische Dokumentation und Nachweise (2 bis 4 Monate, überlappend): Erstellung der technischen Unterlagen, der Risikobewertung und der Konformitätsdokumentation, die den Nachweis der Anforderungen belegen.
    • Konformitätsbewertung und CE-Kennzeichnung (1 bis 3 Monate, ggf. mit externer Stelle): interne Bewertung oder Prüfung durch eine notifizierte Stelle, abschließende Konformitätserklärung und Anbringen der CE-Kennzeichnung.

    In Summe sind das realistisch zwölf bis achtzehn Monate, bei komplexen Produktportfolios oder externer Bewertung eher mehr. Zieht man vom 11. Dezember 2027 diese Dauer ab, landet der sinnvolle Startpunkt spätestens in der ersten Jahreshälfte 2026. Hinzu kommt, dass die 24-Stunden-Meldepflicht ohnehin schon ab September 2026 steht. Wer diesen Prozess aufsetzt, hat einen guten Teil der organisatorischen Grundlagen für die spätere Vollanwendung bereits geschaffen. Beide Fristen sprechen damit für denselben Startzeitpunkt.

     

    TrustSpace Profi-Tipp: Mit der Gap-Analyse beginnen, nicht mit der Technik

    Der häufigste Fehler ist, sofort in einzelne technische Maßnahmen zu springen, ohne den Gesamtstand zu kennen. Wirksamer ist es, zuerst mit einer strukturierten Gap-Analyse zu klären, welche Produkte betroffen sind, in welche CRA-Klasse sie fallen und wo die größten Lücken liegen. Diese Standortbestimmung braucht wenige Wochen, verhindert aber teure Fehlinvestitionen und macht aus einem diffusen Pflichtenberg einen priorisierten, planbaren Fahrplan bis 2027. Eine ISMS-Plattform wie TrustSpaceOS hilft, Anforderungen, Maßnahmen und Nachweise dabei an einem Ort nachvollziehbar zu verwalten.

     

    Bestandsprodukte: Welche Stichtagsregelung gilt

    Eine der häufigsten Fragen betrifft Produkte, die vor dem 11. Dezember 2027 bereits auf dem Markt sind. Hier trennt der Cyber Resilience Act sauber zwischen zwei Pflichtenkreisen. Die grundlegenden Produktanforderungen samt CE-Kennzeichnung und Konformitätsbewertung gelten für ein Bestandsprodukt erst dann, wenn es nach dem Stichtag eine wesentliche Änderung (substantial modification) erfährt, etwa durch ein größeres Funktionsupdate, das die ursprüngliche Konformitätsbewertung berührt. Bleibt ein Produkt unverändert, fällt es nicht rückwirkend unter die volle Produktverantwortung.

    Die Melde- und Berichtspflichten nach Artikel 14 dagegen greifen für alle Produkte, die sich im Verkehr befinden, unabhängig vom Zeitpunkt der Markteinführung. Eine aktiv ausgenutzte Schwachstelle in einem bereits ausgelieferten Produkt muss also ab dem 11. September 2026 gemeldet werden, auch wenn das Produkt lange vor dem CRA in den Markt kam. Zu beachten ist außerdem eine Übergangsregel für Bescheinigungen: EU-Baumusterprüfbescheinigungen und Zulassungsentscheidungen zu Cybersicherheitsanforderungen bleiben bis zum 11. Juni 2028 gültig, sofern sie nicht vorher auslaufen. Die Stichtagsregelung entlastet Bestandsprodukte also bei den Produktanforderungen, nicht aber bei der laufenden Sicherheitsverantwortung.

     

    Fazit: Die Fristen stehen, der Startschuss ist überfällig

    Der Zeitplan des Cyber Resilience Act ist eindeutig und nicht verhandelbar. In Kraft seit dem 10. Dezember 2024, greifen die Regelungen zu notifizierten Stellen ab dem 11. Juni 2026, die 24-Stunden-Meldepflicht ab dem 11. September 2026 und die Vollanwendung ab dem 11. Dezember 2027. Diese vier Daten geben den Takt vor, und der erste operativ spürbare Termin liegt bereits in wenigen Wochen.

    Für Hersteller, Importeure und Händler bedeutet das keinen Grund zur Panik, wohl aber zum Handeln. Wer die Rückwärtsrechnung ernst nimmt, erkennt, dass 2026 das Jahr des Starts ist, nicht 2027. Eine frühe Gap-Analyse, ein belastbarer Meldeprozess vor September 2026 und ein realistischer Projektplan bis zur Vollanwendung verwandeln einen abstrakten Countdown in ein steuerbares Vorhaben. Die Fristen kommen ohnehin. Wer sie kennt und rückwärts plant, entscheidet selbst über das Tempo.

     

    Häufige Fragen (FAQ)

    Ab wann gilt der Cyber Resilience Act?

    Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten. Er gilt jedoch gestaffelt: Die Regelungen zu notifizierten Stellen greifen ab dem 11. Juni 2026, die Melde- und Berichtspflichten nach Artikel 14 ab dem 11. September 2026 und die vollständigen Produktpflichten ab dem 11. Dezember 2027.

    Was passiert am 11. September 2026?

    Ab dem 11. September 2026 gelten die Meldepflichten nach Artikel 14. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle binnen 24 Stunden als Frühwarnung an den zuständigen CSIRT und die ENISA melden, gefolgt von einer ausführlicheren Meldung nach 72 Stunden und einem Abschlussbericht. Diese Pflicht gilt auch für bereits im Markt befindliche Produkte.

    Muss der Cyber Resilience Act in nationales Recht umgesetzt werden?

    Nein. Der Cyber Resilience Act ist eine EU-Verordnung (Verordnung (EU) 2024/2847) und gilt damit in allen Mitgliedstaaten unmittelbar und einheitlich. Eine gesonderte Umsetzung in deutsches Recht ist nicht erforderlich, die Fristen stehen EU-weit fest.

    Gilt der CRA auch für Produkte, die schon auf dem Markt sind?

    Teilweise. Die grundlegenden Produktanforderungen mit CE-Kennzeichnung greifen für Bestandsprodukte erst, wenn sie nach dem 11. Dezember 2027 eine wesentliche Änderung erfahren. Die Melde- und Berichtspflichten nach Artikel 14 gelten dagegen ab dem 11. September 2026 für alle Produkte im Verkehr, unabhängig vom Zeitpunkt der Markteinführung.

    Warum sollte man mit der CRA-Vorbereitung schon 2026 beginnen?

    Weil ein Konformitätsprojekt aus Gap-Analyse, Umsetzung von Security by Design, technischer Dokumentation und Konformitätsbewertung realistisch zwölf bis achtzehn Monate dauert. Zieht man diese Dauer vom Stichtag 11. Dezember 2027 ab, liegt der sinnvolle Startpunkt in der ersten Jahreshälfte 2026, zumal die Meldepflicht ohnehin bereits ab September 2026 gilt.

  • Wen betrifft der Cyber Resilience Act? Betroffenheit in 5 Minuten prüfen

    Wen betrifft der Cyber Resilience Act? Betroffenheit in 5 Minuten prüfen

    Das Wichtigste in Kürze

    • Wer betroffen ist: Der Cyber Resilience Act (Verordnung (EU) 2024/2847) gilt für alle, die „Produkte mit digitalen Elementen” auf dem EU-Markt bereitstellen, also Hardware und Software mit direkter oder indirekter Datenverbindung zu einem Gerät oder Netz.
    • Welche Rollen zählen: Pflichten treffen Hersteller, Importeure und Händler unterschiedlich stark, dazu kommt die neue Sonderrolle des Open-Source-Software-Verwalters (Steward).
    • Nicht kommerziell = außen vor: Produkte, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt werden, fallen nicht unter den CRA.
    • Sektor-Ausnahmen: Bereits reguliert und damit ausgenommen sind unter anderem Medizinprodukte, Kraftfahrzeuge, zivile Luftfahrt und Schiffsausrüstung; reine Cloud-Dienste (SaaS) fallen ebenfalls nicht direkt darunter.
    • Bestandsschutz: Produkte, die vor dem 11.12.2027 auf den Markt kamen, unterliegen dem CRA erst, wenn sie danach wesentlich verändert werden.
    • Fristen: In Kraft seit 10.12.2024, Meldepflichten ab 11.09.2026, volle Anwendung ab 11.12.2027.

     

    Kaum eine EU-Regulierung hat 2026 so viele Hersteller und Händler verunsichert wie der Cyber Resilience Act. Die Frage, die sich fast jedes Unternehmen mit einem vernetzten Produkt zuerst stellt, ist einfach: Bin ich überhaupt betroffen? Die Antwort entscheidet darüber, ob ab Ende 2027 erheblicher Aufwand für Konformitätsbewertung, Dokumentation und Schwachstellenbehandlung ansteht oder ob das Angebot in eine Ausnahme fällt. Wer sie falsch einschätzt, riskiert im schlimmsten Fall Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

    Dieser Leitfaden beantwortet die Betroffenheitsfrage systematisch und führt Sie mit einer klaren Prüf-Logik in fünf Schritten durch die Selbsteinordnung. Wenn Sie die Bewertung anschließend rechtssicher absichern oder Ihre Pflichten priorisieren wollen, hilft eine spezialisierte Cyber Resilience Act Beratung für Hersteller und Händler dabei, den konkreten Handlungsbedarf für Ihr Portfolio zu bestimmen.

     

    Was ist der Cyber Resilience Act?

    Der Cyber Resilience Act, deutsch auch Cyberresilienz-Verordnung, ist mit der Verordnung (EU) 2024/2847 das erste horizontale EU-Gesetz, das verbindliche Cybersicherheitsanforderungen an Produkte mit digitalen Elementen über deren gesamten Lebenszyklus stellt. „Horizontal” bedeutet, dass er nicht auf eine einzelne Branche zielt, sondern grundsätzlich alle vernetzten Produkte erfasst, vom smarten Türschloss bis zur Softwarebibliothek.

    Als Verordnung gilt der CRA EU-weit unmittelbar, ohne nationale Umsetzung und in allen Mitgliedstaaten identisch. In Kraft ist er seit dem 10. Dezember 2024, die zentralen Pflichten greifen gestaffelt bis zur vollen Anwendung am 11. Dezember 2027. Genau deshalb lohnt sich die Betroffenheitsprüfung jetzt: Die Vorlaufzeit ist knapper, als sie wirkt.

     

    Für wen gilt der Cyber Resilience Act?

    Der Anwendungsbereich des CRA ist bewusst weit gefasst. Erfasst wird jedes Produkt mit digitalen Elementen, das im Rahmen einer Geschäftstätigkeit auf dem Unionsmarkt bereitgestellt wird, nicht nur bei klassischen IT-Herstellern, sondern bei praktisch jedem Anbieter vernetzter Produkte. Ob Ihr Unternehmen betroffen ist, hängt an zwei Fragen: Handelt es sich um ein Produkt mit digitalen Elementen, und welche Rolle nehmen Sie in der Lieferkette ein?

    Was ist ein „Produkt mit digitalen Elementen”?

    Der CRA definiert ein Produkt mit digitalen Elementen als ein Software- oder Hardware-Produkt einschließlich seiner Fern-Datenverarbeitungslösungen. Das entscheidende Kriterium: Die bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung schließt eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netz ein. Diese Definition ist absichtlich breit und deckt sowohl fertige Produkte als auch Komponenten ab, die separat auf den Markt gebracht werden.

    Ein häufig übersehener Punkt sind die sogenannten Fern-Datenverarbeitungslösungen. Eine Datenverarbeitung aus der Ferne, ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte und die vom Hersteller oder unter seiner Verantwortung entwickelt wurde, gilt als Teil des Produkts und fällt in den Anwendungsbereich. Ein reiner Cloud-Dienst, der eigenständig als Software as a Service angeboten wird, ist dagegen kein Produkt mit digitalen Elementen und wird nicht vom CRA erfasst. Die Grenze verläuft also nicht bei „Cloud ja oder nein”, sondern bei der Frage, ob die Fernverarbeitung fester Bestandteil der Produktfunktion ist.

    Welche Rollen die Verordnung kennt

    Der CRA verteilt die Pflichten entlang der Lieferkette. Welche Anforderungen konkret gelten, hängt davon ab, welche Rolle ein Unternehmen für ein bestimmtes Produkt einnimmt:

    • Hersteller: Trägt die Hauptlast. Er muss Produkte sicher entwerfen (Security by Design), über den gesamten Lebenszyklus eine Cybersicherheits-Risikobewertung führen, technische Dokumentation und Konformitätsbewertung erstellen, die CE-Kennzeichnung anbringen und Schwachstellen im Supportzeitraum behandeln.
    • Importeur: In der EU niedergelassene Person, die ein Produkt eines außerhalb der EU ansässigen Herstellers auf den Markt bringt. Er darf nur konforme Produkte in Verkehr bringen und prüft vorab, dass Konformitätsbewertung, CE-Kennzeichnung und Dokumentation vorliegen.
    • Händler: Jeder weitere Akteur in der Lieferkette, der ein Produkt bereitstellt, ohne seine Eigenschaften zu verändern. Er handelt mit gebotener Sorgfalt und prüft, ob CE-Kennzeichnung und Unterlagen vorhanden sind.
    • Open-Source-Software-Verwalter (Steward): Eine juristische Person, die die Entwicklung bestimmter, für kommerzielle Tätigkeiten bestimmter Open-Source-Software nachhaltig und systematisch unterstützt. Sie trifft ein abgestufter, leichterer Pflichtenkatalog (Cybersicherheitspolitik, Meldung von Schwachstellen und Vorfällen), Bußgelder sind für Steward-Verstöße ausgeschlossen.

    Wichtig ist die Umkehrregel: Wer als Importeur oder Händler ein Produkt unter eigenem Namen oder eigener Marke anbietet oder es wesentlich verändert, gilt selbst als Hersteller und trägt dessen volle Pflichten. Ein „nur Wiederverkäufer” wird so schneller zum Hersteller im Sinne des CRA, als vielen bewusst ist.

     

    Betroffenheit in 5 Schritten prüfen

    Ob der CRA für ein konkretes Produkt gilt, lässt sich mit fünf aufeinander aufbauenden Fragen einordnen. Ein „Nein” beendet die Prüfung meist mit dem Ergebnis „nicht betroffen”.

    Schritt 1: Hat Ihr Produkt digitale Elemente?

    Enthält Ihr Produkt Software, Firmware oder eine sonstige digitale Komponente? Reine mechanische Erzeugnisse ohne jede Software fallen nicht darunter. Sobald Code im Spiel ist, ist das erste Kriterium erfüllt.

    Schritt 2: Besteht eine Datenverbindung zu Gerät oder Netz?

    Umfasst die bestimmungsgemäße oder vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung zu einem anderen Gerät oder einem Netzwerk? Diese Hürde ist niedrig: Auch eine indirekte Verbindung, etwa über eine Schnittstelle oder ein anderes Produkt, genügt. Vollständig isolierte Geräte sind die seltene Ausnahme.

    Schritt 3: Bringen Sie das Produkt auf dem EU-Markt in Verkehr?

    Wird das Produkt im Rahmen einer Geschäftstätigkeit auf dem Unionsmarkt bereitgestellt? Der CRA gilt marktbezogen, nicht sitzbezogen: Auch ein Hersteller außerhalb der EU ist betroffen, sobald sein Produkt auf dem EU-Markt angeboten wird. Nicht kommerziell bereitgestellte Produkte fallen heraus.

    Schritt 4: Greift eine Sektor-Ausnahme?

    Ist Ihr Produkt bereits durch eine sektorspezifische EU-Regulierung abgedeckt, etwa als Medizinprodukt, Kraftfahrzeug, Luftfahrterzeugnis oder Schiffsausrüstung? Dann ist es vom CRA ausgenommen, weil die Cybersicherheit dort bereits geregelt ist. Ohne einschlägige Ausnahme bleibt es im Scope.

    Schritt 5: Welche Rolle nehmen Sie ein?

    Sind Sie Hersteller, Importeur oder Händler, und bieten Sie das Produkt unter eigenem Namen an oder verändern es wesentlich? Diese Antwort bestimmt nicht mehr das Ob, sondern das Ausmaß Ihrer Pflichten. Wer unter eigener Marke auftritt oder substanziell modifiziert, rutscht in die Herstellerrolle mit den weitreichendsten Anforderungen.

     

    Um diese fünf Schritte noch schneller durchzugehen, stellen wir an dieser Stelle in Kürze einen interaktiven Betroffenheitschecker bereit. Er führt Sie mit wenigen Fragen durch die Prüf-Logik und gibt eine erste Einordnung, ob und in welcher Rolle Ihr Produkt unter den Cyber Resilience Act fällt. Bis dahin helfen die folgenden Produktbeispiele und Ausnahmen bei der Einordnung.

     

    Betroffene und nicht betroffene Produkte im Vergleich

    Die abstrakte Definition wird an konkreten Beispielen greifbarer. Die folgende Übersicht zeigt typische Produkte, die klar in den Anwendungsbereich fallen, und solche, die durch eine Ausnahme oder mangels digitaler Elemente außen vor bleiben.

    Vom CRA erfasst Nicht (direkt) erfasst
    Smart-Home-Geräte (Kameras, Türschlösser, Thermostate) Medizinprodukte (geregelt über Verordnung (EU) 2017/745)
    Laptops, Smartphones, Router und Netzwerktechnik Kraftfahrzeuge (geregelt über Verordnung (EU) 2019/2144)
    Betriebssysteme, Firewalls, VPN-Software Zivile Luftfahrterzeugnisse (Verordnung (EU) 2018/1139)
    Industrielle Steuerungssysteme und IoT-Sensorik Schiffsausrüstung (Richtlinie 2014/90/EU)
    Mobile Apps, Firmware, Software-Bibliotheken und SDKs Eigenständige SaaS-/Cloud-Dienste (fallen unter NIS 2)
    Passwortmanager und Antivirensoftware Nicht kommerzielle, quelloffene Software

    Die rechte Spalte ist kein Freibrief. Wird eine Komponente, die für ein ausgenommenes Produkt bestimmt ist, separat auf den Markt gebracht, kann sie für sich genommen wieder in den Anwendungsbereich fallen. Und eine Sektor-Ausnahme heißt nicht, dass keine Cybersicherheitspflichten bestehen, sondern nur, dass sie aus einem anderen Rechtsakt kommen.

     

    Die wichtigsten Ausnahmen im Detail

    Der Anwendungsbereich ist weit, die Ausnahmen sind eng und klar definiert. Wer sich auf eine beruft, sollte deren Grenzen genau kennen.

    Bereits regulierte Sektoren

    Produkte, deren Cybersicherheit schon durch spezifische EU-Rechtsakte geregelt ist, nimmt der CRA aus, um Doppelregulierung zu vermeiden. Dazu zählen Medizinprodukte und In-vitro-Diagnostika (Verordnungen (EU) 2017/745 und 2017/746), Kraftfahrzeuge (Verordnung (EU) 2019/2144), zivile Luftfahrt (Verordnung (EU) 2018/1139) und Schiffsausrüstung (Richtlinie 2014/90/EU). Ebenfalls ausgenommen sind Produkte, die ausschließlich für Zwecke der nationalen Sicherheit oder der Verteidigung entwickelt werden, sowie Produkte zur Verarbeitung von Verschlusssachen.

    Software as a Service und Open-Source

    Reine SaaS-Angebote sind keine Produkte mit digitalen Elementen und werden von der NIS-2-Richtlinie erfasst; erst eine fest ins Produkt integrierte Fern-Datenverarbeitung fällt unter den CRA. Ähnlich abgestuft ist Open Source: Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird, fällt nicht unter den CRA. Erst der Vertrieb im Rahmen einer kommerziellen Tätigkeit löst Pflichten aus, und selbst dann in reduzierter Form. Für die neue Rolle des Open-Source-Software-Verwalters gelten leichtere Anforderungen, Bußgelder sind für sie ausdrücklich ausgeschlossen.

     

    TrustSpace Profi-Tipp: Betroffenheit je Produkt, nicht je Unternehmen

    Die Betroffenheit wird nicht pauschal für das Unternehmen, sondern für jedes einzelne Produkt und jede Rolle bestimmt. Ein Mittelständler kann für sein vernetztes Gerät Hersteller sein, für eine importierte Zusatzkomponente Importeur und für eine ausgenommene Medizinprodukt-Variante gar nicht betroffen. Legen Sie deshalb früh ein Produktinventar an, das je Position Produktart, Rolle und mögliche Ausnahme festhält. Diese Matrix ist die Grundlage jeder späteren Konformitätsplanung.

     

    Besonderheiten für KMU und kleine Hersteller

    Der CRA nimmt kleine und mittlere Unternehmen nicht vom Anwendungsbereich aus, mildert aber an mehreren Stellen die Last. Kleinstunternehmen und kleine Unternehmen dürfen zum Beispiel nicht mit einem Bußgeld belegt werden, wenn sie die 24-Stunden-Frist für die Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle verfehlen. Für „wichtige” Produkte, die sonst eine Drittprüfung verlangen, können Open-Source-Hersteller unter Umständen die Selbstbewertung nutzen, sofern sie die technische Dokumentation öffentlich machen.

    Darüber hinaus verpflichtet die Verordnung Behörden und Mitgliedstaaten, KMU durch Leitlinien und vereinfachte Dokumentation zu entlasten. Der Grundsatz der Verhältnismäßigkeit zieht sich durch: Der Aufwand soll zur Unternehmensgröße und zum Produktrisiko passen. Die grundlegenden Sicherheitsanforderungen und die Konformitätsbewertung entfallen für KMU aber nicht, sie sind lediglich pragmatischer ausgestaltet.

     

    Bestandsschutz: Was gilt für Produkte vor dem Stichtag?

    Eine der häufigsten Sorgen betrifft das bestehende Portfolio. Hier gibt die Verordnung Entwarnung mit einer klaren Übergangsregel: Produkte mit digitalen Elementen, die vor dem 11. Dezember 2027 auf den Markt gebracht wurden, unterliegen dem CRA nur dann, wenn sie ab diesem Datum wesentlich verändert werden. Ein unverändert weiterlaufendes Bestandsprodukt muss also nicht nachträglich CRA-konform gemacht werden.

    Der entscheidende Begriff ist die „wesentliche Änderung”. Ein sicherheitsrelevantes Funktionsupdate oder ein spürbarer Eingriff in Konzeption und Zweck kann die volle CRA-Pflicht auslösen, ein reines Sicherheits-Patch dagegen in der Regel nicht. Wer den Support für ein Bestandsprodukt über 2027 hinaus plant, sollte diese Grenze im Änderungsmanagement beobachten. Wie sich diese und die übrigen Stichtage staffeln, zeigt unsere Übersicht über alle Fristen und Deadlines des Cyber Resilience Act im Detail.

    Steht Ihre Betroffenheit fest, folgt die geordnete Umsetzung, von der Risikobewertung über die technische Dokumentation bis zur Konformitätsbewertung. Eine strukturierte Roadmap zur CRA-Umsetzung hilft dabei, die verbleibende Zeit bis zur vollen Anwendung sinnvoll einzuteilen.

     

    Fazit: Erst einordnen, dann umsetzen

    Der Cyber Resilience Act ist bewusst breit angelegt, und die meisten Unternehmen, die vernetzte Hardware oder Software kommerziell anbieten, fallen darunter. Die eigentliche Kunst liegt nicht in der Ja-Nein-Frage, sondern in der präzisen Einordnung: Produkt mit digitalen Elementen, greift eine der eng gefassten Sektor-Ausnahmen, und welche Rolle nehmen Sie in der Lieferkette ein? Die fünf Prüfschritte liefern dafür einen verlässlichen roten Faden.

    Weil die Betroffenheit je Produkt und je Rolle unterschiedlich ausfällt, ist ein sauberes Produktinventar die beste Vorbereitung. Wer jetzt einordnet, gewinnt Vorlaufzeit bis zur vollen Anwendung am 11. Dezember 2027 und vermeidet, dass aus einer unterschätzten Pflicht ein teures Bußgeldrisiko wird. Die Betroffenheitsprüfung ist damit der erste Baustein einer belastbaren CRA-Strategie.

     

    Häufige Fragen (FAQ)

    Gilt der Cyber Resilience Act auch für Unternehmen außerhalb der EU?

    Ja. Der CRA ist marktbezogen, nicht sitzbezogen. Ein Hersteller mit Sitz außerhalb der EU ist betroffen, sobald sein Produkt mit digitalen Elementen auf dem EU-Markt bereitgestellt wird. In diesem Fall übernimmt häufig ein in der EU niedergelassener Importeur zusätzliche Prüfpflichten, bevor das Produkt in Verkehr gebracht werden darf.

    Fällt reine Software auch unter den CRA?

    Ja. Der Anwendungsbereich umfasst ausdrücklich Software, sofern sie eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netz vorsieht. Das schließt Betriebssysteme, Anwendungen, mobile Apps, Firmware sowie separat vertriebene Bibliotheken und SDKs ein. Nur eigenständige Cloud-Dienste (SaaS) und nicht kommerzielle Open-Source-Software bleiben außen vor.

    Ist mein SaaS-Produkt vom Cyber Resilience Act betroffen?

    Ein rein als Cloud-Dienst angebotenes SaaS-Produkt ist kein Produkt mit digitalen Elementen und daher nicht direkt vom CRA erfasst, sondern eher von der NIS-2-Richtlinie. Anders liegt der Fall, wenn eine Cloud-Funktion als Fern-Datenverarbeitungslösung fest zu einem Gerät oder einer Anwendung gehört: Dann gilt sie als Teil des Produkts und ist mit reguliert.

    Müssen bestehende Produkte nachträglich CRA-konform gemacht werden?

    In der Regel nicht. Produkte, die vor dem 11. Dezember 2027 auf den Markt gebracht wurden, unterliegen dem CRA erst dann, wenn sie ab diesem Datum wesentlich verändert werden. Ein unverändert weiterlaufendes Bestandsprodukt genießt Bestandsschutz. Ein sicherheitsrelevantes Funktionsupdate kann die Pflicht jedoch auslösen.

    Was passiert bei Verstößen gegen den Cyber Resilience Act?

    Bei Verstößen gegen die grundlegenden Cybersicherheitsanforderungen drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Für andere Verstöße gelten niedrigere Stufen. Kleinstunternehmen und kleine Unternehmen sind von der Bußgeldpflicht bei verspäteter Meldung ausgenommen.

  • Schwachstellenmanagement: Der Prozess von Scan bis Patch-Management

    Schwachstellenmanagement: Der Prozess von Scan bis Patch-Management

    Das Wichtigste in Kürze

    • Definition: Schwachstellenmanagement (englisch Vulnerability Management) ist der fortlaufende Prozess, technische Schwachstellen in IT-Systemen zu identifizieren, zu bewerten, zu beheben und die Behebung nachzuweisen.
    • Kein Einmalprojekt: Es ist ein Kreislauf, der jedes System über den gesamten Lebenszyklus begleitet, nicht ein jährlicher Scan.
    • ISO 27001: Control A.8.8 „Handhabung technischer Schwachstellen” verlangt ein dokumentiertes, nachvollziehbares Verfahren mit klaren Verantwortlichkeiten und Fristen.
    • Priorisierung: Der CVSS-Score liefert die Basis-Schwere, die tatsächliche Priorität ergibt sich aus dem Geschäftskontext und aktiver Ausnutzung (etwa über die CISA-KEV-Liste).
    • Nachweisführung: Erst Verifikation (Rescan, Retest) und Reporting machen den Prozess audit-fest.

     

    Kaum ein IT-Prozess wird so oft unterschätzt wie das Schwachstellenmanagement. Firewalls, Verschlüsselung und Zugriffskonzepte greifen erst dann verlässlich, wenn die Systeme dahinter frei von bekannten, ausnutzbaren Lücken sind. Angreifer scannen das Internet automatisiert nach genau diesen Lücken, und die Zahl neu gemeldeter Schwachstellen wächst seit Jahren rasant. Ohne einen systematischen Prozess bleibt die Frage offen, welche der hunderten offenen Punkte zuerst geschlossen werden müssen.

    Gerade im Mittelstand, wo die IT-Sicherheit im Mittelstand häufig auf wenigen Schultern ruht, entscheidet ein strukturiertes Vorgehen darüber, ob knappe Ressourcen auf die wirklich kritischen Risiken gelenkt werden. Dieser Leitfaden erklärt, was Schwachstellenmanagement ist, wie es sich von verwandten Begriffen abgrenzt, wie der Prozess Schritt für Schritt abläuft und wie er sich in ein ISMS nach ISO 27001 einfügt.

     

    Was ist Schwachstellenmanagement?

    Schwachstellenmanagement ist der kontinuierliche, systematische Prozess, mit dem eine Organisation Sicherheitslücken in ihrer IT-Infrastruktur aufdeckt, hinsichtlich ihres Risikos bewertet, behebt und die Wirksamkeit der Maßnahmen überprüft. Gemeint sind damit technische Schwachstellen in Betriebssystemen, Anwendungen, Netzwerkkomponenten, Cloud-Diensten und Firmware, aber auch Fehlkonfigurationen wie offene Ports oder Standardpasswörter.

    Der entscheidende Punkt: Es handelt sich nicht um eine einmalige Aktion, sondern um einen Kreislauf. Neue Schwachstellen werden täglich veröffentlicht, Systeme ändern sich, und was gestern sicher konfiguriert war, kann heute angreifbar sein. Ein reifer Prozess läuft daher dauerhaft und begleitet jedes System vom Einsatz bis zur Außerbetriebnahme.

    Zur Einordnung hilft die Abgrenzung dreier Begriffe: Eine Schwachstelle (Vulnerability) ist eine ausnutzbare Schwäche in einem System. Eine Bedrohung (Threat) ist ein potenzielles Ereignis, das diese Schwäche ausnutzt. Ein Risiko ist die Kombination aus Eintrittswahrscheinlichkeit und Schadenshöhe. Schwachstellenmanagement setzt bei der ersten Größe an, denn Schwachstellen sind die einzige der drei, die eine Organisation direkt und selbst beseitigen kann.

     

    Vulnerability Management, Schwachstellenanalyse und Pentest: die Abgrenzung

    Die Begriffe werden im Alltag oft synonym verwendet, meinen aber Unterschiedliches. Wer sie sauber trennt, plant seine Sicherheitsmaßnahmen zielgerichteter.

    Begriff Fokus Charakter
    Schwachstellenmanagement / Vulnerability Management Gesamter Kreislauf aus Identifikation, Bewertung, Behebung, Verifikation und Reporting Fortlaufender Prozess
    Schwachstellenanalyse / Vulnerability Assessment Momentaufnahme: Erfassung und Bewertung vorhandener Schwachstellen zu einem Zeitpunkt Punktuelle Bestandsaufnahme
    Schwachstellenscan Automatisierte, werkzeuggestützte Suche nach bekannten Schwachstellen und Fehlkonfigurationen Technischer Einzelschritt
    Penetrationstest (Pentest) Manuelle, ausnutzende Prüfung durch Sicherheitsexperten, die reale Angriffe simulieren Tiefenprüfung, meist periodisch

    Vereinfacht gilt: „Vulnerability Management” ist der englische Oberbegriff für das gesamte Schwachstellenmanagement. Die Schwachstellenanalyse ist ein Bestandteil davon, der Scan liefert die Rohdaten, und der Pentest ergänzt die automatisierte Suche um die manuelle Perspektive eines Angreifers, die auch logische Fehler und Verkettungen mehrerer kleiner Schwächen findet, die kein Scanner erkennt.

     

    Der Schwachstellenmanagement-Prozess in fünf Schritten

    In der Praxis hat sich ein Kreislauf aus fünf Phasen bewährt. Er lässt sich unabhängig von Branche und Unternehmensgröße anwenden und beginnt nach dem letzten Schritt wieder von vorn.

    1. Identifikation: Asset-Inventar, Scans und CVE-Feeds

    Am Anfang steht die einfache Wahrheit, dass sich nur schützen lässt, was bekannt ist. Grundlage ist deshalb ein aktuelles Asset-Inventar aller Server, Clients, Netzwerkgeräte, Anwendungen und Cloud-Dienste. Auf dieser Basis suchen automatisierte Schwachstellenscanner nach bekannten Lücken, indem sie die installierten Versionen und Konfigurationen mit öffentlichen Schwachstellendatenbanken abgleichen.

    Die zentrale Referenz dafür sind CVE-Einträge (Common Vulnerabilities and Exposures), eindeutige Kennungen für öffentlich bekannte Schwachstellen. Angereichert werden sie unter anderem über die National Vulnerability Database (NVD) des NIST. Ergänzend liefern Hersteller-Advisories und CVE-Feeds laufend Meldungen zu neuen Lücken. Die Menge ist erheblich: Die Zahl der jährlich gemeldeten CVEs ist zwischen 2020 und 2025 um mehrere Hundert Prozent gestiegen, weshalb NIST seine NVD-Prozesse 2026 neu priorisiert hat.

    2. Bewertung und Priorisierung: CVSS im Geschäftskontext

    Ein Scan liefert schnell hunderte Treffer. Ohne Priorisierung ist diese Liste wertlos, denn niemand kann alles gleichzeitig beheben. Der etablierte Standard zur Einordnung der Schwere ist das Common Vulnerability Scoring System (CVSS), das jeder Schwachstelle einen Basiswert von 0 bis 10 zuweist.

    Schweregrad CVSS-Basiswert Typische Handlungslogik
    Kritisch 9,0 – 10,0 Sofortiger Handlungsbedarf, kurzfristige Behebung
    Hoch 7,0 – 8,9 Zeitnahe Behebung nach festgelegter Frist
    Mittel 4,0 – 6,9 Einplanung im regulären Patch-Zyklus
    Niedrig 0,1 – 3,9 Beobachtung, Behebung nach Verfügbarkeit

    Die aktuelle Version CVSS v4.0 (veröffentlicht Ende 2023) ergänzt den Basiswert um Threat- und Environmental-Metriken, mit denen sich die tatsächliche Bedrohungslage und die eigene Umgebung abbilden lassen. Wichtig ist das Verständnis, dass der Basiswert allein nicht über die Priorität entscheidet. Eine „kritische” Lücke auf einem isolierten Testsystem ohne Datenbezug ist weniger dringlich als eine „mittlere” Lücke auf einem öffentlich erreichbaren Produktivserver.

    Zwei Faktoren gehören deshalb zwingend in die Bewertung: der Geschäftskontext des betroffenen Assets und die Frage, ob eine Schwachstelle aktiv ausgenutzt wird. Ein starkes Signal dafür ist die Aufnahme in den Known-Exploited-Vulnerabilities-Katalog (KEV) der US-Behörde CISA, der Schwachstellen listet, für die eine Ausnutzung in freier Wildbahn belegt ist. Genau diese Verbindung von technischer Schwere und geschäftlicher Auswirkung ist der Kern jeder belastbaren Risikobewertung nach ISO 27001.

    3. Behebung: Patch-Management, Kompensation oder Risikoakzeptanz

    Für jede priorisierte Schwachstelle gibt es grundsätzlich drei Wege. Der Regelfall ist die Behebung durch Patch-Management, also das Einspielen von Sicherheitsupdates der Hersteller in geordneten, getesteten Abläufen. Ein sauberer Patch-Prozess umfasst das Testen vor dem Ausrollen, ein definiertes Wartungsfenster und einen Rückfallplan.

    Ist ein Patch noch nicht verfügbar oder aus Kompatibilitätsgründen nicht sofort einspielbar, greifen kompensierende Maßnahmen: Segmentierung des Netzwerks, Deaktivieren betroffener Dienste, zusätzliche Zugriffsbeschränkungen oder Virtual Patching über eine Web Application Firewall. Der dritte Weg ist die bewusste, dokumentierte Risikoakzeptanz für Fälle, in denen Aufwand und Nutzen einer Behebung in keinem Verhältnis stehen. Entscheidend ist, dass diese Akzeptanz eine begründete Entscheidung der richtigen Ebene ist und nicht ein stilles Liegenlassen.

    4. Verifikation: Rescan und Retest

    Eine Maßnahme gilt erst dann als erledigt, wenn ihre Wirksamkeit belegt ist. Nach der Behebung prüft ein erneuter Scan oder ein gezielter Retest, ob die Schwachstelle tatsächlich geschlossen wurde und dabei keine neuen Probleme entstanden sind. Dieser Schritt wird häufig übersprungen, ist aber der eigentliche Nachweis, dass der Prozess funktioniert, und in einem Audit unverzichtbar.

    5. Reporting und kontinuierliche Verbesserung

    Den Abschluss bildet die Auswertung: Kennzahlen wie die durchschnittliche Zeit bis zur Behebung, die Zahl offener kritischer Schwachstellen und die Einhaltung der eigenen Fristen machen den Sicherheitsstand messbar und für die Geschäftsführung greifbar. Aus diesen Erkenntnissen werden Verbesserungen abgeleitet, womit der Kreislauf von neuem beginnt.

     

    TrustSpace Profi-Tipp: Fristen vor Perfektion

    Der häufigste Fehler ist der Versuch, alle Schwachstellen gleich schnell schließen zu wollen. Wirksamer ist eine verbindliche Behebungsrichtlinie, die je Schweregrad feste Fristen vorgibt (zum Beispiel kritisch innerhalb von 7 Tagen, hoch innerhalb von 30 Tagen). Solche Service-Level machen den Prozess planbar, entlasten das Team von Einzelfallentscheidungen und liefern dem Auditor genau den nachvollziehbaren Maßstab, den ISO 27001 erwartet.

     

    Schwachstellenmanagement in der ISO 27001 (A.8.8)

    In einem Informationssicherheits-Managementsystem nach ISO 27001 ist Schwachstellenmanagement kein optionaler Zusatz, sondern eine explizite Anforderung. Die Norm in der Fassung von 2022 adressiert das Thema in Control A.8.8 „Handhabung technischer Schwachstellen”. Verlangt wird ein dokumentiertes Verfahren, das technische Schwachstellen rechtzeitig identifiziert, die eigene Betroffenheit bewertet und geeignete Maßnahmen einleitet, samt Nachweis aller Aktivitäten.

    Die Neufassung 2022 hat den Fokus bewusst verschoben: weg von einer rein reaktiven „Patcherei” hin zu einem proaktiven Risikomanagement. Die konkrete Umsetzungsanleitung liefert die begleitende Norm ISO/IEC 27002:2022 im gleichnamigen Abschnitt 8.8. A.8.8 ist dabei eine von 93 Maßnahmen des Anhangs A, die sich auf die vier Themenbereiche organisatorisch, personenbezogen, physisch und technologisch verteilen.

    Für die Praxis bedeutet das: Der oben beschriebene Fünf-Schritte-Prozess ist genau der Nachweis, den ein Auditor sehen will. Klare Verantwortlichkeiten, definierte Fristen, dokumentierte Risikoentscheidungen und belegte Rescans machen die Control erfüllbar. Wie sich A.8.8 in den größeren Rahmen aus Scoping, Risikoanalyse und Maßnahmenauswahl einfügt, zeigt der Leitfaden zum Aufbau eines ISMS nach ISO 27001 im Detail.

     

    Werkzeuge und Methoden im Überblick

    Kein einzelnes Werkzeug deckt alle Schwachstellen ab. In der Praxis kombinieren Organisationen mehrere Kategorien, abgestimmt auf ihre Systemlandschaft:

    • Netzwerk- und Infrastruktur-Scanner: prüfen Server, Clients und Netzwerkkomponenten auf bekannte CVEs und Fehlkonfigurationen. Es existieren etablierte kommerzielle wie quelloffene Lösungen.
    • Authentifizierte Scans: melden sich mit Zugangsdaten am System an und liefern ein deutlich vollständigeres Bild als reine Netzwerk-Scans von außen.
    • Web-Application-Scanner: untersuchen Webanwendungen gezielt auf typische Schwächen wie fehlerhafte Eingabevalidierung.
    • Software Composition Analysis (SCA): deckt verwundbare Open-Source-Bibliotheken und Abhängigkeiten in eigenentwickelter Software auf.
    • Penetrationstests: ergänzen die Automatisierung um die manuelle Angreiferperspektive und finden logische Fehler und Angriffsketten, die Scanner nicht erkennen.

    Die Werkzeugwahl ist dabei sekundär gegenüber dem Prozess. Ein Scanner, dessen Ergebnisse niemand priorisiert und nachverfolgt, erzeugt nur eine lange Liste ohne Wirkung. Umgekehrt macht ein klarer Prozess auch mit überschaubaren Mitteln einen messbaren Unterschied.

     

    TrustSpace Profi-Tipp: Vom Scan-Report zum gesteuerten Prozess

    Die eigentliche Herausforderung im Mittelstand ist selten der Scan selbst, sondern die Nachverfolgung: Wer ist zuständig, bis wann muss geschlossen sein, wo ist der Nachweis? Eine ISMS-Software wie TrustSpaceOS verknüpft Schwachstellen mit Assets, Risiken und Maßnahmen, vergibt Verantwortlichkeiten samt Fristen und dokumentiert die Behebung audit-fest. So wird aus einem statischen Report ein steuerbarer Prozess, der die Control A.8.8 belegbar erfüllt.

     

    Häufige Fehler im Schwachstellenmanagement

    Auch mit guten Werkzeugen scheitern Programme immer wieder an denselben Punkten. Diese Stolperfallen sollten Sie kennen:

    1. Scannen ohne Priorisierung:
    Wer alle Treffer als gleich dringlich behandelt, überlastet das Team und schließt am Ende oft die falschen Lücken zuerst. Ohne Kontext- und Ausnutzbarkeitsbewertung bleibt der Scan Selbstzweck.

    2. Unvollständiges Asset-Inventar:
    Vergessene Testserver, veraltete Systeme oder Schatten-IT tauchen im Scan nicht auf und bleiben damit ungeschützt. Blinde Flecken im Inventar sind blinde Flecken in der Sicherheit.

    3. Fehlende Verifikation:
    Eine als „behoben” markierte Schwachstelle ohne Rescan ist eine Annahme, kein Nachweis. Ohne diesen Schritt bleibt offen, ob der Patch tatsächlich gegriffen hat.

    4. Reaktion statt Prozess:
    Wer erst bei einem akuten Vorfall handelt, ist strukturell zu spät. Schwachstellenmanagement entfaltet seinen Wert nur als dauerhafter Kreislauf mit festen Zuständigkeiten und Fristen.

     

    Fazit: Ein Kreislauf, kein Projekt

    Schwachstellenmanagement ist die stille Grundlage jeder wirksamen IT-Sicherheit. Es sorgt dafür, dass bekannte Lücken systematisch gefunden, nach ihrem tatsächlichen Risiko priorisiert und nachweisbar geschlossen werden, bevor Angreifer sie ausnutzen. Der Schlüssel liegt weniger im teuersten Scanner als im gelebten Prozess: Identifikation, Bewertung, Behebung, Verifikation und Reporting im ständigen Kreislauf.

    Wer diesen Prozess in ein ISMS nach ISO 27001 einbettet, erfüllt nicht nur die Control A.8.8, sondern gewinnt vor allem einen klaren, planbaren Umgang mit einem Risiko, das ohne Struktur schnell unübersichtlich wird. Mit definierten Fristen, sauberer Nachweisführung und der richtigen Werkzeugunterstützung wird aus einer Pflichtübung ein belastbarer Baustein Ihrer Sicherheitsstrategie.

     

    Häufige Fragen (FAQ)

    Was ist der Unterschied zwischen Schwachstellenmanagement und einem Schwachstellenscan?

    Ein Schwachstellenscan ist ein einzelner technischer Schritt, der automatisiert nach bekannten Lücken sucht. Schwachstellenmanagement ist der übergeordnete, fortlaufende Prozess, der den Scan einbettet und um Bewertung, Priorisierung, Behebung, Verifikation und Reporting ergänzt. Der Scan liefert Rohdaten, das Management macht daraus gesteuertes Handeln.

    Wie oft sollte man Schwachstellenscans durchführen?

    Ein fester Turnus allein greift zu kurz. Bewährt hat sich eine Kombination aus regelmäßigen Scans (etwa wöchentlich oder monatlich, je nach Kritikalität der Systeme) und anlassbezogenen Scans nach wesentlichen Änderungen oder bei Bekanntwerden schwerwiegender neuer Schwachstellen. Kritische, öffentlich erreichbare Systeme werden häufiger geprüft als interne, gut abgeschottete.

    Ist Schwachstellenmanagement für die ISO 27001 verpflichtend?

    Ja. Die ISO 27001:2022 verlangt in Control A.8.8 ein dokumentiertes Verfahren zur Handhabung technischer Schwachstellen. Wer eine Zertifizierung anstrebt, muss einen nachvollziehbaren Prozess mit klaren Verantwortlichkeiten, Fristen und Nachweisen vorweisen können.

    Was bedeutet der CVSS-Score und reicht er zur Priorisierung aus?

    Der CVSS-Score (0 bis 10) bewertet die technische Schwere einer Schwachstelle und teilt sie in die Stufen niedrig, mittel, hoch und kritisch ein. Als alleiniger Maßstab reicht er nicht: Erst der Geschäftskontext des betroffenen Assets und die Frage, ob die Lücke aktiv ausgenutzt wird, ergeben die tatsächliche Priorität.

    Ersetzt ein Penetrationstest das Schwachstellenmanagement?

    Nein. Ein Pentest ist eine periodische Tiefenprüfung, die die manuelle Angreiferperspektive einbringt. Er ergänzt das Schwachstellenmanagement, ersetzt aber nicht dessen kontinuierlichen Kreislauf aus laufenden Scans, Priorisierung und nachgewiesener Behebung.