CRA-Meldepflicht: 4 Schritte für Rechtsabteilungen

Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle aktiv melden. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat den Start dieser Meldepflichten aus dem Cyber Resilience Act (CRA) an diesem Tag in einer Pressemitteilung bekannt gegeben. Gemeldet wird über die Single Reporting Platform der Agentur der Europäischen Union für Cybersicherheit (ENISA). In Deutschland ist CERT-Bund im BSI das koordinierende Computer Security Incident Response Team (CSIRT) und damit die Stelle, die eine Meldung entgegennimmt und weiterleitet. Das BSI stellt zu den Meldewegen Schritt-für-Schritt-Anleitungen bereit. Bei einer aktiv ausgenutzten Schwachstelle gibt die Verordnung einen strengen Takt vor: eine Erstwarnung binnen 24 Stunden ab Kenntnisnahme, eine ausführlichere Meldung binnen 72 Stunden und ein Abschlussbericht binnen 14 Tagen.

Das lässt sich in wenigen Minuten nachlesen. Unruhe in Rechtsabteilungen von Produktunternehmen entsteht trotzdem, und zwar aus einem anderen Grund: Eine Meldepflicht mit kurzen Fristen ist keine Rechtsfrage, die man einmal klärt und dann ablegt. Sie ist ein Betriebsablauf, der auch dann funktionieren muss, wenn er an einem Freitagabend beginnt und die Person, die sich damit auskennt, gerade nicht erreichbar ist.

Dieser Beitrag ist deshalb kein Überblick über die Rechtslage. Er ist ein Betriebs-Check: vier Stellen, an denen Meldeprozesse in der Praxis scheitern, und was Sie an jeder dieser Stellen vorab festlegen sollten. Am Ende steht ein Testlauf, der sich in etwa 45 Minuten durchspielen lässt.

Warum der Termin ein Betriebstest ist

Rechtsabteilungen sind darauf trainiert, neue Pflichten inhaltlich zu durchdringen. Bei einer Meldepflicht mit engem Zeitfenster verschiebt sich der Schwerpunkt. Die inhaltliche Frage (liegt hier ein meldepflichtiger Sachverhalt vor?) ist anspruchsvoll, aber sie ist beantwortbar, sobald die richtigen Personen mit den richtigen Informationen am Tisch sitzen. Wie kommen die Informationen auf den Tisch, wer sitzt dort, und was bleibt nach der Besprechung übrig?

Bei einem Vorfall ist die Rechtsabteilung nicht der erste, sondern in vielen Unternehmen der dritte oder vierte Beteiligte. Die Information entsteht im Produktteam, im Betrieb, im Support oder bei einem externen Sicherheitsforscher, der eine Meldung an eine allgemeine Adresse schickt. Bis diese Information als möglicherweise meldepflichtiger Vorfall erkannt wird, ist häufig schon Zeit verstrichen: genau die Zeit, die später fehlt.

Der dritte Unterschied betrifft die Beweislage. Eine Meldung ist eine Aussage gegenüber einer Behörde über einen Zustand zu einem bestimmten Zeitpunkt. Wenn sich der Sachverhalt später anders darstellt, ist nicht entscheidend, ob die erste Einschätzung im Rückblick richtig war, sondern ob nachvollziehbar ist, auf welcher Grundlage sie getroffen wurde. Das setzt voraus, dass jemand während des Vorfalls mitschreibt, nicht danach aus der Erinnerung.

Die vier Stellen, an denen ein Meldeprozess scheitert

1. Erkennen: Wie erfährt die Rechtsabteilung, dass etwas schief läuft?

Die häufigste Lücke ist auch die banalste. In vielen Unternehmen existiert ein technischer Incident-Prozess: Eine Meldung geht ein, ein Ticket entsteht, eine Bereitschaft wird alarmiert. Was in diesem Ablauf oft fehlt, ist ein Auslöser, der die Rechtsabteilung einbezieht, und zwar nicht bei jedem Ticket, sondern bei einer bestimmten Klasse von Tickets.

