CRA-Meldepflicht in der Praxis: 24 Stunden, Meldeplattform und interner Prozess

Die Meldepflichten des Cyber Resilience Act sind keine Zukunftsmusik mehr: Seit dem 11. September 2026 muss jeder Hersteller von Produkten mit digitalen Elementen eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden melden. Die Frist läuft auch über das Wochenende, und viele Mittelständler haben dafür weder eine Rufbereitschaft noch einen eingeübten Ablauf. Dieser Artikel ergänzt den Grundlagenartikel um die Praxis: was du wann meldest, wo du es meldest und wie du den Prozess in deinem Unternehmen aufbaust.

Was gilt seit dem 11. September 2026?

Der CRA ist die Verordnung (EU) 2024/2847 und gilt gestaffelt. Für die Meldepflicht sind drei Daten wichtig:

Das ist der Punkt, an dem Hersteller oft stolpern: Die Meldepflicht ist die erste Pflicht des CRA, die dich tatsächlich trifft, und sie gilt unabhängig davon, ob dein Produkt schon CRA-konform ist. Nach übereinstimmenden Angaben mehrerer Fachquellen gilt sie auch für Produkte, die schon im Markt sind. Du kannst also nicht warten, bis du dein Produktportfolio bis Ende 2027 angepasst hast.

Wer die Meldung abgeben muss, ist der Hersteller. Importeure und Händler informieren den Hersteller, wenn sie von einer Schwachstelle erfahren, und melden nicht selbst. Verantwortliche von Open-Source-Projekten (sogenannte Stewards) werden auf der Plattform erst ab dem 11. Dezember 2027 geführt.

Was musst du melden? Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle

Der CRA kennt zwei Auslöser. Nicht jede Schwachstelle und nicht jeder Vorfall gehört dazu.

Aktiv ausgenutzte Schwachstelle

Gemeint ist eine Schwachstelle, für die es belastbare Belege gibt, dass ein böswilliger Akteur sie in einem System ohne Erlaubnis des Systemeigners ausgenutzt hat. So steht es in der Definition des Artikels 3 Nummer 42. Das BSI verlangt dafür nach eigener Darstellung glaubhafte Hinweise auf tatsächliche Ausnutzung in realen Systemen. Ein veröffentlichter Exploit oder ein Proof of Concept allein reicht nicht aus.

Zwei Folgen für die Praxis:

• Eine neu gefundene Schwachstelle ohne Ausnutzung ist kein Meldefall nach Artikel 14. Sie läuft weiter durch dein normales Schwachstellenmanagement, also Bewertung, Korrektur und koordinierte Offenlegung.
• Der Wortlaut verlangt nicht, dass der Angriff gegen dein eigenes Produkt lief. Wenn eine Komponente in deinem Produkt eine Schwachstelle hat, die irgendwo ausgenutzt wird, solltest du den Fall bewusst entscheiden und die Entscheidung dokumentieren. Das ist unsere Auslegung des Wortlauts, kein Behördenstandpunkt.

Schwerwiegender Sicherheitsvorfall

Ein Vorfall ist schwerwiegend, wenn er die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen des Produkts beeinträchtigt oder wenn er das Einschleusen oder Ausführen von Schadcode ermöglicht. Der Vorfall muss sich auf die Sicherheit des Produkts auswirken. Das BSI nennt dazu ein Beispiel: Ransomware im Netz des Herstellers ist nicht automatisch meldepflichtig nach dem CRA, solange das Produkt selbst nicht betroffen ist.

Anders sieht es aus, wenn ein Angreifer deine Build-Pipeline übernimmt und manipulierte Firmware ausliefert. Dann geht es um die Sicherheit des Produkts, und das ist der typische Fall, der bei Supply-Chain-Angriffen auf Hersteller zukommt.

Der Zeitstrahl: 24 Stunden, 72 Stunden, Abschlussbericht

