trustspace

Tag: ISMS

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

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

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

  • Was ist ein ISMS? Definition, Bestandteile und Nutzen

    Was ist ein ISMS? Definition, Bestandteile und Nutzen

    Das Wichtigste in Kürze

    • Definition: Ein ISMS (Informationssicherheits-Managementsystem) ist der geregelte Rahmen, mit dem ein Unternehmen Informationssicherheit systematisch steuert – über Prozesse, Verantwortlichkeiten und Maßnahmen statt über Einzelaktionen.
    • Grundlage: Der internationale Standard ISO/IEC 27001 beschreibt die Anforderungen an ein ISMS. Kern ist der PDCA-Zyklus (Plan-Do-Check-Act).
    • Nutzen: Ein ISMS senkt Risiken, erfüllt regulatorische Pflichten (u. a. NIS2, DSGVO) und schafft Vertrauen bei Kunden und Partnern.
    • Für wen: Nicht nur für Konzerne – auch der Mittelstand profitiert, wenn das ISMS auf die eigene Größe zugeschnitten ist.

    Was ist ein ISMS? Die Definition

    Die Abkürzung ISMS steht für Informationssicherheits-Managementsystem (englisch: Information Security Management System). Ein ISMS ist kein Produkt und keine Software allein, sondern ein Managementsystem: ein festgelegter Satz aus Leitlinien, Prozessen, Rollen und Maßnahmen, mit dem eine Organisation die Sicherheit ihrer Informationen plant, umsetzt, überprüft und laufend verbessert.

    Der entscheidende Unterschied zu einzelnen IT-Sicherheitsmaßnahmen liegt im Wort „System”: Eine Firewall oder ein Passwortkonzept sind Einzelmaßnahmen. Ein ISMS sorgt dafür, dass solche Maßnahmen aus einer bewussten Risikobewertung abgeleitet, dokumentiert, Verantwortlichen zugeordnet und regelmäßig auf Wirksamkeit geprüft werden. Ziel ist der Schutz der drei klassischen Schutzziele der Informationssicherheit: Vertraulichkeit, Integrität und Verfügbarkeit.

    Warum braucht ein Unternehmen ein ISMS?

    Ein ISMS beantwortet drei Fragen, die sich jedes Unternehmen früher oder später stellen muss: Welche Informationen sind schützenswert? Welche Risiken bedrohen sie? Und welche Maßnahmen sind angemessen? Der Nutzen ist dabei zugleich strategisch und regulatorisch:

    • Risiken reduzieren: Sicherheitsvorfälle werden seltener und weniger folgenschwer, weil Risiken systematisch erkannt und behandelt werden.
    • Pflichten erfüllen: Regelwerke wie die NIS2-Richtlinie oder die DSGVO verlangen nachweisbare technische und organisatorische Maßnahmen – ein ISMS liefert genau diesen Nachweis.
    • Vertrauen schaffen: Ein zertifiziertes ISMS nach ISO 27001 ist im B2B-Geschäft oft Voraussetzung, um überhaupt als Lieferant infrage zu kommen.

    Die Bestandteile eines ISMS im Überblick

    Ein ISMS besteht aus mehreren aufeinander aufbauenden Elementen. Die folgende Übersicht zeigt, woraus sich ein Managementsystem zusammensetzt – die Umsetzung jedes Bausteins vertiefen wir in eigenen Beiträgen.

    Baustein Was dahintersteckt
    Geltungsbereich (Scope) Festlegung, welche Bereiche, Standorte und Prozesse das ISMS umfasst.
    Asset- und Strukturanalyse Erfassung der schützenswerten Werte (Daten, Systeme, Prozesse). Details in der ISMS-Strukturanalyse.
    Risikomanagement Bewertung von Bedrohungen und Festlegung, wie mit ihnen umgegangen wird.
    Maßnahmen (Controls) Technische und organisatorische Maßnahmen, abgeleitet aus dem Anhang A der ISO 27001.
    Dokumentation und Rollen Richtlinien, Verantwortlichkeiten und Nachweise – von der Leitlinie bis zum Informationssicherheitsbeauftragten.
    Audit und Verbesserung Regelmäßige Überprüfung der Wirksamkeit. Mehr dazu unter ISMS-Audits.

    ISMS und ISO 27001: Wie hängen sie zusammen?

    ISMS und ISO 27001 werden oft synonym verwendet, meinen aber nicht dasselbe. Das ISMS ist das Managementsystem in Ihrem Unternehmen. ISO/IEC 27001 ist der internationale Standard, der die Anforderungen an ein solches System definiert. Man kann ein ISMS betreiben, ohne es zertifizieren zu lassen – die Zertifizierung nach ISO 27001 macht die Konformität jedoch offiziell nachweisbar. Wie ein ISMS konkret nach diesem Standard aufgebaut wird, zeigt unser Praxis-Guide zum Aufbau eines ISMS nach ISO 27001.

    Ein ISMS lebt: der PDCA-Zyklus

    Ein ISMS ist kein einmaliges Projekt, sondern ein fortlaufender Kreislauf. Die ISO 27001 folgt dem PDCA-Zyklus:

    • Plan: Geltungsbereich, Risiken und Ziele festlegen.
    • Do: Maßnahmen umsetzen und dokumentieren.
    • Check: Wirksamkeit durch Audits und Kennzahlen überprüfen.
    • Act: Aus Erkenntnissen lernen und nachsteuern.

    Dieser Kreislauf sorgt dafür, dass ein ISMS mit neuen Bedrohungen und Anforderungen mitwächst, statt zu veralten.

    ISMS für den Mittelstand: pragmatisch statt überdimensioniert

    Ein häufiges Missverständnis ist, ein ISMS lohne sich nur für Großkonzerne. Tatsächlich lässt sich der Umfang an die Unternehmensgröße anpassen: Der Geltungsbereich, die Tiefe der Dokumentation und die eingesetzten Werkzeuge skalieren mit dem Bedarf. Wie ein schlankes, aber wirksames ISMS im Mittelstand gelingt, beschreibt unser Beitrag ISMS für KMU.

    Software oder Beratung: Wie setzt man ein ISMS um?

    In der Praxis führt ein hybrider Ansatz am schnellsten zum Ziel: Eine ISMS-Software automatisiert wiederkehrende Aufgaben wie Asset-Erfassung, Risikobewertung und Nachweisführung, während Beratung die richtigen Entscheidungen absichert. Unternehmen, die eine Zertifizierung anstreben, kombinieren das häufig mit einer strukturierten ISO-27001-Zertifizierungsberatung, um Aufwand und Zeit bis zum Audit zu reduzieren.

    Welche Funktionen eine solche Plattform mitbringen sollte, von der zentralen Dokumentenlenkung über das Compliance-Cockpit bis zur automatisierten Auditvorbereitung, ordnet unser Überblick zu den Vorteilen einer ISMS-Software ein.

    Häufige Fragen (FAQ)

    Was ist ein ISMS einfach erklärt?

    Ein ISMS ist ein geregeltes System aus Prozessen und Verantwortlichkeiten, mit dem ein Unternehmen dafür sorgt, dass seine Informationen dauerhaft vertraulich, korrekt und verfügbar bleiben – nicht durch Einzelaktionen, sondern systematisch und überprüfbar.

    Was ist der Unterschied zwischen ISMS und ISO 27001?

    Das ISMS ist das Managementsystem im Unternehmen. ISO 27001 ist der Standard, der beschreibt, wie ein solches System aussehen muss. Die Zertifizierung nach ISO 27001 weist nach, dass das ISMS diese Anforderungen erfüllt.

    Ist ein ISMS Pflicht?

    Es gibt keine allgemeine gesetzliche Pflicht zum ISMS. Regelwerke wie NIS2 verlangen aber nachweisbare Sicherheitsmaßnahmen, die sich am einfachsten über ein ISMS umsetzen und belegen lassen. Für viele betroffene Unternehmen ist es damit faktisch unverzichtbar.

    Was kostet ein ISMS?

    Die Kosten hängen von Unternehmensgröße, Geltungsbereich und Umsetzungsweg ab. Software und ein pragmatischer Scope senken den Aufwand deutlich gegenüber einer rein manuellen Einführung.

  • KI-Risikomanagement strukturiert aufbauen

    KI-Risikomanagement strukturiert aufbauen

    Das Wichtigste in Kürze

    • Ein strukturiertes KI-Risikomanagement ist für Unternehmen unverzichtbar – der EU AI Act macht es für eigenständige Hochrisiko-KI-Systeme (Anhang III) ab Dezember 2027 zur Pflicht (durch den Digital Omnibus vom August 2026 verschoben).
    • Typische KI-Risiken umfassen Bias, mangelnde Transparenz, Datenschutzverstöße, Sicherheitslücken und ungeklärte Haftungsfragen.
    • Unternehmen, die bereits ein ISMS nach ISO 27001 oder ein DSGVO-Compliance-Programm betreiben, können KI-Risikomanagement in bestehende Strukturen integrieren.
    • Klare Rollen und Verantwortlichkeiten sowie ein minimaler Governance-Prozess sind die Grundlage für ein wirksames AI Risk Management.
    • Sofort umsetzbare Maßnahmen: KI-Systeme inventarisieren, Risikokategorien definieren und Verantwortlichkeiten festlegen.

     

    Warum KI-Risikomanagement jetzt relevant ist

    Künstliche Intelligenz verändert Geschäftsprozesse in nahezu jeder Branche. Unternehmen setzen KI-Systeme ein, um Entscheidungen zu automatisieren, Kundeninteraktionen zu personalisieren oder große Datenmengen auszuwerten. Mit der wachsenden Verbreitung steigen jedoch auch die Risiken – und der regulatorische Druck nimmt zu.

    Der EU AI Act (Verordnung (EU) 2024/1689) verpflichtet Anbieter und Betreiber eigenständiger Hochrisiko-KI-Systeme (Anhang III) zur Einführung eines umfassenden Risikomanagementsystems; diese Pflichten wurden durch den EU Digital Omnibus von August 2026 auf Dezember 2027 verschoben. Doch auch unabhängig von der Regulierung ist ein systematisches KI-Risikomanagement strategisch sinnvoll: Es schützt vor Reputationsschäden, reduziert Haftungsrisiken und schafft Vertrauen bei Kunden, Partnern und Aufsichtsbehörden.

    Unternehmen, die jetzt handeln, verschaffen sich einen doppelten Vorteil: Sie erfüllen kommende regulatorische Anforderungen frühzeitig und bauen intern die Kompetenz auf, KI verantwortungsvoll und sicher einzusetzen.

     

    Was KI-Risikomanagement im Unternehmenskontext bedeutet

    KI-Risikomanagement (englisch: AI Risk Management) beschreibt den systematischen Prozess, mit dem Unternehmen Risiken identifizieren, bewerten, steuern und überwachen, die durch den Einsatz von KI-Systemen entstehen. Es umfasst technische, organisatorische, rechtliche und ethische Dimensionen.

    Im Unterschied zum klassischen IT-Risikomanagement berücksichtigt das Risikomanagement für KI-Systeme spezifische Eigenschaften künstlicher Intelligenz:

    • Probabilistisches Verhalten: KI-Systeme treffen Entscheidungen auf Basis statistischer Modelle – ihre Ergebnisse sind nicht immer deterministisch oder vollständig vorhersagbar.
    • Datenabhängigkeit: Die Qualität und Repräsentativität der Trainingsdaten beeinflusst direkt die Fairness und Zuverlässigkeit des Systems.
    • Dynamische Entwicklung: KI-Modelle können sich durch kontinuierliches Lernen verändern, was laufende Überwachung erfordert.
    • Erklärbarkeit: Viele KI-Systeme – insbesondere Deep-Learning-Modelle – arbeiten als sogenannte Black Boxes, deren Entscheidungslogik schwer nachvollziehbar ist.

    Ein wirksames AI Risk Management integriert diese Besonderheiten in bestehende Governance-Strukturen, anstatt ein vollständig neues System aufzubauen.

     

    Typische Risikokategorien für KI-Systeme

    Um KI-Risiken strukturiert zu erfassen, empfiehlt sich die Gliederung in klar definierte Kategorien. Die folgenden fünf Bereiche decken die wesentlichen KI-Risiken ab, die Unternehmen adressieren müssen.

     

    1. Bias und Diskriminierung

    KI-Systeme können bestehende gesellschaftliche Vorurteile reproduzieren oder verstärken, wenn ihre Trainingsdaten verzerrt sind. Das betrifft insbesondere Anwendungen im Personalwesen, bei der Kreditvergabe oder im Kundenservice. Ein diskriminierendes KI-System kann erhebliche rechtliche und reputationsbezogene Konsequenzen haben – und verstößt potenziell gegen das Allgemeine Gleichbehandlungsgesetz (AGG) sowie die DSGVO.

    Maßnahmen: Regelmäßige Bias-Audits, diverse Trainingsdatensätze, Fairness-Metriken definieren und überwachen.

     

    2. Mangelnde Transparenz und Erklärbarkeit

    Wenn Entscheidungen von KI-Systemen nicht nachvollziehbar sind, wird es für Unternehmen schwierig, diese gegenüber Betroffenen, Aufsichtsbehörden oder Gerichten zu rechtfertigen. Der EU AI Act fordert für Hochrisiko-KI-Systeme explizit Transparenz und eine verständliche Dokumentation.

    Maßnahmen: Einsatz erklärbarer KI-Methoden (Explainable AI), technische Dokumentation gemäß Artikel 11 EU AI Act, Gebrauchsanweisungen für Betreiber.

     

    3. Datenschutz und Datenqualität

    KI-Systeme verarbeiten häufig große Mengen personenbezogener Daten. Dabei entstehen Risiken in Bezug auf die DSGVO-Compliance: unzureichende Rechtsgrundlagen, fehlende Datenschutz-Folgenabschätzungen oder mangelnde Datenminimierung. Zudem kann schlechte Datenqualität zu fehlerhaften Ergebnissen führen.

    Maßnahmen: Datenschutz-Folgenabschätzung (DSFA) durchführen, Daten-Governance-Richtlinien etablieren, technische und organisatorische Maßnahmen (TOM) implementieren.

     

    4. IT-Sicherheit und Robustheit

    KI-Systeme sind anfällig für spezifische Angriffsformen wie Adversarial Attacks (gezielte Manipulation von Eingabedaten), Model Poisoning (Vergiftung von Trainingsdaten) oder Model Extraction (Abschöpfung des Modellwissens). Diese Bedrohungen gehen über klassische IT-Sicherheitsrisiken hinaus und erfordern spezialisierte Schutzmaßnahmen.

    Maßnahmen: KI-spezifische Bedrohungsmodellierung, Adversarial Testing, Monitoring der Modell-Performance, Integration in das ISMS nach ISO 27001.

     

    5. Haftung und rechtliche Risiken

    Die Frage, wer haftet, wenn ein KI-System Schaden verursacht, ist rechtlich komplex. Die europäische KI-Haftungsrichtlinie und die neue Produkthaftungsrichtlinie schaffen zwar klarere Regeln, doch Unternehmen müssen ihre Haftungsrisiken proaktiv bewerten. Fehlende Dokumentation oder unzureichende menschliche Aufsicht können die Haftungssituation erheblich verschärfen.

    Maßnahmen: Haftungsszenarien dokumentieren, Verantwortlichkeiten klar definieren, Protokollierung und Auditierbarkeit sicherstellen, vertragliche Regelungen mit KI-Anbietern prüfen.

     

    Rollen und Verantwortlichkeiten im KI-Risikomanagement

    Ein funktionierendes AI Risk Management erfordert klare Zuständigkeiten. Ohne definierte Rollen verteilt sich die Verantwortung, und Risiken fallen durch die Lücken. Die folgende Rollenverteilung hat sich in der Praxis bewährt:

    • Geschäftsführung / Vorstand: Trägt die Gesamtverantwortung für das KI-Risikomanagement, gibt die Risikobereitschaft (Risk Appetite) vor und stellt Ressourcen bereit.
    • KI-Verantwortlicher / AI Officer: Koordiniert die KI-Governance im Unternehmen, pflegt das KI-Inventar und stellt die Einhaltung regulatorischer Anforderungen sicher. In kleineren Unternehmen kann diese Rolle vom CISO oder Compliance-Beauftragten übernommen werden.
    • Fachabteilungen: Identifizieren KI-Anwendungsfälle, bewerten fachliche Risiken und stellen die korrekte Nutzung gemäß interner Richtlinien sicher.
    • IT-Sicherheit / CISO: Bewertet technische Risiken, integriert KI-spezifische Bedrohungen in das bestehende Risikomanagement und überwacht die KI-Sicherheit.
    • Datenschutzbeauftragter: Prüft die DSGVO-Konformität von KI-Systemen, begleitet Datenschutz-Folgenabschätzungen und berät zu Fragen der Datenverarbeitung.
    • Rechtsabteilung: Bewertet Haftungsrisiken, prüft Verträge mit KI-Anbietern und überwacht regulatorische Entwicklungen.

    Entscheidend ist, dass diese Rollen nicht nur formal definiert, sondern mit konkreten Aufgaben, Berichtswegen und Eskalationsmechanismen hinterlegt sind.

     

    Minimaler Governance-Prozess für KI-Risikomanagement

    Nicht jedes Unternehmen benötigt von Anfang an ein umfassendes KI-Governance-Framework. Ein minimaler Governance-Prozess bildet die Grundlage, auf der sich das Risikomanagement für künstliche Intelligenz schrittweise erweitern lässt.

     

    Schritt 1: KI-Systeme inventarisieren

    Erstellen Sie ein vollständiges Verzeichnis aller KI-Systeme, die Ihr Unternehmen einsetzt, entwickelt oder bereitstellt. Erfassen Sie dabei mindestens:

    • Name und Beschreibung des Systems
    • Einsatzbereich und Zweck
    • Anbieter (intern oder extern)
    • Verarbeitete Datenarten (insbesondere personenbezogene Daten)
    • Betroffene Personengruppen
    • Vorläufige Risikoeinstufung gemäß EU AI Act Risikostufen

     

    Schritt 2: Risikobewertung durchführen

    Bewerten Sie für jedes KI-System die identifizierten Risiken nach Eintrittswahrscheinlichkeit und potenzieller Schadenshöhe. Nutzen Sie dabei die fünf Risikokategorien (Bias, Transparenz, Datenschutz, Sicherheit, Haftung) als Strukturierungshilfe. Dokumentieren Sie die Ergebnisse in einer KI-Risikomatrix.

     

    Schritt 3: Maßnahmen definieren und priorisieren

    Leiten Sie aus der Risikobewertung konkrete Maßnahmen ab. Priorisieren Sie dabei nach Risikohöhe und Umsetzbarkeit. Typische Maßnahmen umfassen:

    • Technische Schutzmaßnahmen (z. B. Monitoring, Zugriffskontrollen)
    • Organisatorische Maßnahmen (z. B. Schulungen, Richtlinien)
    • Prozessuale Maßnahmen (z. B. Freigabeprozesse, regelmäßige Audits)
    • Vertragliche Maßnahmen (z. B. Anforderungen an KI-Anbieter)

     

    Schritt 4: Überwachen und iterieren

    KI-Risikomanagement ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Etablieren Sie einen regelmäßigen Review-Zyklus – mindestens halbjährlich – um Risikobewertungen zu aktualisieren, die Wirksamkeit von Maßnahmen zu prüfen und neue KI-Systeme in den Prozess aufzunehmen.

     

    Integration in bestehende Compliance-Strukturen

    Unternehmen, die bereits über ein Informationssicherheits-Managementsystem (ISMS) oder ein DSGVO-Compliance-Programm verfügen, müssen das Rad nicht neu erfinden. KI-Risikomanagement lässt sich effizient in bestehende Strukturen integrieren.

     

    Anbindung an das ISMS nach ISO 27001

    Ein ISMS nach ISO 27001 bietet den idealen Rahmen für die Integration von KI-Risiken:

    • Asset-Management: KI-Systeme als Informationswerte im Asset-Inventar erfassen.
    • Risikobeurteilung (Klausel 6.1.2): KI-spezifische Bedrohungen und Schwachstellen in die bestehende Risikobeurteilung aufnehmen.
    • Risikobehandlung: KI-Maßnahmen in den Risikobehandlungsplan integrieren.
    • Annex A Controls: Relevante Controls (z. B. A.8.28 Secure Coding, A.5.8 Informationssicherheit im Projektmanagement) auf KI-Kontexte anwenden.
    • Interne Audits: KI-Systeme in den internen Audit-Plan aufnehmen.

     

    Verbindung zur DSGVO-Compliance

    KI-Risikomanagement und Datenschutz-Compliance überlappen in wesentlichen Bereichen:

    • Datenschutz-Folgenabschätzung (DSFA): Für KI-Systeme mit hohem Risiko für Betroffene ist eine DSFA gemäß Art. 35 DSGVO ohnehin verpflichtend – die Ergebnisse fließen direkt in das KI-Risikomanagement ein.
    • Verarbeitungsverzeichnis: KI-gestützte Verarbeitungstätigkeiten müssen im Verarbeitungsverzeichnis dokumentiert sein.
    • Automatisierte Einzelentscheidungen: Art. 22 DSGVO gibt Betroffenen das Recht, nicht einer ausschließlich automatisierten Entscheidung unterworfen zu werden – ein zentraler Aspekt der AI Compliance.
    • Technische und organisatorische Maßnahmen: Die TOM-Anforderungen der DSGVO lassen sich auf KI-spezifische Risiken erweitern.

     

    Bezug zum EU AI Act

    Der EU AI Act fordert für Hochrisiko-KI-Systeme explizit ein Risikomanagementsystem (Art. 9), das den gesamten Lebenszyklus abdeckt. Unternehmen, die ihr KI-Risikomanagement jetzt auf Basis bewährter Standards aufbauen, erfüllen wesentliche Anforderungen des AI Act bereits vorab. Die Verordnung verlangt unter anderem:

    • Identifikation und Analyse bekannter und vorhersehbarer Risiken
    • Bewertung von Risiken, die bei bestimmungsgemäßer Nutzung und bei vernünftigerweise vorhersehbarer Fehlanwendung auftreten können
    • Geeignete Risikomanagementmaßnahmen unter Berücksichtigung des Stands der Technik
    • Systematisches Testen des KI-Systems zur Bestimmung der geeignetsten Maßnahmen

     

    Häufig gestellte Fragen (FAQ)

     

    Was ist KI-Risikomanagement?

    KI-Risikomanagement ist der systematische Prozess, mit dem Unternehmen Risiken identifizieren, bewerten und steuern, die durch den Einsatz künstlicher Intelligenz entstehen. Es umfasst technische Risiken (z. B. Bias, mangelnde Robustheit), rechtliche Risiken (z. B. Datenschutzverstöße, Haftung) und organisatorische Risiken (z. B. fehlende Kompetenzen, unklare Verantwortlichkeiten). Ziel ist es, den Nutzen von KI-Systemen zu maximieren und gleichzeitig potenzielle Schäden für das Unternehmen und betroffene Personen zu minimieren.

     

    Welche Risiken entstehen durch KI-Systeme?

    KI-Systeme können vielfältige Risiken verursachen. Dazu gehören algorithmische Diskriminierung (Bias), die zu unfairen Entscheidungen führt, Datenschutzverletzungen durch die Verarbeitung sensibler Daten, Sicherheitslücken durch KI-spezifische Angriffsvektoren wie Adversarial Attacks, mangelnde Transparenz bei automatisierten Entscheidungen sowie Haftungsrisiken bei fehlerhaften KI-Ergebnissen. Hinzu kommen Risiken durch Abhängigkeit von einzelnen Anbietern (Vendor Lock-in), unzureichende Datenqualität und die unkontrollierte Nutzung von KI-Tools durch Mitarbeitende (Shadow AI).

     

    Wie passt KI-Risikomanagement zum EU AI Act?

    Der EU AI Act verlangt in Artikel 9 von Anbietern und Betreibern von Hochrisiko-KI-Systemen die Einführung eines Risikomanagementsystems, das den gesamten Lebenszyklus des KI-Systems abdeckt. Unternehmen, die ein strukturiertes KI-Risikomanagement aufbauen, legen damit die Grundlage für die Compliance mit dem EU AI Act. Die Anforderungen des AI Act lassen sich dabei nahtlos in bestehende Managementsysteme wie ein ISMS nach ISO 27001 integrieren. Die vollständigen Pflichten für eigenständige Hochrisiko-KI-Systeme (Anhang III) treten nach der Verschiebung durch den EU Digital Omnibus ab Dezember 2027 in Kraft (für in Produkte eingebettete Hochrisiko-KI nach Anhang I ab August 2028).

     

    Welche Maßnahmen sind für Unternehmen sofort umsetzbar?

    Unternehmen können bereits heute konkrete Schritte unternehmen, um sich auf die Anforderungen des EU AI Act vorzubereiten und KI-Risiken zu minimieren:

    • KI-Inventar erstellen: Alle im Unternehmen eingesetzten KI-Systeme systematisch erfassen und dokumentieren.
    • Risikoeinstufung vornehmen: Jedes KI-System anhand der EU AI Act Risikostufen vorläufig klassifizieren.
    • Verantwortlichkeiten festlegen: Einen KI-Verantwortlichen benennen und Zuständigkeiten definieren.
    • KI-Richtlinie verabschieden: Interne Regeln für den Einsatz von KI-Systemen formulieren.
    • Mitarbeitende schulen: KI-Kompetenz aufbauen – der EU AI Act fordert dies in Artikel 4 bereits seit Februar 2025.
    • Bestehende Prozesse nutzen: KI-Risiken in vorhandene ISMS- oder DSGVO-Prozesse integrieren.

     

    KI-Risikomanagement als Wettbewerbsvorteil

    Unternehmen, die KI-Risikomanagement als rein regulatorische Pflicht betrachten, verschenken Potenzial. Ein strukturierter Umgang mit KI-Risiken schafft Vertrauen – bei Kunden, Geschäftspartnern und Aufsichtsbehörden. Er ermöglicht es, KI-Systeme schneller und sicherer in Betrieb zu nehmen, weil Risiken frühzeitig erkannt und adressiert werden. Und er verhindert kostspielige Nachbesserungen, wenn sich regulatorische Anforderungen verschärfen.

    Der Schlüssel liegt darin, AI Governance nicht als separate Disziplin aufzubauen, sondern in bestehende Compliance- und Sicherheitsstrukturen zu integrieren. Wer bereits ein ISMS betreibt, hat die organisatorischen Grundlagen dafür geschaffen. Eine ISMS-Software wie TrustSpaceOS bündelt KI-Inventar, Risikobewertung und Nachweisführung in einer Plattform und macht diese Integration im Arbeitsalltag handhabbar.

     

    KI-Risikomanagement mit TrustSpace integrieren

    TrustSpace unterstützt Unternehmen dabei, KI-Risikomanagement nahtlos in bestehende ISMS- und Compliance-Strukturen zu integrieren. Mit der TrustSpace-Plattform erfassen Sie KI-Systeme systematisch, bewerten Risiken nach bewährten Standards und dokumentieren Maßnahmen revisionssicher – alles in einer zentralen Lösung. So erfüllen Sie die Anforderungen des EU AI Act, ohne parallele Strukturen aufbauen zu müssen.

    Jetzt unverbindlich beraten lassen →

  • DORA Anforderungen: Was Finanzunternehmen jetzt umsetzen müssen

    DORA Anforderungen: Was Finanzunternehmen jetzt umsetzen müssen

    Das Wichtigste in Kürze

    • Der Digital Operational Resilience Act (DORA) gilt seit dem 17. Januar 2025 verbindlich für Finanzunternehmen und deren IKT-Dienstleister in der EU.
    • Die zentralen DORA Anforderungen umfassen fünf Säulen: IKT-Risikomanagement, Incident-Meldepflichten, Resilienztests, Drittanbieter-Überwachung und Informationsaustausch.
    • Betroffen sind Banken, Versicherungen, Wertpapierfirmen, Zahlungsinstitute und kritische IKT-Drittdienstleister.
    • Verstöße können zu aufsichtsrechtlichen Maßnahmen, Bußgeldern und Reputationsschäden führen.
    • Eine strukturierte Umsetzung mit geeigneten Plattformlösungen reduziert Komplexität und schafft Nachweissicherheit.

     

    Was ist DORA und warum gibt es diese Verordnung?

    Die zunehmende Digitalisierung des Finanzsektors hat die Abhängigkeit von Informations- und Kommunikationstechnologie (IKT) massiv erhöht. Cyberangriffe, Systemausfälle und Schwachstellen bei IT-Dienstleistern können die Stabilität einzelner Institute und ganzer Finanzmärkte gefährden. Genau hier setzt der Digital Operational Resilience Act (DORA) an.

    DORA ist eine EU-Verordnung (Verordnung (EU) 2022/2554), die einen einheitlichen Rahmen für die digitale operationale Resilienz im Finanzsektor schafft. Im Gegensatz zu einer Richtlinie gilt DORA unmittelbar in allen EU-Mitgliedstaaten – ohne nationale Umsetzungsgesetze. Seit dem 17. Januar 2025 müssen alle betroffenen Unternehmen die Anforderungen vollständig erfüllen.

    Das übergeordnete Ziel: Finanzunternehmen sollen IKT-bezogene Störungen und Cyberbedrohungen widerstehen, darauf reagieren und sich davon erholen können – ohne dass kritische Funktionen beeinträchtigt werden.

     

    Wer ist von den DORA Anforderungen betroffen?

    Der Anwendungsbereich von DORA ist bewusst breit gefasst. Die Verordnung richtet sich an über 20 Kategorien von Finanzunternehmen, darunter:

    • Kreditinstitute (Banken, Sparkassen, Genossenschaftsbanken)
    • Versicherungs- und Rückversicherungsunternehmen
    • Wertpapierfirmen und Handelsplätze
    • Zahlungsinstitute und E-Geld-Institute
    • Kapitalverwaltungsgesellschaften (OGAW und AIFM)
    • Kryptodienstleister nach MiCAR
    • Einrichtungen der betrieblichen Altersversorgung
    • Ratingagenturen und Transaktionsregister

    Besonders relevant: Auch kritische IKT-Drittdienstleister – etwa Cloud-Provider, Rechenzentren oder Softwareanbieter – fallen unter ein eigenes Überwachungsrahmenwerk. Sie werden von den europäischen Aufsichtsbehörden (ESAs) direkt beaufsichtigt.

    Für kleinere Finanzunternehmen (sogenannte Kleinstunternehmen) sieht DORA vereinfachte Anforderungen vor, die dem Proportionalitätsprinzip folgen. Dennoch sind auch diese Institute verpflichtet, ein Mindestmaß an digitaler Resilienz sicherzustellen.

     

    Die fünf Säulen der DORA Anforderungen im Detail

    DORA strukturiert die DORA Compliance Anforderungen in fünf zentrale Bereiche, die zusammen ein umfassendes Rahmenwerk bilden. Jede Säule adressiert einen spezifischen Aspekt der digitalen operationalen Resilienz.

     

    Säule 1: IKT-Risikomanagement (Artikel 5–16)

    Das IKT-Risikomanagement bildet das Fundament aller DORA Anforderungen. Finanzunternehmen müssen ein umfassendes, dokumentiertes IKT-Risikomanagement-Rahmenwerk implementieren, das mindestens folgende Elemente umfasst:

    Governance und Organisation:

    • Das Leitungsorgan (Vorstand, Geschäftsführung) trägt die Gesamtverantwortung für das IKT-Risikomanagement und muss eine klare IKT-Strategie genehmigen und überwachen.
    • Es muss eine dedizierte IKT-Risikomanagement-Funktion eingerichtet werden, die von operativen IKT-Funktionen unabhängig ist.
    • Mindestens einmal jährlich ist eine Überprüfung des gesamten Rahmenwerks erforderlich, bei wesentlichen Vorfällen auch anlassbezogen.

    Identifikation und Schutz:

    • Vollständige Inventarisierung aller IKT-Assets, Informationswerte und deren Abhängigkeiten.
    • Durchführung regelmäßiger Risikobewertungen und Klassifizierung nach Kritikalität.
    • Implementierung angemessener Schutzmaßnahmen: Zugriffskontrollen, Verschlüsselung, Netzwerksicherheit, Patch-Management.

    Erkennung, Reaktion und Wiederherstellung:

    • Mechanismen zur zeitnahen Erkennung anomaler Aktivitäten und IKT-bezogener Vorfälle.
    • Dokumentierte Reaktionspläne (Incident Response) mit klaren Eskalationswegen.
    • Business-Continuity-Pläne und Wiederherstellungsverfahren mit definierten Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO).
    • Regelmäßige Durchführung von Backup-Tests und Wiederherstellungsübungen.

    Plattformen wie TrustSpace unterstützen Unternehmen dabei, das IKT-Risikomanagement strukturiert aufzubauen, Assets zu inventarisieren und Risikobewertungen effizient durchzuführen – mit durchgängiger Dokumentation für Audit-Nachweise.

     

    Säule 2: IKT-bezogenes Vorfallmanagement und Meldepflichten (Artikel 17–23)

    DORA standardisiert erstmals EU-weit das Meldewesen für IKT-bezogene Vorfälle im Finanzsektor. Die Anforderungen umfassen:

    Klassifizierung von Vorfällen:

    • Finanzunternehmen müssen IKT-bezogene Vorfälle anhand festgelegter Kriterien klassifizieren, darunter: Anzahl betroffener Kunden, Dauer der Dienstunterbrechung, geografische Ausbreitung, Datenverluste, Kritikalität der betroffenen Dienste und wirtschaftliche Auswirkungen.
    • Vorfälle werden als schwerwiegend eingestuft, wenn bestimmte Schwellenwerte überschritten werden.

    Meldepflichten bei schwerwiegenden Vorfällen:

    • Erstmeldung: Unverzüglich, spätestens innerhalb von 4 Stunden nach Klassifizierung als schwerwiegend (maximal 24 Stunden nach Erkennung).
    • Zwischenmeldung: Innerhalb von 72 Stunden nach der Erstmeldung mit aktualisierten Informationen.
    • Abschlussmeldung: Spätestens einen Monat nach der Erstmeldung mit Ursachenanalyse und ergriffenen Maßnahmen.

    Freiwillige Meldung: Finanzunternehmen können auch erhebliche Cyberbedrohungen freiwillig an die zuständige Behörde melden, um den sektorweiten Informationsaustausch zu fördern.

    Entscheidend ist, dass Unternehmen bereits im Vorfeld Prozesse, Templates und Zuständigkeiten für das Vorfallmanagement definieren. Wer erst im Ernstfall beginnt, die Meldekette aufzubauen, verliert wertvolle Zeit.

     

    Säule 3: Tests der digitalen operationalen Resilienz (Artikel 24–27)

    DORA verlangt ein umfassendes Testprogramm, das die Widerstandsfähigkeit der IKT-Systeme regelmäßig überprüft. Die Anforderungen sind abgestuft:

    Basis-Tests (für alle betroffenen Unternehmen):

    • Schwachstellenscans und -bewertungen
    • Open-Source-Analysen
    • Netzwerksicherheitsbewertungen
    • Gap-Analysen
    • Überprüfung der physischen Sicherheit
    • Überprüfung von Softwarecode (Source Code Reviews)
    • Kompatibilitätstests und Leistungstests
    • End-to-End-Tests und Penetrationstests

    Diese Tests müssen mindestens jährlich durchgeführt werden. Kritische IKT-Systeme sind mindestens einmal jährlich zu testen.

    Erweiterte Tests – Threat-Led Penetration Testing (TLPT):

    • Systemrelevante Finanzunternehmen müssen alle drei Jahre bedrohungsgeleitete Penetrationstests (TLPT) nach dem TIBER-EU-Rahmenwerk durchführen.
    • TLPTs simulieren reale Angriffsszenarien auf Basis aktueller Bedrohungsinformationen (Threat Intelligence).
    • Die Tests müssen von qualifizierten externen Testern durchgeführt werden, wobei interne Tester unter bestimmten Bedingungen mitwirken können.
    • Die zuständige Aufsichtsbehörde muss in den TLPT-Prozess eingebunden werden.

    Alle Testergebnisse, identifizierten Schwachstellen und Abhilfemaßnahmen sind zu dokumentieren und dem Leitungsorgan vorzulegen.

     

    Säule 4: Management des IKT-Drittparteienrisikos (Artikel 28–44)

    Die Überwachung von IKT-Drittanbietern ist eine der anspruchsvollsten DORA Anforderungen. Finanzunternehmen lagern zunehmend kritische IT-Funktionen aus – von Cloud-Infrastruktur über Kernbankensysteme bis hin zu Cybersecurity-Services. DORA adressiert die damit verbundenen Risiken umfassend:

    Vertragliche Anforderungen:

    • Alle Vereinbarungen mit IKT-Drittdienstleistern müssen schriftlich geschlossen werden und bestimmte Mindestinhalte enthalten.
    • Dazu gehören: vollständige Leistungsbeschreibungen, Service Level Agreements (SLAs), Datenschutzbestimmungen, Kündigungsrechte, Auditrechte, Unterstützungspflichten bei Vorfällen und Exit-Strategien.
    • Für kritische oder wichtige Funktionen gelten verschärfte vertragliche Anforderungen, etwa in Bezug auf Datenlokalisierung, Zugangsrechte der Aufsichtsbehörden und Subunternehmer-Management.

    Due Diligence und laufende Überwachung:

    • Vor Vertragsabschluss ist eine gründliche Risikoanalyse des IKT-Drittdienstleisters durchzuführen.
    • Finanzunternehmen müssen ein Informationsregister über alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern führen und dieses der Aufsichtsbehörde auf Anfrage vorlegen.
    • Konzentrationsrisiken sind zu identifizieren und zu bewerten – insbesondere wenn kritische Funktionen bei wenigen Anbietern gebündelt sind.

    Überwachungsrahmenwerk für kritische IKT-Drittdienstleister:

    • Die ESAs (EBA, EIOPA, ESMA) benennen kritische IKT-Drittdienstleister nach festgelegten Kriterien.
    • Diese unterliegen einer direkten Aufsicht durch einen federführenden Aufseher (Lead Overseer), der Empfehlungen aussprechen und bei Nichteinhaltung Maßnahmen einleiten kann.

    Das strukturierte Vendor Risk Management von TrustSpace ermöglicht Finanzunternehmen, ihre IKT-Dienstleister systematisch zu erfassen, zu bewerten und fortlaufend zu überwachen – inklusive automatisierter Risikobewertung und lückenloser Dokumentation.

     

    Säule 5: Vereinbarungen zum Informationsaustausch (Artikel 45)

    DORA ermutigt Finanzunternehmen zum freiwilligen Austausch von Informationen und Erkenntnissen über Cyberbedrohungen. Dieser Informationsaustausch soll:

    • Das Bewusstsein für Cyberbedrohungen im Finanzsektor schärfen
    • Die kollektive Fähigkeit zur Erkennung und Abwehr von Angriffen verbessern
    • Frühwarnsysteme stärken

    Voraussetzung ist, dass der Austausch innerhalb vertrauenswürdiger Gemeinschaften erfolgt und die geltenden Datenschutzbestimmungen eingehalten werden. Finanzunternehmen müssen die zuständige Aufsichtsbehörde über ihre Teilnahme an solchen Vereinbarungen informieren.

     

    DORA Compliance Anforderungen: Umsetzung in der Praxis

    Die regulatorischen Anforderungen sind umfangreich. Die folgende Übersicht zeigt die zentralen Handlungsfelder für eine erfolgreiche DORA-Umsetzung:

    Gap-Analyse und Ist-Aufnahme

    Der erste Schritt besteht in einer systematischen Gap-Analyse, die den aktuellen Reifegrad der Organisation mit den DORA-Anforderungen abgleicht. Dabei sollten folgende Bereiche bewertet werden:

    • Vorhandene IKT-Risikomanagement-Strukturen und -Prozesse
    • Bestehende Incident-Response-Prozesse und deren DORA-Konformität
    • Aktueller Stand des Testprogramms (Umfang, Frequenz, Methodik)
    • Vertragliche Regelungen mit IKT-Drittdienstleistern
    • Dokumentationsqualität und Nachweisfähigkeit

    Governance-Struktur aufbauen

    DORA legt großen Wert auf die Verantwortung des Leitungsorgans. Folgende Governance-Elemente sind zu etablieren:

    • Klare Zuordnung der IKT-Risikoverantwortung auf Vorstands-/Geschäftsführungsebene
    • Einrichtung einer unabhängigen IKT-Risikomanagement-Funktion
    • Definition von Berichtslinien und Eskalationswegen
    • Regelmäßige Schulungen des Leitungsorgans zu IKT-Risiken
    • Integration von IKT-Risiken in die Gesamtrisikostrategie

    Technische Maßnahmen implementieren

    Auf technischer Ebene erfordern die DORA Anforderungen unter anderem:

    • Implementierung von Security Information and Event Management (SIEM)
    • Aufbau oder Optimierung eines Security Operations Center (SOC)
    • Einführung automatisierter Schwachstellenscans
    • Verschlüsselung von Daten in Transit und at Rest
    • Multi-Faktor-Authentifizierung für kritische Systeme
    • Netzwerksegmentierung und Zero-Trust-Architekturen
    • Regelmäßige Backup-Verfahren mit getesteter Wiederherstellung

    Drittanbieter-Register aufbauen

    Das von DORA geforderte Informationsregister muss alle vertraglichen Vereinbarungen mit IKT-Drittdienstleistern erfassen. Für jeden Anbieter sind mindestens zu dokumentieren:

    • Art und Umfang der erbrachten IKT-Dienstleistungen
    • Klassifizierung (kritisch/wichtig vs. nicht-kritisch)
    • Vertragliche Regelungen und SLAs
    • Standorte der Datenverarbeitung
    • Subunternehmer-Ketten
    • Ergebnisse von Risikobewertungen und Audits

     

    Zusammenspiel von DORA mit anderen Regulierungen

    DORA steht nicht isoliert, sondern ergänzt bestehende Regulierungen und schafft sektorspezifische Konkretisierungen:

    • NIS-2-Richtlinie: DORA gilt als lex specialis gegenüber NIS 2 für den Finanzsektor. Finanzunternehmen, die DORA erfüllen, erfüllen grundsätzlich auch die IKT-bezogenen Anforderungen von NIS 2.
    • DSGVO: Die Datenschutz-Grundverordnung bleibt parallel anwendbar. DORA ergänzt die DSGVO um spezifische Anforderungen an die IKT-Sicherheit und das Vorfallmanagement.
    • EBA-/EIOPA-Guidelines: Bestehende aufsichtliche Leitlinien (z.B. EBA Guidelines on ICT and Security Risk Management) werden durch DORA teilweise ersetzt oder ergänzt.
    • ISO 27001: Eine bestehende ISO-27001-Zertifizierung bildet eine solide Grundlage, deckt aber nicht alle DORA-spezifischen Anforderungen ab – insbesondere bei Resilienztests und Drittanbieter-Überwachung.

     

    Typische Herausforderungen bei der DORA-Umsetzung

    In der Praxis stehen Finanzunternehmen vor wiederkehrenden Herausforderungen:

    Komplexität des Drittanbieter-Managements

    Viele Finanzunternehmen haben hunderte IKT-Dienstleister. Die vollständige Erfassung, Klassifizierung und vertragliche Anpassung erfordert erhebliche Ressourcen. Besonders die Identifikation von Subunternehmer-Ketten und Konzentrationsrisiken ist aufwendig.

    Fehlende Automatisierung

    Manuelle Prozesse – etwa Excel-basiertes Risikomanagement oder E-Mail-gestütztes Vorfallmanagement – skalieren nicht. Wer die Anforderungen effizient und nachweissicher umsetzen will, benötigt geeignete Softwarelösungen.

    Qualifikationslücken

    DORA verlangt Expertise in IKT-Risikomanagement, Cybersecurity, Vertragsrecht und regulatorischer Compliance. Nicht jedes Unternehmen verfügt intern über alle erforderlichen Kompetenzen, insbesondere im Bereich TLPT.

    Integration in bestehende Strukturen

    DORA-Anforderungen müssen in bestehende Risikomanagement-, Compliance- und IT-Strukturen integriert werden. Eine isolierte DORA-Umsetzung führt zu Redundanzen und ineffizienten Prozessen.

     

    Wie TrustSpace bei der DORA-Umsetzung unterstützt

    TrustSpace bietet als integrierte Compliance-Plattform wesentliche Funktionen für die Erfüllung der DORA Anforderungen:

    • IKT-Risikomanagement: Strukturierte Erfassung und Bewertung von IKT-Risiken mit automatisierten Workflows und durchgängiger Dokumentation.
    • Asset-Management: Zentrale Inventarisierung aller IKT-Assets und deren Abhängigkeiten.
    • Vendor Risk Management: Systematische Erfassung, Bewertung und Überwachung aller IKT-Drittdienstleister inklusive Informationsregister.
    • Audit-Readiness: Lückenlose Nachweisdokumentation für interne Audits und aufsichtliche Prüfungen.
    • Integriertes Managementsystem: Verknüpfung von DORA mit bestehenden Rahmenwerken wie ISO 27001, NIS 2 und DSGVO.

     

    Fazit: DORA Anforderungen systematisch umsetzen

    Der Digital Operational Resilience Act stellt Finanzunternehmen vor anspruchsvolle, aber notwendige Anforderungen. Die Verordnung schafft einen überfälligen einheitlichen Rahmen für die digitale Widerstandsfähigkeit des europäischen Finanzsektors.

    Entscheidend für eine erfolgreiche Umsetzung ist ein strukturierter, priorisierter Ansatz: Beginnen Sie mit einer Gap-Analyse, etablieren Sie die erforderlichen Governance-Strukturen und setzen Sie auf Automatisierung und geeignete Plattformlösungen, um die Anforderungen nachhaltig und nachweissicher zu erfüllen. Eine zentrale ISMS-Software wie TrustSpaceOS führt IKT-Risikomanagement, Vendor-Überwachung und Audit-Nachweise in einem System zusammen und senkt den manuellen Aufwand der DORA-Umsetzung deutlich.

    Unternehmen, die DORA nicht nur als regulatorische Pflicht, sondern als Chance zur Stärkung ihrer digitalen Resilienz begreifen, schaffen einen echten Wettbewerbsvorteil – und erhöhen gleichzeitig das Vertrauen von Kunden, Partnern und Aufsichtsbehörden.

  • ISMS Risikobehandlungsplan: Erstellung, Dokumentation und Umsetzung nach ISO 27001

    ISMS Risikobehandlungsplan: Erstellung, Dokumentation und Umsetzung nach ISO 27001

    Der Risikobehandlungsplan ist eines der zentralen Dokumente in einem Informationssicherheitsmanagementsystem (ISMS) nach ISO 27001. Er dokumentiert, wie eine Organisation mit identifizierten Informationssicherheitsrisiken umgeht: welche Risiken durch Maßnahmen reduziert werden, welche bewusst akzeptiert werden und welche auf andere Weise behandelt werden. Ohne einen nachvollziehbaren Risikobehandlungsplan ist eine ISO 27001 Zertifizierung nicht möglich.

    Trotz seiner zentralen Bedeutung stellt der Risikobehandlungsplan viele Unternehmen vor Herausforderungen: Wie wird er strukturiert? Welche Risikobehandlungsoptionen stehen zur Verfügung? Wie wird die Verbindung zu den Annex A Controls hergestellt? Dieser Artikel beantwortet diese Fragen praxisnah und zeigt Schritt für Schritt, wie Sie einen wirksamen ISMS Risikobehandlungsplan erstellen.

    Das Wichtigste in Kürze:

    • Der Risikobehandlungsplan dokumentiert, wie identifizierte Risiken im ISMS systematisch behandelt werden – er ist ein Pflichtdokument nach ISO 27001 (Kapitel 6.1.3).
    • Es stehen vier Risikobehandlungsoptionen zur Verfügung: Risikominderung, Risikovermeidung, Risikotransfer und Risikoakzeptanz.
    • Jedes behandelte Risiko muss mit konkreten Maßnahmen (Controls) verknüpft werden – die ISO 27001 Annex A liefert einen Referenzkatalog mit 93 Controls.
    • Die Erklärung zur Anwendbarkeit (SoA) und der Risikobehandlungsplan sind eng miteinander verbunden und werden im Audit gemeinsam geprüft.
    • Ein wirksamer Risikobehandlungsplan enthält klare Verantwortlichkeiten, Zeitpläne und messbare Kriterien für die Umsetzung der Maßnahmen.

     

    Was ist ein ISMS Risikobehandlungsplan?

    Der ISMS Risikobehandlungsplan ist ein dokumentierter Plan, der für jedes identifizierte und bewertete Informationssicherheitsrisiko festlegt, wie die Organisation damit umgeht. Er ist das Bindeglied zwischen der Risikoanalyse (in der Risiken identifiziert und bewertet werden) und der operativen Umsetzung von Sicherheitsmaßnahmen. Wie sich dieser Schritt in das Gesamtprojekt einfügt, von der Scope-Definition bis zum Zertifikat, beschreibt unser Praxis-Guide zum Aufbau eines ISMS nach ISO 27001.

    Einordnung in den ISMS-Prozess

    Der Risikobehandlungsplan entsteht im Rahmen des Risikomanagementprozesses, der in der ISO 27001 in Kapitel 6.1 beschrieben wird. Der Gesamtprozess umfasst:

    1. Risikoidentifikation: Welche Risiken bestehen für die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen?
    2. Risikobewertung: Wie hoch ist die Eintrittswahrscheinlichkeit und welches Ausmaß hätte der Schaden?
    3. Risikobehandlung: Wie wird mit den bewerteten Risiken umgegangen? Hier entsteht der Risikobehandlungsplan.
    4. Risikoüberwachung: Werden die Maßnahmen wirksam umgesetzt und verändern sich die Risiken über die Zeit?

    Der Risikobehandlungsplan wird von der Geschäftsführung (oder dem definierten Risikoeigner) genehmigt und bildet die Grundlage für die Zuweisung von Ressourcen und Verantwortlichkeiten. In Audits ist er eines der am intensivsten geprüften Dokumente.

    Anforderungen der ISO 27001 an den Risikobehandlungsplan

    Die ISO 27001 stellt in Kapitel 6.1.3 explizite Anforderungen an den Risikobehandlungsprozess und den daraus resultierenden Plan:

    • Für jedes Risiko müssen geeignete Risikobehandlungsoptionen ausgewählt werden.
    • Alle zur Risikobehandlung erforderlichen Controls müssen bestimmt werden (unter Berücksichtigung von Annex A als Referenz).
    • Die ausgewählten Controls müssen mit den Annex A Controls abgeglichen werden, um sicherzustellen, dass keine wesentlichen Controls übersehen wurden.
    • Eine Erklärung zur Anwendbarkeit (Statement of Applicability, SoA) muss erstellt werden.
    • Der Risikobehandlungsplan muss formuliert und von den Risikoeignern genehmigt werden.

     

    Die vier Risikobehandlungsoptionen im Detail

    Die Risikobehandlung nach ISO 27001 kennt vier grundlegende Optionen. Für jedes identifizierte Risiko muss eine (oder eine Kombination) dieser Optionen gewählt und dokumentiert werden.

    1. Risikominderung (Risikomodifikation)

    Die Risikominderung ist die am häufigsten gewählte Option. Durch die Implementierung von Sicherheitsmaßnahmen (Controls) wird die Eintrittswahrscheinlichkeit und/oder die Auswirkung eines Risikos auf ein akzeptables Niveau reduziert.

    Beispiele:

    • Implementierung von Multi-Faktor-Authentifizierung zur Reduktion des Risikos unbefugter Zugriffe.
    • Einführung eines Patch-Management-Prozesses zur Minimierung von Schwachstellen.
    • Durchführung von Security-Awareness-Schulungen zur Reduktion von Phishing-Risiken.
    • Verschlüsselung von Daten zur Minderung des Risikos bei Datenverlust.

    Wichtig: Die Risikominderung eliminiert ein Risiko nicht vollständig. Es verbleibt immer ein Restrisiko, das dokumentiert und von den Risikoeignern akzeptiert werden muss.

    2. Risikovermeidung

    Bei der Risikovermeidung wird die risikobehaftete Aktivität, der Prozess oder die Technologie vollständig aufgegeben. Das Risiko wird eliminiert, indem seine Ursache beseitigt wird.

    Beispiele:

    • Verzicht auf den Einsatz einer unsicheren Legacy-Anwendung durch Migration auf eine moderne Alternative.
    • Einstellung eines Dienstes, der nicht ausreichend abgesichert werden kann.
    • Verlagerung sensibler Datenverarbeitung aus einem unsicheren Standort.

    Einschränkung: Risikovermeidung ist nicht immer praktikabel. Viele Risiken sind mit Kernprozessen des Unternehmens verbunden und können nicht einfach vermieden werden, ohne die Geschäftstätigkeit einzuschränken.

    3. Risikotransfer (Risikoübertragung)

    Beim Risikotransfer wird das Risiko ganz oder teilweise auf einen Dritten übertragen. Die häufigsten Formen sind Versicherungen und die Auslagerung an spezialisierte Dienstleister.

    Beispiele:

    • Abschluss einer Cyber-Versicherung zur finanziellen Absicherung gegen Schäden durch Cyberangriffe.
    • Auslagerung des IT-Betriebs an einen spezialisierten Managed-Security-Service-Provider (MSSP).
    • Vertragliche Übertragung von Sicherheitsverantwortung auf einen Cloud-Anbieter (Shared-Responsibility-Modell).

    Wichtig: Der Risikotransfer überträgt die finanzielle oder operative Verantwortung – die Rechenschaftspflicht verbleibt jedoch bei der Organisation. Sie bleibt dafür verantwortlich, dass angemessene Sicherheitsmaßnahmen getroffen werden, auch wenn ein Dienstleister die operative Umsetzung übernimmt.

    4. Risikoakzeptanz

    Bei der Risikoakzeptanz entscheidet die Organisation bewusst, ein Risiko ohne zusätzliche Maßnahmen zu tragen. Diese Option ist gerechtfertigt, wenn die Kosten der Risikobehandlung den potenziellen Schaden übersteigen oder wenn das Risiko bereits innerhalb der definierten Risikoakzeptanzkriterien liegt.

    Beispiele:

    • Akzeptanz des Restrisikos nach Implementierung von Minderungsmaßnahmen, wenn das verbleibende Risiko unterhalb der Schwelle liegt.
    • Bewusste Akzeptanz eines geringen Risikos, dessen Behandlung unverhältnismäßig hohe Kosten verursachen würde.

    Voraussetzungen: Die Risikoakzeptanz muss dokumentiert, begründet und von den zuständigen Risikoeignern oder der Geschäftsführung formal genehmigt werden. „Akzeptanz durch Nichtstun“ – also das unbewusste Ignorieren eines Risikos – ist keine gültige Risikoakzeptanz im Sinne der ISO 27001.

     

    Schritt-für-Schritt-Anleitung: ISMS Risikobehandlungsplan erstellen

    Die Erstellung eines ISMS Risikobehandlungsplans folgt einem strukturierten Prozess. Die folgende Anleitung orientiert sich an den Anforderungen der ISO 27001 und zeigt die einzelnen Schritte praxisnah auf.

    Schritt 1: Ergebnisse der Risikoanalyse übernehmen

    Der Risikobehandlungsplan baut auf den Ergebnissen der vorgelagerten Risikoanalyse auf. Wie belastbar diese Ergebnisse sind, entscheidet sich bereits eine Stufe früher: Erst eine vollständige Strukturanalyse der Systeme, Prozesse und Informationswerte stellt sicher, dass kein relevanter Bereich unbewertet bleibt. Für den Plan werden alle Risiken übernommen, die oberhalb der definierten Risikoakzeptanzschwelle liegen und daher einer Behandlung bedürfen. Jedes Risiko sollte dabei folgende Attribute mitbringen:

    • Eindeutige Risiko-ID
    • Beschreibung des Risikos (Bedrohung, Schwachstelle, betroffener Informationswert)
    • Bewertung der Eintrittswahrscheinlichkeit und Auswirkung
    • Aktueller Risikowert (vor Behandlung)
    • Zugeordneter Risikoeigner

    Schritt 2: Risikobehandlungsoption auswählen

    Für jedes zu behandelnde Risiko wird eine der vier Risikobehandlungsoptionen (oder eine Kombination) ausgewählt. Die Auswahl sollte auf einer fundierten Kosten-Nutzen-Analyse basieren:

    • Welche Option reduziert das Risiko am effektivsten?
    • Welche Kosten sind mit der jeweiligen Option verbunden?
    • Ist die Option mit den Geschäftszielen und der Risikobereitschaft der Organisation vereinbar?
    • Welches Restrisiko verbleibt nach der Behandlung?

    Schritt 3: Maßnahmen (Controls) definieren

    Für jedes Risiko, das gemindert werden soll, müssen konkrete Maßnahmen (Controls) definiert werden. Die ISO 27001 Annex A bietet mit ihren 93 Controls (in der Version 2022) einen umfassenden Referenzkatalog, der in vier Themenbereiche gegliedert ist:

    Themenbereich Anzahl Controls Beispiele
    Organisatorische Controls 37 Informationssicherheitsrichtlinie, Rollen und Verantwortlichkeiten, Threat Intelligence
    Personenbezogene Controls 8 Screening, Awareness-Schulungen, Verantwortlichkeiten nach Beendigung
    Physische Controls 14 Physische Sicherheitszonen, Schutz vor Umweltbedrohungen, Speichermedien
    Technologische Controls 34 Zugangssteuerung, Kryptografie, Logging, Netzwerksicherheit

    Wichtig: Die Annex A Controls dienen als Referenz, nicht als Pflichtliste. Unternehmen müssen prüfen, welche Controls für ihre spezifischen Risiken relevant sind. Darüber hinaus können auch Controls aus anderen Quellen (z. B. BSI IT-Grundschutz, branchenspezifische Standards) herangezogen werden.

    Schritt 4: Erklärung zur Anwendbarkeit (SoA) erstellen

    Die Erklärung zur Anwendbarkeit (Statement of Applicability) ist ein Pflichtdokument, das eng mit dem Risikobehandlungsplan verknüpft ist. Sie listet alle Controls aus Annex A auf und dokumentiert für jedes Control:

    • Ob das Control angewendet wird oder nicht.
    • Die Begründung für die Aufnahme oder den Ausschluss.
    • Den aktuellen Umsetzungsstand.

    Die SoA stellt sicher, dass kein relevantes Control übersehen wird und dass der Ausschluss von Controls nachvollziehbar begründet ist.

    Schritt 5: Umsetzungsdetails festlegen

    Für jede Maßnahme im Risikobehandlungsplan müssen operative Details definiert werden:

    • Verantwortlicher: Wer ist für die Umsetzung der Maßnahme verantwortlich?
    • Zeitplan: Bis wann muss die Maßnahme umgesetzt sein?
    • Ressourcen: Welche finanziellen, personellen und technischen Ressourcen werden benötigt?
    • Erwartetes Restrisiko: Auf welches Niveau wird das Risiko durch die Maßnahme voraussichtlich reduziert?
    • Wirksamkeitskriterien: Woran wird gemessen, ob die Maßnahme wirksam ist?

    Schritt 6: Genehmigung durch Risikoeigner

    Der Risikobehandlungsplan muss von den zuständigen Risikoeignern formal genehmigt werden. Die Genehmigung umfasst:

    • Zustimmung zu den gewählten Risikobehandlungsoptionen.
    • Akzeptanz der verbleibenden Restrisiken.
    • Freigabe der erforderlichen Ressourcen.

    Diese Genehmigung ist ein explizites Audit-Kriterium und muss dokumentiert nachweisbar sein.

     

    TrustSpace Profi-Tipp: Die Erstellung und Pflege eines ISMS Risikobehandlungsplans kann komplex und zeitaufwändig sein – insbesondere wenn Risikoanalyse, Maßnahmenmanagement und SoA in verschiedenen Dokumenten und Tabellen gepflegt werden. TrustSpaceOS integriert den gesamten Risikomanagementprozess in einer Plattform: Von der Risikoidentifikation über die automatisierte Verknüpfung mit Annex A Controls bis hin zur Generierung der SoA. Risikoeigner können Behandlungspläne direkt in der Plattform genehmigen, und der Umsetzungsfortschritt wird in Echtzeit nachverfolgt. So sparen Sie bis zu 60 % des manuellen Aufwands und gehen bestens vorbereitet in jedes Audit.

     

     

    Häufige Fehler beim Risikobehandlungsplan

    In der Praxis treten bei der Erstellung und Pflege von ISMS Risikobehandlungsplänen regelmäßig typische Fehler auf, die im Audit zu Beanstandungen führen.

    Fehlende Verbindung zwischen Risikoanalyse und Maßnahmen

    Der häufigste Fehler: Maßnahmen werden ausgewählt, ohne dass eine nachvollziehbare Verbindung zu den identifizierten Risiken besteht. Jede Maßnahme im Risikobehandlungsplan muss auf mindestens ein konkretes Risiko zurückführbar sein. Umgekehrt muss für jedes Risiko oberhalb der Akzeptanzschwelle mindestens eine Behandlungsoption dokumentiert sein.

    Unzureichende Begründung der Risikoakzeptanz

    Risiken als „akzeptiert“ zu kennzeichnen, ohne eine fundierte Begründung zu liefern, ist ein häufiger Audit-Befund. Die Risikoakzeptanz muss auf definierten Kriterien basieren, die Begründung muss dokumentiert sein, und die Genehmigung durch den Risikoeigner muss vorliegen.

    Fehlende oder unrealistische Zeitpläne

    Ein Risikobehandlungsplan ohne Zeitplan ist ein reines Absichtsdokument. Ebenso problematisch sind unrealistische Zeitvorgaben, die nie eingehalten werden. Setzen Sie realistische Meilensteine und überprüfen Sie den Fortschritt regelmäßig.

    Keine Betrachtung des Restrisikos

    Nach der Implementierung von Maßnahmen verbleibt ein Restrisiko. Dieses muss explizit bewertet und dokumentiert werden. Liegt das Restrisiko weiterhin oberhalb der Akzeptanzschwelle, sind zusätzliche Maßnahmen oder eine formale Risikoakzeptanz erforderlich.

    Statischer Plan ohne Aktualisierung

    Ein Risikobehandlungsplan ist ein lebendes Dokument. Neue Risiken, veränderte Bedrohungslagen, organisatorische Änderungen und die Ergebnisse von Wirksamkeitsprüfungen müssen kontinuierlich in den Plan einfließen. Ein Plan, der seit der initialen Erstellung nicht mehr aktualisiert wurde, verfehlt seinen Zweck.

     

    Der Risikobehandlungsplan im Audit

    Im Rahmen einer ISO 27001 Zertifizierung wird der Risikobehandlungsplan intensiv geprüft. Auditoren achten insbesondere auf folgende Aspekte:

    Konsistenz der Dokumentation

    Der Auditor prüft, ob eine nachvollziehbare Kette von der Risikoanalyse über den Risikobehandlungsplan bis zur SoA und den implementierten Controls besteht. Lücken oder Widersprüche zwischen diesen Dokumenten führen zu Feststellungen.

    Genehmigung und Verantwortlichkeiten

    Die formale Genehmigung des Plans durch die Risikoeigner wird geprüft. Ebenso wird überprüft, ob die benannten Verantwortlichen ihre Rolle kennen und aktiv wahrnehmen.

    Umsetzungsstand der Maßnahmen

    Auditoren prüfen stichprobenartig, ob die im Risikobehandlungsplan definierten Maßnahmen tatsächlich implementiert und wirksam sind. Eine Maßnahme, die nur auf dem Papier existiert, erfüllt die Anforderungen nicht.

    Nachvollziehbare Risikoakzeptanz

    Für jedes akzeptierte Risiko wird geprüft, ob die Akzeptanzentscheidung auf definierten Kriterien basiert, dokumentiert und genehmigt ist. Die Begründung muss plausibel und nachvollziehbar sein.

    Aktualität des Plans

    Ein Risikobehandlungsplan, der seit der initialen Erstellung nicht mehr überarbeitet wurde, deutet auf ein nicht gelebtes Risikomanagement hin. Auditoren erwarten regelmäßige Reviews und Aktualisierungen. Welche Prüfungen dabei in welchem Turnus anstehen, vom Erstzertifizierungs- bis zum Überwachungsaudit, ordnet unser Beitrag zu Ablauf und Arten von ISMS-Audits ein.

     

    Best Practices für einen wirksamen Risikobehandlungsplan

    Basierend auf Erfahrungen aus zahlreichen ISMS-Implementierungen haben sich folgende Best Practices bewährt:

    • Integration statt Isolation: Pflegen Sie Risikoanalyse, Risikobehandlungsplan und SoA in einem integrierten System, nicht in getrennten Dokumenten. So vermeiden Sie Inkonsistenzen und reduzieren den Pflegeaufwand. Welche Kernfunktionen ein solches System abdecken sollte, zeigt unser Überblick zu ISMS-Software und ihren zentralen Modulen.
    • Klare Risikoakzeptanzkriterien: Definieren Sie vorab quantitative oder qualitative Kriterien, ab welchem Niveau Risiken akzeptabel sind. Dies erleichtert die Entscheidungsfindung und stellt Konsistenz sicher.
    • Regelmäßige Reviews: Überprüfen Sie den Risikobehandlungsplan mindestens quartalsweise oder anlassbezogen (z. B. nach Sicherheitsvorfällen, organisatorischen Änderungen oder neuen Bedrohungen).
    • Messbare Wirksamkeitskriterien: Definieren Sie für jede Maßnahme, woran ihre Wirksamkeit gemessen wird. Beispiele: Anzahl erfolgreicher Phishing-Simulationen, Patch-Compliance-Rate, Ergebnisse von Penetrationstests.
    • Einbindung der Fachbereiche: Risikoeigner aus den Fachbereichen müssen aktiv in die Erstellung und Genehmigung des Plans eingebunden werden. Informationssicherheit ist keine reine IT-Aufgabe.
    • Priorisierung nach Risikohöhe: Behandeln Sie die höchsten Risiken zuerst. Eine risikobasierte Priorisierung stellt sicher, dass begrenzte Ressourcen dort eingesetzt werden, wo sie den größten Effekt haben.

     

    Fazit: Der Risikobehandlungsplan als Steuerungsinstrument der Informationssicherheit

    Der ISMS Risikobehandlungsplan ist weit mehr als ein Audit-Dokument – er ist das zentrale Steuerungsinstrument für die Informationssicherheit Ihres Unternehmens. Er übersetzt die Ergebnisse der Risikoanalyse in konkrete, nachverfolgbare Maßnahmen und stellt sicher, dass Risiken systematisch und nachvollziehbar behandelt werden.

    Ein wirksamer Risikobehandlungsplan zeichnet sich durch klare Verantwortlichkeiten, realistische Zeitpläne, eine nachvollziehbare Verbindung zu den identifizierten Risiken und den Annex A Controls sowie eine konsequente Pflege und Aktualisierung aus. Unternehmen, die ihren Risikobehandlungsplan als lebendes Dokument begreifen und aktiv nutzen, profitieren nicht nur im Audit, sondern stärken ihre Informationssicherheit nachhaltig.

     

    Sie möchten Ihren ISMS Risikobehandlungsplan effizient erstellen und pflegen? TrustSpaceOS bietet ein integriertes Risikomanagement-Modul, das Risikoanalyse, Risikobehandlungsplan und Statement of Applicability in einer Plattform vereint. Automatisierte Verknüpfungen zu ISO 27001 Annex A Controls, integrierte Genehmigungs-Workflows und Echtzeit-Reporting machen die Pflege Ihres Risikobehandlungsplans so effizient wie möglich. Unsere erfahrenen ISO 27001 Berater unterstützen Sie zusätzlich bei der Konzeption und Implementierung Ihres Risikomanagements.

    Jetzt kostenlose Erstberatung vereinbaren

  • NIS-2-Meldepflicht: Fristen, Abläufe und praktische Anleitung für den Ernstfall

    NIS-2-Meldepflicht: Fristen, Abläufe und praktische Anleitung für den Ernstfall

    Die NIS-2-Richtlinie verschärft die Anforderungen an die Cybersicherheit in der EU erheblich – und mit ihr kommen strenge Meldepflichten auf Unternehmen zu. Wer einen Sicherheitsvorfall nicht rechtzeitig meldet, riskiert empfindliche Bußgelder und persönliche Haftung der Geschäftsführung. Doch welche Vorfälle sind überhaupt meldepflichtig? Welche Fristen gelten? Und an wen muss die Meldung erfolgen?

    Dieser Artikel erklärt die NIS-2-Meldepflicht im Detail, zeigt die konkreten Fristen und Abläufe und gibt eine praxisnahe Anleitung, damit Ihr Unternehmen im Ernstfall vorbereitet ist. In Deutschland gilt sie seit dem 6. Dezember 2025 unmittelbar über § 32 BSIG; den Gesamtrahmen dazu bündelt unsere Zusammenfassung der NIS-2-Richtlinie.

    Das Wichtigste in Kürze:

    • Die NIS-2-Richtlinie führt ein dreistufiges Meldesystem für Sicherheitsvorfälle ein: Frühwarnung (24h), ausführlicher Bericht (72h) und Abschlussbericht (1 Monat).
    • Meldepflichtig sind erhebliche Sicherheitsvorfälle, die den Betrieb wesentlicher oder wichtiger Einrichtungen beeinträchtigen.
    • Zuständige Behörde in Deutschland ist das Bundesamt für Sicherheit in der Informationstechnik (BSI).
    • Unternehmen benötigen klare interne Prozesse und Incident-Response-Pläne, um die Fristen einzuhalten.
    • Bei Verstößen gegen die Meldepflicht drohen Bußgelder von bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes.

     

    NIS-2-Meldepflicht: Was ändert sich gegenüber NIS-1?

    Die ursprüngliche NIS-Richtlinie (NIS-1) von 2016 enthielt bereits Meldepflichten für Betreiber wesentlicher Dienste und Anbieter digitaler Dienste. Allerdings waren die Anforderungen uneinheitlich und ließen den Mitgliedstaaten erheblichen Spielraum bei der Umsetzung.

    NIS-2 schafft hier klare Verhältnisse:

    • Erweiterter Anwendungsbereich: Deutlich mehr Sektoren und Unternehmen fallen unter die Richtlinie – nach § 28 BSIG erstmals auch mittlere Unternehmen ab 50 Beschäftigten oder mit einem Jahresumsatz und einer Jahresbilanzsumme von jeweils über 10 Mio. Euro.
    • Einheitliche Meldefristen: Statt unterschiedlicher nationaler Regelungen gelten nun EU-weit verbindliche Zeitfenster.
    • Dreistufiges Meldesystem: Frühwarnung, ausführlicher Bericht und Abschlussbericht bilden ein strukturiertes Verfahren.
    • Verschärfte Sanktionen: Bei Verstößen drohen deutlich höhere Bußgelder als unter NIS-1.

    Die NIS-2-Meldung eines Sicherheitsvorfalls wird damit zu einer der kritischsten Compliance-Pflichten für betroffene Unternehmen. Sie steht allerdings nicht allein: Registrierung beim BSI, Risikomanagement und Nachweisführung greifen ineinander – in welcher Reihenfolge kleinere Unternehmen das abarbeiten sollten, zeigt unsere NIS-2-Checkliste für den Mittelstand.

     

    Welche Sicherheitsvorfälle sind meldepflichtig?

    Nicht jeder IT-Vorfall löst eine Meldepflicht aus. NIS-2 definiert den Begriff des erheblichen Sicherheitsvorfalls anhand konkreter Kriterien:

    Definition: Erheblicher Sicherheitsvorfall

    Ein Sicherheitsvorfall gilt als erheblich, wenn er:

    • eine schwerwiegende Betriebsstörung der Dienste verursacht oder verursachen kann,
    • finanzielle Verluste für die betroffene Einrichtung nach sich zieht,
    • andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt.

    Beispiele für meldepflichtige Vorfälle

    Vorfalltyp Meldepflichtig? Begründung
    Ransomware-Angriff mit Betriebsunterbrechung Ja Schwerwiegende Betriebsstörung
    Datenexfiltration personenbezogener Daten Ja Erheblicher Schaden für Betroffene
    DDoS-Angriff mit Serviceausfall > 1 Stunde Ja Störung wesentlicher Dienste
    Kompromittierung eines Administrationszugangs Ja Potenzielle schwerwiegende Auswirkungen
    Fehlgeschlagener Phishing-Versuch (erkannt, blockiert) Nein Keine Auswirkung auf Betrieb
    Geplante Wartungsunterbrechung Nein Kein Sicherheitsvorfall

    Sonderfall: Vorfälle beim Dienstleister

    Nicht jeder meldepflichtige Vorfall entsteht im eigenen Netz. Fällt ein Cloud-Provider oder Managed-Service-Anbieter durch einen Angriff aus und beeinträchtigt das Ihren eigenen Dienst erheblich, läuft Ihre 24-Stunden-Frist trotzdem – gerechnet ab dem Moment, in dem Sie Kenntnis erlangen. Deshalb gehören Meldewege und Reaktionszeiten in jeden Dienstleistervertrag. Wie sich die Sicherheit der Lieferkette systematisch bewerten und vertraglich absichern lässt, beschreiben wir separat.

    Abgrenzung zur DSGVO-Meldepflicht

    Wichtig: Die NIS-2-Meldepflicht besteht zusätzlich zur Meldepflicht nach Art. 33 DSGVO. Betrifft ein Vorfall sowohl die IT-Sicherheit als auch personenbezogene Daten, müssen beide Meldewege bedient werden – an das BSI (NIS-2) und an die zuständige Datenschutzaufsichtsbehörde (DSGVO).

     

    Die drei Meldestufen im Detail: 24h, 72h und Abschlussbericht

    Das dreistufige Meldesystem der NIS-2-Richtlinie folgt einer klaren zeitlichen Logik. Jede Stufe hat einen definierten Inhalt und Zweck.

    Stufe 1: Frühwarnung – innerhalb von 24 Stunden

    Die Frühwarnung muss innerhalb von 24 Stunden nach Kenntnisnahme des erheblichen Sicherheitsvorfalls erfolgen. Sie dient der schnellen Alarmierung der Behörden.

    Pflichtinhalte der Frühwarnung:

    • Erste Einschätzung, ob der Vorfall auf eine rechtswidrige oder böswillige Handlung zurückzuführen ist
    • Angabe, ob grenzüberschreitende Auswirkungen möglich sind
    • Kurze Beschreibung des Vorfalls

    Die Frühwarnung muss keine vollständige Analyse enthalten – es geht um Schnelligkeit, nicht um Perfektion.

    Stufe 2: Ausführlicher Bericht – innerhalb von 72 Stunden

    Innerhalb von 72 Stunden nach Kenntnisnahme muss ein detaillierter Bericht folgen. Dieser aktualisiert und ergänzt die Frühwarnung um:

    • Eine erste Bewertung des Sicherheitsvorfalls (Schwere, Auswirkungen)
    • Angaben zu den Kompromittierungsindikatoren (Indicators of Compromise, IoC)
    • Bereits ergriffene und geplante Gegenmaßnahmen

    Stufe 3: Abschlussbericht – innerhalb von einem Monat

    Spätestens einen Monat nach dem ausführlichen Bericht ist ein Abschlussbericht einzureichen. Dieser enthält:

    • Eine detaillierte Beschreibung des Vorfalls einschließlich Schweregrad und Auswirkungen
    • Die Art der Bedrohung oder Ursache, die den Vorfall ausgelöst hat
    • Ergriffene und laufende Abhilfemaßnahmen
    • Gegebenenfalls die grenzüberschreitenden Auswirkungen des Vorfalls

    Sollte der Vorfall zum Zeitpunkt des Abschlussberichts noch andauern, ist stattdessen ein Zwischenbericht fällig – der Abschlussbericht wird dann nach Behebung nachgereicht.

     

    TrustSpace Profi-Tipp: Bereiten Sie Vorlagen für alle drei Meldestufen im Voraus vor. Im Ernstfall bleibt keine Zeit, die richtigen Formulierungen und Inhalte zusammenzusuchen. TrustSpaceOS bietet vordefinierte Incident-Report-Templates, die sich im Ernstfall in Minuten ausfüllen und übermitteln lassen.

     

     

    Zuständige Behörden: An wen muss gemeldet werden?

    BSI als zentrale Meldestelle in Deutschland

    In Deutschland ist das Bundesamt für Sicherheit in der Informationstechnik (BSI) die zuständige Behörde für NIS-2-Meldungen. Nach § 32 BSIG gehen die Meldungen an eine gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe. Das BSI fungiert als:

    • Nationale zuständige Behörde im Sinne der NIS-2-Richtlinie
    • Computer Security Incident Response Team (CSIRT) für die Koordination der Vorfallbewältigung
    • Zentrale Anlaufstelle für grenzüberschreitende Zusammenarbeit

    Meldewege

    Das BSI-Portal ist seit dem 6. Januar 2026 freigeschaltet; der Zugang läuft über das ELSTER-Unternehmenskonto (“Mein Unternehmenskonto”). Für die NIS-2-Meldung eines Sicherheitsvorfalls stehen folgende Kanäle bereit:

    • Online-Meldeportal des BSI (bevorzugter Weg)
    • E-Mail an die dedizierte Meldestelle
    • Telefonische Meldung für besonders dringende Fälle (24/7-Erreichbarkeit)

    Sonderfall: Grenzüberschreitende Vorfälle

    Bei Vorfällen mit Auswirkungen auf andere EU-Mitgliedstaaten koordiniert das BSI die Information der betroffenen nationalen Behörden über das EU-weite CSIRT-Netzwerk. Unternehmen müssen den grenzüberschreitenden Charakter bereits in der Frühwarnung angeben.

     

    NIS-2 Incident Reporting: Praktische Anleitung in 7 Schritten

    Damit Ihr Unternehmen im Ernstfall handlungsfähig ist, empfiehlt sich folgendes strukturiertes Vorgehen für das NIS-2 Incident Reporting:

    Schritt 1: Vorfall erkennen und klassifizieren

    • Automatisierte Monitoring-Systeme (SIEM, IDS/IPS) zur Früherkennung einsetzen
    • Klar definierte Kriterien, wann ein Vorfall als erheblich einzustufen ist
    • Sofortige Eskalation an das Incident-Response-Team

    Schritt 2: Interne Alarmkette auslösen

    • Benachrichtigung der Geschäftsführung (Haftungsrelevanz)
    • Information des IT-Sicherheitsbeauftragten / CISO
    • Einberufung des Incident-Response-Teams

    Schritt 3: Frühwarnung absenden (24h-Frist)

    • Nutzung des vorbereiteten Templates
    • Übermittlung über das BSI-Meldeportal
    • Dokumentation von Zeitpunkt und Inhalt der Meldung

    Schritt 4: Forensische Analyse starten

    • Beweissicherung (Logs, Systemabbilder, Netzwerkverkehr)
    • Identifikation von Kompromittierungsindikatoren (IoC)
    • Ermittlung des Angriffswegs und der betroffenen Systeme

    Schritt 5: Ausführlichen Bericht erstellen (72h-Frist)

    • Zusammenfassung der bisherigen Erkenntnisse
    • Dokumentation der IoC und ergriffenen Gegenmaßnahmen
    • Übermittlung an das BSI

    Schritt 6: Gegenmaßnahmen umsetzen und dokumentieren

    • Eindämmung des Vorfalls (Containment)
    • Bereinigung betroffener Systeme
    • Wiederherstellung des Normalbetriebs
    • Lückenlose Dokumentation aller Maßnahmen

    Schritt 7: Abschlussbericht einreichen (1-Monat-Frist)

    • Vollständige Vorfallanalyse mit Root-Cause-Analyse
    • Bewertung der Wirksamkeit der Gegenmaßnahmen
    • Ableitung von Verbesserungsmaßnahmen (Lessons Learned)

     

    Häufige Fehler bei der NIS-2-Meldepflicht

    In der Praxis scheitern Unternehmen häufig an vermeidbaren Fehlern. Diese sollten Sie kennen:

    1. Fehlende Vorfallerkennung:
    Ohne funktionierendes Monitoring-System werden Vorfälle oft erst nach Tagen oder Wochen erkannt – die 24-Stunden-Frist für die Frühwarnung beginnt aber mit der Kenntnisnahme, und Behörden können hinterfragen, warum ein Vorfall nicht früher bemerkt wurde.

    2. Unklare interne Zuständigkeiten:
    Wenn im Ernstfall erst geklärt werden muss, wer die Meldung verantwortet, geht wertvolle Zeit verloren. Definieren Sie Rollen und Verantwortlichkeiten im Voraus.

    3. Überperfektionismus bei der Frühwarnung:
    Die 24-Stunden-Meldung soll eine erste Einschätzung liefern, keine vollständige forensische Analyse. Viele Unternehmen verlieren Zeit, weil sie die Frühwarnung zu detailliert gestalten wollen.

    4. Fehlende Dokumentation:
    Jede Entscheidung, jede Maßnahme und jede Kommunikation muss dokumentiert werden. Im Zweifel dient die Dokumentation als Nachweis gegenüber Behörden und Auditoren.

    5. DSGVO-Meldung vergessen:
    Bei Vorfällen mit personenbezogenen Daten muss parallel die Datenschutzaufsichtsbehörde informiert werden – die NIS-2-Meldung ersetzt die DSGVO-Meldung nicht.

     

    TrustSpace Profi-Tipp: Führen Sie mindestens einmal jährlich eine Incident-Response-Übung durch, bei der Sie einen Sicherheitsvorfall simulieren und den gesamten Meldeprozess durchspielen. So identifizieren Sie Schwachstellen in Ihrem Prozess, bevor der Ernstfall eintritt. TrustSpace unterstützt Sie bei der Planung und Durchführung solcher Übungen.

     

     

    Checkliste: Ist Ihr Unternehmen auf die Meldepflicht vorbereitet?

    Nutzen Sie diese Checkliste zur Selbsteinschätzung:

    • ☐ Monitoring: Sind automatisierte Systeme zur Vorfallerkennung im Einsatz (SIEM, EDR)?
    • ☐ Klassifizierung: Gibt es klare Kriterien, wann ein Vorfall als „erheblich” gilt?
    • ☐ Incident-Response-Plan: Existiert ein dokumentierter und getesteter Notfallplan?
    • ☐ Alarmketten: Sind Eskalationswege und Zuständigkeiten definiert?
    • ☐ Meldevorlagen: Liegen Templates für Frühwarnung, ausführlichen Bericht und Abschlussbericht bereit?
    • ☐ BSI-Meldezugang: Ist der Zugang zum BSI-Meldeportal eingerichtet und getestet?
    • ☐ DSGVO-Schnittstelle: Ist der parallele Meldeprozess an die Datenschutzaufsicht definiert?
    • ☐ Übungen: Wird der Meldeprozess regelmäßig geübt?
    • ☐ Dokumentation: Ist ein System zur lückenlosen Vorfallsdokumentation vorhanden?
    • ☐ Geschäftsführung: Ist die Geschäftsleitung über ihre persönliche Haftung informiert?

     

    NIS-2-Meldepflicht: Konsequenzen bei Verstößen

    Die NIS-2-Richtlinie sieht empfindliche Sanktionen für Verstöße gegen die Meldepflicht vor:

    • Wesentliche Einrichtungen: Bußgelder bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes (je nachdem, welcher Betrag höher ist)
    • Wichtige Einrichtungen: Bußgelder bis zu 7 Mio. Euro oder 1,4 % des weltweiten Jahresumsatzes
    • Persönliche Haftung: Geschäftsführer können bei Pflichtverletzung persönlich haftbar gemacht werden

    Besonders kritisch: Die Aufsichtsbehörden können bei wiederholten Verstößen auch Leitungspersonen vorübergehend untersagen, ihre Führungsfunktion auszuüben. In Deutschland staffelt § 65 BSIG die Tatbestände in mehreren Stufen und setzt bereits bei 100.000 Euro an – die vollständige Systematik der NIS-2-Bußgelder und der Geschäftsführerhaftung haben wir separat aufbereitet.

     

    Fazit: Vorbereitung ist alles

    Die NIS-2-Meldepflicht stellt Unternehmen vor organisatorische und technische Herausforderungen. Die kurzen Fristen – insbesondere die 24-Stunden-Frist für die Frühwarnung – erfordern klar definierte Prozesse, geschultes Personal und geeignete technische Werkzeuge.

    Der Schlüssel liegt in der Vorbereitung: Unternehmen, die ihren Incident-Response-Prozess heute aufsetzen, testen und optimieren, werden im Ernstfall handlungsfähig sein. Wer erst beim ersten Vorfall beginnt, Prozesse zu definieren, wird die Fristen mit hoher Wahrscheinlichkeit reißen.

     

    Sie möchten Ihr Unternehmen optimal auf die NIS-2-Meldepflichten vorbereiten? TrustSpace unterstützt Sie mit umfassender NIS2-Beratung und automatisiertem Incident-Reporting über TrustSpaceOS. Von der Gap-Analyse bis zum fertigen Meldeprozess – unsere InfoSec-Experten begleiten Sie auf dem Weg zur vollständigen NIS-2-Compliance.

    Jetzt kostenlose Erstberatung vereinbaren →

  • Aufbau ISMS nach ISO 27001: Der Praxis-Guide für den Mittelstand

    Aufbau ISMS nach ISO 27001: Der Praxis-Guide für den Mittelstand

    Das Wichtigste in Kürze

    • Definition: Ein ISMS (Informationssicherheits-Managementsystem) ist kein reines IT-Projekt, sondern ein organisatorischer Rahmen für Prozesse, Richtlinien und Risikomanagement.
    • Zweck: Es schützt die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und minimiert Haftungsrisiken für die Geschäftsführung (besonders unter NIS2).
    • Kernstück: Die individuelle Risikoanalyse bestimmt, welche Maßnahmen (Controls) tatsächlich notwendig sind – es gibt kein „One-Size-Fits-All“.
    • Ressourcen: Der Aufbau erfordert Zeit und Budget. Hybride Ansätze aus Software und Expertenberatung reduzieren den manuellen Aufwand oft um bis zu 70 %.
    • Zyklen: Der PDCA-Zyklus (Plan-Do-Check-Act) sorgt dafür, dass die Sicherheit nicht stagniert, sondern kontinuierlich verbessert wird.

     

    Die Entscheidung für den Aufbau eines ISMS nach ISO 27001 fällt heute selten rein freiwillig. Oft sind es der Druck von Enterprise-Kunden, die Anforderungen der Automobilindustrie (TISAX®) oder gesetzliche Verschärfungen wie die NIS2-Richtlinie, die Geschäftsführer und IT-Verantwortliche zum Handeln zwingen. Doch jenseits des reinen Compliance-Zwangs bietet ein strukturiertes Informationssicherheits-Managementsystem (ISMS) einen entscheidenden Wettbewerbsvorteil: Es macht Ihr Unternehmen resilient gegen Angriffe und signalisiert Vertrauenswürdigkeit.

    In diesem Ratgeber erfahren Sie, wie Sie den Prozess von der ersten Gap-Analyse bis zum Zertifikat strukturieren, welche Stolperfallen lauern und wie moderne Ansätze den Dokumentationsaufwand massiv senken.

     

    Was bedeutet der Aufbau eines ISMS konkret?

    Viele Unternehmen missverstehen die ISO 27001 als rein technisches Regelwerk. Tatsächlich fordert die Norm aber primär Management-Prozesse. Ein ISMS ist die Gesamtheit aller Regeln, Verfahren und Verantwortlichkeiten, die nötig sind, um Informationssicherheit zu definieren, zu steuern, zu kontrollieren und fortlaufend zu verbessern.

    Der Aufbau folgt dabei strikt dem PDCA-Zyklus (Plan-Do-Check-Act). Das Ziel ist nicht die absolute Sicherheit – die gibt es nicht –, sondern der angemessene Umgang mit Risiken. Was „angemessen“ ist, definieren Sie auf Basis Ihres Geschäftsmodells und Ihrer Risikoappetenz selbst.

     

    Phase 1: Vorbereitung und Scoping (Plan)

    Bevor die erste Richtlinie geschrieben wird, muss der Rahmen gesteckt werden. Ein häufiger Fehler ist der Versuch, sofort das gesamte Unternehmen inklusive aller Tochtergesellschaften und Standorte zu zertifizieren.

    Management Commitment und Ressourcen

    Ohne die volle Rückendeckung der Geschäftsführung wird das Projekt scheitern. Informationssicherheit kostet Geld und bindet Arbeitszeit. Die Geschäftsführung muss nicht nur das Budget freigeben, sondern auch die Leitlinie zur Informationssicherheit (Security Policy) unterzeichnen und vorleben. Gerade im Hinblick auf die Geschäftsführerhaftung bei aktuellen Regularien ist dies auch ein Selbstschutz.

    Definition des Geltungsbereichs (Scope)

    Der Scope legt fest, welche Prozesse, Abteilungen und Standorte das ISMS abdeckt. Für ein Software-Unternehmen gehören die Entwicklung und der Cloud-Betrieb zwingend dazu; die Kantine eher nicht. Ein präzise definierter Scope verhindert, dass sich das Projektteam in irrelevanten Details verliert.

    Hier lohnt sich oft eine externe Perspektive, um den Scope weder zu eng (Akzeptanzprobleme bei Kunden) noch zu weit (Kostenexplosion) zu fassen. Unsere ISO 27001 Beratung setzt genau hier an, um von Beginn an die Weichen auf Effizienz zu stellen.

     

    Phase 2: Asset-Management und Risikoanalyse

    Dies ist das Herzstück Ihres ISMS. Warum die Risikoanalyse im ISMS das Fundament jeder Sicherheitsstrategie ist, haben wir in einem eigenen Beitrag beschrieben. Wenn Sie hier gründlich arbeiten, wird der Rest des Weges deutlich einfacher.

    Inventarisierung der Werte (Assets)

    Sie können nicht schützen, was Sie nicht kennen. Erfassen Sie alle relevanten Werte. Dazu gehören:

    • Hardware: Server, Laptops, Mobilgeräte.
    • Software: ERP-Systeme, Entwicklungstools, SaaS-Anwendungen.
    • Informationen: Kundendaten, Quellcode, Finanzdaten.
    • Personal & Standorte: Schlüsselpersonen und physische Büros.

    Risikobewertung

    Für jedes Asset müssen potenzielle Bedrohungen identifiziert werden. Was passiert, wenn der Laptop eines Vertrieblers gestohlen wird? Was, wenn der Cloud-Provider ausfällt?

    Bewertet werden diese Szenarien meist nach Eintrittswahrscheinlichkeit und Schadenshöhe. Das Ergebnis ist eine Risikomatrix, die Ihnen zeigt, wo der Handlungsbedarf am größten ist. Wie Sie Bewertungsskalen festlegen, Szenarien konsistent einschätzen und die Ergebnisse auditfest dokumentieren, zeigt unser Leitfaden zur Risikobewertung nach ISO 27001 in der Praxis. Excel-Listen stoßen hier schnell an ihre Grenzen, da sie keine dynamischen Verknüpfungen erlauben und die Historie schwer nachvollziehbar machen.

     

    Phase 3: Maßnahmenumsetzung und Dokumentation (Do)

    Basierend auf den identifizierten Risiken wählen Sie Maßnahmen aus dem Anhang A der ISO 27001 aus. Dieser Katalog umfasst 93 Maßnahmen (Controls) in vier Themenbereichen (Organisatorisch, Personenbezogen, Physisch, Technologisch).

    Erklärung zur Anwendbarkeit (SoA)

    Das „Statement of Applicability“ (SoA) ist das wichtigste Dokument für den Auditor. Hier listen Sie auf, welche der 93 Maßnahmen Sie anwenden – und begründen auch, warum Sie bestimmte Maßnahmen ausschließen (z. B. „Sichere Entwicklungsrichtlinien“ in einem reinen Handelsunternehmen ohne eigene Entwicklung).

    Praktische Umsetzung

    Nun geht es an die Umsetzung. Dies beinhaltet:

    • Richtlinien erstellen: Passwort-Policy, Home-Office-Regelung, Zutrittskonzepte.
    • Technische Härtung: Einführung von MFA (Multi-Faktor-Authentifizierung), Verschlüsselung von Festplatten, Cybersecurity Lösungen wie Endpoint-Protection.
    • Schulungen: Mitarbeitende müssen die neuen Regeln kennen und verstehen. Awareness-Kampagnen sind Pflicht.

     

    TrustSpace Profi-Tipp: Weg von der „Papier-Compliance“

    Viele Unternehmen tappen in die Falle, Dokumente nur für den Auditor zu schreiben. Das Ergebnis sind hunderte Seiten Text, die kein Mitarbeiter liest. Ein modernes ISMS sollte lebendig sein.

    Nutzen Sie spezialisierte ISMS Software wie TrustSpaceOS. Diese zentralisiert nicht nur Richtlinien, sondern verknüpft sie direkt mit den Assets und Risiken. Unsere Erfahrung zeigt: Durch intelligente Vorlagen und digitale Workflows lässt sich der Dokumentationsaufwand um bis zu 70 % reduzieren. Statt statischer Word-Dokumente erhalten Sie ein audit-festes Dashboard, das auch für die Geschäftsführung verständlich ist.

     

    Phase 4: Überprüfung und Verbesserung (Check & Act)

    Ein ISMS ist nie „fertig“. Die Bedrohungslage ändert sich täglich, und Ihr Unternehmen entwickelt sich weiter.

    Interne Audits

    Bevor der externe Zertifizierer kommt, müssen Sie sich selbst prüfen (lassen). Ein internes Audit simuliert den Ernstfall. Hier wird geprüft, ob die niedergeschriebenen Prozesse auch der Realität entsprechen. Werden Offboarding-Prozesse eingehalten? Sind die Backup-Tests dokumentiert? Welche Auditarten es gibt, wie ein Auditprogramm über den Dreijahreszyklus aufgebaut wird und worauf Prüfer besonders achten, haben wir im Überblick zu ISMS-Audits zusammengefasst.

    Management Review

    Mindestens einmal jährlich muss die Geschäftsführung den Status des ISMS bewerten. Funktionieren die Maßnahmen? Sind die Ressourcen ausreichend? Gibt es neue regulatorische Anforderungen wie etwa durch die NIS2-Richtlinie? Aus diesem Review leiten sich Korrekturmaßnahmen ab, womit der PDCA-Zyklus von vorne beginnt.

     

    Häufige Fehler beim Aufbau eines ISMS

    Trotz guter Vorsätze scheitern Projekte oder verzögern sich massiv. Meiden Sie diese Fallstricke:

    1. Das „IT-Insel-Problem“:
    Wenn der CISO oder IT-Leiter das Projekt allein im Keller durchzieht, fehlt die Akzeptanz im Rest der Firma. Marketing, HR und Vertrieb müssen frühzeitig eingebunden werden, da Sicherheitsprozesse ihre tägliche Arbeit beeinflussen.

    2. Tool-Fokus statt Prozess-Fokus:
    Die teuerste Firewall nutzt nichts, wenn der Admin das Standardpasswort nicht ändert. Technik ist wichtig, aber organisatorische Maßnahmen (Richtlinien, Prozesse) sind oft entscheidender für die Normerfüllung.

    3. Perfektionismus:
    Sie müssen zum Zeitpunkt der Zertifizierung nicht gegen jeden theoretischen Quantencomputer-Angriff geschützt sein. Sie müssen aber nachweisen können, dass Sie das Risiko erkannt und einen Plan haben. Starten Sie pragmatisch und verbessern Sie sich kontinuierlich.

     

    Warum ein hybrider Ansatz sinnvoll ist

    Traditionelle Unternehmensberatungen arbeiten oft stundenbasiert und produzieren viel manuellen Aufwand. Reine Software-Tools (SaaS) lassen Sie mit der inhaltlichen Befüllung oft allein („Hier ist das Eingabefeld, viel Erfolg“). Welche Funktionen eine Plattform mitbringen muss, damit sie im Tagesgeschäft tatsächlich entlastet statt zusätzliche Pflegearbeit zu erzeugen, ordnet unser Beitrag zu Software für Informationssicherheits-Managementsysteme ein.

    Für den Mittelstand hat sich daher ein hybrider Weg bewährt, wie wir ihn bei TrustSpace leben: Eine intuitive Plattform (TrustSpaceOS) übernimmt die Struktur, Automatisierung und Nachweisführung, während echte Experten („InfoSec-as-a-Service“) bei komplexen Fragen zur Seite stehen. Dies kombiniert die Skalierbarkeit von Software mit der Sicherheit individueller Beratung. Erfahren Sie mehr über unser Team und unseren Ansatz.

     

    Fazit: Investition in die Zukunftsfähigkeit

    Der Aufbau eines ISMS nach ISO 27001 ist ein Kraftakt, der sich jedoch auszahlt. Sie minimieren nicht nur das Risiko teurer Sicherheitsvorfälle, sondern erfüllen auch die Eintrittskarte für lukrative Märkte und Enterprise-Kunden. Mit der richtigen Strategie und modernen Tools verwandeln Sie die trockene Compliance-Pflicht in einen echten Wettbewerbsvorteil.

     

    Häufige Fragen (FAQ)

    Wie lange dauert der Aufbau eines ISMS?

    Die Dauer hängt stark von der Größe des Unternehmens und dem Reifegrad ab. Mit traditionellen Methoden rechnen Unternehmen oft mit 12 bis 18 Monaten. Durch den Einsatz von Automatisierung und vorgefertigten Content-Frameworks (wie bei TrustSpace) lässt sich dieser Zeitraum oft auf 3,5 bis 6 Monate verkürzen.

    Was kostet eine ISO 27001 Zertifizierung?

    Die Kosten setzen sich aus drei Blöcken zusammen: interne Ressourcen, externe Unterstützung (Software/Beratung) und die Zertifizierungsgesellschaft (Auditor). Für kleine Mittelständler beginnen externe Audit-Kosten oft bei ca. 10.000 €, während die Implementierungskosten stark variieren. Festpreismodelle bieten hier Planungssicherheit.

    Ist ein ISMS für KMU Pflicht?

    Gesetzlich ist es für die meisten KMU (noch) keine Pflicht, es sei denn, sie fallen unter die KRITIS-Regulierung oder NIS2. Faktisch wird es jedoch durch die Lieferkette zur Pflicht: Große Auftraggeber verlangen den Nachweis immer häufiger als Bedingung für eine Zusammenarbeit.