Cybersicherheit mit System

Cybersicherheit mit System: NIS2, CRA, RED, DORA und CSA Regulatorien verstehen, Risiken gezielt managen 

So erfüllen Sie als IT- und Compliance-Verantwortlicher die neuen Anforderungen mit SBOM und Vulnerability Management 

Die Anforderungen für Unternehmen an die Cybersicherheit steigen - nicht nur technisch, sondern auch regulatorisch. Mit NIS2, CRA, RED, DORA und CSA rücken Vorschriften ins Zentrum, die Unternehmen in verschiedenen Branchen zur Stärkung ihrer Resilienz verpflichten. Bis mindestens 2027 befinden sich Unternehmen zudem in einer Übergangsphase, in der für viele digitale Produkte sowohl die Anforderungen der RED-Richtlinie (Radio Equipment Directive), ab August 2025, als auch erste Vorgaben des Cyber Resilience Act (CRA) abhängig vom Zeitpunkt der Markteinführung gelten können. Während RED sich speziell auf Funkgeräte konzentriert, weitet der CRA den Geltungsbereich ab 2027 deutlich aus: Auch reine Softwareprodukte, vernetzte Hardware und IoT-Lösungen fallen dann unter die neuen Vorgaben zur Produktsicherheit und Schwachstellenresilienz. Dabei ergänzen sich RED und CRA: RED stellt aktuell den Mindeststandard für Funkgeräte dar, während der CRA ab 2027 einen ganzheitlichen, europaweiten Sicherheitsrahmen für sämtliche digitalen Produkte etabliert 

Eine frühzeitige Umsetzung der Anforderungen ist daher nicht nur aus Compliance-Sicht sinnvoll, sondern auch wirtschaftlich klug: Unternehmen, die bereits jetzt mit der technischen und dokumentarischen Vorbereitung beginnen, reduzieren zukünftige Umstellungskosten und vermeiden doppelte Entwicklungsaufwände. 

In diesem Beitrag geben wir einen kompakten Überblick über die vier zentralen Rahmenwerke der EU zur Cybersecurity und zeigen, wie Unternehmen ihre Sicherheitsstrategie regulatorisch absichern können.  

Besonders im Fokus: das Schwachstellenmanagement und die Software Bill of Materials (SBOM) - zwei Schlüsselkomponenten, die auch in unserer  Vulnerability-Management-Lösung bei conplement eine zentrale Rolle spielen. Denn nur wer weiß, was in seiner Software steckt, kann schnell auf Risiken reagieren und bleibt compliant. Im Folgenden werden die vier wichtigen Cybersecurity-Rahmenwerke und -Regelungen NIS2, CRA, DORA und CSA gegenübergestellt. Dabei werden Gemeinsamkeiten, Unterschiede sowie die jeweiligen Anwendungsbereiche erläutert. 

1. Überblick der Regelwerke 

 

2. Gemeinsamkeiten 

•  Cybersecurity-Fokus: Alle vier zielen darauf ab, die Cybersicherheit und Resilienz gegenüber digitalen Bedrohungen zu erhöhen
  
  
• Risikomanagement: Sie fordern ein systematisches Management von Cyberrisiken und Sicherheitsvorfällen. 
  
  
• Erhöhung der Sicherheit in der digitalen Infrastruktur: Ob kritische Infrastrukturen, Finanzsektor, digitale Produkte oder Cloud-Umgebungen - alle adressieren Sicherheitsaspekte in digitalisierten Umgebungen. 
  
  
• EU-Kontext: NIS2, CRA und DORA sind EU-rechtliche Maßnahmen, die in der EU gelten und harmonisierte Sicherheitsstandards setzen.
  
  
• Meldepflichten: Sowohl NIS2 als auch DORA und CRA beinhalten Anforderungen zur Meldung von Sicherheitsvorfällen oder Schwachstellen. 

3. Unterschiede im Detail 

3.1 NIS2 (Network and Information Systems Directive 2) 

•  Ziel: Verbesserung der Cybersicherheit in kritischen und wichtigen Sektoren der EU. 
  
  
• Abdeckung: Breite Palette von Sektoren (z.B. Energie, Verkehr, Gesundheit, digitale Dienste, öffentliche Verwaltung). 
  
  
• Fokus: Schutz von Netz- und Informationssystemen, inklusive Lieferketten und Managementverantwortung. 
  
  
• Rechtsform: Richtlinie, die von den Mitgliedstaaten in nationales Recht umgesetzt wird.
  
  
• Pflichten: Einführung von Risikomanagement, Meldepflichten (Erstmeldung binnen 24 Stunden), Sicherheitsmaßnahmen und staatliche Aufsicht.
  
  
• Status Deutschland: Die deutsche Umsetzung verzögerte sich erheblich. Das NIS2-Umsetzungsgesetz wird voraussichtlich im Herbst 2025 in Kraft treten, nachdem das Gesetzgebungsverfahren aufgrund der Bundestagsneuwahlen und des Diskontinuitätsprinzips neu gestartet werden muss.
  
  
• Sanktionen: Erhebliche Bußgelder bei Verstößen. 
  
  
• Besonderheit: Breite gesellschaftliche Relevanz, betrifft viele Unternehmen und Organisationen in kritischen Bereichen. 
  
  

