FAQ - NIS2, CRA, ISO 27001 & BSI TR-03183

Der Cyber Resilience Act (CRA) ist eine EU-Verordnung mit der Bezeichnung (EU) 2024/2847. Sie legt Sicherheitsanforderungen für Produkte mit digitalen Elementen fest. Das betrifft Hardware und Software, die in der EU verkauft werden. Ziel ist es, Sicherheit bereits in der Entwicklung zu verankern, nicht nachträglich.

Quelle: Verordnung (EU) 2024/2847

Der CRA gilt für Hersteller von Produkten mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Das umfasst Hardware-Produkte mit Software-Anteil ebenso wie reine Software-Produkte. Importeure und Händler haben ebenfalls Pflichten, wenn auch in geringerem Umfang als Hersteller.

Quelle: Verordnung (EU) 2024/2847, Art. 2

Der CRA tritt in drei Stufen in Kraft. Am 11. Dezember 2024 ist die Verordnung in Kraft getreten. Die Übergangsfristen laufen seitdem. Am 11. September 2026 greift die 24-Stunden-Meldepflicht für aktiv ausgenutzte Schwachstellen. Am 11. Dezember 2027 gilt der CRA vollständig: CE-Kennzeichnung wird Pflicht, nicht-konforme Produkte dürfen nicht mehr in der EU verkauft werden.

Quelle: Verordnung (EU) 2024/2847; BSI

Security by Design ist eine der drei Kernanforderungen des CRA. Sie bedeutet: Sicherheit muss ab der Planungs- und Entwicklungsphase berücksichtigt werden. Sicherheit darf kein nachträglicher Zusatz sein. Hersteller müssen dokumentieren, wie sie Sicherheit im Entwicklungsprozess verankern.

Quelle: Verordnung (EU) 2024/2847, Anhang I

Hersteller müssen Schwachstellen über den gesamten Produktlebenszyklus identifizieren, verfolgen und beheben. Nutzer müssen über bekannte Schwachstellen informiert werden. Der Mindest-Supportzeitraum beträgt 5 Jahre. Ohne SBOM und aktives Monitoring ist die Einhaltung dieser Pflichten in der Praxis kaum möglich.

Quelle: Verordnung (EU) 2024/2847, Anhang I, Teil II

Ab dem 11. September 2026 gelten drei Fristen. Innerhalb von 24 Stunden muss eine Frühwarnung an ENISA und das zuständige nationale CSIRT erfolgen. Innerhalb von 72 Stunden ist eine vollständige Meldung erforderlich. Spätestens nach 14 Tagen ist ein Abschlussbericht einzureichen. Die Fristen beginnen ab dem Zeitpunkt der Kenntniserlangung.

Quelle: Verordnung (EU) 2024/2847, Art. 14

Ja. Der CRA verpflichtet Hersteller, eine Software Bill of Materials (SBOM) zu erstellen und bereitzuhalten. Eine SBOM listet alle Softwarekomponenten eines Produkts maschinenlesbar auf. Ohne SBOM lässt sich nicht feststellen, welche Produkte von einer bekannten Schwachstelle betroffen sind. Das macht eine gezielte Reaktion auf Vorfälle wie Log4Shell unmöglich.

Quelle: Verordnung (EU) 2024/2847, Anhang I, Teil II

Der Normungsauftrag M/606 sieht 41 harmonisierte Normen vor: vier horizontale Normen der EN-40000-1-x-Serie, die für jedes Produkt gelten, sowie 26 vertikale, produktspezifische Normen, überwiegend aus der ETSI-Reihe EN 304 6xx, ergänzt um CENELEC-Normen für Halbleiter und Chipkarten. Bislang ist keine dieser Normen im Amtsblatt der EU zitiert.

Quelle: Normungsauftrag M/606, C(2025)618

Die EN-40000-1-x-Serie ist der horizontale Normenrahmen zum Cyber Resilience Act: Begriffe (-1-1), Grundsätze der Cyberresilienz (-1-2), Schwachstellenbehandlung (-1-3) und generische Sicherheitsanforderungen (-1-4). Sie gilt für jedes Produkt mit digitalen Elementen und wird durch eine produktspezifische vertikale Norm ergänzt.

Quelle: CEN-CLC/JTC 13, Normungsauftrag M/606

Nein. Eine harmonisierte Norm löst die Konformitätsvermutung nach Art. 27 CRA erst aus, wenn ihre Fundstelle im Amtsblatt der EU zitiert ist. Das ist für keine CRA-Norm der Fall, unabhängig vom Bearbeitungsstand der jeweiligen Norm. Für Klasse-I-Produkte ist der Selbsterklärungsweg (Modul A) damit derzeit faktisch nicht nutzbar.

Quelle: Verordnung (EU) 2024/2847, Art. 27

Das hängt von der Produktklasse ab. Standardprodukte und "wichtige Produkte" der Klasse I können sich grundsätzlich selbst erklären (Modul A), Klasse I allerdings nur bei vollständiger Anwendung der harmonisierten Norm. Für Klasse-II-Produkte und kritische Produkte ist eine benannte Stelle immer zwingend, Modul A ist dort ausgeschlossen.

