CRA-Vorfallreaktion: Eigentümer, Fristen und Meldenachweise

Seit 11. September 2026 müssen Hersteller im CRA-Anwendungsbereich aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden, die sich auf die Sicherheit von Produkten mit digitalen Elementen auswirken. Die Frühwarnung ist innerhalb von 24 Stunden nach Kenntniserlangung und die vollständige Meldung innerhalb von 72 Stunden fällig.

Das größte operative Risiko ist nicht ein fehlendes Formular. Es sind ein nicht vereinbarter T0, fehlende Entscheidungsverantwortung und Vertretung, unzuverlässige Informationsquellen sowie eine fehlende Aufzeichnung darüber, warum ein Ereignis auf bestimmte Weise eingestuft wurde.

Der Meldezeitplan

Phase	Frist	Was zu kontrollieren ist
Kenntniserlangung	T0	Zeitstempel, Informationsquelle und empfangende Person
Frühwarnung	innerhalb von 24 h	Die in dieser Phase nach CRA/SRP erforderlichen Informationen
Vollständige Meldung	innerhalb von 72 h	Zusätzliche Informationen zum Ereignis und zu seinen Auswirkungen
Abschlussbericht — aktiv ausgenutzte Schwachstelle	spätestens 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme	Behebung und Ergebnis der Bearbeitung
Abschlussbericht — schwerwiegender Vorfall	innerhalb von 1 Monat nach der 72-Stunden-Meldung	Vorfallsverlauf, Auswirkungen, Maßnahmen und Ergebnis

Prüfen Sie immer die aktuellen Anweisungen der einheitlichen CRA-Meldeplattform. Operative Leitlinien und das Portal können sich schneller verändern als die Verordnung selbst.

Nicht jede Schwachstelle löst eine Meldung nach Artikel 14 aus

Der CRA bezieht sich auf eine aktiv ausgenutzte Schwachstelle, nicht auf jeden Befund eines Scanners. Ebenso ist „schwerwiegender Vorfall“ ein regulatorischer Begriff und kein Synonym für jedes Sicherheitsticket mit hoher Priorität.

Ein guter Ablauf trennt:

Erkennung oder Eingang von Informationen;
technische Ersteinschätzung;
Bewertung anhand regulatorischer Kriterien;
Entscheidung durch eine verantwortliche Person;
Vorbereitung der Meldung;
Einreichung über den richtigen Kanal;
Behebung, Nachverfolgung und Abschlussbericht.

Einen Befund ohne menschliche Genehmigung automatisch als „CRA-meldepflichtig“ zu kennzeichnen, schafft sowohl das Risiko falsch positiver Ergebnisse als auch das Risiko versäumter Meldungen.

Legen Sie die Verantwortung fest, bevor die Frist beginnt

Eine Rolle namens „Sicherheitsteam“ reicht nicht aus. Bestimmen Sie für jedes Produkt:

wer Informationen zu Schwachstellen oder Vorfällen empfängt;
wer die technische Ersteinschätzung durchführt;
die produktverantwortliche Person;
wer die regulatorische Einstufung genehmigt;
wer über die SRP einreicht;
eine Vertretung für jede zeitkritische Rolle;
einen gegebenenfalls außerhalb der Arbeitszeiten erforderlichen Eskalationsweg, passend zu Produkt und Betriebsmodell.

Wenn eine Person mehrere Rollen innehat, halten Sie das ausdrücklich fest. Kleine Teams können funktionieren; unklare Zuständigkeit nicht.

Was bei T0 zu erfassen ist

Erstellen Sie die erste Aufzeichnung, bevor sich die Diskussion darauf verlagert, ob das Ereignis „wirklich schwerwiegend“ ist. Bewahren Sie mindestens auf:

den genauen Zeitpunkt der Kenntniserlangung;
die Informationsquelle;
Produkt und Fassung;
meldende Person oder Erkennungssystem;
eine kurze Beschreibung der Beobachtung;
die Person, die die Information erhalten hat;
eine Verknüpfung zum Quellartefakt oder Nachweis.