3.2 CRA (Cyber Resilience Act) 

•  Ziel: Sicherstellung, dass digitale Produkte sicher entwickelt, betrieben und gewartet werden. 
  
  
• Abdeckung: Hersteller, Händler und Importeure von digitalen Produkten mit Vernetzungsmöglichkeiten (Hardware, Software, IoT). 
  
  
• Fokus: Produktlebenszyklus-Sicherheit, „Security by Design", kontinuierliche Überwachung von Schwachstellen und Updates. 
  
  
• Rechtsform: Verordnung, direkt anwendbar in der EU. 
  
  
• Produktkategorien: Der CRA unterteilt Produkte in vier Kategorien: 

Während Standard-Produkte mit einer einfachen Herstellerselbsterklärung auskommen, erfordern kritische Produkte aufwendige Zertifizierungsverfahren durch externe Stellen. Hersteller müssen ihre Produkte entsprechend einordnen und die jeweiligen Security-by-Design-Prinzipien von Beginn der Entwicklung an implementieren. 

• Pflichten: Risikoanalysen, Dokumentation, Schwachstellenmanagement, Meldepflichten bei Sicherheitslücken (ab 11. September
  2026).
  
  
• Sanktionen: Bis zu 15 Mio. EUR oder 2,5% des weltweiten Jahresumsatzes.
  
  
• Besonderheit: Fokus auf Produktsicherheit, nicht auf Organisationen oder Sektoren. 

3.3 DORA (Digital Operational Resilience Act) 

• Ziel: Gewährleistung der digitalen operativen Resilienz von Finanzinstituten und deren IT-Drittanbietern. 
  
  
• Abdeckung: 20 verschiedene Arten von Finanzinstituten (Banken, Versicherungen, Zahlungsdienstleister, Krypto-Anbieter, Wertpapierfirmen, etc.) und ihre ICT-Drittanbieter. 
  
  
• Fokus: ICT-Risikomanagement, Resilienztests (einschließlich Threat-led Penetration Testing alle drei Jahre), Drittanbietermanagement, standardisierte Meldeprozesse. 
  
  
• Rechtsform: Verordnung, direkt anwendbar. 
  
  
• Pflichten: Strenge Anforderungen an ICT-Sicherheitsmaßnahmen, regelmäßige Tests, Überwachung von Drittanbietern, Meldepflichten für schwerwiegende Vorfälle. 
  
  
• Umfang: Betrifft schätzungsweise 22.000 Finanzunternehmen in der EU, davon 3.600 in Deutschland. 
  
  
• Sanktionen: Bis zu 2% des weltweiten Jahresumsatzes. 
  
  
• Besonderheit: Spezifische Regulierung für den Finanzsektor mit Fokus auf operative Kontinuität und Widerstandsfähigkeit, erstmalige direkte EU-Aufsicht über kritische ICT-Drittdienstleister. 
  
  

3.4 CSA (Cloud Security Alliance) 

• Ziel: Bereitstellung von Best Practices und Leitlinien für sichere Cloud-Nutzung. 
  
  
• Abdeckung: Organisationen, die Cloud-Dienste nutzen oder anbieten. 
  
  
• Fokus: Cloud-spezifische Sicherheitsarchitekturen, Governance, Compliance, Risikomanagement. 
  
  
• Rechtsform: Gemeinnützige Organisation, die verschiedene Frameworks und Standards entwickelt, kein Gesetz. 
  
  
• Hauptkomponenten: Cloud Controls Matrix (CCM): Cybersecurity-Kontrollrahmen mit 197 Kontrollobjektiven in 17 Domänen 
  
  
• Security Guidance for Cloud Computing: Umfassende Leitlinien mit verschiedenen Sicherheitsdomänen 
  
  
• STAR-Programm: Zertifizierungsprogramm für Cloud-Sicherheit mit drei Stufen 
  
  
• CAIQ (Consensus Assessments Initiative Questionnaire): Fragebogen zur Bewertung von Cloud-Anbietern 
  
  
• Pflichten: Empfehlungen und Standards für Cloud-Sicherheit, z.B. Zero Trust, DevSecOps, Datenschutz. 
  
  
• Besonderheit: Branchenweit anerkannte Leitlinien, keine rechtliche Verpflichtung, aber oft Grundlage für Compliance. Die CSA ist eine Organisation, nicht ein einheitliches Framework. 
  
  

4. Anwendungsbereiche im Überblick 

Zusammenfassung 