Quelle: Verordnung (EU) 2024/2847, Art. 32

Das hängt von der Produktkategorie ab: Anhang III/IV bestimmen Einstufung und Konformitätsweg, Anhang I Teil I und II die technischen und prozessualen Anforderungen. Der CRA-Produktanforderungen-Check listet für 27 Produktkategorien die konkreten Anforderungen, den zulässigen Konformitätsweg und die anwendbaren Normen auf.

Quelle: Verordnung (EU) 2024/2847, Anhang I, III und IV

Anhang I Teil II Nr. 5 verlangt eine veröffentlichte Politik zur koordinierten Offenlegung von Schwachstellen (CVD). Die BSI TR-03183-3 konkretisiert das: eine security.txt nach RFC 9116 unter /.well-known/security.txt, signiert nach RFC 9580, mit getrennten PSIRT- und CSIRT-Kontakten, zugesicherten Reaktionszeiten von 5 bzw. 10 Arbeitstagen und einer Offenlegungsfrist von 90 (verlängerbar um weitere 90) Tagen.

Quelle: Verordnung (EU) 2024/2847, Anhang I Teil II Nr. 5; BSI TR-03183-3

Acht Pflichtangaben: Name und Typ des Produkts samt Kennung, Name und Anschrift des Herstellers, eine Erklärung, dass die Ausstellung in alleiniger Verantwortung des Herstellers erfolgt, den Gegenstand der Erklärung zur Rückverfolgbarkeit, die eigentliche Konformitätsaussage, verwendete Normen oder Spezifikationen, das durchgeführte Konformitätsbewertungsverfahren samt benannter Stelle (bei Modul B+C oder H) und die Unterzeichnung mit Ort und Datum.

Quelle: Verordnung (EU) 2024/2847, Art. 28, 30 und Anhang V

NIS2 ist die zweite Fassung der EU-Richtlinie zur Netz- und Informationssicherheit. Sie ersetzt die erste NIS-Richtlinie und erweitert den Anwendungsbereich erheblich. Mitgliedstaaten mussten sie ursprünglich bis Oktober 2024 in nationales Recht umsetzen. In Deutschland erfolgte die Umsetzung mit erheblicher Verspätung durch das NIS2UmsuCG, das am 6. Dezember 2025 in Kraft getreten ist und die Pflichten im BSI-Gesetz verankert.

Quelle: Richtlinie (EU) 2022/2555; NIS2UmsuCG

NIS2 gilt für Unternehmen in den 18 Sektoren aus Anlage 1 und 2 BSIG. Ab 250 Beschäftigten oder Umsatz über 50 Mio. und Bilanzsumme über 43 Mio. Euro gilt eine Einrichtung in einem Anlage-1-Sektor (u. a. Energie, Verkehr, Gesundheit, digitale Infrastruktur) als „besonders wichtig". Ab 50 Beschäftigten oder Umsatz und Bilanzsumme über jeweils 10 Mio. Euro gilt eine Einrichtung als „wichtig". Das betrifft auch alle Anlage-2-Sektoren (u. a. Post, Chemie, Lebensmittel, verarbeitendes Gewerbe, digitale Anbieter), die nie „besonders wichtig" werden können. Bei Konzernstrukturen zählen verbundene Unternehmen für diese Schwellen mit.

Quelle: § 28 BSIG; Richtlinie (EU) 2022/2555, Art. 2 und Anhang

Erhebliche Sicherheitsvorfälle müssen in drei Stufen gemeldet werden. Innerhalb von 24 Stunden ab Kenntniserlangung ist eine Frühwarnung an die zuständige Behörde oder das CSIRT erforderlich. Innerhalb von 72 Stunden folgt eine vollständige Meldung. Nach spätestens einem Monat ist ein Abschlussbericht einzureichen.

Quelle: Richtlinie (EU) 2022/2555, Art. 23

Die Frist beginnt ab dem Zeitpunkt der Kenntniserlangung. Das bedeutet: Wird ein Vorfall nicht erkannt, beginnt die Frist nicht. Das ist jedoch kein Freifahrtschein. Wer durch fehlendes Monitoring keine Kenntnis erlangt, verstößt damit selbst gegen NIS2, denn die Pflicht zur Erkennung ist Teil der Sicherheitsanforderungen.

Quelle: Richtlinie (EU) 2022/2555, Art. 23

Fehlende Kenntnis durch fehlendes Monitoring ist kein Schutz vor einer NIS2-Verletzung. NIS2 verlangt, dass betroffene Unternehmen die nötigen Maßnahmen treffen, um Sicherheitsvorfälle erkennen zu können, technisch wie organisatorisch. Wer kein Monitoring betreibt, erfüllt diese Anforderung nicht, unabhängig davon, ob ein Vorfall tatsächlich eintritt.

Quelle: Richtlinie (EU) 2022/2555, Art. 21

NIS2 richtet sich an Betreiber kritischer und wichtiger Dienste. Der CRA richtet sich an Hersteller von Produkten mit digitalen Elementen. Ein Unternehmen kann unter beide Regelwerke fallen, zum Beispiel ein Hersteller von Industriesteuerungen, der selbst Teil kritischer Infrastruktur ist. Die Meldepflichten überschneiden sich, unterscheiden sich aber in Empfänger und Detail.

