Konformität mit NIS2-Richtlinie und Cyber Resilience Act

NIS2 und Cyber Resilience Act

Die NIS2-Richtlinie (EU 2022/2555) und der Cyber Resilience Act (CRA) bilden neue EU-Vorgaben zur Cybersicherheit. NIS2 zielt auf Betreiber wesentlicher Dienste und kritischer Infrastrukturen ab, während der CRA ein Mindestmaß an IT-Sicherheit für Produkte mit digitalen Elementen vorschreibt. Beide Regelwerke gehen über freiwillige Standards wie ISO/IEC 27001 hinaus und schaffen verbindliche Pflichten. EU-Mitgliedstaaten mussten NIS2 bis Oktober 2024 in nationales Recht umsetzen – Deutschland arbeitet an einem NIS2-Umsetzungsgesetz, das voraussichtlich Ende 2025 in Kraft tritt. Der CRA ist hingegen eine EU-Verordnung, die am 10. Dezember 2024 in Kraft getreten ist und ab dem 11. Dezember 2027 vollumfänglich gilt. Im Folgenden werden die zentralen Anforderungen beider Regelungen erläutert – insbesondere was über eine ISO 27001-Zertifizierung hinaus zu beachten ist – sowie die Auswirkungen auf Lieferanten (z.B. Dienstleister) und Software/Cloud-Anbieter.

Anforderungen der NIS2-Richtlinie

Geltungsbereich: NIS2 erweitert den Sektor- und Unternehmenskreis der ersten NIS-Richtlinie erheblich. In Deutschland werden voraussichtlich rund 30.000 Unternehmen als „besonders wichtige“ oder „wichtige Einrichtungen“ neu reguliert, darunter große und mittlere Unternehmen aus 18 Sektoren (z.B. Energie, Gesundheit, digitale Infrastruktur wie Cloud-Provider). Die NIS2-Pflichten gelten verbindlich, sobald das nationale Gesetz greift, ohne längere Übergangsfrist. Bei Verstößen drohen empfindliche Bußgelder bis zu 10 Mio. € bzw. 2 % des weltweiten Jahresumsatzes (für „besonders wichtige“ Einrichtungen)– für „wichtige“ Einrichtungen bis 7 Mio. € bzw. 1,4 %– sowie ggf. persönliche Haftung der Geschäftsführung und Tätigkeitsverbote.

Governance und Verantwortung: NIS2 richtet sich explizit an die Unternehmensleitung. Geschäftsführungen und Vorstände tragen nun persönliche Verantwortung für die Cybersicherheit und müssen sich entsprechend schulen lassen (Art. 20 NIS2). Unternehmen ab einer bestimmten Größe müssen u.a. einen CISO bzw. Informationssicherheitsbeauftragten benennen und ein Cybersecurity-Komitee auf Führungsebene etablieren. Diese Top-Down-Verankerung der IT-Sicherheit ist essenziell für die Compliance.

Technische und organisatorische Maßnahmen: Artikel 21 NIS2 verlangt ein Bündel von Mindestmaßnahmen (Stand der Technik), die alle betroffenen Organisationen umsetzen müssen. Wichtige Anforderungen sind unter anderem:

• Risikomanagement: Durchführung einer Risikoanalyse und Etablierung von Sicherheitsrichtlinien und -prozessen zur Behandlung identifizierter Risiken. Dazu zählt die regelmäßige dokumentierte Risikoanalyse der IT-Systeme.
• Incident Handling: Verfahren zur Erkennung, Meldung und Bewältigung von Sicherheitsvorfällen definieren. Es muss ein Notfall- und Reaktionsplan bestehen, um Cyberangriffe schnell einzudämmen.
• Business Continuity: Konzepte zur Aufrechterhaltung des Betriebs und Wiederherstellung nach Zwischenfällen (inkl. Backup-Management, Desaster-Recovery-Plan und Krisenmanagement) umsetzen.
• Lieferkettensicherheit: Sicherheit in der Lieferkette gewährleisten, d.h. Sicherheitsrisiken bei Anbietern und Dienstleistern bewerten und steuern. Sicherheitsanforderungen sollen in Verträge mit Lieferanten aufgenommen und regelmäßige Überprüfungen ihrer Sicherheit durchgeführt werden. Außerdem sollte die Incident-Response mit kritischen Zulieferern koordiniert werden.
• Systemsicherheit & Schwachstellenmanagement: Sicherheit bei Entwicklung, Beschaffung und Wartung von IT-Systemen sicherstellen. Ein Prozess zum Management von Schwachstellen (Erkennen, Priorisieren, Patchen) ist Pflicht.
• Wirksamkeitsprüfung: Wirksamkeit der Cybersicherheits-Maßnahmen regelmäßig evaluieren (z.B. durch Audits, Penetrationstests oder Kontrollen), um das Niveau stetig zu verbessern.
• Cyberhygiene und Schulung: Grundlegende Sicherheitspraktiken (z.B. Updates, Passwortrichtlinien) und Bewusstseins-Schulungen für Belegschaft und Management implementieren.
• Kryptografie: Einsatz angemessener Verschlüsselungsverfahren und Kryptografierichtlinien zum Schutz sensibler Daten und Kommunikation sicherstellen.
• Personalsicherheit & Zugänge: Maßnahmen zur Zugangskontrolle, Identitätsverwaltung und Sicherung von Assets umsetzen (z.B. Prinzip der geringsten Berechtigungen, Offboarding-Prozesse).
• Multi-Faktor-Authentifizierung und sichere Kommunikation: Wo immer möglich MFA einführen und sichere (Notfall-)Kommunikationswege etablieren (kein Einsatz unsicherer Kanäle für kritische Systeme).

