trustspace

Tag: Mittelstand

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

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

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

    Das Wichtigste in Kürze

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

     

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

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

     

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

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

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

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

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

     

    Wer verhängt die Bußgelder?

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

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

     

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

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

    Marktrücknahme und Verkaufsverbot

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

    Die CE-Kennzeichnung als Voraussetzung für den Marktzugang

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

    Reputations- und Lieferkettenfolgen

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

    Zivilrechtliche Haftungsrisiken

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

     

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

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

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

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

     

    TrustSpace Profi-Tipp: Sanktionsrisiko als Budgetargument nutzen

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

     

    Was bedeutet das für KMU?

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

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

     

    Fazit: Das Bußgeld ist nur die sichtbare Spitze

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

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

     

    Häufige Fragen (FAQ)

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

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

    Wer verhängt die Bußgelder in Deutschland?

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

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

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

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

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

    Was ist schlimmer als das Bußgeld selbst?

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

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

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

    Das Wichtigste in Kürze

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

     

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

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

     

    Was ist der Cyber Resilience Act?

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

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

     

    Für wen gilt der Cyber Resilience Act?

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

    Was ist ein „Produkt mit digitalen Elementen”?

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

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

    Welche Rollen die Verordnung kennt

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

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

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

     

    Betroffenheit in 5 Schritten prüfen

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

    Schritt 1: Hat Ihr Produkt digitale Elemente?

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

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

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

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

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

    Schritt 4: Greift eine Sektor-Ausnahme?

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

    Schritt 5: Welche Rolle nehmen Sie ein?

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

     

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

     

    Betroffene und nicht betroffene Produkte im Vergleich

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

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

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

     

    Die wichtigsten Ausnahmen im Detail

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

    Bereits regulierte Sektoren

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

    Software as a Service und Open-Source

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

     

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

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

     

    Besonderheiten für KMU und kleine Hersteller

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

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

     

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

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

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

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

     

    Fazit: Erst einordnen, dann umsetzen

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

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

     

    Häufige Fragen (FAQ)

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

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

    Fällt reine Software auch unter den CRA?

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

    Ist mein SaaS-Produkt vom Cyber Resilience Act betroffen?

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

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

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

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

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

  • SOC 2 Compliance für Unternehmen erklärt

    SOC 2 Compliance für Unternehmen erklärt

    Das Wichtigste in Kürze

    • SOC 2 ist ein vom AICPA entwickeltes Rahmenwerk, das die Sicherheit, Verfügbarkeit und Vertraulichkeit von Kundendaten bei Dienstleistern überprüft.
    • Die SOC 2 Compliance basiert auf fünf Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality und Privacy.
    • Beim SOC 2 Type 1 wird das Kontrolldesign zu einem Stichtag geprüft, beim SOC 2 Type 2 zusätzlich die Wirksamkeit über einen Zeitraum von mindestens sechs Monaten.
    • Besonders relevant ist SOC 2 für SaaS-Anbieter, Cloud-Dienstleister und IT-Unternehmen, die Kundendaten verarbeiten – insbesondere bei US-amerikanischen Geschäftsbeziehungen.
    • Eine strukturierte Vorbereitung mit geeigneten Compliance-Tools reduziert Kosten und verkürzt den Audit-Prozess erheblich.

     

    Was ist SOC 2 und warum ist es wichtig?

    SOC 2 (System and Organization Controls 2) ist ein Prüfstandard des American Institute of Certified Public Accountants (AICPA). Er definiert Anforderungen an Dienstleistungsunternehmen hinsichtlich des Umgangs mit Kundendaten. Anders als etwa ISO 27001 handelt es sich bei SOC 2 nicht um eine Zertifizierung im klassischen Sinne, sondern um einen Prüfbericht (Audit Report), der von einem unabhängigen Wirtschaftsprüfer (CPA) erstellt wird.

    Die SOC 2 Compliance hat sich in den vergangenen Jahren zum De-facto-Standard für Dienstleister entwickelt, die Kundendaten verarbeiten – insbesondere im US-amerikanischen Markt. Immer häufiger verlangen auch europäische Unternehmen von ihren Anbietern einen SOC-2-Bericht als Nachweis angemessener Sicherheitskontrollen. Nicht zu verwechseln ist SOC 2 mit einem Security Operations Center (SOC) – dieses ist die organisatorische Einheit für die laufende Bedrohungsüberwachung, während SOC 2 den Prüfstandard für den Nachweis wirksamer Kontrollen bezeichnet.

    Konkret beantwortet ein SOC-2-Bericht die Frage: Verfügt das geprüfte Unternehmen über wirksame Kontrollen, um die Sicherheit, Verfügbarkeit und Vertraulichkeit von Kundendaten zu gewährleisten?

     

    Für wen ist SOC 2 relevant?

    Die SOC 2 Anforderungen richten sich primär an Unternehmen, die Dienstleistungen erbringen und dabei Zugriff auf Kundendaten haben. Typische Zielgruppen sind:

    • SaaS-Anbieter: Cloud-basierte Softwarelösungen, die Kundendaten speichern oder verarbeiten
    • Cloud-Dienstleister: Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS) Provider
    • Managed Service Provider (MSP): IT-Dienstleister, die Systeme und Netzwerke für Kunden betreiben
    • Rechenzentren und Hosting-Anbieter: Unternehmen, die physische oder virtuelle Infrastruktur bereitstellen
    • Finanzdienstleister und FinTechs: Anbieter von Zahlungs-, Buchhaltungs- oder Bankdienstleistungen
    • HR- und Payroll-Anbieter: Unternehmen, die sensible Mitarbeiterdaten verarbeiten

    In der Praxis wird SOC 2 Compliance zunehmend zur Voraussetzung für Geschäftsbeziehungen: Große Unternehmenskunden, insbesondere aus den USA, fordern einen aktuellen SOC-2-Bericht, bevor sie einen Vertrag abschließen. Wer keinen vorweisen kann, verliert potenzielle Deals – besonders im Enterprise-Segment.

     

    Die 5 Trust Service Criteria im Detail

    Die Trust Service Criteria (TSC) bilden das inhaltliche Fundament der SOC 2 Compliance. Sie definieren, welche Kontrollbereiche geprüft werden. Das Kriterium Security ist verpflichtend, die übrigen vier werden je nach Geschäftsmodell und Kundenanforderungen hinzugewählt.

     

    1. Security (Sicherheit) – verpflichtend

    Das Security-Kriterium – auch als Common Criteria bezeichnet – bildet die Basis jeder SOC-2-Prüfung. Es umfasst Kontrollen zum Schutz von Systemen und Daten vor unbefugtem Zugriff. Typische SOC 2 Kontrollen in diesem Bereich sind:

    • Zugriffskontrollen und Berechtigungsmanagement
    • Firewalls, Intrusion Detection und Netzwerksicherheit
    • Verschlüsselung von Daten (in Transit und at Rest)
    • Multi-Faktor-Authentifizierung (MFA)
    • Incident-Response-Prozesse
    • Sicherheitsbewusstsein und Mitarbeiterschulungen

     

    2. Availability (Verfügbarkeit)

    Dieses Kriterium prüft, ob Systeme und Dienste gemäß den vereinbarten Service Level Agreements (SLAs) verfügbar sind. Relevant für Anbieter, die hohe Uptime-Garantien geben. Kontrollen umfassen unter anderem Disaster-Recovery-Pläne, Monitoring, Kapazitätsmanagement und Redundanzkonzepte.

     

    3. Processing Integrity (Verarbeitungsintegrität)

    Hier wird überprüft, ob die Datenverarbeitung vollständig, korrekt, zeitnah und autorisiert erfolgt. Besonders wichtig für Unternehmen, die Finanztransaktionen, Berechnungen oder datengesteuerte Entscheidungen verarbeiten.

     

    4. Confidentiality (Vertraulichkeit)

    Das Vertraulichkeitskriterium adressiert den Schutz von Informationen, die als vertraulich klassifiziert sind – etwa Geschäftsgeheimnisse, geistiges Eigentum oder vertragliche Informationen. Kontrollen umfassen Datenklassifizierung, Zugriffsbeschränkungen und sichere Datenvernichtung.

     

    5. Privacy (Datenschutz)

    Das Privacy-Kriterium bezieht sich auf den Schutz personenbezogener Daten gemäß den Datenschutzrichtlinien des Unternehmens. Es orientiert sich an international anerkannten Datenschutzprinzipien wie Zweckbindung, Datenminimierung und Betroffenenrechte. Für europäische Unternehmen besteht hier eine enge Verbindung zur DSGVO.

     

    SOC 2 Type 1 vs. SOC 2 Type 2: Die Unterschiede

    Ein zentraler Aspekt der SOC 2 Compliance ist die Unterscheidung zwischen Type 1 und Type 2. Beide Prüfungen folgen denselben Trust Service Criteria, unterscheiden sich aber grundlegend in Umfang und Aussagekraft.

    Kriterium SOC 2 Type 1 SOC 2 Type 2
    Prüfungsgegenstand Design der Kontrollen Design und operative Wirksamkeit der Kontrollen
    Zeitraum Stichtagsbezogen (Point in Time) Prüfungszeitraum von mindestens 6 Monaten (häufig 12 Monate)
    Aussagekraft Kontrollen sind angemessen gestaltet Kontrollen funktionieren nachweislich über einen Zeitraum
    Dauer der Prüfung Wenige Wochen Mehrere Monate (je nach Prüfungszeitraum)
    Kosten Geringer (ca. 20.000–50.000 USD) Höher (ca. 30.000–100.000+ USD)
    Marktakzeptanz Einstieg, aber zunehmend nicht ausreichend Branchenstandard, von den meisten Kunden gefordert
    Empfehlung Als erster Schritt oder bei Zeitdruck Langfristiges Ziel für nachhaltigen Nachweis

    Praxisempfehlung: Viele Unternehmen starten mit einem SOC 2 Type 1-Bericht, um kurzfristig die Kontrollen nachzuweisen, und arbeiten parallel daran, die operative Wirksamkeit für den SOC 2 Type 2-Bericht zu dokumentieren. Langfristig erwarten die meisten Kunden und Partner einen aktuellen Type-2-Bericht.

     

    Der SOC-2-Audit-Prozess: Phasen und Ablauf

    Ein SOC2 Audit ist ein strukturierter Prozess, der sich in mehrere Phasen gliedert. Eine sorgfältige Vorbereitung ist entscheidend, um den Prüfungsprozess effizient zu durchlaufen und ein positives Ergebnis zu erzielen.

     

    Phase 1: Scoping und Readiness Assessment

    Im ersten Schritt wird der Prüfungsumfang festgelegt. Dabei werden folgende Fragen beantwortet:

    • Welche Systeme und Dienste sind im Scope des SOC-2-Berichts?
    • Welche Trust Service Criteria sind relevant?
    • Welche bestehenden Kontrollen gibt es bereits?
    • Wo bestehen Lücken (Gap-Analyse)?

    Ein Readiness Assessment durch einen erfahrenen Berater oder Prüfer hilft, Schwachstellen vor dem eigentlichen Audit zu identifizieren und zu beheben.

     

    Phase 2: Kontrollimplementierung und Dokumentation

    Auf Basis der Gap-Analyse werden fehlende Kontrollen implementiert und bestehende Kontrollen dokumentiert. Zentrale Elemente sind:

    • Erstellung und Formalisierung von Richtlinien und Verfahren (Policies & Procedures)
    • Implementierung technischer Kontrollen (z.B. Zugriffsmanagement, Monitoring, Verschlüsselung)
    • Einrichtung von Prozessen für Change Management, Incident Response und Risikobewertung
    • Aufbau einer lückenlosen Nachweisdokumentation (Evidence Collection)

     

    Phase 3: Beobachtungszeitraum (nur Type 2)

    Beim SOC 2 Type 2 müssen die implementierten Kontrollen über einen definierten Zeitraum – in der Regel sechs bis zwölf Monate – nachweislich wirksam betrieben werden. Während dieses Zeitraums sammelt das Unternehmen kontinuierlich Nachweise: Logdateien, Genehmigungsprotokolle, Screenshots, Ticketsysteme und weitere Dokumentation.

     

    Phase 4: Das eigentliche Audit

    Ein zugelassener CPA (Certified Public Accountant) oder eine CPA-Firma führt die Prüfung durch. Der Auditor:

    • Prüft das Design der Kontrollen (Type 1 und Type 2)
    • Testet die operative Wirksamkeit durch Stichproben und Nachweisanalyse (nur Type 2)
    • Führt Interviews mit verantwortlichen Mitarbeitern
    • Dokumentiert Feststellungen und mögliche Abweichungen (Exceptions)

     

    Phase 5: Berichterstellung und Nachbereitung

    Der Auditor erstellt den SOC-2-Bericht, der eine Beschreibung des Systems, die Stellungnahme des Prüfers (Opinion), die geprüften Kontrollen und deren Testergebnisse enthält. Ein unqualified opinion (uneingeschränktes Prüfurteil) bestätigt, dass die Kontrollen den Anforderungen entsprechen. Der Bericht wird anschließend an Kunden und Partner weitergegeben – in der Regel unter einer Vertraulichkeitsvereinbarung (NDA).

     

    SOC 2 Anforderungen: Kontrollen und Nachweise

    Die konkreten SOC 2 Anforderungen variieren je nach gewählten Trust Service Criteria und Geschäftsmodell. Es gibt jedoch Kernbereiche, die in nahezu jedem SOC-2-Audit geprüft werden. Eine strukturierte SOC 2 Compliance Checklist hilft bei der systematischen Vorbereitung:

     

    Organisatorische Kontrollen

    • Sicherheitsrichtlinien: Dokumentierte Information Security Policy, Acceptable Use Policy, Data Classification Policy
    • Risikomanagement: Formaler Risikobewertungsprozess mit regelmäßiger Aktualisierung
    • Governance: Definierte Rollen und Verantwortlichkeiten für Informationssicherheit
    • Vendor Management: Bewertung und Überwachung von Drittanbietern
    • Mitarbeiterschulungen: Regelmäßige Security-Awareness-Trainings mit Teilnahmeprotokollen

     

    Technische Kontrollen

    • Zugriffsmanagement: Rollenbasierte Zugriffskontrollen (RBAC), regelmäßige Access Reviews, Offboarding-Prozesse
    • Verschlüsselung: TLS/SSL für Daten in Transit, AES-256 für Daten at Rest
    • Monitoring und Logging: Zentralisiertes Logging, SIEM-Systeme, Alerting bei Anomalien
    • Schwachstellenmanagement: Regelmäßige Vulnerability Scans und Patch-Management
    • Netzwerksicherheit: Firewalls, Netzwerksegmentierung, VPN für Remote-Zugriff
    • Endpoint Security: Antivirus, EDR-Lösungen, Mobile Device Management

     

    Operative Kontrollen

    • Change Management: Dokumentierte Prozesse für Änderungen an Systemen und Code
    • Incident Response: Formaler Plan mit definierten Eskalationsstufen und Kommunikationswegen
    • Business Continuity: Disaster-Recovery-Pläne mit regelmäßigen Tests
    • Backup-Management: Automatisierte Backups mit getesteter Wiederherstellung

     

    Häufige Fehler und Kostentreiber bei der SOC-2-Umsetzung

    Die Vorbereitung auf ein SOC2 Audit birgt typische Stolperfallen. Wer diese kennt, spart Zeit, Geld und vermeidet unangenehme Überraschungen während der Prüfung.

     

    1. Zu breites Scoping

    Ein häufiger Fehler ist ein zu weit gefasster Prüfungsumfang. Nicht alle Systeme und Dienste müssen im SOC-2-Scope liegen. Eine klare Abgrenzung reduziert den Aufwand erheblich – ohne die Aussagekraft des Berichts zu schmälern.

     

    2. Fehlende oder inkonsistente Dokumentation

    SOC-2-Auditoren prüfen nicht nur, ob Kontrollen existieren, sondern ob sie dokumentiert, kommuniziert und nachweisbar sind. Unternehmen, die ihre Richtlinien und Prozesse erst kurz vor dem Audit formalisieren, stoßen häufig auf Inkonsistenzen.

     

    3. Manuelle Evidence Collection

    Die Nachweissammlung ist einer der größten Kostentreiber. Wer Screenshots manuell erstellt, Logdateien einzeln exportiert und Nachweise in Ordnerstrukturen ablegt, investiert unverhältnismäßig viel Zeit. Automatisierte Lösungen können diesen Aufwand um bis zu 80 Prozent reduzieren.

     

    4. Keine kontinuierliche Compliance

    SOC 2 ist kein einmaliges Projekt. Der Bericht gilt in der Regel für zwölf Monate und muss dann erneuert werden. Unternehmen, die Kontrollen nur für das Audit betreiben, statt sie in den Arbeitsalltag zu integrieren, haben beim nächsten Audit erneut den vollen Aufwand.

     

    5. Unterschätzung der Kosten

    Die Kosten einer SOC 2 Zertifizierung (im Sinne des Berichts) setzen sich aus mehreren Komponenten zusammen: Auditor-Honorare, interne Personalkosten, Toolkosten und gegebenenfalls Beratungsgebühren. Je nach Unternehmensgröße und Scope liegen die Gesamtkosten zwischen 50.000 und 200.000 USD – ein Readiness Assessment und geeignete Tools können jedoch erheblich zur Kostenkontrolle beitragen.

     

    SOC 2 Compliance für kleinere Teams: Praxistipps

    Auch Startups und kleinere Teams können die SOC 2 Anforderungen erfolgreich umsetzen – wenn sie strategisch vorgehen. Die folgenden Empfehlungen helfen, den Aufwand handhabbar zu halten:

    • Klein starten: Beginnen Sie mit SOC 2 Type 1 und dem Security-Kriterium. Erweitern Sie den Scope erst, wenn Kunden es explizit fordern.
    • Compliance-Plattform nutzen: Tools wie TrustSpace automatisieren die Nachweissammlung, Richtlinienverwaltung und Audit-Vorbereitung – ein enormer Vorteil für kleine Teams mit begrenzten Ressourcen.
    • Bestehende Frameworks nutzen: Wenn Sie bereits eine ISO 27001-Zertifizierung besitzen, decken viele Kontrollen auch SOC-2-Anforderungen ab. Vermeiden Sie Doppelarbeit durch ein integriertes Managementsystem.
    • Security-by-Design: Integrieren Sie Sicherheitskontrollen von Anfang an in Ihre Entwicklungs- und Betriebsprozesse, statt sie nachträglich aufzusetzen.
    • Verantwortlichkeiten klar zuordnen: Auch ohne dediziertes Compliance-Team sollte eine Person als SOC-2-Projektleitung benannt werden.
    • Frühzeitig mit dem Auditor sprechen: Ein Vorgespräch mit der Prüfungsgesellschaft klärt Erwartungen und verhindert Missverständnisse.

     

    SOC 2 und andere Frameworks: Synergien nutzen

    Die SOC 2 Compliance steht nicht isoliert. Unternehmen, die bereits andere Sicherheitsstandards umgesetzt haben, profitieren von erheblichen Überschneidungen:

    • ISO 27001: Hohe Überlappung bei Kontrollen zu Zugriffsmanagement, Risikobewertung, Incident Response und Dokumentation. Eine ISO-27001-Zertifizierung bildet eine starke Basis für SOC 2.
    • DSGVO: Das Privacy-Kriterium der Trust Service Criteria korreliert mit zentralen DSGVO-Anforderungen. Bestehende technisch-organisatorische Maßnahmen (TOM) sind direkt verwertbar.
    • TISAX: Unternehmen mit TISAX-Assessment verfügen bereits über fundierte Informationssicherheitskontrollen, die für SOC 2 adaptiert werden können.
    • SOC 1 vs. SOC 2: SOC 1 fokussiert auf Kontrollen, die für die Finanzberichterstattung der Kunden relevant sind. SOC 2 ist breiter gefasst und adressiert die allgemeine Informationssicherheit.

     

    Häufig gestellte Fragen (FAQ)

     

    Was ist SOC 2 und für wen ist es relevant?

    SOC 2 ist ein Prüfstandard des AICPA, der die Wirksamkeit von Sicherheitskontrollen bei Dienstleistungsunternehmen bewertet. Relevant ist SOC 2 vor allem für SaaS-Anbieter, Cloud-Dienstleister, IT-Outsourcing-Unternehmen und alle Organisationen, die Kundendaten verarbeiten oder hosten. Besonders im US-amerikanischen Markt ist ein aktueller SOC-2-Bericht häufig Voraussetzung für Geschäftsabschlüsse.

     

    Was ist der Unterschied zwischen SOC 2 Type 1 und Type 2?

    SOC 2 Type 1 prüft, ob angemessene Kontrollen zu einem bestimmten Stichtag implementiert sind (Designprüfung). SOC 2 Type 2 geht darüber hinaus und testet, ob diese Kontrollen über einen Zeitraum von mindestens sechs Monaten tatsächlich wirksam betrieben werden (Wirksamkeitsprüfung). Type 2 hat eine deutlich höhere Aussagekraft und wird von den meisten Kunden und Partnern bevorzugt.

     

    Wie läuft ein SOC-2-Audit ab?

    Ein SOC2 Audit durchläuft typischerweise fünf Phasen: Scoping und Readiness Assessment, Kontrollimplementierung und Dokumentation, Beobachtungszeitraum (bei Type 2), die eigentliche Prüfung durch einen CPA-Auditor sowie die Berichterstellung. Die Gesamtdauer beträgt je nach Type und Vorbereitungsstand zwischen drei Monaten (Type 1) und zwölf bis achtzehn Monaten (Type 2 inklusive Beobachtungszeitraum).

     

    Welche Anforderungen und Kontrollen sind entscheidend?

    Die SOC 2 Anforderungen orientieren sich an den fünf Trust Service Criteria. Entscheidend sind vor allem Kontrollen in den Bereichen Zugriffsmanagement, Verschlüsselung, Monitoring, Change Management, Incident Response und Vendor Management. Alle Kontrollen müssen nicht nur implementiert, sondern auch dokumentiert und durch Nachweise belegbar sein.

     

    Fazit: SOC 2 Compliance strategisch angehen

    Die SOC 2 Compliance ist mehr als eine regulatorische Pflichtübung – sie ist ein strategischer Wettbewerbsvorteil. Unternehmen, die einen aktuellen SOC-2-Bericht vorweisen können, signalisieren Kunden und Partnern, dass sie den Schutz von Daten ernst nehmen. Gerade für den US-Markt und Enterprise-Kunden ist SOC 2 heute oft eine Grundvoraussetzung.

    Der Schlüssel zum Erfolg liegt in einer strukturierten Vorbereitung: Definieren Sie einen klaren Scope, führen Sie eine Gap-Analyse durch, nutzen Sie Synergien mit bestehenden Frameworks und setzen Sie auf Automatisierung bei der Nachweissammlung. So reduzieren Sie Kosten, vermeiden typische Fehler und schaffen eine Compliance-Grundlage, die auch langfristig tragfähig ist. Eine zentrale ISMS-Software wie TrustSpaceOS automatisiert die Nachweissammlung und führt SOC-2-Kontrollen, Richtlinien und Audit-Evidence an einem Ort zusammen.

     

    SOC 2 Compliance effizient umsetzen – mit TrustSpace

    TrustSpace unterstützt Sie als integrierte ISMS-Plattform bei der systematischen Umsetzung Ihrer SOC 2 Compliance. Von der automatisierten Nachweissammlung über die Richtlinienverwaltung bis zur Audit-Vorbereitung – alles in einer Lösung. Nutzen Sie Synergien mit ISO 27001, DSGVO und weiteren Frameworks und behalten Sie den Überblick über alle Kontrollen und Nachweise.

    Jetzt Demo vereinbaren und SOC 2 Readiness beschleunigen.

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

  • TISAX Anforderungen verständlich erklärt

    TISAX Anforderungen verständlich erklärt

    Das Wichtigste in Kürze

    • TISAX (Trusted Information Security Assessment Exchange) ist der branchenspezifische Standard für Informationssicherheit in der Automobilindustrie, verwaltet von der ENX Association.
    • Grundlage aller TISAX Anforderungen ist der VDA ISA Katalog – ein Fragenkatalog, der auf ISO 27001 basiert und um branchenspezifische Module erweitert ist.
    • Die Anforderungen decken drei Prüfziele ab: Informationssicherheit, Prototypenschutz und Datenschutz.
    • Je nach Schutzbedarf des Auftraggebers müssen Unternehmen ein Assessment auf Level 2 oder Level 3 durchführen.
    • TrustSpace unterstützt Unternehmen bei der strukturierten Umsetzung der TISAX Anforderungen und der effizienten Vorbereitung auf das Assessment.

     

    Was ist TISAX und für wen ist es relevant?

    TISAX steht für „Trusted Information Security Assessment Exchange“ und ist ein Prüf- und Austauschverfahren für Informationssicherheit in der Automobilindustrie. Es wurde vom Verband der Automobilindustrie (VDA) initiiert und wird seit 2017 von der ENX Association betrieben.

    TISAX ist keine Zertifizierung im klassischen Sinne, sondern ein standardisiertes Assessment-Verfahren, dessen Ergebnis (Label) über die ENX-Plattform mit anderen Teilnehmern geteilt werden kann. Das vermeidet redundante Prüfungen durch verschiedene OEMs und Tier-1-Zulieferer. Welches TISAX®-Label ein Unternehmen am Ende erhält, hängt von den geprüften Prüfzielen und dem festgelegten Schutzbedarf ab.

    Wer braucht TISAX?

    TISAX ist relevant für alle Unternehmen, die in der automobilen Lieferkette tätig sind und von einem OEM oder Tier-1-Zulieferer aufgefordert werden, ihre Informationssicherheit nach TISAX nachzuweisen. Das betrifft:

    • Zulieferer aller Ebenen (Tier 1 bis Tier n)
    • Engineering-Dienstleister und Entwicklungspartner
    • IT-Dienstleister der Automobilindustrie
    • Logistik- und Servicepartner mit Zugang zu schützenswerten Informationen
    • Beratungsunternehmen, die mit vertraulichen Daten der OEMs arbeiten

    In der Praxis wird TISAX von den großen deutschen OEMs (Volkswagen, BMW, Mercedes-Benz, Porsche) und vielen internationalen Herstellern als Voraussetzung für die Geschäftsbeziehung verlangt.

     

    Der VDA ISA Katalog: Grundlage aller TISAX Anforderungen

    Die inhaltliche Basis für alle TISAX Anforderungen bildet der VDA ISA (Information Security Assessment) Katalog. Dieser Fragenkatalog definiert die Prüfkriterien, gegen die ein Unternehmen bewertet wird.

    Aufbau des VDA ISA

    Der VDA ISA gliedert sich in mehrere Module:

    • Informationssicherheit: Kernmodul, das auf ISO 27001 basiert und Themen wie Zugangssteuerung, Kryptografie, physische Sicherheit, Incident Management und Business Continuity abdeckt
    • Prototypenschutz: Zusatzmodul für Unternehmen, die mit physischen oder virtuellen Prototypen und vorserienrelevanten Informationen arbeiten
    • Datenschutz: Zusatzmodul, das die Einhaltung datenschutzrechtlicher Anforderungen (insbesondere DSGVO) im Rahmen der Auftragsverarbeitung prüft

    Bewertungssystematik: Reifegrade

    Jede Kontrollfrage im VDA ISA wird anhand eines Reifegradmodells bewertet:

    • Reifegrad 0: Unvollständig – kein Prozess vorhanden
    • Reifegrad 1: Durchgeführt – Prozess wird ad hoc durchgeführt, ist aber nicht dokumentiert
    • Reifegrad 2: Gesteuert – Prozess ist dokumentiert und wird regelmäßig durchgeführt
    • Reifegrad 3: Etabliert – Standardprozess ist definiert, wird konsequent angewandt und gemessen
    • Reifegrad 4: Vorhersagbar – Prozess wird quantitativ gesteuert
    • Reifegrad 5: Optimierend – kontinuierliche Verbesserung ist systematisch etabliert

    Für ein erfolgreiches TISAX Assessment müssen alle relevanten Kontrollfragen mindestens Reifegrad 3 erreichen. Einzelne Abweichungen auf Reifegrad 2 können unter bestimmten Bedingungen akzeptiert werden, erfordern aber einen konkreten Maßnahmenplan.

     

    Die zentralen Anforderungsbereiche im Detail

    Die folgenden Bereiche bilden den Kern der TISAX Anforderungen:

    1. Informationssicherheits-Richtlinien

    Das Unternehmen muss eine dokumentierte Informationssicherheitspolitik haben, die von der Geschäftsleitung verabschiedet und kommuniziert wurde. Daraus abgeleitet werden spezifische Richtlinien für einzelne Sicherheitsbereiche.

    2. Organisation der Informationssicherheit

    Klare Rollen und Verantwortlichkeiten für Informationssicherheit müssen definiert sein. Das umfasst einen Informationssicherheitsbeauftragten (ISB), Berichtslinien zur Geschäftsleitung und die Integration in die Organisationsstruktur.

    3. Personalsicherheit

    Anforderungen an Mitarbeitersensibilisierung, Schulungen, Vertraulichkeitsvereinbarungen und Prozesse bei Eintritt, Wechsel und Austritt von Mitarbeitern.

    4. Asset Management

    Alle Informationswerte (Assets) müssen inventarisiert, klassifiziert und einem Verantwortlichen zugeordnet sein. Dazu gehören IT-Systeme, Anwendungen, Daten und physische Medien.

    5. Zugangssteuerung

    Umfassende Anforderungen an Benutzerregistrierung, Zugangsrechte, privilegierte Zugänge und die regelmäßige Überprüfung von Berechtigungen (Access Reviews).

    6. Kryptografie

    Anforderungen an den Einsatz von Verschlüsselung für Daten in Transit und at Rest sowie an das Management von kryptografischen Schlüsseln.

    7. Physische Sicherheit

    Schutz von Gebäuden, Räumen und Einrichtungen, in denen Informationen verarbeitet oder gespeichert werden. Besonders relevant bei Prototypenschutz.

    8. Betriebssicherheit

    Anforderungen an Change Management, Kapazitätsplanung, Schutz vor Schadsoftware, Patch-Management, Logging und die Trennung von Entwicklungs-, Test- und Produktionsumgebungen.

    9. Kommunikationssicherheit

    Schutz von Netzwerken, Netzwerkdiensten und der Informationsübertragung (E-Mail, Datentransfer, Cloud-Dienste).

    10. Lieferantenbeziehungen

    Anforderungen an die Sicherheitsbewertung und -steuerung von Lieferanten und Dienstleistern, die Zugang zu Informationen des Unternehmens haben.

    11. Incident Management

    Dokumentierte Prozesse für die Erkennung, Meldung, Eskalation und Behandlung von Informationssicherheitsvorfällen.

    12. Business Continuity Management

    Anforderungen an Notfallpläne, Wiederherstellungsverfahren und deren regelmäßige Übung und Aktualisierung.

    13. Compliance

    Identifikation und Einhaltung aller relevanten gesetzlichen, vertraglichen und regulatorischen Anforderungen an die Informationssicherheit.

     

    Assessment Levels: Prüftiefe und Vorgaben

    TISAX unterscheidet drei Assessment Levels, die sich in der Prüftiefe und -methodik unterscheiden:

    Level 1: Selbstauskunft

    Reine Selbstbewertung ohne externe Prüfung. Level 1 wird in der Praxis kaum gefordert und erzeugt kein TISAX-Label.

    Level 2: Plausibilitätsprüfung

    Der Prüfdienstleister führt eine Plausibilitätsprüfung der Selbstauskunft durch. Dies geschieht in der Regel remote per Dokumentenprüfung und Interview. Geeignet für Unternehmen mit normalem Schutzbedarf. Was der Prüfer dabei im Detail verlangt und welche Nachweise vorliegen müssen, zeigt der Überblick zum Assessment Level 2.

    Level 3: Vollständige Vor-Ort-Prüfung

    Der Prüfdienstleister führt ein umfassendes Vor-Ort-Audit durch, bei dem Dokumente, Prozesse und technische Implementierungen detailliert geprüft werden. Erforderlich für Unternehmen mit hohem Schutzbedarf oder bei Prototypenschutz. Welche zusätzlichen Nachweise dafür zu erbringen sind, fasst der Beitrag zu den Anforderungen an Level 3 zusammen.

    Welches Level gefordert wird, wird vom Auftraggeber (OEM oder Tier 1) festgelegt und hängt vom Schutzbedarf der geteilten Informationen ab. Wie diese Einstufung im Detail funktioniert, erklärt unser Leitfaden zu den TISAX® Klassifizierungsstufen. Die meisten Assessment-Anforderungen in der Praxis liegen bei Level 2 oder Level 3.

     

    Typische Fehler bei der TISAX-Vorbereitung

    Aus der Praxis lassen sich wiederkehrende Stolpersteine identifizieren, die Unternehmen bei der Vorbereitung auf TISAX vermeiden sollten:

    1. Zu späte Vorbereitung

    Viele Unternehmen beginnen erst mit der Vorbereitung, wenn der OEM das Assessment fordert. Eine solide Vorbereitung benötigt typischerweise 3 bis 12 Monate – je nach Reifegrad und Assessment Level. Wie ein realistischer Vorlauf praktisch aussieht, beschreibt unser Leitfaden zur Vorbereitung auf die TISAX®-Zertifizierung.

    2. Fokus nur auf Dokumentation

    TISAX prüft nicht nur, ob Richtlinien und Prozesse dokumentiert sind, sondern ob sie tatsächlich gelebt werden. Rein formale Dokumentation ohne gelebte Praxis führt zu Feststellungen im Assessment.

    3. Unterschätzung der Scope-Definition

    Der Geltungsbereich (Scope) des Assessments muss sorgfältig definiert werden. Alle Standorte, Systeme und Prozesse, die mit den prüfungsrelevanten Informationen in Kontakt kommen, müssen einbezogen werden.

    4. Fehlende Management-Unterstützung

    TISAX ist kein reines IT-Projekt. Ohne aktive Unterstützung der Geschäftsleitung fehlen die notwendigen Ressourcen und die organisatorische Verbindlichkeit.

    5. Vernachlässigung der Lieferantenkette

    Die Anforderungen an Lieferantenmanagement werden häufig unterschätzt. Unternehmen müssen nachweisen, dass auch ihre eigenen Dienstleister angemessene Sicherheitsmaßnahmen umsetzen.

     

    Praxisnaher Fahrplan für die TISAX-Vorbereitung

    Ein strukturierter Ansatz für die Umsetzung der TISAX Anforderungen umfasst folgende Phasen:

    Phase 1: Initialisierung (2–4 Wochen)

    • Scope-Definition: Welche Standorte, Systeme und Informationen sind betroffen?
    • Festlegung des Assessment Levels und der Prüfziele
    • Sicherung der Management-Unterstützung und Ressourcen
    • Benennung eines Projektleiters und eines Informationssicherheitsbeauftragten

    Phase 2: Gap-Analyse (4–6 Wochen)

    • Systematische Bewertung des Ist-Zustands gegen den VDA ISA Katalog
    • Identifikation von Lücken (Gaps) und Priorisierung der Handlungsfelder
    • Erstellung eines realistischen Maßnahmenplans

    Phase 3: Umsetzung (8–24 Wochen)

    • Implementierung fehlender Prozesse, Richtlinien und technischer Maßnahmen
    • Schulung und Sensibilisierung der Mitarbeiter
    • Aufbau der erforderlichen Dokumentation
    • Regelmäßige Fortschrittskontrolle

    Phase 4: Internes Audit und Assessment-Vorbereitung (4–6 Wochen)

    • Durchführung eines internen Audits (Pre-Assessment)
    • Behebung identifizierter Schwachstellen
    • Registrierung bei der ENX Association
    • Auswahl eines zugelassenen Prüfdienstleisters

    Phase 5: Assessment (2–4 Wochen)

    • Durchführung des externen Assessments
    • Bearbeitung eventueller Feststellungen (Corrective Actions)
    • Erhalt des TISAX-Labels

    TrustSpace begleitet Unternehmen durch alle Phasen der TISAX-Vorbereitung – von der Gap-Analyse über die Maßnahmenumsetzung bis zur Assessment-Begleitung.

     

    Häufig gestellte Fragen zu TISAX Anforderungen

    Welche Anforderungen gelten für TISAX konkret?

    Die Anforderungen basieren auf dem VDA ISA Katalog und umfassen die Bereiche Informationssicherheit, optional Prototypenschutz und Datenschutz. Jede Kontrollfrage muss mindestens Reifegrad 3 erreichen.

    Was ist der VDA ISA Katalog?

    Der VDA ISA ist ein Fragenkatalog, der die Prüfkriterien für TISAX definiert. Er basiert auf ISO 27001, wurde aber um automobilspezifische Anforderungen erweitert – insbesondere zum Prototypenschutz.

    Welche Nachweise werden im Assessment erwartet?

    Je nach Assessment Level werden Dokumente (Richtlinien, Prozessbeschreibungen, Nachweise), Interviews mit Verantwortlichen und bei Level 3 eine Vor-Ort-Begehung mit technischer Überprüfung erwartet.

    Was ist der Unterschied zwischen Level 2 und Level 3?

    Level 2 ist eine Plausibilitätsprüfung (meist remote), Level 3 eine vollständige Vor-Ort-Prüfung mit höherer Prüftiefe. Welches Level erforderlich ist, bestimmt der Auftraggeber.

    Wie lange dauert die Vorbereitung auf TISAX?

    Je nach Ausgangslage und Assessment Level zwischen 3 und 12 Monaten. Bei einem realistischen TISAX Zeitplan ist eine frühzeitige Planung entscheidend.

     

    Fazit: TISAX Anforderungen systematisch erfüllen

    Die TISAX Anforderungen sind umfassend, aber bei strukturierter Herangehensweise gut beherrschbar. Der Schlüssel liegt in einer sauberen Scope-Definition, einer ehrlichen Gap-Analyse, konsequenter Umsetzung und ausreichend Zeit für die Vorbereitung. Wie Unternehmen TISAX® und NIS2 parallel meistern, besprechen unsere Experten auch im Podcast zu NIS2 und TISAX.

    Unternehmen, die bereits ein ISMS nach ISO 27001 betreiben, haben einen erheblichen Vorsprung – viele Anforderungen sind bereits abgedeckt. TrustSpace hilft dabei, die Lücken zu identifizieren und die automobilspezifischen Zusatzanforderungen effizient umzusetzen.

  • IT-Sicherheit im Mittelstand: Schwachstellen erkennen und Maßnahmen schnell umsetzen

    IT-Sicherheit im Mittelstand: Schwachstellen erkennen und Maßnahmen schnell umsetzen

    Das Wichtigste in Kürze

    • Mittelständische Unternehmen sind überdurchschnittlich häufig Ziel von Cyberangriffen – oft fehlen Ressourcen, Strukturen und Bewusstsein für systematische IT-Sicherheit.
    • Typische Schwachstellen sind veraltete Systeme, fehlende Netzwerksegmentierung, mangelnde Mitarbeitersensibilisierung und unzureichendes Patch-Management.
    • Regulierungen wie die DSGVO und die NIS-2-Richtlinie verpflichten Unternehmen zunehmend zu konkreten Sicherheitsmaßnahmen – auch KMU.
    • Ein strukturiertes IT-Sicherheitskonzept für KMU beginnt mit einer Risikoanalyse und wird idealerweise als fortlaufender Prozess in einem ISMS gebündelt.
    • TrustSpace unterstützt mittelständische Unternehmen dabei, ein ISMS aufzubauen und gesetzliche Anforderungen effizient zu erfüllen.

     

    Warum IT-Sicherheit im Mittelstand besonders kritisch ist

    Cyberangriffe treffen längst nicht mehr nur Großkonzerne. Im Gegenteil: Der Mittelstand rückt zunehmend in den Fokus professioneller Angreifer. Die Gründe dafür sind systemisch.

    Mittelständische Unternehmen verfügen häufig über wertvolle Datenbestände – von Kundendaten über Konstruktionszeichnungen bis hin zu Finanzinformationen –, betreiben aber selten ein vergleichbares Sicherheitsniveau wie größere Organisationen. Die IT-Abteilung besteht oft aus wenigen Personen, die neben dem Tagesgeschäft auch die Sicherheit verantworten. Dedizierte Security-Teams oder ein Chief Information Security Officer (CISO) sind die Ausnahme. Wo genau ein angemessenes Sicherheitsniveau liegt, lässt sich ohnehin erst bestimmen, wenn die Schutzziele der Informationssicherheit für das eigene Unternehmen konkret definiert sind.

    Hinzu kommt: Viele KMU unterschätzen das eigene Risiko. Sie gehen davon aus, für Angreifer uninteressant zu sein. Dabei zeigt die Statistik das Gegenteil. Laut Bitkom-Studien waren in den letzten Jahren mehr als 80 % aller deutschen Unternehmen von Cyberangriffen betroffen – mit einem Gesamtschaden im dreistelligen Milliardenbereich. Welche Grundlagen der IT-Cyber-Security vor Cyberangriffen schützen, haben wir separat zusammengefasst.

    Cybersecurity für KMU ist daher keine optionale Investition, sondern eine betriebswirtschaftliche Notwendigkeit. Wer IT-Sicherheit vernachlässigt, riskiert nicht nur finanzielle Schäden, sondern auch Reputationsverluste, Betriebsunterbrechungen und regulatorische Sanktionen. Wie sich der Aufbau eines belastbaren Schutzniveaus fachlich begleiten lässt, zeigen unsere Leistungen rund um die Cybersecurity mit TrustSpace.

     

    Typische Schwachstellen der IT-Sicherheit im Mittelstand

    Die Schwachstellen mittelständischer Unternehmen sind oft struktureller Natur. Sie resultieren weniger aus technischer Inkompetenz als aus fehlenden Prozessen, Ressourcen und Priorisierung.

    1. Fehlendes oder veraltetes Patch-Management

    Ungepatchte Software und Betriebssysteme gehören zu den häufigsten Einfallstoren für Cyberangriffe. Viele KMU setzen Legacy-Systeme ein, für die keine Sicherheitsupdates mehr verfügbar sind, oder versäumen es, verfügbare Patches zeitnah einzuspielen.

    2. Unzureichende Netzwerksegmentierung

    In vielen mittelständischen Unternehmen existiert ein flaches Netzwerk, in dem alle Systeme im selben Segment kommunizieren. Gelingt es einem Angreifer, einen Endpunkt zu kompromittieren, kann er sich nahezu ungehindert lateral im Netzwerk bewegen.

    3. Mangelnde Mitarbeitersensibilisierung

    Phishing und Social Engineering sind nach wie vor die erfolgreichsten Angriffsvektoren. Ohne regelmäßige Security-Awareness-Trainings werden Mitarbeiter unwissentlich zum größten Sicherheitsrisiko.

    4. Fehlende oder ungetestete Backups

    Backups existieren zwar in vielen Unternehmen, werden aber selten auf Wiederherstellbarkeit getestet. Im Ernstfall – etwa bei einem Ransomware-Angriff – zeigt sich dann, dass die Sicherungen unvollständig, veraltet oder kompromittiert sind.

    5. Keine klaren Verantwortlichkeiten

    Wenn IT-Sicherheit nicht organisatorisch verankert ist, fehlen definierte Zuständigkeiten, Eskalationswege und Reaktionspläne. Die Folge: Im Ernstfall wird wertvolle Zeit verloren. Welche Rollen dabei zu besetzen sind und wer im Unternehmen tatsächlich von Informationssicherheit betroffen ist, sollte schriftlich festgehalten sein.

    6. Unzureichendes Zugriffsmanagement

    Übertriebene Berechtigungen, geteilte Passwörter und fehlende Multi-Faktor-Authentifizierung (MFA) machen es Angreifern leicht, privilegierte Zugänge zu erlangen.

    7. Keine Übersicht über die eigene IT-Landschaft

    Viele KMU wissen nicht exakt, welche Systeme, Anwendungen und Schnittstellen in ihrer IT-Umgebung aktiv sind. Ohne ein aktuelles Asset-Inventar können Schwachstellen nicht systematisch identifiziert werden.

     

    IT-Sicherheitskonzept für KMU: Der Maßnahmen-Rahmen

    Ein wirksames IT-Sicherheitskonzept für KMU muss nicht die Komplexität eines Großkonzern-Ansatzes haben. Es muss aber systematisch, nachvollziehbar und an die individuellen Risiken angepasst sein.

    Schritt 1: Bestandsaufnahme und Risikoanalyse

    Am Anfang steht die Identifikation der schützenswerten Assets: Welche Daten, Systeme und Prozesse sind geschäftskritisch? Welche Bedrohungsszenarien sind realistisch? Wie hoch wäre der Schaden bei einem erfolgreichen Angriff?

    Eine strukturierte Risikobewertung bildet die Grundlage für alle weiteren Maßnahmen.

    Schritt 2: Technische Basismaßnahmen implementieren

    Die folgenden technischen Maßnahmen sollten in jedem mittelständischen Unternehmen umgesetzt sein:

    • Firewalls und Netzwerksegmentierung: Trennung von internen Netzwerken, Gastnetzwerken und kritischen Systemen
    • Endpoint Protection: Aktuelle Antivirus- und EDR-Lösungen auf allen Endgeräten
    • Patch-Management: Automatisierte und dokumentierte Update-Prozesse für alle Systeme
    • Verschlüsselung: Daten im Transit (TLS) und at Rest (Festplattenverschlüsselung)
    • Multi-Faktor-Authentifizierung: Für alle externen Zugänge und privilegierte Konten
    • Backup-Strategie: 3-2-1-Regel mit regelmäßigen Restore-Tests
    • E-Mail-Security: Spamfilter, DMARC, DKIM und SPF-Konfiguration
    • Protokollierung: Zentrale Log-Sammlung und -auswertung (SIEM oder vergleichbar)

    Schritt 3: Organisatorische Maßnahmen verankern

    Technik allein reicht nicht. Entscheidend sind die begleitenden organisatorischen Maßnahmen:

    • Sicherheitsrichtlinien: Dokumentierte Policies für Passwörter, Mobile Devices, Remote Work und Datenklassifizierung
    • Rollenbasiertes Berechtigungskonzept: Least-Privilege-Prinzip mit regelmäßigen Reviews
    • Security Awareness: Regelmäßige Schulungen und simulierte Phishing-Kampagnen
    • Incident-Response-Plan: Dokumentierter Ablauf für die Reaktion auf Sicherheitsvorfälle
    • Dienstleistersteuerung: Sicherheitsanforderungen und vertragliche Regelungen für IT-Dienstleister und Cloud-Anbieter
    • Business Continuity Planning: Notfallpläne für den Ausfall geschäftskritischer Systeme

    Schritt 4: Kontinuierliche Überprüfung und Verbesserung

    IT-Sicherheit ist kein Projekt, sondern ein fortlaufender Prozess. Die Bedrohungslandschaft verändert sich ständig, ebenso wie die eigene IT-Umgebung. Deshalb müssen Maßnahmen regelmäßig überprüft und angepasst werden – idealerweise im Rahmen eines Informationssicherheits-Managementsystems (ISMS).

     

    Maßnahmen-Checkliste: IT-Sicherheit für den Mittelstand

    Die folgende Checkliste fasst die wichtigsten Maßnahmen zusammen, die jedes mittelständische Unternehmen adressieren sollte:

    Infrastruktur und Netzwerk:

    • Aktuelle Firewall mit regelmäßig überprüftem Regelwerk
    • Netzwerksegmentierung nach Schutzbedarf
    • VPN für alle Remote-Zugriffe
    • WLAN-Sicherheit mit WPA3 und separatem Gastnetz
    • Vollständiges und aktuelles IT-Asset-Inventar

    Endgeräte und Software:

    • Automatisiertes Patch-Management für Betriebssysteme und Anwendungen
    • Endpoint Detection and Response (EDR) auf allen Geräten
    • Festplattenverschlüsselung auf Laptops und mobilen Geräten
    • Mobile Device Management (MDM) für dienstliche Mobilgeräte

    Identitäts- und Zugriffsmanagement:

    • Multi-Faktor-Authentifizierung für alle kritischen Systeme
    • Zentrales Identity Management (idealerweise SSO)
    • Dokumentiertes Berechtigungskonzept mit regelmäßigen Reviews
    • Automatische Deprovisionierung bei Mitarbeiteraustritt

    Datensicherung und Wiederherstellung:

    • Backup-Strategie nach 3-2-1-Prinzip
    • Regelmäßige Restore-Tests (mindestens quartalsweise)
    • Offline- oder immutable Backups zum Schutz vor Ransomware
    • Dokumentierte Recovery-Zeiten (RTO/RPO)

    Organisation und Awareness:

    • Benannter Verantwortlicher für Informationssicherheit
    • Jährliche Security-Awareness-Schulungen für alle Mitarbeiter
    • Dokumentierter Incident-Response-Plan
    • Regelmäßige Sicherheitsaudits (intern oder extern)

     

    Regulatorische Anforderungen: DSGVO und NIS-2

    Die IT-Sicherheit im Mittelstand wird nicht nur durch wirtschaftliche Überlegungen, sondern zunehmend auch durch gesetzliche Anforderungen getrieben. Den systematischen Umgang mit diesen Vorgaben fasst der Begriff IT Compliance zusammen. Zwei Regulierungen sind dabei besonders relevant.

    DSGVO: Technische und organisatorische Maßnahmen

    Die Datenschutz-Grundverordnung (DSGVO) verpflichtet in Art. 32 jeden Verantwortlichen und Auftragsverarbeiter, „geeignete technische und organisatorische Maßnahmen” zum Schutz personenbezogener Daten zu treffen. Die TOMs nach DSGVO müssen dem jeweiligen Verarbeitungsrisiko angemessen sein.

    Für den Mittelstand bedeutet das konkret:

    • Personenbezogene Daten müssen durch angemessene Schutzmaßnahmen gesichert sein
    • Die Maßnahmen müssen dokumentiert und ihre Wirksamkeit nachweisbar sein
    • Bei Datenpannen besteht eine Meldepflicht innerhalb von 72 Stunden
    • Verstöße können mit Bußgeldern von bis zu 20 Millionen Euro oder 4 % des Jahresumsatzes geahndet werden

    NIS-2-Richtlinie: Erweiterte Pflichten für KMU

    Die NIS-2-Richtlinie der EU weitet die Anforderungen an Cybersicherheit erheblich aus. Im Vergleich zur Vorgängerrichtlinie NIS-1 sind nun deutlich mehr Unternehmen betroffen – auch viele mittelständische Betriebe.

    Kernpunkte der NIS-2-Anforderungen:

    • Risikomanagement: Unternehmen müssen ein systematisches Risikomanagement für Cybersicherheit implementieren
    • Incident Handling: Pflicht zur Erkennung, Meldung und Behandlung von Sicherheitsvorfällen
    • Lieferkettenmanagement: Sicherheitsanforderungen müssen auch auf Zulieferer und Dienstleister ausgedehnt werden
    • Geschäftskontinuität: Business-Continuity- und Krisenmanagement-Pläne werden Pflicht
    • Geschäftsführerhaftung: Die Unternehmensleitung haftet persönlich für die Umsetzung der Sicherheitsmaßnahmen

    Unternehmen ab 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz in den betroffenen Sektoren fallen unter NIS 2. Die Umsetzung in nationales Recht erfolgt über das NIS2UmsuCG, das am 6. Dezember 2025 in Kraft getreten ist. In einzelnen Sektoren kommen weitere Vorgaben hinzu: Wie eng der Rahmen etwa in der IT-Sicherheit im Gesundheitswesen gesteckt ist, zeigt das Zusammenspiel aus KRITIS-Pflichten, B3S und KBV-Richtlinie.

    Weitere regulatorische Rahmenwerke

    Je nach Branche und Geschäftstätigkeit können weitere Anforderungen relevant sein:

    • BSI IT-Grundschutz: Umfassender Maßnahmenkatalog für Informationssicherheit
    • ISO 27001: Internationaler Standard für Informationssicherheits-Managementsysteme
    • TISAX: Branchenstandard für die Automobilindustrie
    • KRITIS-Verordnung: Anforderungen für Betreiber kritischer Infrastrukturen

     

    Der Weg zum ISMS: IT-Sicherheit systematisch aufbauen

    Einzelne Maßnahmen allein ergeben noch kein kohärentes Sicherheitskonzept. Mittelständische Unternehmen, die ihre IT-Sicherheit nachhaltig verbessern wollen, sollten ein Informationssicherheits-Managementsystem (ISMS) aufbauen.

    Ein ISMS integriert alle Sicherheitsmaßnahmen in einen strukturierten Rahmen mit:

    • Definierten Verantwortlichkeiten und Rollen
    • Regelmäßiger Risikoanalyse und -bewertung
    • Dokumentierter Maßnahmenumsetzung und -überwachung
    • Kontinuierlicher Überprüfung und Verbesserung (PDCA-Zyklus)
    • Nachweis der Compliance gegenüber Kunden, Partnern und Behörden

    Softwaregestützt lässt sich ein solches System deutlich schneller aufbauen und dauerhaft betreiben als über verteilte Dokumentenvorlagen – genau diesen Weg deckt die TrustSpace ISMS-Software ab.

    Der internationale Standard ISO 27001 bietet dafür ein bewährtes Rahmenwerk, das auch für mittelständische Unternehmen skalierbar ist.

     

    Häufig gestellte Fragen zur IT-Sicherheit im Mittelstand

    Wie starte ich mit IT-Sicherheit in meinem Unternehmen?

    Der erste Schritt ist eine Bestandsaufnahme: Welche IT-Systeme und Daten gibt es? Wo liegen die größten Risiken? Darauf aufbauend werden priorisierte Maßnahmen definiert. Ein externer Security-Check oder eine Gap-Analyse kann als Ausgangspunkt dienen.

    Braucht ein mittelständisches Unternehmen ein ISMS?

    Ein ISMS ist nicht für jedes Unternehmen gesetzlich vorgeschrieben, aber in den meisten Fällen sinnvoll. Spätestens wenn Kundenanforderungen, regulatorische Vorgaben (NIS 2, DSGVO) oder Zertifizierungen wie ISO 27001 relevant werden, ist ein strukturiertes ISMS der effizienteste Weg.

    Was kostet IT-Sicherheit für KMU?

    Die Kosten hängen von Unternehmensgröße, Branche und Reifegrad ab. Als Richtwert empfehlen Branchenexperten, 10–15 % des IT-Budgets für Sicherheitsmaßnahmen zu kalkulieren. Die Kosten eines erfolgreichen Cyberangriffs übersteigen diese Investition regelmäßig um ein Vielfaches.

    Ist mein Unternehmen von NIS 2 betroffen?

    NIS 2 betrifft Unternehmen ab 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz in definierten Sektoren (u. a. Energie, Gesundheit, digitale Infrastruktur, verarbeitendes Gewerbe, IKT-Dienstleistungen). Auch kleinere Unternehmen können betroffen sein, wenn sie als kritischer Zulieferer fungieren.

     

    Fazit: IT-Sicherheit im Mittelstand ist kein Luxus

    Die Bedrohungslage für mittelständische Unternehmen ist real und wächst. Gleichzeitig steigen die regulatorischen Anforderungen durch DSGVO, NIS 2 und branchenspezifische Standards. Wer jetzt nicht handelt, riskiert nicht nur Cyberangriffe, sondern auch Bußgelder, Haftungsrisiken und den Verlust von Kundenvertrauen.

    Die gute Nachricht: Cybersecurity für KMU muss nicht unbedingt teuer oder komplex sein. Mit einem strukturierten Ansatz, den richtigen Prioritäten und den passenden Werkzeugen lässt sich ein wirksames Sicherheitsniveau aufbauen.

    TrustSpace bietet mittelständischen Unternehmen eine Plattform, die den Aufbau eines ISMS nach ISO 27001 effizient und skalierbar macht – inklusive Risikomanagement, Maßnahmentracking, Audit-Vorbereitung und automatisiertem Compliance-Nachweis. So wird IT-Sicherheit vom Kostenfaktor zum Wettbewerbsvorteil.

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

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

    Das Wichtigste in Kürze

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

     

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

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

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

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

     

    Zeitplan: Wann gelten welche Vorschriften?

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

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

     

    Die vier EU AI Act Risikostufen im Überblick

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

     

    Stufe 1: Verbotene KI-Praktiken (unannehmbares Risiko)

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

    Verbotene KI-Praktiken umfassen:

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

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

     

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

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

    Wann gilt ein KI-System als Hochrisiko?

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

    A) Sicherheitskomponenten regulierter Produkte (Anhang I):

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

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

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

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

     

    Pflichten für Anbieter von Hochrisiko-KI-Systemen

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

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

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

     

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

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

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

     

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

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

    Betroffene Systeme und ihre Pflichten:

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

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

     

    Stufe 4: KI-Systeme mit minimalem Risiko

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

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

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

     

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

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

    Pflichten für alle GPAI-Anbieter:

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

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

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

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

     

    Praktische Schritte zur Klassifizierung und Compliance

    Schritt 1: KI-Systeme inventarisieren

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

    Schritt 2: Risikostufe bestimmen

    Prüfen Sie für jedes System systematisch:

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

    Schritt 3: Rolle bestimmen

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

    Schritt 4: Compliance-Maßnahmen ableiten

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

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

     

    Zusammenspiel mit anderen Regulierungen

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

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

     

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

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

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

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

  • BSI Grundschutz Kompendium 2026: Der Übergang zu IT-Grundschutz++ und die praktische Umsetzung

    BSI Grundschutz Kompendium 2026: Der Übergang zu IT-Grundschutz++ und die praktische Umsetzung

    Das BSI Grundschutz Kompendium ist das zentrale Standardwerk für Informationssicherheit in Deutschland. Herausgegeben vom Bundesamt für Sicherheit in der Informationstechnik (BSI), bietet es Unternehmen, Behörden und Organisationen einen systematischen Rahmen, um ihre IT-Infrastruktur und Informationswerte wirksam zu schützen. Mit dem Stichtag 1. Januar 2026 hat das BSI mit der Einführung von IT-Grundschutz++ den bisher größten Meilenstein seit der Modernisierung 2017 gesetzt und das Kompendium grundlegend digitalisiert und verschlankt.

    Für Unternehmen im DACH-Raum bleibt das BSI IT-Grundschutz Kompendium auch 2026 der Maßstab schlechthin: Es dient als eigenständiges Sicherheitsframework und bildet die Basis für die Zertifizierung nach „ISO 27001 auf der Basis von IT-Grundschutz”. Dieser Artikel erklärt den Aufbau des Kompendiums, die massiven Änderungen durch IT-Grundschutz++ und zeigt, wie Unternehmen das Werk in der aktuellen Übergangsphase in der Praxis nutzen können. Wer die Umstellung fachlich begleiten lassen möchte, findet in unserer BSI IT-Grundschutz Beratung den passenden Einstieg.

    Das Wichtigste in Kürze:

    • Das BSI Grundschutz Kompendium wandelt sich ab 2026 mit IT-Grundschutz++ von einem statischen PDF-Dokument zu einem agilen, prozessorientierten und digitalen Regelwerk (JSON-Format).
    • Die Edition 2024/2025 bleibt in einer mehrjährigen Übergangsphase (bis voraussichtlich 2029) für bestehende Zertifizierungen gültig.
    • IT-Grundschutz++ bringt eine Verschlankung der Anforderungen um bis zu 80 % sowie ein neues, effizienteres Punktesystem für Schutzziele.
    • Unternehmen können das Kompendium weiterhin für die Basis-, Standard- und Kern-Absicherung nutzen, um schrittweise ein angemessenes Schutzniveau zu erreichen.
    • Das Framework lässt sich nahtlos auf die aktuelle ISO 27001:2022 Controls mappen – ideal zur Erfüllung von NIS-2-Vorgaben.

     

    Was ist das BSI Grundschutz Kompendium?

    Das BSI Grundschutz Kompendium ist eine umfassende Sammlung von Sicherheitsanforderungen und Empfehlungen. Es löste 2017 die früheren IT-Grundschutz-Kataloge ab und verfolgt einen modularen, maßnahmenorientierten Ansatz. Das Kompendium bildet zusammen mit den BSI-Standards 200-1 bis 200-4 das Gesamtframework des IT-Grundschutzes.

    Abgrenzung zu den BSI-Standards

    Während die BSI-Standards die methodische Grundlage liefern – also beschreiben, wie ein ISMS aufgebaut wird (BSI-Standard 200-1), wie die IT-Grundschutz-Methodik angewendet wird (BSI-Standard 200-2), wie eine Risikoanalyse durchgeführt wird (BSI-Standard 200-3) und wie Business Continuity Management funktioniert (BSI-Standard 200-4) – enthält das BSI Grundschutz Kompendium die konkreten Sicherheitsanforderungen in Form von Bausteinen.

    Diese Arbeitsteilung bedeutet: Die BSI-Standards sagen Ihnen wie Sie vorgehen, das Kompendium sagt Ihnen was Sie umsetzen müssen.

    Adressaten des Kompendiums

    Das BSI Grundschutz Kompendium richtet sich an ein breites Spektrum von Organisationen:

    • Bundesbehörden: Für sie ist die Anwendung des IT-Grundschutzes verpflichtend.
    • KRITIS-Betreiber & NIS-2-relevante Einrichtungen: Betreiber kritischer und wichtiger Infrastrukturen nutzen den IT-Grundschutz als robusten Nachweis für angemessene Sicherheitsmaßnahmen.
    • Unternehmen: Privatwirtschaftliche Unternehmen jeder Größe profitieren von den konkreten, nun verschlankten Handlungsempfehlungen.
    • Dienstleister: IT-Dienstleister und Berater nutzen das Kompendium als Referenzrahmen für ihre Sicherheitskonzepte.

     

    Aufbau und Struktur des BSI Grundschutz Kompendiums

    Trotz der Transformation zu IT-Grundschutz++ bleibt die systematische Architektur in Form von Bausteinen erhalten, die in thematischen Schichten organisiert sind. Das Herzstück bilden diese Bausteine, die nun jedoch deutlich kompakter und objektorientierter aufgebaut sind. Einen detaillierten Überblick über die einzelnen Bausteine, ihre Schichten und die Umsetzungsreihenfolge bietet unser Leitfaden zu den BSI Bausteinen im Überblick.

    Die 10 Schichten im Überblick

    Die grundlegende Schichten-Struktur adressiert weiterhin die wesentlichen Bereiche der Informationssicherheit:

    Schicht Kürzel Themenbereich Beispiel-Bausteine
    1 ISMS Sicherheitsmanagement ISMS.1 Sicherheitsmanagement
    2 ORP Organisation und Personal ORP.1 Organisation, ORP.4 Identitätsmanagement
    3 CON Konzepte und Vorgehensweisen CON.1 Kryptokonzept, CON.3 Datensicherungskonzept
    4 OPS Betrieb OPS.1.1.3 Patch-Management, OPS.1.2.5 Fernwartung
    5 DER Detektion und Reaktion DER.1 Detektion, DER.2.1 Incident Management
    6 APP Anwendungen APP.1.1 Office-Produkte, APP.5.3 E-Mail/Groupware
    7 SYS IT-Systeme SYS.1.1 Allgemeiner Server, SYS.2.1 Allgemeiner Client
    8 IND Industrielle IT IND.1 Prozessleit- und Automatisierungstechnik
    9 NET Netze und Kommunikation NET.1.1 Netzarchitektur, NET.3.2 Firewall
    10 INF Infrastruktur INF.1 Allgemeines Gebäude, INF.2 Rechenzentrum

    Aufbau eines einzelnen Bausteins (Neues Format)

    Mit der Umstellung auf IT-Grundschutz++ im Jahr 2026 hat sich der Aufbau innerhalb der Bausteine deutlich verschlankt:

    • Objektorientierte Beschreibung: Klare Definition des Gegenstands ohne redundante Begleittexte.
    • Zielsetzung & Neues Punktesystem: Welches Schutzziel wird verfolgt? Das neue Punktesystem für Vertraulichkeit, Integrität und Verfügbarkeit löst hierbei veraltete, starre Kategorien ab.
    • Gefährdungslage: Stark gestraffte Typisierung von Bedrohungen.
    • Anforderungen: Die konkreten Sicherheitsanforderungen (Basis, Standard, Erhöhter Schutzbedarf) wurden massiv reduziert (teilweise um bis zu 80 %), um die Umsetzbarkeit in der Praxis zu beschleunigen.
    • Digitale Kreuzreferenzen (JSON): Native, maschinenlesbare Mappings zu den Controls der ISO 27001:2022 und NIS-2-Vorgaben für den Import in ISMS-Tools.

     

    Wichtige Neuerungen 2026: Die Ära von IT-Grundschutz++

    Das BSI hat den Ruf nach mehr Agilität und weniger Bürokratie erhört. Das Jahr 2026 markiert das Ende der rein statischen, jährlichen PDF-Wälzer und den Beginn einer neuen, digitalen Methodik.

    1. “Digital First” und Prozessorientierung

    Das Kompendium wird nun primär als maschinenlesbares Format (JSON) bereitgestellt. Dies ermöglicht eine nahtlose Integration in ISMS- und GRC-Software. Updates können dynamischer ausgerollt werden, und die manuelle Pflege von Excel-Listen entfällt für moderne Unternehmen nahezu vollständig.

    2. Drastische Reduzierung der Anforderungen

    Die wohl wichtigste Neuerung für die Praxis: Das BSI hat die Menge der Einzelanforderungen radikal gekürzt. Durch die Zusammenlegung von Redundanzen und den Fokus auf essenzielle Sicherheitsmaßnahmen sinkt der Implementierungs- und Prüfaufwand erheblich, ohne das Sicherheitsniveau zu kompromittieren.

    3. Die Übergangsphase (2026 – 2029)

    Keine Panik bei laufenden Zertifizierungen: Organisationen, die ihr ISMS auf Basis der Edition 2024 oder 2025 aufgebaut haben, können diese Struktur während der Übergangsphase (bis voraussichtlich 2029) beibehalten und rezertifizieren. Ein methodischer Migrationsplan auf die neue Grundschutz++-Struktur sollte jedoch zeitnah erarbeitet werden.

    4. Stärkere Berücksichtigung aktueller Trends

    • Cloud-Sicherheit & Containerisierung: Vollständig in die neuen digitalen Bausteine integriert.
    • Zero-Trust-Architekturen: Als Standardparadigma in den Netzwerk- und Identitätsbausteinen verankert.
    • KI & Automatisierung: Neue Guidelines zum sicheren Betrieb und Einsatz von KI-gestützten Tools im Unternehmenskontext.

     

    Die drei Vorgehensweisen: Basis-, Standard- und Kern-Absicherung

    Trotz der methodischen Neuerungen bleiben die bewährten Vorgehensweisen des BSI-Standard 200-2 erhalten.

    Basis-Absicherung

    Die Basis-Absicherung ist der schnellste Einstieg. Unternehmen setzen zunächst nur die als „Basis” gekennzeichneten Anforderungen aller relevanten Bausteine um. Ideal für den schnellen Aufbau eines Mindestschutzniveaus.

    Standard-Absicherung

    Die Standard-Absicherung umfasst alle Basis- und Standard-Anforderungen und entspricht dem vom BSI empfohlenen Sicherheitsniveau. Sie ist die Voraussetzung für eine Zertifizierung nach ISO 27001 auf der Basis von IT-Grundschutz.

    Kern-Absicherung

    Hier steht der Schutz der „Kronjuwelen” im Vordergrund. Anstatt alle Assets gleichmäßig abzusichern, werden die kritischsten Geschäftsprozesse identifiziert und sofort mit dem höchsten Schutzniveau versehen.

     

    Praktische Umsetzung: So nutzen Unternehmen das Kompendium 2026

    Die praktische Anwendung folgt einem bewährten, aber durch digitale Tools nun stark beschleunigten Prozess:

    Phase 1: Strukturanalyse

    Systematische Erfassung der IT-Landschaft. Durch automatisierte Asset-Discovery-Tools lässt sich diese Phase heute deutlich effizienter gestalten als noch vor wenigen Jahren.

    Phase 2: Schutzbedarfsfeststellung

    Ermittlung des Schutzbedarfs. Hier greift künftig das neue, feinere Punktesystem von IT-Grundschutz++, das eine präzisere und realistischere Bewertung von Vertraulichkeit, Integrität und Verfügbarkeit zulässt.

    Phase 3 & 4: Modellierung und IT-Grundschutz-Check

    Zuordnung der (nun digitalen) Bausteine zu den Assets und Durchführung des Soll-Ist-Vergleichs. Die Gap-Analyse zeigt exakt, welche Anforderungen der verschlankten Bausteine noch fehlen.

    Phase 5 & 6: Risikoanalyse und Umsetzung

    Bei erhöhtem Schutzbedarf greift die Risikoanalyse (BSI-Standard 200-3). Anschließend werden Maßnahmen priorisiert, umgesetzt und auditsicher dokumentiert.

     

    TrustSpace Profi-Tipp für die Migration: Die Umstellung auf IT-Grundschutz++ und die Verarbeitung der neuen JSON-basierten Bausteine erfordern leistungsfähige Werkzeuge. TrustSpaceOS ist bereits auf die neue BSI-Methodik vorbereitet. Die Plattform verarbeitet die neuen, agilen Datenformate nativ, unterstützt das aktuelle Punktesystem und bietet automatisierte Migrationspfade von der Edition 2024/2025 auf Grundschutz++. So reduzieren Sie den manuellen Aufwand bei der Umstellung erheblich und bleiben lückenlos zertifizierungsfähig.

     

     

    BSI Grundschutz und ISO 27001: NIS-2 konform werden

    Besonders durch die seit Ende 2024 europaweit verbindliche NIS-2-Richtlinie hat die Kombination aus ISO 27001 und IT-Grundschutz enorm an Bedeutung gewonnen.

    ISO 27001 auf der Basis von IT-Grundschutz

    Diese Zertifizierung vereint das international anerkannte Rahmenwerk der ISO 27001:2022 mit den extrem konkreten (und nun verschlankten) Handlungsanweisungen des BSI. Wie sich die Controls beider Standards konkret zuordnen lassen, zeigt unser Leitfaden zum BSI Grundschutz ISO 27001 Mapping.

    Vorteile der integrierten Umsetzung

    • Vermeidung von Doppelarbeit: Dank der maschinenlesbaren Kreuzreferenzen im IT-Grundschutz++ wird das Mapping auf die 93 Controls der ISO 27001:2022 automatisiert.
    • Regulatorische Sicherheit: Das Kompendium liefert den perfekten “State of the Art” (Stand der Technik) Nachweis, der von Gesetzgebern im Rahmen von NIS-2 oder DORA gefordert wird.
    • Konkrete Umsetzungshilfe: Wo die ISO 27001 abstrakt bleibt (“Sie müssen ein Backup-Konzept haben”), sagt das BSI genau, wie dieses technisch sicher auszugestalten ist.

     

    Häufige Fehler bei der aktuellen Anwendung

    Trotz der Vereinfachungen durch das BSI gibt es Stolpersteine:

    1. Die Migration verschlafen

    Zwar gelten alte Editionen in der Übergangsphase bis 2029 weiter, doch wer neue Projekte noch klassisch auf Papier oder in Excel mit der Edition 2024 startet, baut technische Schulden auf. Nutzen Sie für Neuaufbauten direkt digitale Tools und die neue Methodik.

    2. Unvollständige Strukturanalyse (Stichwort: Cloud & SaaS)

    Moderne IT findet in der Cloud statt. Wer Schatten-IT und SaaS-Lösungen nicht in die Strukturanalyse einbezieht, riskiert massive Compliance-Lücken.

    3. Isolierte Betrachtung von Bausteinen

    Auch die neuen, verschlankten Bausteine haben Abhängigkeiten. Identitätsmanagement (ORP.4) und Netzwerkarchitektur (NET.1.1) müssen beispielsweise ineinandergreifen, um Zero-Trust-Konzepte umzusetzen.

     

    Fazit: Das BSI Grundschutz Kompendium 2026 als Fundament

    Mit der Einführung von IT-Grundschutz++ am 1. Januar 2026 hat das BSI genau den Schritt gemacht, den die Wirtschaft gefordert hat: Weg vom bürokratischen Papiertiger, hin zu einem agilen, maschinenlesbaren und deutlich verschlankten Framework.

    Das BSI Grundschutz Kompendium bietet Unternehmen im DACH-Raum mehr denn je den Vorteil einer perfekten Symbiose aus internationaler ISO 27001-Kompatibilität und extrem konkreten, praktisch anwendbaren Sicherheitsmaßnahmen. Wer die aktuelle Übergangsphase nutzt, um sein ISMS mit modernen Tools zu digitalisieren, schafft ein zukunftssicheres Fundament gegen Cyber-Bedrohungen und für aktuelle Compliance-Anforderungen wie NIS-2.

     

    Sie möchten Ihr ISMS auf das neue IT-Grundschutz++ migrieren oder neu aufbauen? TrustSpace unterstützt Sie bei jedem Schritt: Mit TrustSpaceOS steuern Sie Ihre IT-Grundschutz-Umsetzung zentral, nutzen automatisierte Mappings zur ISO 27001:2022 und verarbeiten die neuen BSI-Datenformate mühelos. Unsere erfahrenen InfoSec-Berater begleiten Sie durch die Umstellungsphase bis zur erfolgreichen ISO 27001 Zertifizierung.

    Jetzt kostenlose Erstberatung vereinbaren