Cyberresilienz-Verordnung für Softwareanbieter in Zypern: Fahrplan 2026–27

Prüfen, ob das Angebot ein Produkt mit digitalen Elementen ist

Die CRA betrifft Produkte mit digitalen Elementen, die auf dem Unionsmarkt bereitgestellt werden und deren beabsichtigte oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz umfasst. Software selbst kann das Produkt sein; ein physisches Gerät ist nicht nötig. Definieren Sie genau den angebotenen Gegenstand: herunterladbare Anwendung, Firmware, Plug-in, vernetztes Gerät oder integriertes System. Vermerken Sie, unter wessen Namen er verkauft wird, wer die Entwicklung steuert und wer Sicherheitsupdates bereitstellt. Eine Gründung in Zypern befreit ein Unternehmen nicht, wenn sein Produkt in der EU angeboten wird. Bewerten Sie jede Produktlinie und ihren tatsächlichen Vertriebsweg statt nur die Firmierung.

Die Abgrenzung zwischen Produkt und Dienst ist besonders wichtig. Eine entfernte Datenverarbeitungslösung kann dazugehören, wenn sie vom Hersteller oder in seinem Auftrag entwickelt wurde und das Produkt ohne sie eine Funktion nicht erfüllen kann. Eine App, deren Kernfunktion die eigene API des Herstellers braucht, verlangt deshalb eine Prüfung des Backend-Teils im Sicherheitskonzept. Ein unabhängiger Webdienst oder eine Cloudleistung außerhalb seiner Verantwortung wird dagegen nicht automatisch Teil des Produkts. Gewöhnliches SaaS wird nicht allein deshalb zum CRA-Produkt, weil es im Internet läuft. Beschreiben Sie technische Abhängigkeit, Vertrag, Kontrolle und Zweck der entfernten Komponente. Andere Rechtsregime können für den Dienst trotzdem relevant sein.

Halten Sie Ausnahmen und Grenzfälle schriftlich fest. Einige Produktgruppen unterliegen besonderen EU-Vorschriften und haben eigene Ausschlüsse oder abgestimmte Regeln. Freie und quelloffene Software außerhalb einer kommerziellen Tätigkeit steht anders da als ein kommerziell vertriebenes Produkt; ein Open-Source-Software-Steward hat wiederum eigene Pflichten. Erfassen Sie Produktfamilie, Version, Vertriebskanal, Geschäftsmodell, vorgesehene Nutzer und entfernte Abhängigkeiten. Bei Unsicherheit ziehen Sie die neueste Umsetzungshilfe der Kommission und die Definitionen der Verordnung heran. Eine Vertriebsbeschreibung wie „nur Plattform“ oder „nur Open Source“ ersetzt diese Prüfung nicht. Bewahren Sie die Gründe auf, damit die Einordnung nach einer Produktänderung überprüfbar bleibt.

Weiterführend: DSA-Leitfaden zu Plattformmeldungen.

Rechtsgrundlage und Hinweise: Verordnung (EU) 2024/2847, Cyberresilienz-Verordnung, Artikel 2, 3, 13, 14, 71 und Anhänge I–IV; Europäische Kommission: Zusammenfassung der Cyberresilienz-Verordnung; Europäische Kommission: Umsetzungshinweise 2026 zur CRA

Hersteller-, Importeur- und Händlerrolle je Produkt bestimmen

Die zentralen Pflichten für Gestaltung, Konformität und Schwachstellenbehandlung liegen beim Hersteller: bei der Person oder Gesellschaft, die ein Produkt entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke vermarktet. Eine zyprische Firma kann Herstellerin sein, obwohl Programmierer im Ausland sitzen oder Komponenten von Dritten stammen. Ein Wiederverkäufer eines Produkts von außerhalb der EU kann stattdessen Importeur oder Händler mit anderen Prüf- und Mitwirkungspflichten sein. Bei White-Label-Angeboten kann sich die Rolle ändern. Dokumentieren Sie tatsächliche Marke, Lieferkette, Vertrag, Freigabe von Releases und Ansprechpartner. Entscheidend ist die reale Stellung am Markt, nicht ein beliebiges Etikett in einem Outsourcingvertrag.