Diese Punkte entsprechen weitgehend den im Gesetz genannten Bereichen. NIS2 fordert zudem, dass die Sicherheitsmaßnahmen stets Stand der Technik sind und angemessen zur Risikolage der Einrichtung passen.

Meldepflichten: Anders als ISO 27001 schreibt NIS2 ein striktes Meldesystem für Cybervorfälle vor. Bei einem erheblichen Sicherheitsvorfall muss innerhalb von 24 Stunden nach Bekanntwerden eine Erstmeldung an die Behörde (BSI bzw. zuständige Stelle) erfolgen, ein ausführlicher Zwischenbericht nach 72 Stunden und spätestens einen Monat danach ein Abschlussbericht mit Ursachenanalyse. Diese Dreistufen-Meldepflicht erfordert, dass Unternehmen entsprechende Prozesse und Kommunikationskanäle vorbereiten. Das bedeutet auch, dass Lieferanten schnell informieren müssen, damit betroffene Kunden fristgerecht melden können. NIS2 erhöht damit die Transparenz gegenüber Behörden deutlich – ein Unterschied zu ISO 27001, das keine externe Meldepflicht kennt.

Aufsicht und Nachweise: NIS2 unterstellt betroffene Unternehmen einer staatlichen Aufsicht (in DE v.a. durch das BSI). Unternehmen müssen die Umsetzung der Maßnahmen dokumentieren und auf Verlangen nachweisen. Betreiber kritischer Anlagen werden alle drei Jahre geprüft, andere Einrichtungen müssen mit Stichprobenkontrollen rechnen. Die Aufsichtsbehörden erhalten erweiterte Befugnisse, z.B. Registrierungspflichten der Unternehmen und Befugnis zu unangekündigten Inspektionen. Fazit: Organisationen müssen unter NIS2 eine dauerhafte Compliance-Bereitschaft sicherstellen – nicht nur punktuell für Audits.

Anforderungen des Cyber Resilience Act

Ziel und Geltungsbereich: Der Cyber Resilience Act (CRA) ist die erste EU-weit verbindliche Verordnung, die Cybersicherheitsanforderungen für Produkte festlegt. Er gilt für nahezu alle Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden – also sowohl Hardware mit Software als auch Softwareprodukte an sich. Entscheidend ist, dass ein Produkt direkt oder indirekt mit einem anderen Gerät oder dem Internet kommunizieren kann. Beispiele: vernetzte Verbrauchergegenstände (Smart-Home-Geräte, Wearables, IoT), industrielle Systeme (z.B. Router, Firewalls, ICS-Steuerungen) und allgemeine Software wie Betriebssysteme oder mobile Apps. Ausgenommen vom CRA sind rein dienstbasierte Angebote wie Software-as-a-Service (SaaS) – d.h. Cloud-Services ohne „Produkt“-Charakter fallen formal nicht unter diese Verordnung. Für alle in den Anwendungsbereich fallenden Produkte muss jedoch ab 2027 eine CE-Kennzeichnung die Erfüllung der Cybersecurity-Anforderungen bestätigen.