Quelle: Richtlinie (EU) 2022/2555; Verordnung (EU) 2024/2847

Der Compliance-Kompass ordnet die eigenen Angaben zu Branche, Größe, Produkten mit digitalen Elementen und KI-Einsatz allen drei Regelwerken zu und verweist direkt auf die passende Vorlage: NIS2-Checkliste, CRA-Klartext oder AIMS-Handbuch. Vier Fragen genügen für eine erste Einschätzung, die keine rechtliche Prüfung ersetzt.

Quelle: CyberKlartext Compliance-Kompass

Die wichtigsten Notfallkontakte (IT-Hotline, Datenschutzbeauftragter, Geschäftsführung, ggf. die Zentrale Ansprechstelle Cybercrime), die interne Meldekette, drei bis fünf konkrete Sofortmaßnahmen sowie der Standort des ausführlichen Notfallhandbuchs, ergänzt um eine kurze Liste dessen, was im Ernstfall zu unterlassen ist. Der CyberKlartext Notfallkarten-Generator erstellt solche Karten fertig formuliert für vier Szenarien und drei Zielgruppen.

Quelle: CyberKlartext Notfallkarten-Generator

Erste Anlaufstelle ist das BSI Service-Center über die kostenlose Hotline 0800 274 1000 (Mo-Do 8-17 Uhr, Fr 8-16 Uhr) oder service-center@bsi.bund.de. Dieselbe Nummer nimmt auch Meldungen im Rahmen des Cyber-Sicherheitsnetzwerks entgegen. NIS2-pflichtige Einrichtungen müssen zusätzlich die gesetzlichen Fristen einhalten: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht nach spätestens einem Monat.

Quelle: BSI Service-Center

Über das BSI-Melde- und Informationsportal (MIP), das seit dem 6. Januar 2026 online ist. Die ursprüngliche Frist von drei Monaten nach Inkrafttreten des NIS2UmsuCG (6. März 2026) hat das BSI wegen geringer Registrierungsquote auf den 31. Juli 2026 verlängert. Diese verlängerte Frist ist inzwischen abgelaufen. Betroffene, aber noch nicht registrierte Unternehmen sollten die Registrierung umgehend nachholen.

Quelle: BSI Melde- und Informationsportal (MIP)

Das BSI kann als Aufsichtsbehörde Anordnungen treffen und Bußgelder verhängen, wenn eine betroffene Einrichtung sich nicht registriert. Eine verspätete Registrierung heilt den Verstoß nicht rückwirkend, verringert aber das Risiko einer Beanstandung deutlich gegenüber dauerhafter Nichtregistrierung, besonders wenn sie vor einer Prüfung oder einem Sicherheitsvorfall nachgeholt wird.

Quelle: § 28, § 65 BSIG

Ein Vorfall, der nach § 32 BSIG entweder schwerwiegende Betriebsstörungen oder finanzielle Verluste für die betroffene Einrichtung verursacht hat oder verursachen kann, oder der andere Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann. Nicht jede kleinere Störung erreicht diese Schwelle. Ein dokumentiertes Bewertungskriterium im Incident-Response-Plan hilft, das im Ernstfall schnell und nachvollziehbar zu entscheiden.

Quelle: § 32 BSIG

Weil NIS2-pflichtige Kunden verpflichtet sind, auch die Cybersicherheit ihrer Lieferkette zu berücksichtigen (Art. 21 Abs. 2 lit. d). Diese Pflicht geben viele Unternehmen über Lieferantenfragebögen und vertragliche Sicherheitsanforderungen an ihre Zulieferer weiter, unabhängig davon, ob der Zulieferer selbst NIS2-pflichtig ist. In der Praxis ist dieser indirekte Weg für viele mittelständische Betriebe der eigentliche Anlass für ein strukturiertes Sicherheitsmanagement.

Quelle: Art. 21 Abs. 2 lit. d Richtlinie (EU) 2022/2555

Ja, in der Regel. Das BSIG verweist für die Berechnung von Beschäftigtenzahl, Umsatz und Bilanzsumme auf die KMU-Definition der EU-Empfehlung 2003/361/EG. Bei verbundenen Unternehmen (etwa wenn eine Muttergesellschaft die Stimmrechtsmehrheit an einer Tochter hält) werden die Kennzahlen vollständig konsolidiert, bei Partnerunternehmen mit 25 bis 50 Prozent Beteiligung anteilig. Eine für sich kleine Konzerntochter kann dadurch NIS2-pflichtig werden, wenn die Unternehmensgruppe insgesamt die Schwellen überschreitet.

Quelle: EU-Empfehlung 2003/361/EG; § 28 BSIG

Die BSI TR-03183 ist eine Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik. Sie beschreibt, wie Hersteller die Anforderungen des CRA technisch umsetzen können. Die Richtlinie besteht aus vier Teilen: Teil 1 behandelt den risikobasierten Ansatz und das Bewertungsverfahren, Teil 2 beschreibt SBOM-Anforderungen, Teil 3 regelt Schwachstellen-Reports und Notifications, Teil H beschreibt Modul H über ein bestehendes ISO/IEC-27001-ISMS. Alle vier Teile sind kostenlos beim BSI verfügbar.

