DEEN

Compliance & NachweisbarkeitAus der Praxis

CRA-Meldepflicht: Was Ihr System in 24 Stunden liefern muss

4 Min. Lesezeit

Seit dem 11. September 2026 gelten die Meldepflichten des Cyber Resilience Act. Wer ein Produkt mit digitalen Elementen in der EU auf den Markt bringt, muss eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall melden: binnen 24 Stunden als Frühwarnung und binnen 72 Stunden mit einer ausführlicheren Meldung. Der Meldeweg führt über die einheitliche Meldeplattform zum nationalen CSIRT-Koordinator und zu ENISA.

Die juristische Seite ist klar. Die Frage in den Teams ist eine andere: Kann unser System das überhaupt liefern?

Vor allem trifft es Organisationen, die eigentlich etwas anderes voranbringen sollten. In Europa müsste der Fokus auf Innovation liegen — nicht darauf, dass ein Vorfall außerhalb der eigenen Kontrolle plötzlich eine ganze Woche oder länger blockiert. Mehrere Menschen, die im Prozess grundsätzlich wissen, was zu tun ist, werden trotzdem aus dem Alltag gerissen. Der Fokus wandert vom Wesentlichen weg.

Das ist ein Organisationsproblem: Menschen und Aufmerksamkeit auf mehrere Themen gleichzeitig aufzuteilen. Es ist dieselbe Kritik wie an Multitasking und zu vielen Meetings — verschärft durch Krankheit oder Urlaub. Dauernde Verfügbarkeit Einzelner kann keine Lösung sein.

Was die Uhr wirklich startet

Die 24 Stunden laufen ab Kenntnis. Nicht ab Bestätigung, nicht ab fertiger Analyse.

Ein Kunde meldet um 17:40 Uhr ein auffälliges Verhalten. Jemand schaut um 21:00 Uhr hinein und erkennt die Ausnutzung — ab dann bleibt weniger als ein Arbeitstag.

Die Frühwarnung verlangt noch keine vollständige Ursachenanalyse. Sie enthält zunächst Minimalangaben zum Ereignis und zu betroffenen Mitgliedstaaten; bei Sicherheitsvorfällen auch dazu, ob eine rechtswidrige oder böswillige Handlung vermutet wird. Trotzdem muss das Team schon jetzt erkennen, was es vor sich hat. Wer dafür erst Logs, Snapshots und das Gedächtnis zweier Kollegen zusammensetzt, verbringt die Frist mit Archäologie statt mit Eindämmung.

Pflicht, Systemfähigkeit, Beleg

Meldestufe und PflichtWas die Organisation können mussWoran man es belegt
24 Stunden: Ereignis einordnen, betroffene Mitgliedstaaten benennenKenntniszeitpunkt und erste Reichweite verlässlich festhaltenEröffneter Vorfall mit Zeitstempel, Quelle und unveränderter Erstbewertung
72 Stunden: Produkt, Art der Ausnutzung oder des Vorfalls und Maßnahmen beschreibenBetroffene Versionen, Nutzer oder Mandanten eingrenzenAbfrage über Versions- und Mandantenschlüssel, technisch erzwungene Zuordnung
Abschlussbericht: Ursache, Schwere, Auswirkungen und Maßnahmen darlegenDen Verlauf fortschreiben, ohne frühere Erkenntnisse zu überschreibenVersionierter Vorfallverlauf mit Urheber und Grund jeder Änderung
CRA-Produktdokumentation: Komponenten und Abhängigkeiten dokumentierenDie gesetzlich verlangte SBOM dem konkreten ausgelieferten Build zuordnenAutomatisch erzeugte und archivierte Stückliste je Build
Meldung und Eindämmung parallel organisierenZuständigkeiten und Änderungen an Konfiguration oder Berechtigungen nachvollziehenBenannte Melderolle und Änderungshistorie mit Urheber und Grund

Auf die 72-Stunden-Meldung folgt ein Abschlussbericht: bei Schwachstellen spätestens 14 Tage, nachdem eine Korrekturmaßnahme verfügbar ist; bei schwerwiegenden Sicherheitsvorfällen binnen eines Monats nach der 72-Stunden-Meldung.

Die rechte Spalte entscheidet. Alles davon lässt sich zusammensuchen — nur selten innerhalb der Frist und noch seltener so, dass es einer späteren Prüfung standhält.

Warum Logs zu spät kommen

Technische Logs sind für Betrieb und Fehlersuche gebaut. Sie zeigen, dass etwas geändert wurde. Selten warum und auf welcher fachlichen Grundlage. Sie werden gekürzt, rotiert und sind je nach Aufbewahrung früh verschwunden. Vorfälle fallen dagegen gerne erst Wochen später auf.

Dazu der strukturelle Haken: Ein danebengestelltes Log muss bei jeder neuen Schnittstelle mitgepflegt werden. Unvollständig ist es genau dort, wo unter Termindruck integriert wurde — also häufig dort, wo der Vorfall herkommt.

Fünf Fragen vor dem Ernstfall

  1. Können wir für einen beliebigen Datensatz in unter einer Stunde sagen, wer ihn wann und warum verändert hat?
  2. Lässt sich der betroffene Mandantenkreis abfragen — oder muss er geschätzt werden?
  3. Wissen wir, welche Abhängigkeiten in der konkret ausgelieferten Version stecken?
  4. Wer darf die Meldung absenden, und ist diese Person am Sonntagabend erreichbar?
  5. Bleibt unsere Erstmeldung erhalten, wenn sich das Bild später ändert?

Wer drei davon mit „vermutlich“ beantwortet, hat kein Compliance-Problem, sondern ein Architekturthema.

Die Grenze

Der CRA ist kein Anlass, ein laufendes System umzubauen. Für die meisten Häuser reicht ein enger Schnitt: die eine Domäne, in der Entscheidungen zählen — Freigaben, Berechtigungen, Vertrags- und Preislogik. Dort lohnt sich ein belastbarer Ereignisverlauf. Der Rest bleibt.

Umgekehrt: Ein perfekter Ereignisstrom ersetzt keinen Prozess. Wenn niemand definiert hat, wer meldet und ab wann die Uhr läuft, hilft die beste Nachvollziehbarkeit nicht.

Weiterlesen

← Zurück zum Blog

Beiträge zu diesem Thema