Sinnvoll ist deshalb weniger eine allgemeine Informationspflicht als eine benannte Bedingung. Beispiele für Bedingungen, die sich technisch oder organisatorisch abbilden lassen: Es gibt einen Hinweis darauf, dass eine Schwachstelle aktiv ausgenutzt wird. Es liegt eine Meldung von außen vor, also von einem Sicherheitsforscher, einem Kunden oder einer Behörde. Ein Produkt, das in der EU in Verkehr gebracht wurde, ist betroffen. Ein Vorfall zieht eine Kundenkommunikation nach sich.

Formulieren Sie diese Bedingungen so, dass eine Person in der Bereitschaft sie ohne juristische Vorbildung anwenden kann. Wenn die Bedingung lautet „bei potenziell meldepflichtigen Vorfällen informieren”, hat die Bereitschaft die rechtliche Bewertung bereits übernommen, vermutlich um zwei Uhr nachts und ohne es zu merken.

Zur Erkennung gehört außerdem ein Punkt, den Rechtsabteilungen selten auf dem Zettel haben: Welche Eingangswege für Hinweise von außen gibt es überhaupt, und liest sie jemand? Eine Schwachstellenmeldung, die in einem allgemeinen Kontaktformular landet, kann tagelang liegen bleiben, ohne dass ein Prozess anspringt.

2. Bewerten: Wer entscheidet, und mit welcher Rolle?

„Aktiv ausgenutzt” und „schwerwiegend” sind Bewertungen, nicht Messwerte. Sie setzen eine Zusammenschau aus technischer Beobachtung und rechtlicher Einordnung voraus. Genau deshalb ist diese Entscheidung der Punkt, an dem Meldeprozesse am häufigsten ins Rutschen kommen: Sie ist zu technisch für die Rechtsabteilung allein und zu rechtlich für das Sicherheitsteam allein.

Die praktische Konsequenz ist unangenehm eindeutig. Wenn diese Bewertung nicht vorab einer Rolle zugeordnet ist, wird sie im Ernstfall in einer Runde mit sieben Beteiligten getroffen, in der niemand widerspricht und danach niemand sagen kann, wer entschieden hat. Solche Entscheidungen halten einer späteren Prüfung schlecht stand, nicht weil sie falsch wären, sondern weil sie niemandem zuzurechnen sind.

Legen Sie deshalb drei Dinge vorab fest. Erstens: eine Rolle, die entscheidet, und eine benannte Vertretung für den Fall der Abwesenheit. Rolle heißt Funktion mit Namen, nicht Abteilung. Zweitens: welche Informationen dieser Rolle vorliegen müssen, damit sie entscheiden kann: typischerweise eine technische Einschätzung zur Ausnutzung, der Kreis der betroffenen Produkte und Versionen, der Stand der Eindämmung und der Zeitpunkt der ersten Beobachtung. Drittens: was gilt, solange die Information unvollständig ist. Eine Meldepflicht mit kurzer Frist verträgt keinen Zustand, in dem auf Vollständigkeit gewartet wird; es braucht eine Regel für die Entscheidung unter Unsicherheit und eine Regel für die Korrektur.

Der letzte Punkt wird regelmäßig unterschätzt. Die realistische Lage am ersten Tag lautet selten „wir wissen es nicht”. Häufiger: „wir wissen dreierlei, und zwei davon widersprechen sich”.

3. Melden: Wer hat den Zugang, und zwar heute?

Dies ist die Stelle, die sich am günstigsten vorab lösen lässt und trotzdem am häufigsten offen ist. Ein Zugang zu einer Meldeplattform, der erst im Vorfall eingerichtet wird, ist kein Zugang. Registrierungen brauchen Freigaben, Freigaben brauchen Menschen, und Menschen sind an Freitagabenden schwer erreichbar.