Die Meldung läuft in drei Stufen. Die ersten beiden Fristen laufen ab dem Zeitpunkt, an dem du Kenntnis erlangst. Die dritte hängt vom Fall ab.

Die Frühwarnung ist bewusst dünn gehalten. Du sollst in 24 Stunden das Signal geben, nicht die Analyse abgeben. Die Meldung auf der Plattform lässt sich laut BSI bis zum Abschluss fortschreiben, bereits erfasste Angaben werden in die nächste Stufe übernommen.

Wann beginnt die Uhr?

Mit Kenntnis. Das ist der Satz, an dem sich in der Praxis alles entscheidet, denn es ist nicht der Zeitpunkt, an dem ein Ticket zugewiesen wird oder jemand Zeit hat. Wer morgens um 9 Uhr eine belastbare Information in einem Postfach hat und erst am Montag hineinschaut, hat die Zeit trotzdem verbraucht. Lege intern fest, ab welcher Information du von "Kenntnis" ausgehst, und halte den Zeitpunkt im Ticket fest. Als Vorschlag: Der Zeitpunkt, zu dem ein Mitglied des Triage-Teams die Belege gesehen und als belastbar eingestuft hat, wird als Kenntnis dokumentiert. Bis dahin muss die Triage selbst aber schnell sein, sonst entsteht der Eindruck, du hättest den Start der Uhr hinausgezögert.

Und die Nutzer?

Neben der Meldung an die Behörden musst du die betroffenen Nutzer informieren, und zwar über die Schwachstelle oder den Vorfall und über die Maßnahmen, mit denen sie sich schützen können. Wenn du das nicht rechtzeitig tust, können die CSIRTs diese Information selbst an Nutzer geben. Plane die Kundeninformation deshalb als eigenen Strang im Prozess ein und nicht als Fußnote.

Was passiert bei einem Verstoß?

Der CRA sieht für Verstöße gegen die Pflichten Bußgelder vor, die in den bekannten Spannen bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes reichen. Kleinst- und Kleinunternehmen werden für eine versäumte 24-Stunden-Frühwarnung nicht mit einem Bußgeld belegt, die Pflicht zu melden bleibt aber bestehen. Ein Unternehmen mit 100 Mitarbeitenden gilt als mittleres Unternehmen und hat diese Erleichterung nicht.

Wo meldest du? Die Single Reporting Platform

Es gibt nur einen Meldeweg: die Single Reporting Platform (CRA-SRP) der ENISA, der EU-Agentur für Cybersicherheit. Sie ist seit dem 11. September 2026 unter portal.cra-srp.enisa.europa.eu erreichbar. Du meldest einmal, die Plattform verteilt die Meldung an das koordinierende CSIRT und an die ENISA.

Welches CSIRT ist zuständig?

Bei Herstellern mit Hauptniederlassung in der EU ist es das CSIRT des Mitgliedstaats, in dem die wesentlichen Entscheidungen zur Cybersicherheit getroffen werden. Für Hersteller ohne Niederlassung in der EU gilt eine Reihenfolge über den Bevollmächtigten, den Importeur und den Händler bis hin zum Mitgliedstaat mit den meisten Nutzern. In Deutschland ist das koordinierende CSIRT das CERT-Bund im BSI. Das BSI führt zusätzlich die Marktüberwachung für den CRA.

Registrierung und Zugang

Laut BSI musst du dich nicht vorab registrieren, Registrierung und Abgabe einer Meldung sollen in wenigen Minuten möglich sein. Beim ersten Mal läuft das so: Du wählst die Rolle als Assigned Representative, wählst Land und koordinierendes CSIRT, meldest dich mit einem EU-Login an, akzeptierst die Nutzungsbedingungen, prüfst die vorausgefüllten Angaben und trägst die Herstellerdaten ein. Weitere Vertreter lädst du ein. Die Formulare sind laut BSI in englischer Sprache.