Rollenkette und Haftung: Der CRA verteilt Pflichten entlang der gesamten Wertschöpfungskette („Wirtschaftsakteure“). Hauptverantwortlich ist stets der Hersteller: Er muss eine Threat Analysis and Risk Assessment (TARA) für das Produkt durchführen und nachweislich ein sicheres Design umsetzen. Hersteller müssen umfangreiche technische Dokumentation erstellen und über den gesamten Lebenszyklus pflegen. Importeure müssen prüfen, dass der Hersteller seinen Pflichten nachgekommen ist (inkl. CE-Kennzeichnung, EU-Konformitätserklärung und Doku) und übernehmen bei Versäumnissen direkte Haftung. Distributoren wiederum müssen vor Vertrieb sicherstellen, dass das Produkt eine gültige CE-Kennzeichnung trägt und alle vorgeschriebenen Anleitungen beiliegen. Kurz: Jeder in der Lieferkette – vom Hersteller bis zum Händler – kann für die Nichtkonformität zur Rechenschaft gezogen werden. Dies soll verhindern, dass unsichere Produkte in Umlauf kommen, und verlagert die Verantwortung weg vom Endnutzer hin zu Herstellern und Anbietern.

Technische Kernanforderungen (Anhang I): Der CRA schreibt vor, dass Produkte “secure by design” und “secure by default” entwickelt werden. Wichtigste Sicherheitsanforderungen sind u.a.:

• Sichere Voreinstellungen: Produkte müssen im sichersten voreingestellten Zustand ausgeliefert werden. Z.B. dürfen keine Hardcode-Standardpasswörter mehr verwendet werden; unnötige Dienste/Ports sollen ab Werk deaktiviert sein.
• Minimierung der Angriffsfläche: Die Produktarchitektur soll potenzielle Einfallstore für Angriffe so weit wie möglich reduzieren (Prinzip der Minimierung von Funktionen und Schnittstellen auf das Notwendige).
• Integrität und Vertraulichkeit: Digitale Produkte müssen geeignete Vorkehrungen treffen, um Daten und Befehle vor unautorisiertem Zugriff oder Manipulation zu schützen. Dies erfordert starke Authentifizierung (keine universellen Default-Credentials) und zeitgemäße Verschlüsselung sensibler Datenübertragungen.
• Keine bekannten Schwachstellen: Zum Zeitpunkt des Inverkehrbringens dürfen keine bekannten exploitable Sicherheitslücken im Produkt bestehen. Hersteller sollen also vor Release gründliche Tests und Schwachstellenanalysen durchführen.
• Schwachstellenmanagement & Updates: Es muss ein Prozess existieren, um neu auftretende Schwachstellen über den Lebenszyklus zu überwachen, zu melden und zu beheben. Hersteller sind verpflichtet, Sicherheitsupdates kostenlos bereitzustellen und zwar für einen angemessenen Zeitraum (in der Regel die erwartete Nutzungsdauer oder eine in der Verordnung definierte Frist). Ein Product Security Incident Response Team (PSIRT) bzw. vergleichbare Prozesse sollten etabliert werden, um eingehende Schwachstellenmeldungen (z.B. von Forschern über Coordinated Disclosure) entgegenzunehmen und zeitnah Patches auszuspielen.
• Nutzerinformationen (Anhang II): Dem Produkt müssen umfassende Sicherheitsinformationen und Anleitungen beiliegen. Dazu gehören z.B. Hinweise für den sicheren Aufbau/Installation, empfohlene Konfigurationen, Angaben zur Supportdauer für Updates, Kontaktstellen für Schwachstellenmeldungen usw. Der Benutzer soll in die Lage versetzt werden, das Produkt sicher zu betreiben.

Zusätzlich definiert der CRA zwei Klassen kritischer Produkte (wie z.B. Passwort-Manager, Firewall-Appliances u.a.), für die verschärfte Konformitätsbewertungsverfahren gelten. Für die Mehrheit der Produkte wird der Hersteller eine Selbstbewertung durchführen und die EU-Konformitätserklärung ausstellen dürfen; höhere Risikoklassen erfordern eine Prüfung durch eine notifizierte Stelle (Third-Party Audit). In allen Fällen muss der Hersteller die technische CE-Dokumentation (inkl. Risikobeurteilung, Testberichte, implementierte Maßnahmen) bereithalten, da Marktaufsichtsbehörden diese anfordern und Produkte bei Non-Compliance vom Markt entfernen können.

Meldepflichten und Fristen: Ähnlich wie NIS2 kennt der CRA Meldepflichten, jedoch fokussiert auf Produkte: Ab September 2026 müssen Hersteller binnen 24 Stunden Behörden informieren, wenn ihnen eine aktiv ausgenutzte Schwachstelle oder ein gravierender Sicherheitsvorfall in ihrem Produkt bekannt wird. Konkret ist vorgesehen, solche Meldungen an eine zentrale Stelle (vermutlich die EU-weit zuständige Datenbank bei ENISA oder nationale Behörden) zu machen. Diese Frist bedeutet, dass Hersteller ein fortlaufendes Monitoring betreiben müssen (z.B. CVE-Tracking, Bug-Bounty-Programme etc.), um von Exploits zu erfahren. Bis Dezember 2027 müssen dann alle übrigen CRA-Anforderungen erfüllt sein. Die Sanktionen bei Nicht-Einhaltung sind drastisch: Für Verstöße gegen grundlegende Sicherheitsanforderungen drohen Bußgelder bis 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes (je nachdem welcher Wert höher ist). Auch formale Verstöße (fehlende Dokumentation, keine CE-Kennzeichnung) können sanktioniert werden. Unternehmen sollten daher frühzeitig ihren Compliance-Fahrplan ausrollen, da die Implementierung der technischen und organisatorischen Maßnahmen (z.B. Entwicklungspraxis umstellen, Produktupdates planen) in der Regel mehrere Jahre Vorlauf benötigt.

Zusätzliche Maßnahmen trotz ISO 27001-Zertifizierung

Eine bestehende ISO/IEC 27001-Zertifizierung ist ein guter Grundstock, aber kein Automatismus für NIS2- oder CRA-Konformität. ISO 27001 liefert gewissermaßen das „Wie“, während die Gesetze das „Was“vorgeben. Insbesondere NIS2 hat weitergehende Pflichten, die über den flexiblen Rahmen des ISO-Standards hinausgehen:

• Rechtliche Verpflichtungen & Behördenkontakte: ISO 27001 ist freiwillig und intern ausgerichtet, NIS2 dagegen gesetzlich verpflichtend. Unternehmen müssen sich bei der Behörde registrieren (in DE innerhalb 3 Monaten nach Inkrafttreten) und formelle Kommunikationswege etablieren. Insbesondere die Meldepflicht an Behörden bei Sicherheitsvorfällen und gegebenenfalls die Benennung eines behördlichen Ansprechpartners sind zusätzliche Aufgaben, die ISO nicht abdeckt.
• Risikoperspektive erweitern: ISO 27001 fokussiert auf unternehmensinterne Risiken für Vertraulichkeit, Integrität, Verfügbarkeit. NIS2 verlangt, dass das Risikomanagement auch gesellschaftliche Auswirkungen berücksichtigt (z.B. Ausfall eines Dienstes auf nationaler Ebene). Die Resilienzplanung muss also breiter angelegt sein – bis hin zu Krisenszenarien, die sektorübergreifend relevant sind.
• Explizite Maßnahmen ohne Ausnahme: Während ISO einen risiko-basierten Ansatz hat (Controls können mit Begründung ausgelassen werden), schreibt NIS2 bestimmte Maßnahmen verbindlich vor. Beispielsweise wird man sich unter NIS2 nicht auf ein Risikoakzeptanzargument berufen können, um etwa auf Multi-Faktor-Authentifizierung oder Network Monitoring zu verzichten – hier gilt der Stand der Technik zwingend. Unternehmen müssen also ggf. zusätzliche technische Maßnahmen implementieren, die bei ISO als optional galten.
• Lieferkettenmanagement vertiefen: ISO 27001 verlangt zwar auch Supplier Security (A.15 in alter Version/A.5.7 in 2022), doch NIS2 geht deutlich weiter. Es fordert eine erhöhte Sorgfaltspflicht über die gesamte Lieferkette. Praktisch heißt das: Ein NIS2-reguliertes Unternehmen muss Risiken auch bei Sub-Unternehmen zweiter/dritter Ebene adressieren. Dies erfordert erweiterte Due-Diligence-Prozesse und regelmäßige Sicherheitsaudits oder Nachweise von Lieferanten. Als ISO-zertifiziertes Unternehmen sollte man daher sein Lieferantenmanagement überprüfen und ggf. ausbauen (z.B. strengere Vertragspflichten, mehr Überwachung).
• Kontinuierliche Compliance & Audits: ISO-Zertifizierungen werden meist in geplanten Intervallen überprüft. NIS2 hingegen ermöglicht unangekündigte Kontrollen durch Behörden. Organisationen müssen einen Zustand permanenter Compliance sicherstellen – Prozesse sollten also so eingerichtet sein, dass sie jederzeit auditierbar sind. Das erfordert u.a. eine lückenlose Dokumentation, laufendes Monitoring und schnelle Reaktionsfähigkeit, wo ISO eher auf periodische Verbesserungszyklen setzt.
• Top-Management-Einbindung: ISO 27001 verlangt zwar Management Commitment, aber NIS2 institutionalisiert die Verantwortung des Top-Managements in neuer Schärfe (persönliche Haftung, Pflichtschulungen). ISO-zertifizierte Unternehmen sollten sicherstellen, dass Vorstand/Geschäftsführung aktiv in Entscheidungsprozesse der IT-Sicherheit eingebunden sind und alle NIS2-Vorgaben kennen.