• NIS2 ist eine breit angelegte EU-Richtlinie zur Verbesserung der Cybersicherheit in kritischen Sektoren. Die deutsche Umsetzung verzögert sich bis voraussichtlich Herbst 2025. 
  
  
• CRA fokussiert auf die Sicherheit von digitalen Produkten über deren gesamten Lebenszyklus und teilt Produkte in vier Risikoklassen ein. 
  
  
• DORA ist eine spezifische Verordnung für 20 verschiedene Arten von Finanzinstituten, die digitale Resilienz und ICT-Risikomanagement regelt.
  
  
• CSA ist eine gemeinnützige Organisation, die verschiedene Frameworks und Leitlinien für Cloud-Sicherheit bereitstellt, insbesondere die Cloud Controls Matrix mit 197 Kontrollobjektiven in 17 Domänen. 

SBOM und Vulnerability Management im Kontext von NIS2, CRA, DORA und CSA 

Ein zentraler Aspekt aller vier Rahmenwerke - ob NIS2, CRA, DORA oder CSA - ist das systematische Management von IT-Risiken und Schwachstellen. Dabei rückt eine Komponente zunehmend in den Fokus: die Software-Stückliste, auch bekannt als SBOM (Software Bill of Materials). Sie bildet die Grundlage für ein effektives Vulnerability Management und ist ein verbindendes Element zwischen technischen Sicherheitsmaßnahmen und regulatorischer Compliance. 

SBOM als Basis für Transparenz und Handlungsfähigkeit 

Eine SBOM listet alle Komponenten und Abhängigkeiten einer Software auf - inklusive Open-Source-Bibliotheken und Drittanbieter-Module. Diese Transparenz ist essenziell, um bekannte Schwachstellen (Common Vulnerabilities and Exposures, CVE) schnell zu identifizieren und gezielt Maßnahmen einzuleiten. Das wird in mehreren Regelwerken inzwischen gefordert oder empfohlen: 

• CRA: fordert die kontinuierliche Überwachung und das Management von Schwachstellen über den gesamten Produktlebenszyklus hinweg. Ein SBOM ist hier faktisch Voraussetzung für „Security by Design“ und die Erfüllung von Meldepflichten. 
  
  
• NIS2: verpflichtet Betreiber kritischer und wichtiger Infrastrukturen zu einem Risikomanagement inklusive Schwachstellenanalyse. Ohne Kenntnis der eingesetzten Softwarekomponenten ist dies kaum umsetzbar - eine SBOM schafft hier die notwendige Grundlage. 
  
  
• DORA: stellt hohe Anforderungen an ICT-Risikomanagement und Resilienztests in Finanzinstitutionen. Eine vollständige Transparenz über eingesetzte Software hilft, Abhängigkeiten besser zu verstehen und Vorfälle schneller einzugrenzen. 
  
  
• CSA: gibt praxisorientierte Empfehlungen, z. B. in der Cloud Controls Matrix (CCM), die auch den Einsatz von SBOM und kontinuierlichem Schwachstellenmanagement in Cloud-Umgebungen befürworten. 
  
  
• RED: die RED II (umgesetzt über die harmonisierten EN 18031-Normen) fordert ab August 2025 ausdrücklich die Erstellung und Pflege einer SBOM für betroffene Produkte 

Vulnerability Management als aktiver Teil der Compliance 

Vulnerability Management ist nicht nur technische Pflicht, sondern auch ein Compliance-Werkzeug. Es umfasst die Identifikation, Bewertung, Priorisierung und Behebung von Schwachstellen - idealerweise automatisiert und kontinuierlich. In Verbindung mit einem gepflegten SBOM lassen sich regulatorische Anforderungen effizient erfüllen: 

• Sicherheitsvorfälle schneller erkennen und melden (z. B. bei NIS2 innerhalb von 24 Stunden)
  
  
• Risiken nachweislich bewerten und dokumentieren (z. B. bei DORA und CRA)
  
  
• Lieferketten transparenter gestalten und absichern (relevant in allen vier Rahmenwerken)

 
Mit SBOM und Vulnerability Management machen Sie nicht nur einen entscheidenden Schritt in Richtung regelwerkskonformer IT-Sicherheit - Sie schaffen auch messbaren wirtschaftlichen Mehrwert: 

• Weniger Kostenrisiko: Sicherheitsvorfälle früh erkennen, Schäden vermeiden. 
  
  
• Geringerer Auditaufwand: Nachweise für NIS2, CRA & Co. effizienter erbringen. 
  
  
• Schnellere Marktzulassung: RED & CRA-konforme Produkte ohne Verzögerung launchen. 
  
  
• Stärkere Kundenwirkung: Vertrauensvorsprung durch belegbare Transparenz. 
  
  
• Zukunftssichere Investition: Heute vorbereiten, morgen Mehraufwand vermeiden. 

  

SBOM und Vulnerability Management sind keine optionalen Tools mehr, sondern zentrale Enabler für Cybersecurity-Compliance. Sie ermöglichen nicht nur Reaktion im Krisenfall, sondern schaffen auch die Grundlage für proaktiven Schutz - regulatorisch abgesichert und technisch skalierbar. 

Wer diese Komponenten heute systematisch etabliert, ist morgen besser vorbereitet - unabhängig davon, welches Regelwerk zur Anwendung kommt.