Verlass dich nicht darauf, dass sich das im Ernstfall nebenbei erledigt. Wenn die Frühwarnung um 3 Uhr nachts fällig wird, ist der Moment schlecht, um zum ersten Mal einen EU-Login zu beantragen. Richte den Zugang jetzt ein, mit einem primären und einem sekundären Vertreter, und teste ihn einmal mit allen Beteiligten.

Was, wenn die Plattform nicht erreichbar ist?

Das BSI nennt als Rückfall die E-Mail direkt an das CERT-Bund. Halte die Kontaktdaten aus der BSI-Veröffentlichung offline verfügbar und prüfe sie regelmäßig. Die Plattform ist außerdem erst in einer ersten Betriebsstufe gestartet und wird nach Angaben der ENISA in den kommenden Monaten erweitert. Ob und wann es eine maschinenlesbare Schnittstelle für automatisierte Meldungen gibt, ist uns nicht bekannt. Plane deshalb mit manueller Eingabe.

Wie baust du den internen Prozess auf?

Eine Vorlage allein hilft nicht, wenn niemand weiß, wer sie ausfüllt. Der Prozess besteht aus fünf Bausteinen: Eingang, Triage, Entscheidung, Meldung und Dokumentation. Er lässt sich in einem Unternehmen mit 100 Mitarbeitenden ohne eigenes Sicherheitsteam betreiben. Du brauchst Rollen, keine Abteilung.

Der Eingang: Woher kommen die Informationen?

Hinweise auf Ausnutzung kommen aus mehr Quellen, als die meisten annehmen:

• die öffentliche Kontaktadresse für Schwachstellenmeldungen (security@ und eine security.txt auf der Website)
• der Kundensupport, wenn mehrere Kunden dasselbe Fehlerbild melden
• eigene Telemetrie und Monitoring der Cloud-Komponenten
• Sicherheitsforscher, Behörden und CSIRTs, die dich direkt ansprechen
• Händler und Importeure, die dich als Hersteller informieren
• Lieferanten, deren Komponenten in deinem Produkt stecken

Alle Kanäle müssen im selben Posteingang oder Ticketsystem landen und eine Alarmierung auslösen. Ein security@-Postfach, das am Freitagabend niemand liest, ist die häufigste Lücke.

Rollen: Wer macht was?

Die Rollen lassen sich auch mit wenigen Personen besetzen. Wichtig ist, dass jede Rolle eine Vertretung hat.

PSIRT steht für Product Security Incident Response Team und ist das, was in großen Konzernen ein eigenes Team ist. Bei dir ist es eine Funktion mit festen Namen. Der Unterschied zum internen IT-Sicherheitsvorfall liegt im Blickwinkel: Dein Incident Response Plan kümmert sich um die eigene IT, das PSIRT um das Produkt beim Kunden.

Ganz wichtig ist die Entscheidungsvollmacht. Wenn der Geschäftsführer im Urlaub ist und die Freigabe von ihm abhängt, ist die Frist weg, bevor er zurückruft. Lege vorab schriftlich fest, wer im Namen des Unternehmens die Frühwarnung freigeben darf.

24/7-Erreichbarkeit ohne Schichtbetrieb

Die Frist kennt kein Wochenende, aber du brauchst deshalb keinen Schichtbetrieb. Für den Mittelstand hat sich bewährt:

• Eine Rufbereitschaft mit drei Personen aus PSIRT-Koordination, Triage und Meldeverantwortlichem, die wochenweise rotiert.
• Eine Alarmierung, die vom security@-Postfach und vom Support-Ticketsystem ausgelöst wird, nicht nur eine E-Mail.
• Zugang zur Plattform für mindestens zwei Personen, beide mit getestetem EU-Login.
• Eine Vertretungsregel für Urlaub und Krankheit, die auch im Dienstplan sichtbar ist.