Klären Sie konkret: Wer ist registriert? Sind es mindestens zwei Personen, damit Urlaub und Krankheit nicht zum Problem werden? Wo sind die Zugangsdaten so hinterlegt, dass sie im Vorfall erreichbar sind, auch wenn interne Systeme betroffen sind? Und wer hat den Meldeweg einmal im Leerlauf angesehen, damit im Ernstfall niemand die Struktur des Formulars zum ersten Mal liest?

Ein zweiter Aspekt ist die inhaltliche Vorbereitung. Eine Meldung verlangt Angaben, die im Vorfall unter Druck zusammengesucht werden müssen: betroffene Produkte und Versionen, Angaben zum Hersteller, Ansprechpartner, technische Beschreibung, Stand der Maßnahmen. Ein großer Teil davon ist vorab bekannt und ändert sich selten. Was vorher in einer Vorlage steht, muss im Vorfall nicht recherchiert werden.

Und noch ein organisatorischer Punkt: Klären Sie vorab, wer neben der Behörde informiert wird und in welcher Reihenfolge. Kundenkommunikation, Versicherung, Aufsichtsrat, betroffene Geschäftspartner mit vertraglichen Meldepflichten: Diese Wege laufen parallel zur Behördenmeldung und konkurrieren um dieselben Personen.

4. Belegen: Was ist dokumentiert?

Die vierte Stelle wird erst Monate später wichtig, entscheidet dann aber über die Qualität der gesamten Bearbeitung. Nach einem Vorfall wird gefragt, wann wer was wusste und warum welche Entscheidung getroffen wurde. Das fragt nicht nur eine Behörde. Das fragen auch die eigene Geschäftsführung, Mandanten, Versicherer und in Streitfällen die Gegenseite.

Was mitgeschrieben werden sollte, ist überschaubar:

• der Zeitpunkt der ersten Beobachtung und wer sie gemacht hat
• der Zeitpunkt, an dem die Rechtsabteilung einbezogen wurde
• die Bewertung mit Begründung, Zeitpunkt und entscheidender Person
• die Informationen, die dieser Bewertung zugrunde lagen
• der Zeitpunkt der Meldung und ihr Inhalt
• jede spätere Änderung der Einschätzung samt Anlass

Der wichtige Teil ist nicht die Liste, sondern der Zeitpunkt der Aufzeichnung. Ein Protokoll, das nach dem Vorfall aus Chatverläufen und Erinnerungen rekonstruiert wird, ist genau das: eine Rekonstruktion. Es ist besser als nichts, aber es trägt weniger als eine Aufzeichnung, die während der Bearbeitung entstanden ist und in der die Lücken sichtbar bleiben.

Praktisch bedeutet das, dass eine Person im Vorfall die Aufgabe haben muss, mitzuschreiben, und dass diese Person nicht dieselbe sein sollte, die entscheidet oder technisch eindämmt. Wer beides gleichzeitig macht, macht das Mitschreiben zuletzt.

Wo Tools helfen und wo nicht

An dieser Stelle ist eine klare Grenze angebracht. Eine Plattform kann eine Eskalation zuverlässig auslösen, Bedingungen prüfen, Fristen berechnen, Pflichtangaben erzwingen und den Ablauf mit Zeitstempeln festhalten. Genau das ist es, was Prozessautomatisierung für einen Incident-Ablauf leisten kann: Sie macht aus einer Absprache einen Ablauf, der auch dann greift, wenn niemand an ihn denkt. Bei e! ist ein solcher Ablauf in der Logic Engine als sichtbarer Entscheidungsbaum angelegt, in dem jede Bedingung und jede Zuständigkeit einsehbar bleibt.

Was ein Tool nicht leisten kann, ist die Bewertung, ob ein Vorfall meldepflichtig ist. Diese Entscheidung ist juristisch und tatsächlich anspruchsvoll, sie hängt von Umständen ab, die nicht vollständig vorab beschreibbar sind, und sie muss einer Person zuzurechnen sein. Jede Automatisierung, die diesen Punkt verdeckt, verschlechtert die Lage, weil sie eine Entscheidung ohne Entscheider erzeugt.