Quelle: BSI TR-03183

Formal ist die TR-03183 eine Technische Richtlinie, kein verbindliches Gesetz. Für CRA-pflichtige Hersteller ist sie in der Praxis jedoch verbindlich: Wer sich an TR-03183 hält, erfüllt die wesentlichen technischen Anforderungen des CRA. Die Richtlinie als "freiwillig" zu beschreiben ist daher irreführend.

Quelle: BSI TR-03183; Verordnung (EU) 2024/2847

TR-03183-2 legt Format und Pflichtfelder der Software Bill of Materials fest: mindestens elf Angaben je Komponente, u. a. Name, Version, Abhängigkeiten, Lizenz und eine SHA-512-Prüfsumme. Zulässig sind CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Eine konforme SBOM darf keine Schwachstelleninformationen enthalten. Dafür sind CSAF und VEX vorgesehen.

Quelle: BSI TR-03183-2

TR-03183-3 behandelt Schwachstellen-Reports und Notifications. Sie beschreibt den Prozess der Coordinated Vulnerability Disclosure, legt den Inhalt von Schwachstellen-Meldungen fest und regelt das Vorgehen nach Bekanntwerden einer Schwachstelle. Hersteller, die sich an TR-03183-3 halten, erfüllen die wesentlichen Anforderungen aus CRA Art. 14: die 24h-Frühwarnung, die 72h-Vollmeldung und den 14-Tage-Abschlussbericht.

Quelle: BSI TR-03183-3; Verordnung (EU) 2024/2847, Art. 14

TR-03183-H beschreibt Modul H nach Art. 32 CRA über ein bestehendes ISO/IEC-27001-ISMS. Statt jedes Produkt einzeln durch eine benannte Stelle prüfen zu lassen, kann ein zertifiziertes ISMS den Konformitätsweg abdecken, sofern es Design, Entwicklung, Produktion und Schwachstellenbehandlung des Produkts umfasst und sechs Annex-A-Controls (u. a. A.8.8, A.8.25, A.8.29) CRA-spezifisch erweitert werden.

Quelle: BSI TR-03183-H

Ja, perspektivisch. Die TR-03183 wird sukzessive durch die entsprechenden harmonisierten europäischen Normen (vor allem die EN-40000-1-x-Serie) abgelöst, sobald diese fertiggestellt und im EU-Amtsblatt zitiert sind. Bis dahin bleibt sie die konkreteste verfügbare Umsetzungshilfe, mit der Hersteller schon heute Praxiserfahrung sammeln können.

Quelle: BSI TR-03183; CEN-CENELEC CRA-Standardisierung