Kläre mit dem Betriebsrat, falls vorhanden, die Vergütung der Rufbereitschaft, bevor du sie einführst. Das gehört zu den Dingen, die später Zeit kosten, wenn man sie nicht früh anspricht.

Die Triage: Aktiv ausgenutzt, ja oder nein?

Die Triage ist der eigentliche Engpass. Sie muss in wenigen Stunden zu einer Entscheidung führen, damit die 24 Stunden für Freigabe und Meldung reichen. Als Richtwert zum Arbeiten: Plane für die Triage maximal vier bis sechs Stunden ab Eingang, den Rest für Freigabe und Plattform. Das ist unser Vorschlag, keine Vorgabe des CRA.

Für die Bewertung brauchst du schnell zu beantworten:

1. Welche Belege liegen vor (Logs, Telemetrie, Kundenvorfall, Bericht einer Behörde, Eintrag in einem Katalog bekannter ausgenutzter Schwachstellen)?
2. Handelt es sich um eine echte Ausnutzung durch einen Angreifer oder um einen Test, ein Pentest-Ergebnis oder einen Proof of Concept?
3. Welche Produkte und Versionen enthalten die betroffene Komponente? Hier entscheidet deine SBOM, ob die Antwort in zehn Minuten oder in zwei Tagen kommt.
4. In welchen Mitgliedstaaten ist das Produkt auf dem Markt?
5. Gibt es schon eine Korrektur oder eine Risikominderung?

Entscheidungsbaum in Textform

Hänge diesen Ablauf als Karte neben die Rufbereitschaft:

EINGANG: Hinweis auf Ausnutzung oder Vorfall (Kunde, Forscher, Monitoring, Behörde, Lieferant)

1. Betrifft es ein Produkt mit digitalen Elementen, das du in Verkehr gebracht hast?
   Nein -> kein CRA-Fall. Prüfe NIS2, DSGVO und Kundenvertrag (Schritt 6). Ende.
   Ja   -> weiter mit Schritt 2.

2. Geht es um eine Schwachstelle oder um einen Vorfall?
   Schwachstelle -> Schritt 3.
   Vorfall       -> Schritt 4.

3. Gibt es belastbare Belege, dass ein Angreifer die Schwachstelle ohne Erlaubnis
   des Systemeigners ausgenutzt hat?
   Nein -> normaler Schwachstellenprozess, Beobachtung, bei neuen Belegen neu bewerten.
           Gründe und Zeitpunkt der Entscheidung dokumentieren. Ende.
   Ja   -> MELDEPFLICHT. Kenntnis-Zeitpunkt festhalten. Weiter mit Schritt 5.

4. Beeinträchtigt der Vorfall Verfügbarkeit, Authentizität, Integrität oder
   Vertraulichkeit sensibler Daten oder Funktionen des Produkts, oder ermöglicht er
   Einschleusen oder Ausführen von Schadcode?
   Nein -> intern dokumentieren, NIS2 und DSGVO separat prüfen. Ende.
   Ja   -> MELDEPFLICHT (schwerwiegender Vorfall). Kenntnis festhalten. Schritt 5.

5. Frist starten und Meldung vorbereiten:
   - Entscheider informieren, Freigabe einholen.
   - Frühwarnung innerhalb von 24 Stunden über die Single Reporting Platform.
   - 72-Stunden-Meldung vorbereiten, Korrektur planen.
   - Kunden informieren, sobald es Schutzmaßnahmen gibt.

6. Parallel prüfen:
   - Sind personenbezogene Daten betroffen? -> DSGVO-Frist von 72 Stunden prüfen.
   - Bist du selbst NIS2-pflichtig und ist es ein erheblicher Vorfall? -> BSI-Meldung.
   - Verpflichten Kundenverträge zu schnelleren oder zusätzlichen Meldungen?

Bei knappen Belegen: melden und später aktualisieren. Eine dokumentierte
Zweiteinschätzung ist besser als eine versäumte Frist.