Für den Cyber Resilience Act ist ISO 27001 nur begrenzt anwendbar, da ISO primär auf interne Informationssicherheit abzielt, während der CRA Produktsicherheit regelt. Eine ISO 27001-Zertifizierung kann zwar Prozesse wie Patch-Management, Incident Response oder Security Testing etabliert haben, doch Hersteller müssen diese Prozesse nun produktspezifisch ausrichten. Zusätzliche Aufgaben für ISO-27001-zertifizierte Firmen, die vom CRA betroffen sind, beinhalten zum Beispiel:

• Integration von Secure Development Life Cycle (SDLC) Praktiken in die Entwicklungsabteilungen (Sichere Codierstandards, Bedrohungsmodellierung pro Produkt, Security Gates vor Release).
• Durchführung einer produktbezogenen Risikoanalyse (TARA) und Dokumentation der Sicherheitsanforderungen für jedes Produkt – ISO 27001 betrachtet Risiken eher auf Geschäftsprozess-Ebene, hier ist ein tiefer technischer Drill-Down nötig.
• Etablierung eines Produkt-Sicherheitsvorfall- und Schwachstellenprozesses (z.B. Product Incident Response Team), der separate von der allgemeinen IT-Incident-Response funktioniert, um extern gemeldete Produktlücken zu behandeln und gesetzeskonform zu melden.
• Sicherstellung, dass Support- und Updatezusagen eingehalten werden können (Ressourcen für Entwicklung von Sicherheitsupdates über Jahre einplanen).
• Erarbeitung der Konformitätsdokumentation: Ein ISO-ISMS wird zwar viele Policies und Records haben, aber für den CRA müssen spezifische Konformitätsnachweise (gemäß Anh. IV CRA) erstellt werden, inklusive Benutzerinformationen (Anh. II).

Kurzum: Eine ISO 27001-Zertifizierung schafft eine gute Basis und Synergien – viele NIS2/CRA-Forderungen wie Risikomanagement, Incident Response, Lieferantensicherheit decken sich inhaltlich mit ISO. Allerdings müssen Unternehmen gezielt die Gaps identifizieren, wo gesetzliche Pflichten über das ISO-Niveau hinausgehen. Ein systematisches Gap Assessment ist empfehlenswert, um die zusätzlichen Kontrollen und Prozesse zu implementieren, bevor die Vorschriften greifen.

Verpflichtungen für Lieferanten und Dienstleister

Sowohl NIS2 als auch der CRA wirken sich auf die gesamte Lieferkette aus. Auch wenn ein Unternehmen selbst nicht unmittelbar unter die Regulierung fällt, kann es als Zulieferer oder Dienstleister von betroffenen Kunden zur Einhaltung hoher Sicherheitsstandards angehalten werden.

Unter NIS2 sind regulierte Unternehmen verpflichtet, die Cybersecurity ihrer Lieferanten im Blick zu haben. In der Praxis werden große Kunden vertragliche Sicherheitsanforderungen an ihre Auftragsverarbeiter, Cloud-Anbieter oder IT-Dienstleister stellen – oft analog zu ihren eigenen Pflichten. Typische Maßnahmen sind:

• Sicherheitsklauseln in Verträge aufnehmen (z.B. Verpflichtung des Lieferanten zu angemessenen technischen-organisatorischen Maßnahmen, Einhaltung von Standards wie ISO 27001 oder BSI-Grundschutz).
• Regelmäßige Sicherheitsbewertungen und Audits der Lieferanten durchführen oder zumindest Self-Assessments/​Zertifikate einfordern. Ein Kunde, der z.B. als KRITIS-Betreiber gilt, könnte vom Lieferanten jährliche Penetrationstests oder Auditberichte verlangen.
• Meldewege vereinbaren: Lieferanten müssen Vorfälle und Sicherheitslücken unverzüglich an ihre Kunden melden, damit diese ggf. binnen 24 Stunden Behörden informieren können. Eine klare Incident-Response-Koordinierung zwischen Kunden und Lieferant (etwa Notfallkontakte auf beiden Seiten, abgestimmte Reaktionspläne) ist essentiell.
• Kontinuierliches Monitoring: Kunden könnten Tools oder Services einsetzen, um die Security-Posture kritischer Dienstleister zu überwachen (z.B. externe Scan-Dienste für Schwachstellen). Lieferanten sollten sich auf solche Bewertungen einstellen und kooperativ zeigen.

Für Lieferanten bedeutet das: Auch wenn sie rechtlich nicht direkt von NIS2 erfasst werden, müssen sie faktisch ein ähnliches Sicherheitsniveau vorweisen, um am Markt zu bestehen. Ein Beispiel: Ein Cloud-Provider, der kritische Unternehmen bedient, wird nur dann weiterhin Aufträge bekommen, wenn er nachweislich robuste Security hat – im Idealfall durch ISO 27001-Zertifizierung oder vergleichbare Nachweise. Kunden könnten vertraglich sogar ein Recht auf Audit beim Lieferanten vereinbaren oder den Lieferanten bei groben Sicherheitsmängeln sanktionieren/wechseln. Unsere Empfehlung als Lieferant ist daher, sich proaktiv auf NIS2-Standards auszurichten, um für Kunden ein geringes Risiko darzustellen.

Der Cyber Resilience Act bezieht sich primär auf die Herstellerrolle, doch indirekt betrifft er auch die Zulieferer von Komponenten. Ein Hersteller wird nur konforme Produkte herausgeben können, wenn alle eingebetteten Komponenten (sei es Software-Libraries, Module oder Hardware-Bauteile) die Sicherheitsanforderungen erfüllen. Somit wird er von seinen Zulieferern entsprechende Zusicherungen und Unterstützung verlangen. Beispielsweise muss ein Software-Drittanbieter dem Hersteller Sicherheitsupdates für seine Komponente bereitstellen, damit der Hersteller die Gesamtprodukt-Sicherheit aufrechterhalten kann. Es ist zu erwarten, dass Hersteller in Verträgen mit Softwarelieferanten festlegen, dass gelieferter Code frei von bekannten Schwachstellen sein muss und der Lieferant bei neu auftretenden Lücken innerhalb definierter Fristen Updates liefert. Auch könnten Vereinbarungen zur Haftungsüberwälzung getroffen werden, falls eine unsichere Zulieferkomponente zu Regulierungssanktionen führt. Für Zulieferer digitaler Komponenten heißt das: Sie sollten ihre Secure Development Practices und Qualitätskontrollen im Griff haben, da ihre Kunden (die Hersteller) dies auditieren und vertraglich absichern möchten. Zwar adressiert der CRA formal nur die in Verkehr bringenden Akteure, aber kein Glied der Kette kann es sich leisten, das „schwächste Glied“ in punkto Security zu sein.

Im Kontext Ihrer Frage („Wir sind eine Datenschutz-Firma und der Cloud-Anbieter ist unser Kunde“) bedeutet das konkret: Ihre Datenschutz- oder IT-Sicherheitsdienstleistungen müssen so aufgestellt sein, dass der Cloud-Anbieter seinerseits die Compliance-Pflichten erfüllt. Zum Beispiel sollten Verträge an die neuen Anforderungen angepasst werden (Auftragsverarbeitungsverträge mit erweiterten Sicherheitsanlagen, SLA für Incident-Meldungen, etc.). Als Dienstleister sollte man dem Kunden proaktiv helfen, Compliance-Nachweise zu erbringen – etwa indem man dokumentiert, wie die eigenen Leistungen NIS2-Maßnahmen unterstützen. Letztlich werden Kunden von ihren Lieferanten denselben Standard einfordern, dem sie selbst genügen müssen. Es empfiehlt sich daher, jetzt interne Richtlinien und Prozesse zu prüfen und mit NIS2/CRA-Vorgaben abzugleichen, um als Lieferant compliant zu sein und Vertrauen beim Kunden zu sichern.

Perspektive eines Software- und Cloud-Anbieters