Ohne diese Aufzeichnung kann die Organisation einige Stunden später möglicherweise nicht mehr feststellen, wann die gesetzliche Frist tatsächlich begann.

Ein praktischer operativer Ablauf

1. Erfassen

Eröffnen Sie einen Fall und bewahren Sie die ursprüngliche Meldung auf. Überschreiben Sie die Quelle nicht, während sich das Verständnis weiterentwickelt.

2. Ersteinschätzung

Bestätigen Sie betroffenes Produkt, Fassung, technischen Umfang, bekannte Auswirkungen und verfügbare Nachweise. Trennen Sie bestätigte Tatsachen von Hypothesen.

3. Einstufen

Dokumentieren Sie die Gründe für und gegen eine Meldepflicht. Die Entscheidung sollte die genehmigende Person und den Genehmigungszeitpunkt benennen.

4. Die 24-Stunden-Frühwarnung einreichen

Bereiten Sie die Frühwarnung anhand der zu diesem Zeitpunkt verfügbaren Informationen vor. Warten Sie nicht auf eine abgeschlossene Ursachenanalyse, wenn die gesetzliche Frist bereits läuft.

5. Die 72-Stunden-Meldung einreichen

Vervollständigen Sie die nach dem aktuellen SRP-Verfahren erforderlichen Informationen.

6. Beheben und kommunizieren

Verbinden Sie Entwicklungsarbeit, Releases, Sicherheitsupdates und Kundenkommunikation mit demselben Fall.

7. Den Abschlussbericht fertigstellen

Schließen Sie den Ablauf erst ab, wenn Ergebnis, Maßnahmen, Prüfnachweise und der erforderliche Abschlussbericht dokumentiert sind.

Üben Sie den Prozess vor einem echten Ereignis

Verwenden Sie ein realistisches, aber hypothetisches Szenario und prüfen Sie:

Das Team weiß, wo die Aufzeichnung angelegt wird.
T0 lässt sich bestimmen.
Die genehmigende Person ist bekannt.
Eine Vertretung ist vorhanden.
Produkt- und Protokolldaten können schnell gesammelt werden.
Die einreichende Person hat einen funktionierenden SRP-Zugang.
Die Übung hinterlässt eine Entscheidungsaufzeichnung und Verbesserungsmaßnahmen.

Die Kenntniserlangung unter Zeitdruck nachvollziehbar machen

Die folgenden Methoden sind praktische Empfehlungen für den Hersteller. Maßgeblich bleiben Artikel 14 und die aktuellen Anweisungen der SRP. Erfassen Sie Eingang, erste technische Bewertung und Entscheidung getrennt. Diese Zeitpunkte beantworten unterschiedliche Fragen. Der Eingang im überwachten Sicherheitspostfach, eine spätere Bestätigung durch die Entwicklung und eine Freigabebesprechung dürfen nicht zu einem einzigen Datum „Vorfall eröffnet“ zusammengezogen werden. Das würde die Unsicherheit über die Kenntniserlangung verdecken, statt sie zu bearbeiten.

Verwenden Sie Zeitstempel mit Zeitzone oder UTC-Abweichung. Ein Team kann in mehreren Ländern arbeiten, und eine Zeitumstellung kann lokale Uhrzeiten mehrdeutig machen. Bewahren Sie den ursprünglichen Zeitstempel neben einer vereinheitlichten Anzeige auf. Bestehen unterschiedliche Einschätzungen zum Beginn der Frist, dokumentieren Sie Tatsachen, rechtliche Bewertung und entscheidende Person. Ein interner Freigabeprozess setzt eine gesetzliche Frist nicht einfach neu in Gang, weil die genehmigende Person zunächst nicht erreichbar war.