Das ist keine Rechtsberatung, klär Zweifelsfälle mit deiner Rechtsabteilung oder Kanzlei.

Die Frühwarnung: Vorlage

Die Plattform fragt die Angaben in Formularen ab. Du kannst aber vorab einen Text mit den Antworten vorbereiten und im Ernstfall nur noch ausfüllen. Da die Formulare in Englisch sind, bietet sich die Vorlage ebenfalls in Englisch an:

EARLY WARNING (Art. 14 CRA), within 24 hours

Report category:     Actively exploited vulnerability / Severe incident
Manufacturer:        [Company name, address, contact for PSIRT]
Affected product:    [Product name, versions, component if known]
Title:               [Short descriptive title, no exploit details]
Awareness:           [Date and time (UTC) you became aware]
Suspected unlawful or malicious act:  Yes / No / Unknown
Member States where the product is made available:  [List, e.g. DE, AT, FR]
Current status:      Under investigation. Detailed notification will follow within 72 hours.
Contact:             [Name, phone (24/7), e-mail]

Vermeide in der Frühwarnung technische Details zum Exploit. Das koordinierende CSIRT gibt die Meldung an die CSIRTs und Marktüberwachungsbehörden der betroffenen Mitgliedstaaten weiter. Schreib deshalb nur, was für die Einordnung nötig ist. In Ausnahmefällen kann das CSIRT die Weitergabe aus Sicherheitsgründen zeitweise zurückhalten, etwa bei laufender koordinierter Offenlegung.

In der 72-Stunden-Meldung ergänzt du Details zur Ausnutzung, zu den betroffenen Versionen, zu Korrekturen oder Risikominderungen und zu dem, was Nutzer tun können. Der Abschlussbericht beschreibt die Schwachstelle mit Schweregrad und Auswirkung, den Angreifer, soweit bekannt, und die bereitgestellte Sicherheitsaktualisierung.

Dokumentation: Was du festhältst

Behandle jede Meldung wie ein Auditobjekt. Wer am Ende nicht belegen kann, wann er Kenntnis hatte und wann er gemeldet hat, steht schlecht da, auch wenn er rechtzeitig war. Halte fest:

• Eingangszeitpunkt, Quelle und Belege
• Zeitpunkt der Kenntnis und wer ihn festgelegt hat
• Ergebnis der Triage mit Begründung, auch für Fälle ohne Meldung
• Zeitpunkt, Kanal und Referenznummer jeder Stufe der Meldung
• Freigabe durch die Entscheiderrolle, mit Name und Uhrzeit
• Kundeninformation mit Datum und Empfängerkreis
• Korrekturen einer Meldung, ohne den ursprünglichen Stand zu überschreiben

In ISMS Lite legst du dafür den Vorgang als Vorfall an und hältst Versandzeitpunkt, Kanal, Referenz und Nachweis der Meldung fest. Eine Korrektur erfasst du als Korrektur und überschreibst nicht den ersten Nachweis. So passt das zu dem, was Auditoren und Aufsichtsbehörden später sehen wollen.

Wie grenzt du die CRA-Meldung gegen NIS2, DSGVO und Kunden ab?

Ein Sicherheitsvorfall bei einem Hersteller kann bis zu vier Meldungen auslösen, mit jeweils eigenem Adressaten, eigener Frist und eigenem Auslöser. Das ist der Punkt, an dem Teams durcheinanderkommen.

Die Meldungen schließen sich nicht aus. Ein Beispiel: Ein Hersteller von Gebäudegateways entdeckt, dass Angreifer eine Schwachstelle in seiner Firmware ausnutzen und dabei auch Zugangsdaten auf Kundengeräten abgreifen. Das löst die CRA-Meldung aus, weil eine aktiv ausgenutzte Schwachstelle vorliegt. Ist der Hersteller selbst NIS2-pflichtig und sind seine eigenen Systeme betroffen, kommt die NIS2-Erstmeldung beim BSI hinzu. Werden personenbezogene Daten kompromittiert, folgt die Meldung einer Datenpanne an die Aufsichtsbehörde. Und die Kunden erwarten, je nach Vertrag, eigene Information.