Pflicht ist mindestens ein Contact-Feld (https:// oder mailto:) und ein Expires-Datum, maximal ein Jahr in der Zukunft. TR-03183-3 verlangt zusätzlich eine feste Reihenfolge der Kontakte (PSIRT-Mailbox, CSIRT-Mailbox, Meldeseite), Preferred-Languages mit mindestens „en" sowie eine Signatur der Datei nach OpenPGP (RFC 9580).

Quelle: BSI TR-03183-3; RFC 9116

Eine erste Rückmeldung binnen 5 Arbeitstagen, eine detaillierte Bewertung binnen 10 Arbeitstagen - jeweils sofern die Meldung nicht anonym erfolgte. Für die öffentliche Offenlegung gilt eine Frist von 90 Tagen, einmalig um weitere 90 Tage verlängerbar in Abstimmung mit dem zuständigen nationalen CSIRT (in Deutschland CERT-Bund).

Quelle: BSI TR-03183-3, Kap. 4.4

Die BSI TR-03185 "Sicherer Software-Lebenszyklus" ist eine Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik, die Anforderungen an sichere Software-Entwicklungsprozesse beschreibt. Sie besteht aus zwei Teilen: Teil 1 für proprietäre Software, Teil 2 für Open-Source-Software.

Quelle: BSI TR-03185

Die TR-03185 deckt einen Teil der CRA-Prozesspflichten ab: Security by Design und Bedrohungsmodellierung (Anhang I Teil I Nr. 1), Schwachstellenmanagement und Meldeverfahren (Anhang I Teil II Nr. 2 bis 8) sowie Sorgfaltspflichten bei Drittkomponenten (Art. 13). Sie ist aber keine direkte CRA-Umsetzungsanleitung wie die TR-03183 und deckt nicht die formalen Pflichten wie CE-Kennzeichnung oder Konformitätsbewertung ab.

Quelle: BSI TR-03185-2; Verordnung (EU) 2024/2847

Die TR-03183 regelt, welche Artefakte ein fertiges Produkt mitbringen muss, etwa SBOM, CSAF-Mitteilungen und security.txt. Die TR-03185 regelt den Entwicklungsprozess dahinter, etwa Bedrohungsmodellierung, Code Management und Testverfahren. Beide Richtlinien ergänzen sich und verweisen aufeinander, ersetzen sich aber nicht.

Quelle: BSI TR-03185; BSI TR-03183

TR-03185-2 richtet sich an Open-Source-Projekte (FLOSS/FOSS) und benennt ausdrücklich keine für die Umsetzung verantwortliche Partei. Sie nennt drei mögliche Umsetzungswege in Präferenzreihenfolge: Hersteller oder Steward wirken direkt in der Upstream-Entwicklung mit, Maintainer setzen die Anforderungen selbst um, oder Hersteller pflegen einen abgesicherten Downstream-Fork.

Quelle: BSI TR-03185-2

Formal ist sie eine Technische Richtlinie und kein Gesetz. Für Hersteller, die Prozesspflichten aus dem Cyber Resilience Act nachweisen müssen, ist sie praktisch dennoch relevant, da sie eine konkrete Auslegung sicherer Entwicklungsprozesse liefert und zunehmend in Ausschreibungen und Lieferverträgen referenziert wird.

Quelle: BSI TR-03185; Verordnung (EU) 2024/2847

Die ENISA Single Reporting Platform wird ab September 2026 Schwachstellen-Meldungen verarbeiten. CSAF ist das vorgesehene Format für maschinenlesbare Meldungen. CSAF deckt die Pflichtfelder aus CRA Art. 14 ab: Hersteller, betroffene Produkte, Schwachstelle, CVSS-Score und Patch-Status. Hersteller, die ab 2026 meldepflichtig sind, sollten das Format frühzeitig kennen.

Quelle: Verordnung (EU) 2024/2847, Art. 14; OASIS CSAF 2.0

Eine CSAF-Datei ist ein JSON-Dokument mit definierten Pflichtfeldern. Dazu gehören Angaben zum Hersteller, zu betroffenen Produkten und Versionen, zur Schwachstelle selbst (inkl. CVE-Nummer und CVSS-Score) sowie zum Status eines verfügbaren Patches. CSAF ist maschinenlesbar und kann direkt in SIEM-Systeme und Schwachstellen-Management-Tools importiert werden.

Quelle: OASIS CSAF 2.0

Ein Risikoregister ist die dokumentierte Übersicht aller identifizierten Informationssicherheitsrisiken einer Organisation, mit Bewertung nach Eintrittswahrscheinlichkeit und Schadenshöhe, gewählter Behandlungsoption und Verantwortlichkeit. ISO/IEC 27001:2022 verlangt es in Kap. 6.1.2 und 6.1.3 als Nachweis, dass Risikobewertung und -behandlung tatsächlich stattgefunden haben. Es ist eines der beiden zwingend vorgeschriebenen ISMS-Dokumente.

Quelle: ISO/IEC 27001:2022, Kap. 6.1.2 und 6.1.3

Das Statement of Applicability (SoA) ist das Dokument, in dem eine Organisation für jeden der 93 Referenz-Controls aus ISO/IEC 27001:2022 Anhang A festhält, ob er angewendet wird, warum, und wie weit die Umsetzung fortgeschritten ist. Zusammen mit dem Risikoregister ist es das zweite zwingend vorgeschriebene ISMS-Dokument nach Kap. 6.1.3 d) und faktisch das Inhaltsverzeichnis jedes Zertifizierungsaudits.

Quelle: ISO/IEC 27001:2022, Kap. 6.1.3 d)

Ja: bewerten, aber nicht zwingend umsetzen. Für jeden der 93 Controls muss dokumentiert sein, ob er anwendbar ist. Nicht anwendbare Controls dürfen ausgeschlossen werden, aber nur mit nachvollziehbarer Begründung, typischerweise weil kein zugehöriges Risiko im Risikoregister vorliegt oder die betroffene Tätigkeit gar nicht stattfindet. Ein unbegründeter Ausschluss ist im Zertifizierungsaudit ein klassischer Findungspunkt.

Quelle: ISO/IEC 27001:2022, Anhang A

Pro Risiko: die betroffenen Werte (Assets), Bedrohung und Schwachstelle, eine Bewertung nach Eintrittswahrscheinlichkeit und Schadenshöhe (meist per Risikomatrix), die gewählte Behandlungsoption (vermindern, vermeiden, verlagern oder akzeptieren), einen namentlich Verantwortlichen und eine Umsetzungsfrist. Bei kritischen, akzeptierten Risiken verlangt eine saubere Dokumentation zusätzlich eine schriftliche Freigabe durch die Geschäftsführung.

Quelle: ISO/IEC 27001:2022, Kap. 6.1.2 und 6.1.3

Anhang A ist Teil der zertifizierbaren Norm ISO/IEC 27001 und listet zu jedem der 93 Controls nur Nummer und Kurztitel. Das dient als feste, prüfbare Referenz für Auditoren. Die vollständige Beschreibung, den Zweck und konkrete Umsetzungsempfehlungen zu jedem Control liefert die eigenständige, informative Norm ISO/IEC 27002:2022. Für die Umsetzung im Alltag ist 27002 die praktische Arbeitsgrundlage, für die Zertifizierung zählt der Bezug auf Anhang A im SoA.