Die nützliche Arbeitsteilung ist deshalb einfach: Der Ablauf wird vorab festgelegt und läuft verlässlich. Die Bewertung bleibt bei einem Menschen, der benannt ist und dessen Begründung festgehalten wird.

Der Belastungstest

Der wirksamste Test kostet einen Nachmittag und braucht keine Vorbereitung außer einem Kalendertermin. Setzen Sie die Personen zusammen, die im Ernstfall beteiligt wären: Rechtsabteilung, Sicherheit oder Betrieb, Produktverantwortung, Kommunikation.

Beschreiben Sie dann einen erfundenen, aber realistischen Fall. Ein externer Sicherheitsforscher meldet am Freitag um 17:40 Uhr eine Schwachstelle in einer Produktversion, die bei Kunden im Einsatz ist. Er schreibt, er habe Hinweise darauf, dass die Schwachstelle bereits ausgenutzt wird. Die Meldung geht an eine allgemeine Kontaktadresse.

Arbeiten Sie diesen Fall im Raum durch und halten Sie an jeder der vier Stellen fest, was tatsächlich passieren würde, nicht, was passieren sollte. Wer liest die Adresse um 17:40 Uhr? Wie lange dauert es, bis die Rechtsabteilung davon erfährt? Wer entscheidet über die Bewertung, wenn die zuständige Person am Wochenende nicht erreichbar ist? Wer hat den Plattformzugang? Wer schreibt mit?

Nach Erfahrung aus solchen Runden treten zwei bis drei Lücken innerhalb der ersten zwanzig Minuten zutage, und es sind fast nie die, die man erwartet hat. Häufig ist es nicht die rechtliche Bewertung, sondern der Eingangsweg oder der fehlende zweite Plattformzugang.

Wiederholen Sie die Probe einmal im Jahr und nach jeder organisatorischen Änderung. Ein Meldeprozess veraltet nicht durch neue Rechtslagen, sondern dadurch, dass Menschen die Rollen wechseln.

Sinnvolle erste Schritte für diese Woche

Wer bei null anfängt, braucht keine Richtlinie. Vier Entscheidungen auf einer Seite genügen als Anfang:

Dieses Dokument ist in einer Besprechung erstellt und deckt einen großen Teil des Risikos ab.

Alles Weitere (die vollständige Richtlinie, die Abstimmung mit vertraglichen Meldepflichten, die Verzahnung mit anderen Meldewegen) ist wichtig, aber es ist nicht das, was am Freitagabend fehlt.

Häufige Fragen

Seit wann gilt die CRA-Meldepflicht für Hersteller genau?

Das BSI hat am 11. September 2026 in einer Pressemitteilung bekannt gegeben, dass Hersteller von Produkten mit digitalen Elementen ab diesem Zeitpunkt aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle aktiv melden müssen. Grundlage ist der Cyber Resilience Act. Gemeldet wird über die Single Reporting Platform der ENISA. Vorbereitend hatte das BSI bereits am 26. Juni 2026 über ein Treffen der CRA-Marktüberwachungsbehörden und den anstehenden Beginn der Meldepflichten informiert. Für die Praxis bedeutet das: Der Ablauf muss ab sofort stehen und greifen, nicht erst zu einem späteren Stichtag.

An wen wird in Deutschland gemeldet?

Die Meldung läuft über die Single Reporting Platform der Agentur der Europäischen Union für Cybersicherheit (ENISA). In Deutschland ist CERT-Bund im Bundesamt für Sicherheit in der Informationstechnik das koordinierende Computer Security Incident Response Team und damit die nationale Stelle, die eine Meldung entgegennimmt und weiterleitet. Das BSI stellt zu den Meldewegen Schritt-für-Schritt-Anleitungen bereit. Praktisch relevant ist, dass der Zugang zur Plattform vorab eingerichtet sein sollte und dass mindestens zwei Personen im Unternehmen ihn nutzen können, damit Abwesenheiten den Ablauf nicht blockieren.

Wer sollte im Unternehmen entscheiden, ob ein Vorfall nach CRA meldepflichtig ist?