Cloud-Service-Provider nehmen eine besondere Rolle ein. Unter NIS2 fallen sie in die Kategorie „Digitale Infrastruktur“ (neben Internetknoten, DNS, CDN usw.). Größere Cloud- und Hosting-Anbieter werden in der EU daher als wichtige oder sogar besonders wichtige Einrichtung eingestuft, sofern sie gewisse Schwellenwerte überschreiten (z.B. Mitarbeiterzahl, Umsatz). Ein Cloud-Anbieter mit bedeutender Marktpräsenz muss sich also auf direkte NIS2-Compliance einstellen. Praktisch bedeutet dies für Cloud-Anbieter: Umsetzung aller zuvor beschriebenen NIS2-Maßnahmen (ISMS einführen, Risiko- und Sicherheitsmanagement unternehmensweit etablieren, 24/7-Incident-Response einrichten etc.) und Registrierung beim BSI innerhalb von 3 Monaten nach Inkrafttreten des deutschen Gesetzes. Viele Cloud-Provider verfügen bereits über ISO 27001 oder ähnliche Zertifikate – diese sollten genutzt werden, um die NIS2-Anforderungen größtenteils abzudecken, aber ergänzt um die gesetzlich geforderten Aspekte (Meldevorgaben, behördliche Kommunikation, ggf. Einsatz von Detektionssystemen wie IDPS nach Stand der Technik). Cloud-Anbieter müssen außerdem beachten, dass Behörden Zugriffsrechte im Rahmen der Aufsicht bekommen – das BSI könnte z.B. Nachweise oder sogar Vor-Ort-Prüfungen verlangen, um die Einhaltung zu kontrollieren.

Für Softwarehersteller (die Software verkaufen, nicht nur als Service betreiben) ist der Cyber Resilience Act einschlägig. Ein Unternehmen, das z.B. eine Softwareplattform entwickelt und an Kunden lizenziert (On-Premise oder als installierbare Software), gilt als Hersteller eines digitalen Produkts und muss bis 2027 die CRA-Vorgaben umsetzen. Dazu gehört, die Software mit allen oben genannten Sicherheitsfunktionen auszustatten (Secure-by-Default, keine bekannten Bugs, Härtung, Logging etc.) und den Konformitätsprozess (CE-Kennzeichnung) zu durchlaufen. Wichtig: Wenn ein Cloud-Anbieter seine Dienste rein als SaaS bereitstellt, greift der CRA formal nicht. Dennoch erwarten Kunden natürlich auch bei SaaS-Produkten hohe Sicherheit – und die EU-Regulatorik entwickelt sich weiter (es gibt z.B. Überlegungen, Cloud-Dienstleister in andere Regime wie den EU Cybersecurity Act/Zertifizierung einzubeziehen). Ein Cloud-Service sollte also freiwillig die Prinzipien des CRA berücksichtigen, etwa sichere Softwareentwicklung und schnelle Patch-Zyklen, um Kunden und Auditoren zu überzeugen. Für Cloud-/SaaS-Anbieter steht im Vordergrund, die NIS2-Konformität sicherzustellen (sofern sie selbst betroffen sind oder ihre Kunden in kritischen Branchen liegen). Aber auch ohne direkte CRA-Pflicht lohnt es sich, die internen Entwicklungsprozesse an den CRA-Grundsätzen zu orientieren – so wird gewährleistet, dass falls künftig doch verbindliche Dienst-Security-Anforderungen kommen, man gut vorbereitet ist.

Zusammenfassend sollten Software- und Cloud-Anbieter sich fragen: Betrifft NIS2 mein Unternehmen direkt? (Größe/Branche prüfen, ggf. BSI-Tool nutzen) und Haben wir Produkte im Sinne des CRA? Falls ja, müssen umgehend Compliance-Projekte gestartet werden. Falls der eigene Betrieb nicht direkt reguliert ist, muss man dennoch die indirekten Anforderungen der Kunden erfüllen.

Konkrete Schritte zur Compliance (Checkliste)

Zum Abschluss einige praktische Schritte, um die Konformität mit NIS2 und dem CRA sicherzustellen – auch für bereits ISO 27001-zertifizierte Organisationen:

1. Betroffenheit analysieren: Prüfen Sie, ob Ihr Unternehmen unter NIS2 fällt (Sektor, Größe) und ob Ihre Produkte vom CRA erfasst sind (digitale Elemente, keine SaaS-Ausnahme). Nutzen Sie verfügbare Self-Assessment-Tools (z.B. vom BSI) oder ziehen Sie Experten hinzu.
2. Management einbinden: Informieren Sie die Geschäftsleitung über die neuen Pflichten und setzen Sie Cybersicherheit zur Chefsache. Benennen Sie klare Verantwortliche: einen CISO bzw. Informationssicherheits-Verantwortlichen und ggf. ein bereichsübergreifendes Sicherheitsgremium. Führen Sie Pflichtschulungen für das Management durch zu NIS2/CRA-Inhalten.
3. Gap-Analyse durchführen: Vergleichen Sie bestehende Sicherheitsmaßnahmen (z.B. Ihr ISMS nach ISO 27001) mit den konkreten Anforderungen aus NIS2 und CRA. Identifizieren Sie Lücken – etwa fehlende Incident-Meldeprozesse, unzureichendes Schwachstellenmanagement oder fehlende Lieferantenkontrollen. Priorisieren Sie diese Lücken nach Risiko und Aufwand.
4. Maßnahmenplan erstellen: Entwickeln Sie auf Basis der Gap-Analyse einen Umsetzungsfahrplan. Dazu gehören: Einführung technischer Controls (z.B. flächendeckend MFA, Netzsegmentierung, Monitoring-Lösungen), Überarbeitung von Policies (Incident Response Plan an Meldepflicht anpassen, Lieferantenrichtlinie verschärfen) sowie Schulungs- und Testmaßnahmen. Stellen Sie sicher, dass alle in NIS2 Art. 21 gelisteten Themen abgedeckt sind (siehe oben: Risikoanalyse, Notfallmanagement, Backup, Lieferkette, Secure Development etc.). Für den CRA planen Sie Security-by-Design in Entwicklungsprojekten ein und bereiten technische Dokumentationen pro Produkt vor.
5. Implementierung und Integration: Setzen Sie die geplanten Maßnahmen Schritt für Schritt um. Nutzen Sie Synergien, um Doppelaufwand zu vermeiden – z.B. kann ein gut implementiertes ISMS gleichzeitig viele NIS2-Kontrollen erfüllen. Integrieren Sie neue Prozesse in bestehende Abläufe (z.B. Schwachstellenmeldungen ins Helpdesk-System; Lieferantenaudits in Beschaffungsprozesse). Dokumentieren Sie alle Änderungen nachvollziehbar.
6. Notfallmeldesystem testen: Richten Sie die Vorfall-Meldekanäle ein (wer meldet ans BSI, innerhalb welcher Fristen) und proben Sie den Ernstfall. Zum Beispiel mittels einer Simulation eines Cyberangriffs prüfen, ob innerhalb von 24 Stunden eine Meldung generiert würde und alle Informationen fließen. Ebenso sollte klar sein, wer intern und beim Kunden im Fall eines Lieferantenvorfalls informiert wird.
7. Lieferanten einbinden: Kommunizieren Sie mit Ihren kritischen Dienstleistern über die neuen Anforderungen. Aktualisieren Sie Verträge mit Sicherheitsanhängen und rechten/pflichten zur Auditierung und Berichterstattung. Helfen Sie wichtigen Zulieferern ggf. dabei, selbst Sicherheitsstandards einzuhalten (z.B. Schulungsmaterial bereitstellen oder gemeinsame Incident-Drills durchführen).
8. Monitoring und kontinuierliche Verbesserung: Etablieren Sie ein kontinuierliches Monitoring der Compliance. Halten Sie sich über Weiterentwicklungen der Rechtslage auf dem Laufenden (BSI-Regelungen, EU-Implementing Acts). Überwachen Sie Ihre Systeme und Produkte fortlaufend auf neue Schwachstellen (CVE-Monitoring, Bedrohungsinformationen). Passen Sie Ihr Sicherheitskonzept an neue Erkenntnisse und Technologien an – NIS2 und CRA verlangen dynamische Anpassung an den Stand der Technik.

Durch diese Schritte nähert sich Ihr Unternehmen einer ganzheitlichen Compliance. Wichtig ist, frühzeitig zu starten – insbesondere, da es für NIS2 in Deutschland voraussichtlich keine Schonfrist geben wird. Nutzen Sie vorhandene Ressourcen: Viele Anforderungen von NIS2 und CRA decken sich mit bewährten Standards und Best Practices der IT-Sicherheit. Wer jetzt handelt, vermeidet nicht nur Sanktionen, sondern erhöht auch die eigene Cyber-Resilienz und die Vertrauenswürdigkeit am Markt. Compliance wird so vom lästigen Muss zum Wettbewerbsvorteil.