Quelle: ISO/IEC 27001:2022, Anhang A; ISO/IEC 27002:2022

ISO/IEC 42001:2023 ist die erste international zertifizierbare Norm für KI-Managementsysteme (AIMS). Sie beschreibt, wie eine Organisation die Entwicklung, Bereitstellung und Nutzung von KI-Systemen steuert, mit Kapiteln 4 bis 10 nach derselben Struktur wie ISO/IEC 27001 und einem normativen Anhang A mit 38 Referenz-Controls. Sie richtet sich ausdrücklich auch an Organisationen, die KI nur einsetzen und nicht selbst entwickeln.

Quelle: ISO/IEC 42001:2023

Ein ISMS nach ISO/IEC 27001 schützt Informationen vor Verlust von Vertraulichkeit, Integrität und Verfügbarkeit. Ein AIMS nach ISO/IEC 42001 betrachtet zusätzlich Risiken, die aus dem Verhalten des KI-Systems selbst entstehen: Verzerrungen in Trainingsdaten, unklare Datenherkunft, fehlende Erklärbarkeit, Modell- und Datendrift im Betrieb und die Frage, wo menschliche Aufsicht greift. Da beide Normen dieselbe Kapitelstruktur nutzen, lassen sie sich zu einem integrierten Managementsystem zusammenführen.

Quelle: ISO/IEC 42001:2023; ISO/IEC 27001:2022

Anhang A enthält 38 Controls in neun Zielbereichen: A.2 Politiken zur KI, A.3 Interne Organisation, A.4 Ressourcen für KI-Systeme, A.5 Bewertung der Auswirkungen, A.6 KI-System-Lebenszyklus, A.7 Daten für KI-Systeme, A.8 Informationen für interessierte Parteien, A.9 Nutzung von KI-Systemen und A.10 Beziehungen zu Dritten und Kunden. Umgesetzt werden müssen nur die Controls, die die eigenen KI-Risiken behandeln. Für jeden Ein- wie Ausschluss verlangt Kap. 6.1.3 f) eine dokumentierte Begründung im Statement of Applicability.

Quelle: ISO/IEC 42001:2023, Anhang A und Kap. 6.1.3 f)

Die KI-System-Folgenabschätzung nach Kap. 6.1.4 ist der deutlichste Unterschied zu ISO 27001. Während die klassische Risikobewertung fragt, welcher Schaden der Organisation droht, verlangt die Folgenabschätzung zusätzlich eine Bewertung der Konsequenzen für Einzelpersonen, Gruppen und die Gesellschaft, einschließlich des vorhersehbaren Missbrauchs. Betrachtet werden unter anderem Fairness, Transparenz, Datenschutz, Zugänglichkeit sowie Gesundheit und Sicherheit. Die Ergebnisse müssen dokumentiert werden und fließen in die Risikobewertung nach 6.1.2 zurück.

Quelle: ISO/IEC 42001:2023, Kap. 6.1.4

Nein. ISO/IEC 42001 ist eine freiwillige internationale Norm und keine harmonisierte europäische Norm. Eine Zertifizierung begründet daher keine Konformitätsvermutung nach der KI-Verordnung (EU) 2024/1689. Die harmonisierten Normen dazu entstehen separat bei CEN/CENELEC JTC 21. Inhaltlich überschneiden sich die Anforderungen aber stark: Risikomanagement, Daten-Governance, technische Dokumentation, Protokollierung, Transparenz und menschliche Aufsicht verlangen beide. Ein AIMS liefert damit einen großen Teil der nötigen Struktur und Nachweise, ersetzt die Prüfung der KI-Verordnung aber nicht.

Quelle: Verordnung (EU) 2024/1689; ISO/IEC 42001:2023

Ja. Die Norm unterscheidet ausdrücklich zwischen Rollen wie Entwickler, Anbieter und Nutzer eines KI-Systems und adressiert alle. Für reine Anwender liegt der Schwerpunkt auf den Controls zur verantwortungsvollen Nutzung (A.9) und zu Beziehungen zu Dritten und Kunden (A.10): Zuständigkeiten mit dem Anbieter klären, Nutzungsgrenzen einhalten, menschliche Aufsicht sicherstellen und Vorfälle kommunizieren. Controls, die sich auf die Eigenentwicklung beziehen, lassen sich im Statement of Applicability begründet ausschließen.

Quelle: ISO/IEC 42001:2023, Anhang A.9 und A.10

Ein CVSS-Score von 9.8 fällt in die Stufe „kritisch" (9.0-10.0) und entsteht typischerweise bei einer Schwachstelle, die über das Netz ohne Authentifizierung und ohne Nutzerinteraktion ausgenutzt werden kann und dabei Vertraulichkeit, Integrität und Verfügbarkeit vollständig kompromittiert. In der Praxis bedeutet das: sofort handeln, bevorzugt außerhalb des regulären Patch-Zyklus. Ob tatsächlich ein Angriff droht, zeigt zusätzlich ein Blick auf verfügbare Exploits und den KEV-Katalog der CISA.

Quelle: FIRST.org CVSS v3.1 Specification