Legen Sie eine Fallkennung fest und verwenden Sie diese in technischer Abstimmung, Meldungsvorbereitung und Nachverfolgung. Bewahren Sie die ursprüngliche Nachricht, relevante Protokolle und die Quelle einer Aussage über aktive Ausnutzung auf. Neue Informationen können die Bewertung verändern. Ergänzen Sie diese Änderung mit Datum und Grundlage. Überschreiben Sie den ersten Eintrag nicht stillschweigend. So bleibt der Verlauf nachvollziehbar, ohne vollständige Kenntnis zum Zeitpunkt der ersten Nachricht vorzutäuschen.

Technische Schwere und regulatorische Bewertung unterscheiden

Die Bewertung eines Scanners kann technische Arbeiten priorisieren. Sie beantwortet aber nicht sämtliche Fragen des Artikels 14. Für eine aktiv ausgenutzte Schwachstelle gilt eine andere Meldegrundlage als für einen schwerwiegenden Vorfall mit Auswirkungen auf die Produktsicherheit. Dokumentieren Sie deshalb den geprüften Meldeweg, das betroffene Produkt und die Nachweise für die einschlägigen Kriterien. Eine einzige Farbe mit der Bezeichnung „kritisch“ verliert diese Unterschiede. Dadurch kann eine unnötige Meldung entstehen oder eine tatsächlich erforderliche Meldung ausbleiben.

Ein hypothetisches Beispiel zeigt die Abgrenzung. Ein Hersteller erhält eine Warnung zu einer schwerwiegenden Bibliotheksschwachstelle. Es liegen jedoch keine Nachweise einer aktiven Ausnutzung vor, und ein schwerwiegender Vorfall wurde nicht festgestellt. Der Befund braucht weiterhin geeignete Schwachstellenbehandlung und eine Bewertung der Produktauswirkung. Der hohe Scannerwert macht ihn nicht automatisch meldepflichtig. Gehen später glaubwürdige Informationen über Ausnutzung ein, erfasst das Team diese Informationen und prüft die Meldefrage unverzüglich erneut.

Eine unsichere Tatsache bleibt in der Aufzeichnung und in übermittelten Informationen als unsicher gekennzeichnet. Trennen Sie bestätigt betroffene, möglicherweise betroffene und noch nicht untersuchte Releases. Benennen Sie den benötigten Nachweis und eine zuständige Person. Das Warten auf vollständige Gewissheit kann die Frühwarnfrist verbrauchen. Erfundenes Wissen schafft ein anderes Problem: Behörden und Nutzer könnten ihre Maßnahmen auf eine falsche Beschreibung der Produktauswirkungen stützen. Beide Risiken müssen im Ablauf sichtbar bleiben.

Informationen vorbereiten, die einer Prüfung standhalten

Vereinbaren Sie vor einem Ereignis, wo Produktkennung, Release-Verlauf, Absatzmärkte und Kontakte zu finden sind. Die Person, die eine Meldung vorbereitet, sollte diese Tatsachen nicht aus Vertriebsnachrichten zusammensuchen müssen. Pflegen Sie eine knappe Produktaufzeichnung und prüfen Sie deren Verbindungen zu Architektur und Schwachstellenverfahren. Das ist eine Empfehlung zur zuverlässigen Vorbereitung. Damit wird keine gesetzliche Pflicht zu einem bestimmten Format eines internen Registers behauptet oder eine bestehende offizielle Meldevorgabe ersetzt.

Führen Sie im Fall getrennte Angaben für beobachtetes Ereignis, technischen Umfang, bekannte Auswirkungen, bereits ergriffene Maßnahmen und offene Prüfungen. Verknüpfen Sie wichtige Tatsachenaussagen mit ihren Quellen. Entwürfe erhalten Status und verantwortliche Person, damit eine Arbeitshypothese nicht als freigegebene Meldung behandelt wird. Die Freigabeprüfung kontrolliert neben der technischen Beschreibung auch Produktidentität, Fristgrundlage und die Unterscheidung zwischen gesicherten und noch vorläufigen Informationen. Das verhindert vermeidbare Widersprüche zwischen verschiedenen Beteiligten.