Der Trugschluss ist, dass eine der Meldungen die anderen ersetzt. Das tut sie nicht. Aktuell musst du jede Meldung über ihren eigenen Kanal abgeben, und das BSI weist darauf hin, dass der Vorschlag der EU-Kommission zum Digital Omnibus einen gemeinsamen Meldeweg vorsieht, aber erst wirkt, wenn er verabschiedet ist. Bis dahin gilt: Eine CRA-Meldung erfüllt weder NIS2 noch DSGVO.

Praktisch heißt das für den Prozess: Der Meldeverantwortliche der CRA-Meldung klärt in Schritt 6 des Entscheidungsbaums immer die anderen Pflichten mit. Dieselben Fakten, derselbe Kenntnis-Zeitpunkt, getrennte Texte. Wenn die Texte inhaltlich auseinanderlaufen, fällt das spätestens beim Abgleich der Behörden auf.

Ein Fall durchgespielt

Nimm einen Hersteller mit 100 Mitarbeitenden, der Gateways für Gebäudetechnik samt Firmware und Cloud-Portal liefert.

Freitag, 17:40 Uhr. Der Support meldet, dass drei Kunden unabhängig voneinander unbekannte Konfigurationsänderungen auf ihren Gateways sehen. Die Rufbereitschaft wird alarmiert, der Triage-Engineer findet in den Logs Zugriffe, die auf eine Ausnutzung einer Schwachstelle in einer Bibliothek hindeuten. Um 19:10 Uhr stuft er die Belege als belastbar ein. Das ist der dokumentierte Kenntnis-Zeitpunkt.

Freitag, 20:30 Uhr. Die PSIRT-Koordination informiert die Geschäftsführung, die Freigabe kommt per Telefon. Die Meldeverantwortliche trägt die Frühwarnung auf der Plattform ein und reicht sie um 21:15 Uhr ein. Die Frist wäre am Samstag um 19:10 Uhr abgelaufen. Parallel prüft das Team, ob personenbezogene Daten betroffen sind (nein, nur Konfigurationsdaten) und ob die Firma als NIS2-Einrichtung meldet (nein).

Montag, 19:10 Uhr ist die Frist für die 72-Stunden-Meldung. Sie geht am Montagvormittag mit Versionsangaben, einer Risikominderung (Zugriff auf die Verwaltungsschnittstelle einschränken) und einer Handlungsanweisung für Kunden raus.

Mittwoch steht der Patch bereit und wird ausgeliefert. Ab dann läuft die Frist von 14 Tagen für den Abschlussbericht. Den Bericht legst du in ISMS Lite als Maßnahme mit Termin und Verantwortlichem an, dann taucht er unter Fristen und ToDos im Dashboard auf und geht nicht im Tagesgeschäft unter.

Der Fall zeigt, wo die Zeit verloren geht: nicht bei der Meldung selbst, sondern bei der Zeit zwischen Hinweis und Entscheidung.

Checkliste: CRA-Meldeprozess

Organisation

• PSIRT-Rollen mit Namen und Vertretung besetzt
• Entscheidungsvollmacht für die Frühwarnung schriftlich geregelt
• Rufbereitschaft für Wochenende und Feiertage eingerichtet
• Vertretung bei Urlaub und Krankheit im Dienstplan sichtbar
• Kontakt zum Betriebsrat oder zur Personalvertretung wegen Rufbereitschaft geklärt

Eingang und Triage