Ordnen Sie jeder Produktlinie einen Verantwortlichen für Sicherheitsarchitektur, Abhängigkeiten, EU-Konformitätserklärung, technische Unterlagen und Eingang von Schwachstellenmeldungen zu. Auch bei eingebundenen Open-Source-Paketen braucht der Hersteller angemessene Prüfung und eine Lösung für bekannt gewordene Sicherheitslücken. Eine Einkaufsklausel, die allein dem externen Entwickler die Verantwortung zuweist, verschiebt gesetzliche Herstellerpflichten nicht automatisch von der Marke des fertigen Produkts weg. Umgekehrt ist ein Marktplatz, der nur Produkte anderer Händler vermittelt, nicht deshalb selbst Hersteller. Seine Plattformpflichten sind gesondert zu bewerten. Zeichnen Sie die Zuständigkeiten als Tabelle nach Produkt, Rechtsträger, Lieferant und Release auf, damit im Vorfall niemand erst Verträge suchen muss.

Die Produktrolle kann sich im Lebenszyklus ändern. Eine wesentliche Änderung nach dem allgemeinen Anwendungsbeginn kann ein älteres Produkt in den vollen Rahmen bringen. Notieren Sie Veröffentlichungen, größere Funktionsänderungen, sicherheitsrelevante Integrationen und die Gesellschaft, die sie vorgenommen hat. Aktualisieren Sie die Rollenkarte bei Erwerb, Verkauf oder Übertragung innerhalb einer Unternehmensgruppe. Für die Meldung eines Vorfalls muss klar sein, welcher Rechtsträger anzeigt und wer technisch genug weiß, um das gesetzliche Auslösekriterium rechtzeitig zu beurteilen. Halten Sie Kontaktpersonen, Vertretung und Entscheidungspfad in derselben Akte. Ein allgemeines Organigramm ohne Produktbezug reicht dafür nicht aus.

Weiterführend: DSA-Leitfaden zur Händlerprüfung.

Rechtsgrundlage und Hinweise: Verordnung (EU) 2024/2847, Cyberresilienz-Verordnung, Artikel 2, 3, 13, 14, 71 und Anhänge I–IV; Europäische Kommission: Zusammenfassung der Cyberresilienz-Verordnung; Europäische Kommission: Umsetzungshinweise 2026 zur CRA

Die Meldepflicht 2026 unabhängig von der Konformität 2027 behandeln

Die Cyberresilienz-Verordnung trat im Dezember 2024 in Kraft. Die Meldepflichten des Artikels 14 für Hersteller gelten seit dem 11. September 2026, während die Hauptanforderungen an Produkte grundsätzlich ab dem 11. Dezember 2027 gelten. Nach Darstellung der Kommission erfassen Meldungen auch Produkte mit digitalen Elementen, die bereits vor 2027 auf dem EU-Markt verfügbar waren. Warten Sie also nicht auf ein späteres CE-Kennzeichnungsprojekt, bevor Sie Meldezugang und Verantwortliche einrichten. Umgekehrt sollte das Unternehmen nicht behaupten, ein altes Produkt habe schon die vollständige CRA-Konformitätsbewertung durchlaufen, nur weil sein Sicherheitsteam Vorfälle bearbeitet. Halten Sie beide Stufen getrennt im Projektplan.

Eine aktiv ausgenutzte Schwachstelle ist nicht jede theoretische Schwäche aus einem automatisierten Scan. Ein schwerwiegender Vorfall ist nicht jedes kleine Support-Ticket. Richten Sie die Triage an den gesetzlichen Definitionen und den tatsächlichen Auswirkungen auf die Produktsicherheit aus. Artikel 14 verlangt eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung und eine weitere Meldung innerhalb von 72 Stunden; die Fristen für Abschlussberichte unterscheiden sich je nach Vorfallart. Ein allgemeines Antwortversprechen an Kunden oder eine monatliche Besprechung von Schwachstellen hält diese Uhr nicht an. Erstellen Sie Beurteilungskriterien, einen rund um die Uhr erreichbaren Meldeweg und einen Vermerk, wann das Team erstmals belastbare Kenntnis hatte.

Für Open-Source-Software-Stewards beginnt die entsprechende Pflicht nach Artikel 24 Absatz 3 erst am 11. Dezember 2027. Wenden Sie die aktuelle Herstellerfrist nicht allein deshalb auf eine Organisation an, weil sie Code in einem öffentlichen Repository veröffentlicht. Prüfen Sie ihre rechtliche Rolle und ob ein Produkt kommerziell auf dem Markt bereitgestellt wird. Pflegen Sie eine datierte Matrix mit Produkt, Hersteller oder anderer Rolle, EU-Verfügbarkeit, Beginn jeder Pflicht und Vorfallkontakt. Nach einem neuen Release, einer geänderten Lizenz oder einem neuen Geschäftsmodell muss diese Matrix überprüft werden. Ein einmaliges Gründungsmemo ist keine ausreichende Grundlage für laufende Meldeentscheidungen.

Rechtsgrundlage und Hinweise: Verordnung (EU) 2024/2847, Cyberresilienz-Verordnung, Artikel 2, 3, 13, 14, 71 und Anhänge I–IV; Europäische Kommission: CRA-Meldepflichten; ENISA: zentrale CRA-Meldeplattform; Europäische Kommission: Zusammenfassung der Cyberresilienz-Verordnung

Den ENISA-Meldeweg vor einem Notfall einüben

Die zentrale CRA-Meldeplattform der ENISA ist seit dem 11. September 2026 in Betrieb. Der Hersteller übermittelt dort eine Meldung an den zuständigen CSIRT-Koordinator; die Daten werden nach den Regeln der Verordnung auch ENISA und weiteren zuständigen Stellen zugänglich. Prüfen Sie für einen zyprischen Hersteller die aktuellen Angaben zum Koordinator und die Hinweise der Plattform, statt ungeprüft eine frühere Incident-E-Mail-Adresse zu verwenden. Registrieren Sie eine zugewiesene vertretungsberechtigte Person und eine Stellvertretung. Testen Sie Anmeldung, Mehrfaktorauthentifizierung und Zugriff außerhalb der Bürozeiten. Ein Vorfall am Wochenende darf nicht an einem einzigen abwesenden Kontoinhaber oder abgelaufenen Zugangsdaten scheitern.

Die erste Nachricht darf auf den früh verfügbaren Informationen beruhen; sie muss nicht bis zum Abschluss der Ursachenanalyse warten. Erfassen Sie Zeitpunkt der Kenntnis, betroffenes Produkt und Versionen, Hinweise auf aktive Ausnutzung oder Schwere, bekannten Schaden, Sofortmaßnahmen und offene Fragen. Die Kommission beschreibt eine Frühwarnung innerhalb von 24 Stunden und eine ausführlichere Mitteilung innerhalb von 72 Stunden. Bei aktiv ausgenutzter Schwachstelle folgt der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme; bei schwerwiegendem Vorfall innerhalb eines Monats nach der 72-Stunden-Meldung. Bewahren Sie Zeitachse, eingereichte Inhalte, Empfangsbestätigungen und interne Freigaben auf. Aktualisierungen dürfen ursprüngliche Unsicherheiten transparent berichtigen.

Parallelmeldungen sind gesondert zu entscheiden. Die CRA kann Information betroffener Nutzer zu einer aktiv ausgenutzten Schwachstelle oder einem schweren Vorfall verlangen. Enthält das Ereignis personenbezogene Daten, ist ein eigener Test der Meldepflichten nach der DSGVO nötig; regulierte Kunden oder Verträge können weitere Fristen setzen. Nutzen Sie einen gemeinsamen Vorfallsdatensatz mit getrennten Uhren, Empfängern und Textverantwortlichen. Eine CRA-Einreichung erfüllt nicht automatisch eine Datenschutzmeldung. ENISA stellt aktuelle FAQ und Bedienungsanleitungen für die Plattform bereit; prüfen Sie diese nach größeren Änderungen. Eine Übung sollte Wochenendbetrieb, eine verwundbare Cloudkomponente und einen fehlgeschlagenen Vertreter-Login enthalten, damit die Schwachstelle im Prozess vor einem echten Vorfall sichtbar wird.

Weiterführend: DSGVO-Leitfaden für Datenschutzvorfälle.

Rechtsgrundlage und Hinweise: Verordnung (EU) 2024/2847, Cyberresilienz-Verordnung, Artikel 2, 3, 13, 14, 71 und Anhänge I–IV; Europäische Kommission: CRA-Meldepflichten; ENISA: zentrale CRA-Meldeplattform; ENISA: Anleitung zur zugewiesenen Vertreterperson; Verordnung (EU) 2016/679, DSGVO, Artikel 33 und 34

Anhang I in konkrete Sicherheitsarbeit übersetzen