Bewahren Sie die eingereichte Fassung und den Nachweis der Einreichung gemeinsam mit dem Fall auf. Ein Entwurf im GRC-System beweist nicht, dass die Meldung den vorgeschriebenen Kanal erreicht hat. Dokumentieren Sie Empfangsbestätigung oder Referenz aus dem offiziellen Verfahren und den Einreichungszeitpunkt. Werden Informationen später berichtigt oder ergänzt, nennen Sie die zugehörige frühere Meldung. Dadurch bleiben die externe Meldefolge und die interne Entscheidungshistorie aufeinander bezogen, auch wenn unterschiedliche Personen die einzelnen Schritte ausführen.

Die Kommunikation mit Nutzern gezielt gestalten

Behördenmeldung und Nutzerinformation hängen zusammen, erfüllen aber verschiedene Aufgaben. Artikel 14 enthält auch Pflichten gegenüber betroffenen Nutzern. Prüfen Sie anhand der Verordnung und aktueller Leitlinien, was im konkreten Fall erforderlich ist. Die praktische Nachricht erklärt betroffenes Produkt, relevante Fassungen, verfügbare Korrektur- oder Minderungsmaßnahmen und die notwendige Nutzerhandlung. Eine Empfangsbestätigung des Meldeportals liefert diese Anweisung noch nicht an Kunden. Der Kommunikationsweg muss deshalb eigenständig geplant und im Fall dokumentiert werden.

Lassen Sie technische Anweisungen vor ihrer Veröffentlichung durch die Entwicklung prüfen. Ein falscher Umgehungsschritt kann eine wichtige Funktion unterbrechen oder eine weitere Schnittstelle öffnen. Die kommunikationsverantwortliche Person prüft, ob die Zielgruppe die Nachricht erreicht und erkennen kann, ob ihre Installation betroffen ist. Veröffentlichen Sie keine unnötigen Einzelheiten zur Ausnutzung in einem allgemeinen Hinweis. Die angemessene Tiefe hängt von Ereignis, Nutzergruppe und Stand der Behebung ab. Das Beispiel verlangt keine pauschale Geheimhaltung technischer Informationen.

Ordnen Sie jede Fassung der Nutzerinformation dem Fall zu. Ändert sich die Empfehlung, weil ein geprüftes Update verfügbar wird, dokumentieren Sie neue Anweisung und Übergang. Bei Vertrieb über Händler muss der Weg bis zu betroffenen Nutzern geklärt werden. Der Hersteller besitzt möglicherweise nicht sämtliche Endnutzeradressen. Diese Kommunikationskontrollen sind praktische Empfehlungen. Passen Sie sie an den tatsächlichen Vertriebsweg und die einschlägigen rechtlichen Anforderungen an, statt einfach eine allgemeine E-Mail an bekannte Vertriebskontakte als ausreichend anzusehen.

Einen Wochenendfall ohne echte Meldung üben

Verwenden Sie ein deutlich gekennzeichnetes hypothetisches Szenario. Eine glaubwürdige externe Meldung über aktive Ausnutzung eines unterstützten Produkts geht beispielsweise am späten Freitag ein. Die übliche Produktverantwortliche ist nicht erreichbar. Die Vertretung erfasst den Eingang, findet die Release-Aufzeichnung, erreicht die technische Prüfung und erstellt eine simulierte Frühwarnung. Senden Sie im Rahmen einer internen Übung keine erfundenen Ereignisse an die produktive Meldeplattform. Die Übung prüft interne Vorbereitung und Entscheidungswege, nicht die Belastbarkeit eines Behördenportals.