Ein Score von 8.8 liegt in der Stufe „hoch" (7.0-8.9) und tritt häufig bei Schwachstellen auf, die zwar über das Netz ausnutzbar sind, aber eine Nutzerinteraktion erfordern, etwa das Öffnen einer präparierten Datei oder den Besuch einer manipulierten Seite. Der Handlungsbedarf ist hoch, aber im Unterschied zu einer kritischen Lücke bleibt in der Regel Zeit, den Patch im nächsten geplanten Wartungsfenster einzuspielen, sofern kein aktiver Exploit bekannt ist.

Quelle: FIRST.org CVSS v3.1 Specification

Ein Score von 6.5 liegt in der Stufe „mittel" (4.0-6.9). Solche Schwachstellen erfordern meist zusätzliche Voraussetzungen: einen bereits vorhandenen Zugang mit niedrigen Rechten, eine bestimmte Konfiguration oder eine Nutzerinteraktion. Die Behandlung gehört in den regulären Patch-Zyklus. Wichtig ist der Kontext: Eine mittlere Schwachstelle in einem aus dem Internet erreichbaren System kann dringlicher sein als eine hohe in einem isolierten Testsystem.

Quelle: FIRST.org CVSS v3.1 Specification

CVSS v3.1 kennt fünf Stufen: 0.0 bedeutet „keine" Auswirkung, 0.1 bis 3.9 gilt als niedrig, 4.0 bis 6.9 als mittel, 7.0 bis 8.9 als hoch und 9.0 bis 10.0 als kritisch. Die Einteilung bezieht sich ausschließlich auf die technische Schwere der Schwachstelle selbst. Sie berücksichtigt weder, ob ein Exploit existiert, noch wie schützenswert das betroffene System im eigenen Unternehmen ist.

Quelle: FIRST.org CVSS v3.1 Specification

CVSS bewertet, wie schwer eine Schwachstelle technisch wiegt, wenn sie ausgenutzt wird. EPSS (Exploit Prediction Scoring System) schätzt dagegen als Wahrscheinlichkeit zwischen 0 und 1, wie wahrscheinlich eine Ausnutzung in den nächsten 30 Tagen ist. Beide ergänzen sich: Eine Lücke mit CVSS 9.8 und sehr niedrigem EPSS kann in der Praxis weniger dringend sein als eine mit CVSS 7.5 und hohem EPSS. Für die Priorisierung im Tagesgeschäft ist die Kombination aus beidem plus dem KEV-Katalog aussagekräftiger als jeder Einzelwert.

Quelle: FIRST.org EPSS; CISA KEV-Katalog

Nein. Der CVSS-Score beschreibt nur die technische Schwere unter Idealbedingungen. Eine Schwachstelle mit CVSS 7.5, für die ein funktionsfähiger Exploit kursiert und die im KEV-Katalog steht, erfordert schnelleres Handeln als eine mit CVSS 9.0, die nur theoretisch ausnutzbar ist oder ein nicht erreichbares System betrifft. Die Priorisierung sollte daher immer Score, Exploit-Verfügbarkeit und die eigene Systemexposition zusammen betrachten.

Quelle: FIRST.org CVSS v3.1; CISA BOD 22-01

Der CRA verlangt in Anhang I eine Cybersicherheits-Risikobeurteilung für jedes Produkt mit digitalen Elementen. Die TARA (Threat Analysis and Risk Assessment) ist die etablierte Methode, um diese Anforderung zu erfüllen: Sie grenzt das System ab, identifiziert schützenswerte Werte, leitet Bedrohungsszenarien ab, bewertet die Risiken und definiert Maßnahmen. Die Ergebnisse gehören in die technische Dokumentation nach Anhang VII und müssen über den gesamten Unterstützungszeitraum fortgeschrieben werden.

Quelle: Verordnung (EU) 2024/2847, Anhang I und VII

Threat Modeling ist das systematische Identifizieren von Bedrohungsszenarien anhand der Systemarchitektur, meist mit STRIDE als Klassifikationsraster. Die TARA umfasst diesen Schritt, geht aber weiter: Sie bewertet die gefundenen Bedrohungen nach Eintrittswahrscheinlichkeit und Schadensausmaß und leitet daraus verbindliche, nachverfolgte Maßnahmen ab. Threat Modeling ist damit ein Baustein der TARA und kein Ersatz dafür.

Quelle: IEC 62443-4-1; Microsoft STRIDE

Verpflichtet sind Hersteller von Produkten mit digitalen Elementen nach dem EU Cyber Resilience Act, Hersteller industrieller Automatisierungskomponenten nach IEC 62443-4-1 sowie Automobilhersteller und -zulieferer nach ISO/SAE 21434. Reine Betreiber und Anwender brauchen keine produktbezogene TARA. Für sie ist das organisationsbezogene Risikomanagement nach ISO 27001 oder NIS2 der passende Rahmen.

Quelle: Verordnung (EU) 2024/2847; IEC 62443-4-1; ISO/SAE 21434