Anhang I verbindet Anforderungen an Sicherheitseigenschaften des Produkts mit dem Umgang mit Schwachstellen während seiner Unterstützungsdauer. Artikel 13 verlangt eine Cybersicherheitsrisikobewertung, die Gestaltung, Entwicklung, Herstellung und Wartung steuert. Beginnen Sie mit beabsichtigter Nutzung, vorhersehbarem Fehlgebrauch, Angriffsflächen und Folgen einer Kompromittierung. Leiten Sie daraus Freigabekriterien ab: geeignete sichere Voreinstellungen, Zugriffskontrolle, verringerte Angriffsfläche, Schutz von Vertraulichkeit und Integrität, Verfügbarkeit und Sicherheitsupdates. Ein allgemeines Zertifikat über einen Penetrationstest erklärt nicht, wie verschiedene Versionen und Komponenten die jeweils anwendbaren Anforderungen erfüllen. Hinterlegen Sie Entscheidungen und Testergebnisse beim tatsächlichen Release statt bei einer idealisierten Architekturfolie.

Errichten Sie ein belastbares Verfahren für Abhängigkeiten und Sicherheitslücken. Das Team muss wissen, welche fremden und quelloffenen Komponenten in welcher ausgelieferten Version stecken, wie ein Fix geprüft wird und wer ein Update ausliefern darf. Definieren Sie einen Eingang für Schwachstellenmeldungen, Verantwortliche für Triage, abgestimmte Offenlegung und Nachweise der Behebung. Die CRA verlangt Sorgfalt beim Einbau von Komponenten und wirksamen Umgang mit Schwachstellen; die technische Dokumentation muss diese Schritte nachvollziehbar machen. Ein maschinenlesbares Komponentenverzeichnis hilft organisatorisch, beweist aber allein nicht alle Anforderungen des Anhangs I. Prüfen Sie auch Wartbarkeit von Signaturschlüsseln und Lieferkette, nicht nur Quellcodeanalysen.

Setzen Sie Kontrollen risikobezogen um, statt für jede Funktion dieselbe Maßnahme zu behaupten. Ein lokales Hilfsprogramm und eine Fernverwaltungssoftware können unterschiedliche Anforderungen an Authentifizierung, Protokollierung, Abschottung und Tests haben. Die Bewertung soll diese Unterschiede begründen und bei Änderungen der Bedrohungslage oder Architektur aktualisiert werden. Beziehen Sie einen entfernten Dienst ein, der für eine Produktfunktion notwendig ist. Testen Sie Auslieferung und Rücknahme von Updates: ein nur auf Papier geregelter Patchprozess kann im Ernstfall einen Ausfall verursachen. Sichern Sie die Nachweise je Produktversion, damit die spätere Konformitätsakte zum tatsächlich vertriebenen Code passt.

Weiterführend: DSGVO-Compliance-Leitfaden.

Rechtsgrundlage und Hinweise: Verordnung (EU) 2024/2847, Cyberresilienz-Verordnung, Artikel 2, 3, 13, 14, 71 und Anhänge I–IV; Europäische Kommission: Zusammenfassung der Cyberresilienz-Verordnung; Europäische Kommission: Umsetzungshinweise 2026 zur CRA

Unterstützungsdauer und Nutzerinformationen belastbar festlegen

Nach Artikel 13 legt der Hersteller die Unterstützungsdauer anhand der erwarteten Nutzung des Produkts, vernünftiger Nutzererwartungen und weiterer Faktoren der Verordnung fest. Sie beträgt grundsätzlich mindestens fünf Jahre; bei einer tatsächlich kürzeren zu erwartenden Produktlebensdauer kann sie dieser entsprechen. Machen Sie aus der Ausnahme keinen Automatismus für Jahresabonnements, ohne zu prüfen, ob das Produkt oder seine Version wirklich nicht länger verwendet wird. Ein langlebiges Netzwerkgerät oder Desktopwerkzeug kann eine noch längere Betreuung verlangen. Dokumentieren Sie Annahmen, Vergleichsprodukte, typische Nutzung und Entscheidung für jede Produktfamilie. Vertragslaufzeit und technische Lebensdauer sind nicht zwangsläufig dieselbe Größe.

Planen Sie Personal und Mittel für die gesamte Zusage: Überwachung von Schwachstellen, Aktualisierung von Komponenten, Signaturschlüssel, Update-Infrastruktur, Nutzerkommunikation und Vertretung bei Personalwechsel. Ein heute günstig verkauftes Produkt kann später erhebliche Wartungskosten erzeugen. Nennen Sie das Ende der Unterstützungsdauer mit Monat und Jahr beim Kauf klar und verständlich, wie die Kommission erläutert. Verstecken Sie die Angabe nicht in einer widersprüchlichen Hilfeseite. Nutzt ein Kunde das Produkt in einem regulierten Dienst, muss er seine eigenen Risiken und Wechselmöglichkeiten einschätzen können. Teilen Sie wesentliche Grenzen der Wartung frühzeitig und konsistent mit.

Die Nutzeranweisungen nach Anhang II müssen sichere Installation, Betrieb und Verwendung ermöglichen. Dokumentieren Sie Updateweg, Meldestelle für Schwachstellen, unterstützte Versionen und erhebliche Abhängigkeiten. Prüfen Sie mit einem realen Nutzer, ob er einen Patch findet und den Zeitpunkt des Supportendes versteht. Bei einem kritischen Sicherheitsupdate sollte die Nachricht betroffene Versionen benennen, ohne unnötig Angriffsdetails zu verbreiten. Dokumentation und tatsächliches Releaseverhalten müssen übereinstimmen. Eine Behauptung über automatische Updates ist irreführend, wenn ein Teil der installierten Kunden auf verwundbaren Versionen bleibt und keine Warnung erhält. Ein öffentlicher Versionsplan hilft nur, wenn das Team ihn auch pflegt.

Rechtsgrundlage und Hinweise: Verordnung (EU) 2024/2847, Cyberresilienz-Verordnung, Artikel 2, 3, 13, 14, 71 und Anhänge I–IV; Europäische Kommission: Zusammenfassung der Cyberresilienz-Verordnung; Europäische Kommission: Umsetzungshinweise 2026 zur CRA

Den Konformitätsweg für 2027 rechtzeitig vorbereiten

Für ein Produkt, auf das die Hauptpflichten Anwendung finden, muss der Hersteller die Konformität bewerten, technische Unterlagen erstellen, eine EU-Konformitätserklärung ausstellen und vor der Bereitstellung die CE-Kennzeichnung anbringen. Die Akte sollte Risikobewertung, Sicherheitsanforderungen, Entwurfsentscheidungen, Tests, Schwachstellenbehandlung und Anweisungen mit einer konkreten Produktversion verbinden. Eine Werbeaussage „CRA-konform“ ist keine Bewertung. Geben Sie dem Produktteam die Verantwortung, Nachweise während der Entwicklung zu sammeln. Monate von Architekturentscheidungen erst kurz vor Dezember 2027 aus Erinnerungen zu rekonstruieren, ist teuer und unsicher. Legen Sie für jede Version eine Freigabeentscheidung mit Dokumentenstand und Unterzeichner ab.

Das einschlägige Verfahren hängt von der Produktkategorie sowie verfügbaren harmonisierten Normen oder Zertifizierungssystemen ab. Laut Kommission können gewöhnliche Produkte im Allgemeinen interne Kontrolle nutzen. Produkte mit Kernfunktionen wichtiger oder kritischer Kategorien der Anhänge III und IV können einen anderen Weg erfordern. Nehmen Sie nicht an, irgendein Cybersicherheitszertifikat, SOC-Bericht oder Lieferantenversprechen sei bereits das gesetzliche Verfahren. Prüfen Sie geltende delegierte Rechtsakte zur Kategorisierung und tatsächlich im EU-System referenzierte Normen. Dokumentieren Sie, warum das konkrete Produkt der gewählten Kategorie angehört und wer die abschließende Erklärung unterzeichnet. Bei Zweifeln vor Markteinführung fachlichen Rat einholen.

Behandeln Sie ältere Produkte genau. Nach Kommissionsdarstellung können Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, bei einer wesentlichen Änderung ab diesem Datum unter den allgemeinen CRA-Rahmen fallen. Die Meldepflicht betrifft derweil schon verfügbare Produkte. Eine neue Hauptversion kann neue Prüfungen zu Anwendungsbereich und Konformität verlangen; ein gewöhnlicher Sicherheitspatch ist nicht automatisch wesentlich. Führen Sie einen Releasevermerk zu Sicherheitswirkung, Produktidentität und geänderten Funktionen. Das verhindert unnötige Neueinstufung ebenso wie den gegenteiligen Fehler, eine stark veränderte Version mit veralteter Dokumentation auszuliefern. Der Vermerk sollte vor, nicht nach der Vertriebsfreigabe entstehen.

Weiterführend: Leitfaden zur Barrierefreiheit im E-Commerce.

Rechtsgrundlage und Hinweise: Verordnung (EU) 2024/2847, Cyberresilienz-Verordnung, Artikel 2, 3, 13, 14, 71 und Anhänge I–IV; Europäische Kommission: Zusammenfassung der Cyberresilienz-Verordnung; Europäische Kommission: Umsetzungshinweise 2026 zur CRA

Drei praktische Starttests mit Nachweisen durchführen

Prüfen Sie zunächst zwei echte Angebote: eine installierbare Anwendung, die eine eigene Unternehmens-API aufruft, und ein getrenntes reines Cloud-Abonnement. Schreiben Sie auf, warum jedes Angebot die Produkt- und Remote-Verarbeitungsdefinition erfüllt oder nicht. Benennen Sie Hersteller sowie mögliche Importeure oder Händler. Simulieren Sie dann eine Schwachstelle in einer Abhängigkeit einer bereits im Vorjahr verkauften Version. Kann das Team betroffene Produkte ermitteln, aktive Ausnutzung bewerten, den Beginn der Artikel-14-Frist festlegen und sich bei ENISA anmelden? Ein alter Verkaufstermin beseitigt die heutige Meldepflicht nicht automatisch. Halten Sie Ergebnis und offene Entscheidung schriftlich fest.

Prüfen Sie die Wartungszusage an einem Produkt mit voraussichtlich mindestens fünfjähriger Nutzung. Welche Updates, Mitarbeiter, Schlüssel und Infrastruktur sind für diesen Zeitraum nötig? Kann der Käufer das Ende der Unterstützungsdauer erkennen und eine Sicherheitskorrektur erhalten? Kann das Team eine ausgelieferte Drittkomponente bis zu ihrer Version und dem Fix zurückverfolgen? Falls alles vom Gedächtnis eines einzelnen Entwicklers oder einem Lieferanten ohne Reaktionspflicht abhängt, verbessern Sie die Abläufe vor Marktausweitung. Geben Sie jedem Befund einen Eigentümer und ein Datum. Eine reine Richtlinie als PDF beweist weder die Fähigkeit zum Patchen noch die Nutzerinformation bei einem Problem.

Testen Sie zuletzt die 2027er Konformitätsakte an einem realen Releasekandidaten: Anwendungsbereich, Risikobewertung, Nachweise zu Anhang I, Komponentenprüfung, Nutzeranweisungen, Unterstützungsdauer, zutreffendes Bewertungsverfahren und Verantwortlichen für die Erklärung. Schließen Sie Lücken vor der Veröffentlichung, statt unbelegte Websiteversprechen zu ergänzen. Prüfen Sie Materialien von Kommission und ENISA bei jedem Meilenstein erneut; gestufte Anwendungsdaten, delegierte Rechtsakte und Plattformanweisungen machen statische Checklisten anfällig. Eine belastbare Akte zeigt zugleich, welche Schlussfolgerung das Unternehmen gezogen hat und was das Produkt tatsächlich tut.

Rechtsgrundlage und Hinweise: Verordnung (EU) 2024/2847, Cyberresilienz-Verordnung, Artikel 2, 3, 13, 14, 71 und Anhänge I–IV; Europäische Kommission: Zusammenfassung der Cyberresilienz-Verordnung; Europäische Kommission: CRA-Meldepflichten; ENISA: zentrale CRA-Meldeplattform

Primärquellen und Geltungsbereich

Quellenabgleich: 7. Oktober 2026. Dieser Leitfaden bezieht sich auf die Republik Zypern. Beispiele sind hypothetisch und keine Kundenfälle. Prüfen Sie vor einer Einreichung die aktuellen amtlichen Anforderungen.

• Verordnung (EU) 2024/2847, Cyberresilienz-Verordnung, Artikel 2, 3, 13, 14, 71 und Anhänge I–IV
• Europäische Kommission: Zusammenfassung der Cyberresilienz-Verordnung
• Europäische Kommission: CRA-Meldepflichten
• Europäische Kommission: Umsetzungshinweise 2026 zur CRA
• ENISA: zentrale CRA-Meldeplattform
• ENISA: Anleitung zur zugewiesenen Vertreterperson
• Verordnung (EU) 2016/679, DSGVO, Artikel 33 und 34

Praktische Leitfäden zu diesem Thema

• NIS2 in Zypern: wesentliche und wichtige Einrichtungen richtig einordnen

  Prüfen Sie den NIS2-Anwendungsbereich nach zyprischem Recht: Sektor, Unternehmensgröße, Ausnahmen, Einstufung, Behördenkontakt und Sechs-Stunden-Frist.