Messen Sie die Zeit für beeinflussbare Schritte: Produktunterlagen finden, Genehmigung erreichen, technische Informationen beschaffen und Entwurf zusammenstellen. Die Übung soll falsche Telefonnummern, fehlende Zugänge und unklare Eskalation zeigen. Das sind bearbeitbare Befunde. Ein Treffen, bei dem alle versprechen, im Ernstfall „schnell zu reagieren“, prüft diese Probleme nicht. Halten Sie die beobachteten Unterbrechungen und erforderlichen Verbesserungen mit Zuständigkeit und Termin fest. So entsteht aus dem Aufwand ein konkretes Ergebnis.

Wiederholen Sie die Übung mit fehlenden Informationen. Die Komponente ist bekannt, aber noch nicht alle ausgelieferten Fassungen sind bestätigt. Prüfen Sie, ob der Entwurf diese Unsicherheit korrekt beschreibt und ob jemand die Release-Zuordnung vervollständigt. Besprechen Sie auch, wie ergänzende Informationen über das offizielle Verfahren nachgereicht würden. Das Ziel ist ein geordneter Ablauf mit unvollständigen Tatsachen. Eine Simulation, die jede Antwort bereits in der Ausgangslage liefert, verdeckt die eigentliche Schwierigkeit der zeitgebundenen Entscheidung.

Behebung und Abschlussbericht miteinander verbinden

Bei einer aktiv ausgenutzten Schwachstelle hängt die Abschlussfrist von der Verfügbarkeit einer Korrekturmaßnahme ab. Erfassen Sie diesen Meilenstein und den Nachweis dafür. Er ist nicht einfach mit dem Schließdatum eines internen Tickets gleichzusetzen. Bei einem schwerwiegenden Vorfall gilt die oben dargestellte andere Frist. Die Fallaufzeichnung muss den einschlägigen Meldeweg tragen. Sonst kopieren Beteiligte möglicherweise den Zeitplan aus der falschen Vorlage und bemerken den Fehler erst beim nächsten Statusbericht.

Die Korrekturmaßnahme braucht eine zum Produkt passende Prüfung. Verknüpfen Sie Änderung, Release, Testergebnis und Verteilungsaufzeichnung. Ein erfolgreicher Build zeigt allein weder das korrigierte Sicherheitsverhalten noch die Erreichbarkeit des Updates für Nutzer. Handelt es sich nur um eine vorläufige Minderung, beschreiben Sie Grenzen und verbleibende Arbeit. Technischer Status und Meldebeschreibung müssen dieselbe Lage wiedergeben. Eine grüne Aufgabenanzeige darf nicht voraussetzen, dass eine noch ungeprüfte Maßnahme bereits zuverlässig funktioniert.

Unsere empfohlene Abschlussprüfung betrachtet Chronologie, eingereichte Fassungen, Nutzeranweisungen, Korrekturmaßnahmen, Prüfnachweise und notwendige Prozessänderungen. Benennen Sie verbleibende Aufgaben samt Zuständigkeit, statt sie im Status „gelöst“ zu verstecken. Nach einem Fall oder einer Übung werden Kontaktliste und Entscheidungsregeln dort geändert, wo ein tatsächlicher Fehler sichtbar wurde. Behalten Sie die Ausgangsfassung für die Nachvollziehbarkeit. So wächst ein wiederholbarer Meldeablauf aus beobachteter Arbeit und nicht allein aus der Veröffentlichung einer weiteren Richtlinie.

Die Rolle von Pulsar GRC

Pulsar kann den Vorfall oder die Schwachstelle mit Risiken, Maßnahmen, Verantwortlichen, Dokumenten, Nachweisen, Berichten und der Entscheidungshistorie verbinden. Risiken, Aufgaben, Dokumente, Nachweise und Berichte bewahren den Zusammenhang von Reaktionen und Entscheidungen.

Ihre Organisation bewertet, ob Artikel 14 anwendbar ist, genehmigt die Meldung und reicht sie über den passenden Kanal bei der SRP ein. Die Vorbereitung von Aufzeichnungen in Pulsar ersetzt nicht die Einreichung einer Meldung.