Eine feste Frist nennt keines der Regelwerke, aber alle verlangen eine Fortschreibung über den Produktlebenszyklus. In der Praxis heißt das: bei jeder wesentlichen Architektur- oder Funktionsänderung, bei neuen Schnittstellen, nach sicherheitsrelevanten Vorfällen und ergänzend in einem festen Turnus, üblicherweise jährlich. Jede Fortschreibung sollte mit Datum und Verantwortlichem dokumentiert sein, damit sie im Audit nachvollziehbar bleibt.

Quelle: Verordnung (EU) 2024/2847, Anhang I; IEC 62443-4-1

Das Ergebnis ist ein dokumentiertes Risikoregister: eine Liste bewerteter Bedrohungsszenarien mit Angabe des betroffenen Assets, der Eintrittswahrscheinlichkeit, des Schadensausmaßes, der abgeleiteten Maßnahme, des Verantwortlichen und des verbleibenden Restrisikos. Prüffähig wird es durch Konkretheit: benanntes Asset, benannte Ursache, benannter Verantwortlicher und eine vorab dokumentierte Bewertungsskala.

Quelle: IEC 62443-4-1; ISO/SAE 21434, Annex G

Zuschüsse zu Hard- und Software von Bund und Ländern (z.B. Digitalbonus Bayern, MID-Digitale Sicherheit NRW), zinsvergünstigte Kredite wie der KfW-Förderkredit Digitalisierung, und Beratungsförderung wie die BAFA-Förderung unternehmerisches Know-how, die auch Beratung zu NIS2 oder ISO 27001 abdeckt. Der Fördermittel-Radar listet die aktuellen Programme nach Bundesland und Thema filterbar auf.

Quelle: Förderdatenbank des Bundes; KfW; BAFA

Ja, über Beratungsförderungen wie die BAFA-Förderung unternehmerisches Know-how, die externe Beratung zu IT-Sicherheit und Digitalisierungsstrategie bezuschusst: bis zu 80 % der Beratungskosten in den neuen Bundesländern, 50 % im übrigen Bundesgebiet. Die Umsetzung selbst (z.B. technische Maßnahmen) läuft meist über ein separates Zuschuss- oder Kreditprogramm.

Quelle: BAFA - Unternehmensberatung

Jedes Programm im Fördermittel-Radar trägt ein Prüfdatum gegen die offizielle Programmseite. Da sich Fördersätze, Budgets und Fristen kurzfristig ändern (Programme wie ZIM oder DIGI-Zuschuss Hessen wurden 2026 zwischenzeitlich gestoppt bzw. eingestellt), ist vor jeder Antragstellung ein Blick auf die verlinkte offizielle Seite Pflicht. Der Radar ersetzt keine individuelle Förderberatung.

Quelle: Fördermittel-Radar, CyberKlartext

Alles, was im Vorfall gebraucht wird und nicht von der betroffenen IT abhängen darf: eine ausgedruckte Notfallkarte mit Sofortmaßnahmen und Kontakten, die Telefonliste von IT-Dienstleister, Datenschutzbeauftragtem, Versicherung und Behörden, rollenbezogene Checklisten, eine Übersicht der Meldefristen und ein Protokoll, in dem jede Maßnahme mit Zeitstempel festgehalten wird. Das BSI empfiehlt ausdrücklich eine Papierversion, weil im Ernstfall oft kein System mehr erreichbar ist. Digital ergänzen lässt sich das durch eine App auf dem Smartphone, die unabhängig von Firmennetz und Firmenkonten funktioniert.

Quelle: BSI / Allianz für Cyber-Sicherheit: Einstieg ins IT-Notfallmanagement für KMU

Über einen Kanal außerhalb der betroffenen Infrastruktur, in der Incident Response "Out-of-Band-Kommunikation" genannt. Bei Ransomware und übernommenen Konten muss davon ausgegangen werden, dass Angreifer in Postfächern und Chats mitlesen oder die Systeme ohnehin abgeschaltet sind. Bewährt haben sich private Mobilgeräte mit einem Ende-zu-Ende-verschlüsselten Kanal, eine gedruckte Telefonkette als Rückfallebene und die klare Regel, welche Informationen dort geteilt werden dürfen. Wichtig ist, den Ersatzkanal vorher einzurichten und in einer Übung zu testen. Mitten im Vorfall ist dafür keine Zeit.

Quelle: BSI / Allianz für Cyber-Sicherheit: Einstieg ins IT-Notfallmanagement für KMU

Für Einrichtungen im Anwendungsbereich von NIS2 gilt ab Kenntniserlangung: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden und Abschlussbericht binnen eines Monats (Art. 23 Abs. 4 NIS-2, § 32 BSIG). Sind personenbezogene Daten betroffen, kommt die Meldung an die Datenschutz-Aufsichtsbehörde binnen 72 Stunden nach Art. 33 DSGVO hinzu, gegebenenfalls zusätzlich die Benachrichtigung der Betroffenen nach Art. 34. Alle Fristen laufen ab dem Zeitpunkt, an dem der Vorfall bekannt wurde, nicht ab dem Abschluss der Analyse. Auch ein Zwischenstand ist meldepflichtig, wenn die Ursache noch unklar ist.

Quelle: Richtlinie (EU) 2022/2555 Art. 23; § 32 BSIG; Art. 33 DSGVO