• Öffentliche Kontaktadresse für Schwachstellen (security@, security.txt) eingerichtet
• Alle Eingangskanäle lösen eine Alarmierung aus
• Kriterien für "belastbare Belege" schriftlich festgelegt
• Definition des Kenntnis-Zeitpunkts im Prozess festgelegt
• Aktuelle SBOM je Produkt und Version verfügbar
• Entscheidungsbaum an die Rufbereitschaft verteilt

Meldung

• Zugang zur Single Reporting Platform mit EU-Login eingerichtet und getestet
• Primärer und sekundärer Vertreter in der Plattform hinterlegt
• Vorlage für Frühwarnung, Meldung und Abschlussbericht abgestimmt
• Rückfall per E-Mail an das CERT-Bund bekannt, Kontaktdaten offline vorhanden
• Liste der Mitgliedstaaten, in denen jedes Produkt angeboten wird, aktuell

Abgrenzung und Kommunikation

• Prüfschritt für NIS2, DSGVO und Kundenverträge im Prozess verankert
• Vertragliche Meldefristen gegenüber Kunden erfasst
• Vorlage für Kundeninformation mit Schutzmaßnahmen vorbereitet
• Ansprechpartner für Kanzlei und Datenschutz benannt

Dokumentation und Übung

• Jeder Vorgang mit Zeitstempeln, Referenz und Nachweis dokumentiert
• Triage-Entscheidungen ohne Meldung ebenfalls dokumentiert
• Übung mit einem fiktiven Fall zum Wochenendbeginn durchgeführt
• Lessons Learned und Verbesserungen als Maßnahmen erfasst

Häufige Fehler bei der CRA-Meldepflicht

Die Plattform erst im Ernstfall einrichten. Wer um 3 Uhr nachts zum ersten Mal einen EU-Login anlegt und die Rollen klärt, verliert Stunden. Richte den Zugang vorab ein und teste ihn.

Die 24 Stunden mit Arbeitsstunden verwechseln. Die Frist läuft ab Kenntnis, auch Samstag und Sonntag. Ein Postfach, das am Freitagabend niemand liest, ist keine Erreichbarkeit.

Jede Schwachstelle als Meldefall behandeln. Der CRA verlangt keine Meldung jeder Schwachstelle. Nur belastbar ausgenutzte Schwachstellen und schwerwiegende Vorfälle lösen Artikel 14 aus. Wer alles meldet, überfordert das eigene Team und verwässert die Meldungen.

Annehmen, dass eine Meldung die anderen ersetzt. Die CRA-Meldung erfüllt weder NIS2 noch DSGVO noch Kundenverträge. Jede Pflicht hat ihren eigenen Kanal. Ohne einen gemeinsamen Prüfschritt wird eine davon vergessen.

Die Uhr nach hinten rücken. Wenn "Kenntnis" intern erst dann gilt, wenn der Chef zurückruft, wird die Dokumentation unglaubwürdig. Lege den Zeitpunkt nach nachvollziehbaren Kriterien fest und halte ihn sofort fest.

Fazit: Der Prozess entscheidet über die ersten 24 Stunden

Die Meldung selbst lässt sich laut BSI in wenigen Minuten abgeben, schwierig sind die Stunden davor: Hinweis erkennen, Belege bewerten, Freigabe einholen. Richte diese Woche den Plattformzugang ein, benenne die Rufbereitschaft und spiele mit deinem Team einen Fall am Freitagabend durch. Für die Grundlagen der Verordnung und die Pflichten ab Dezember 2027 findest du alles im Artikel zum Cyber Resilience Act.

Weiterführende Artikel

• Cyber Resilience Act: Neue Pflichten für Hersteller von Produkten mit digitalen Elementen
• Schwachstellenmanagement aufbauen: Scanner, Priorisierung und Patch-Workflow
• SBOM erstellen: Software-Stückliste nach CRA mit CycloneDX und SPDX
• Sicherheitsvorfälle kommunizieren: Intern, extern und an die Presse
• Secure Development Lifecycle (SDL): Sicherheit in den Entwicklungsprozess einbauen