Pulsar GRC an einem operativen Ablauf ansehen

Üben Sie einen Vorfall ohne echte Meldung

Wählen Sie ein fiktives Produkt, von dem Ihre Übung annimmt, dass es im CRA-Bereich liegt. Wenn das Beispiel SaaS oder ein Backend umfasst, dokumentieren Sie, warum es für dieses Produkt relevant ist. Gehen Sie nicht davon aus, dass jeder reine Browserdienst unter CRA fällt. Verwenden Sie eine synthetische Benachrichtigung, die außerhalb der Bürozeiten eingeht, eine technische Feststellung und eine Entscheidung, die einen autorisierten Prüfer erfordert.

Notieren Sie, wann den Übungsteilnehmern der Sachverhalt bewusst wird, und unterscheiden Sie diesen Punkt vom Öffnen eines Tickets. Weisen Sie den Prüfer, den Entscheidungseigentümer und den Stellvertreter zu. Verfolgen Sie, welche Fakten feststehen und welche noch geprüft werden. Die Fristen gemäß Artikel 14 beziehen sich auf die geltenden Voraussetzungen der Kenntniserlangung und Meldung und nicht nur auf den Zeitpunkt, zu dem ein Manager den Antrag öffnet.

Halten Sie den Zweig „Aktiv ausgenutzte Schwachstelle“ getrennt vom Zweig „Schwerwiegender Vorfall“. Ihre Bedingungen für den Abschlussbericht unterscheiden sich: Der Schwachstellenbericht enthält eine Frist, die an die Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme gebunden ist, während die Meldeweg für schwerwiegende Vorfälle einen eigenen Zeitplan für den Abschlussbericht hat. Nutzen Sie den aktuellen Gesetzestext und die offiziellen Meldeleitlinien für den von Ihnen festgestellten Fall.

Bereiten Sie in Pulsar die Übungsmaßnahmen, Eigentümer, Fristen und synthetischen Beweise vor. Notieren Sie die Entscheidung des Prüfers und alle fehlenden Informationen. Überprüfen Sie nach dem Speichern den Endzustand. Das nützliche Ergebnis ist eine dokumentierte Probe, die eine fehlende Ersatz- oder Beweispflicht aufdeckt, bevor ein reales Ereignis eintritt.

Reichen Sie eine Übung nicht bei ENISA, einem CSIRT oder einem echten Kunden ein. Pulsars Akte ist keine offizielle Meldebestätigung, und der öffentliche Prozess verspricht keine automatische Berichterstattung an die Behörden. Behalten Sie eine tatsächliche Einreichung, ihren offiziellen Kanal und den Empfang als separate Aktionen in einem realen Vorfall bei. Lesen Sie vor der Registrierung die Zahlungsmethode und Stornierungsbedingungen der 14-tägigen Testversion.

Quellen

ENISA — Einheitliche CRA-Meldeplattform Quellen geprüft: 2. Oktober 2026.
Pulsar GRC — Zugriff, Datenisolierung und Export (Polnisch) Quellen überprüft: 2026-10-10.
CRA — Regulation (EU) 2024/2847 — Produktumfang und geltende Verpflichtungen.
European Commission — CRA reporting — Meldebedingungen, Branchen und Termine.
European Commission — CRA legislative summary — Umfang, Umgang mit Schwachstellen und Anwendungstermine.
Pulsar GRC — features — Interne Handlungen und Beweise.
Veröffentlichter Produktumfang und Testbedingungen — Veröffentlichter Produktumfang und Testbedingungen. Lesen Sie die Bedingungen und starten Sie die 14-tägige Testversion

CRA für SaaS: Umfang, eigene Maßnahmen und Beweise

Schwachstellen von IoT-Komponenten: Lieferanten, Entscheidungen und Korrekturen

Polnisches KSC/NIS2 für IT-Anbieter: Bewertung und Maßnahmenregister