Diese Entscheidung sollte einer verantwortlichen Rolle mit benannter Vertretung zugeordnet sein, nicht einer Abteilung und nicht einer Runde. Die Begriffe „aktiv ausgenutzt” und „schwerwiegend” erfordern eine Zusammenschau aus technischer Beobachtung und rechtlicher Einordnung, weshalb die entscheidende Rolle beides zugeliefert bekommen muss: eine technische Einschätzung zur Ausnutzung, den Kreis der betroffenen Produkte und Versionen, den Stand der Eindämmung und den Zeitpunkt der ersten Beobachtung. Ebenso wichtig ist eine vorab festgelegte Regel für die Entscheidung unter Unsicherheit und für die spätere Korrektur der Einschätzung, denn am ersten Tag eines Vorfalls ist die Informationslage in der Regel widersprüchlich und nicht bloß lückenhaft.

Was muss während eines Vorfalls nach CRA dokumentiert werden?

Sinnvoll sind der Zeitpunkt der ersten Beobachtung und wer sie gemacht hat, der Zeitpunkt der Einbeziehung der Rechtsabteilung, die Bewertung mit Begründung und entscheidender Person, die Informationen, auf denen diese Bewertung beruhte, Zeitpunkt und Inhalt der Meldung sowie jede spätere Änderung der Einschätzung samt Anlass. Entscheidend ist weniger der Umfang als der Zeitpunkt der Aufzeichnung: Ein während der Bearbeitung entstandenes Protokoll trägt deutlich mehr als eine nachträgliche Rekonstruktion aus Chatverläufen und Erinnerungen. In der Praxis bewährt es sich, die Aufzeichnung einer Person zuzuweisen, die im Vorfall nicht gleichzeitig entscheidet oder technisch eindämmt.

Betrifft die Meldepflicht auch Unternehmen, die keine Software verkaufen?

Der Cyber Resilience Act adressiert Produkte mit digitalen Elementen, und das ist weiter als klassische Software. Vernetzte Geräte und Komponenten mit Softwareanteil können ebenso betroffen sein. Rechtsabteilungen sollten deshalb nicht bei der Frage „verkaufen wir Software?” stehen bleiben, sondern erfassen, welche der eigenen Produkte digitale Elemente enthalten und in der EU in Verkehr gebracht wurden. Die Einordnung im Einzelfall ist eine eigene Prüfung und sollte nicht im Vorfall zum ersten Mal gestellt werden.

Wie lässt sich der Meldeprozess ohne großes Projekt vorbereiten?

Mit vier Festlegungen auf einer Seite: die Bedingung, bei der die Rechtsabteilung eskaliert wird und die eine Person in der Bereitschaft ohne juristische Vorbildung anwenden kann; die Rolle, die die Bewertung trifft, samt Vertretung; die zwei Personen mit Zugang zur Meldeplattform; und die Person, die im Vorfall mitschreibt. Anschließend sollte der Ablauf einmal an einem erfundenen Fall durchgespielt werden. Eine solche Probe dauert etwa 45 Minuten und legt in der Regel innerhalb der ersten zwanzig Minuten zwei bis drei Lücken offen, häufig beim Eingangsweg für Hinweise von außen oder beim fehlenden zweiten Plattformzugang.

Stand dieses Beitrags: 16. September 2026. Dieser Beitrag ist eine betriebliche Orientierungshilfe und ersetzt keine Rechtsberatung.

Quellen

• BSI, Pressemitteilung vom 11.09.2026 zum Start der CRA-Meldepflichten für Hersteller: https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260911_CRA_Meldepflicht_Schwachstellen.html
• BSI, Meldung vom 26.06.2026 zum Treffen der CRA-Marktüberwachungsbehörden: https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/Treffen_CRA_Markt%C3%BCberwachungsbeh%C3%B6rden_260625.html
• Verordnung (EU) 2024/2847 (Cyber Resilience Act), Artikel 14: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32024R2847
• ENISA CRA Single Reporting Platform: https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp