Warum „das war doch ein Gutmütiger“ die falsche Prüfung ist

Die Überlegung läuft fast immer gleich: Der Finder hat sich freiwillig gemeldet, er wollte helfen, also war der Zugriff nicht wirklich unbefugt, also ist nichts zu melden. Jeder Schritt dieser Kette klingt vernünftig. Zusammen prüfen sie die falsche Frage.

Artikel 33 Absatz 1 DSGVO verlangt die Meldung an die Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden. Die einzige Ausnahme greift, wenn die Verletzung „voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt“. Der Maßstab ist das Risiko für die Betroffenen, nicht die Gesinnung dessen, der die Lücke gefunden hat. Ein gutwilliger Finder senkt das Risiko, das von seinem eigenen Zugriff ausgeht, auf nahezu null. Über alle anderen möglichen Zugriffe sagt er nichts aus.

Dazu kommt eine Unterscheidung, die in der Aufregung oft untergeht: Eine Sicherheitslücke ist noch keine Datenpanne. Eine Lücke ist ein Schwachpunkt — ein fehlendes Update, ein zu weit gefasstes Zugriffsrecht. Zur meldepflichtigen Verletzung wird sie erst, wenn personenbezogene Daten tatsächlich betroffen waren. Der Haken: Sobald jemand sie gefunden und Daten gesehen hat, ist dieser Punkt überschritten. Die Frage lautet dann nicht mehr ob, sondern wie weit.

Die Frage, die Sie beantworten müssen — und meist nicht können

Drehen Sie die Prüfung um. Statt zu fragen, ob es schlimm war, fragen Sie, ob Sie überhaupt feststellen könnten, dass es schlimm war. Vier Fragen genügen:

• Wie lange lag die Lücke offen? Nicht seit wann Sie davon wissen, sondern seit wann sie existierte. Das ist meist ein Datum aus der Versionsverwaltung oder dem Änderungsprotokoll.
• Wie weit reichen Ihre Protokolle zurück? Viele Systeme werfen Protokolldateien nach sieben oder vierzehn Tagen weg. Ist die Lücke älter als Ihr Protokoll, endet die Beweisführung hier.
• Protokollieren Sie überhaupt das Richtige? Ein Webserver-Protokoll zeigt aufgerufene Adressen. Ob dabei personenbezogene Daten zurückgegeben wurden und welche, steht dort in der Regel nicht.
• Können Sie andere Zugriffe ausschließen — oder haben Sie nur keine gefunden? Das ist nicht dasselbe.

Der letzte Punkt ist der wichtigste, und er ist der am häufigsten begangene Denkfehler. Wer nach einer Meldung im Protokoll nach der einen genannten Adresse sucht, findet genau diese eine. Daraus folgt nicht, dass es keine weiteren gab. Keine Spur gefunden zu haben ist etwas anderes, als belegen zu können, dass es keine Spur gibt. Auf diesem Umkehrschluss ruht die gesamte Entlastung — und er trägt nicht.

Auch wer nicht meldet, muss es begründen können

Der Absatz, den kaum jemand liest, ist Artikel 33 Absatz 5 DSGVO. Er verlangt, jede Verletzung zu dokumentieren — „einschließlich aller im Zusammenhang mit der Verletzung stehenden Fakten, ihrer Auswirkungen und der ergriffenen Abhilfemaßnahmen“. Und ausdrücklich so, dass die Aufsichtsbehörde die Einhaltung überprüfen kann.

Das gilt auch dann, wenn Sie sich gegen eine Meldung entscheiden. Die Entscheidung, nicht zu melden, ist selbst dokumentationspflichtig. Wer sie trifft, muss aufschreiben, worauf er sie stützt.

Hier schließt sich der Kreis zur Protokollfrage. Ein Vermerk „nach unserer Einschätzung kein Risiko“ ist keine Begründung, sondern eine Behauptung. Eine belastbare Begründung benennt, welche Daten betroffen waren, über welchen Zeitraum die Lücke offenstand, welche Protokolle ausgewertet wurden und was sie abdecken. Wer an dieser Stelle merkt, dass er nichts hinschreiben kann, hat die Antwort auf die Ausgangsfrage bereits gefunden. Womit man anfängt, damit es gar nicht erst so weit kommt, steht in unserem Beitrag zur IT-Sicherheit im Kleinbetrieb.

Seit dem 11. September laufen drei Uhren

Bis vor Kurzem war die DSGVO für die meisten Betriebe die einzige Uhr. Seit dem 11. September 2026 gelten zusätzlich die Meldepflichten des Cyber Resilience Act, und sie hängen an genau derselben Frage, die Sie nicht beantworten können: aktiv ausgenutzt oder nicht.

Die drei Regelwerke lassen sich sauber auseinanderhalten, und diese Trennung ist der Punkt, an dem in der Praxis die meiste Verwirrung entsteht:

• Die DSGVO verpflichtet Sie als Verantwortlichen für personenbezogene Daten. Empfänger ist die zuständige Aufsichtsbehörde, die Frist beträgt 72 Stunden. Kommt hohes Risiko für die Betroffenen hinzu, müssen diese nach Artikel 34 zusätzlich benachrichtigt werden.
• NIS2 verpflichtet Sie als Betreiber — also für das, was in Ihrem eigenen Betrieb passiert. Andere Empfänger, eigene Fristen. Das steht ausführlich in unserem Artikel zur NIS2-Meldepflicht.
• Der Cyber Resilience Act verpflichtet Sie als Hersteller — für Lücken in einem Produkt, das Sie in Verkehr bringen. Bei einer aktiv ausgenutzten Schwachstelle: Frühwarnung binnen 24 Stunden, ausführlichere Meldung binnen 72 Stunden, Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Abhilfemaßnahme verfügbar ist. Bei einem schwerwiegenden Sicherheitsvorfall verlängert sich der Abschlussbericht auf einen Monat.

Gemeldet wird nach dem Cyber Resilience Act einmal über die Single Reporting Platform der ENISA, die die Meldung gleichzeitig an das koordinierende CSIRT weiterleitet; in Deutschland ist das CERT-Bund beim BSI. Der Unterschied, der in kaum einem Ratgeber sauber gezogen wird: NIS2 betrifft den Betrieb, der Cyber Resilience Act das Produkt. Wer Software baut und sie zugleich selbst betreibt, kann von beidem gleichzeitig getroffen sein — mit verschiedenen Empfängern und verschiedenen Uhren. Was davon auf Zulieferer zukommt, steht in unserem Artikel zu NIS2 in der Lieferkette.

Die CRA-Uhr beißt sich dabei besonders mit der Protokollfrage. Der Auslöser ist eine „aktiv ausgenutzte“ Schwachstelle, und das BSI umschreibt das als zuverlässige Evidenz dafür, dass jemand die Lücke tatsächlich ausgenutzt hat. Wer seine Protokolle nicht auswerten kann, kann das weder feststellen noch ausschließen. Die 24 Stunden laufen trotzdem.

Wann Sie Hersteller im Sinne des Cyber Resilience Act sind, hängt an einer Formulierung aus Artikel 3: Hersteller ist, wer Produkte mit digitalen Elementen entwickelt oder entwickeln lässt und sie unter eigenem Namen oder eigener Marke vermarktet. Ob eine reine Auftragsentwicklung für einen einzelnen Kunden darunterfällt, die nie unter eigenem Namen auf den Markt kommt, ist damit nicht eindeutig beantwortet. Wir halten das ausdrücklich für eine offene Frage und nicht für eine Entwarnung — wer Software für andere baut, sollte sie mit einem Anwalt klären, bevor der Fall eintritt. Die übrigen Pflichten des Cyber Resilience Act greifen ohnehin erst ab dem 11. Dezember 2027.

Die eine Stunde, die sich nicht nachholen lässt

Wenn die Meldung eingeht, ist der Reflex, sofort die Lücke zu schließen. Das ist nachvollziehbar und in dieser Reihenfolge falsch.

Sichern Sie zuerst die Protokolle — Webserver, Anwendung, Datenbank, Firewall —, und zwar als Kopie an einem Ort, an dem nichts sie überschreibt. Erst danach schließen Sie die Lücke. Der Grund steht weiter oben: Die gesamte spätere Bewertung hängt an diesen Dateien. Ein Neustart oder eine Bereinigung kann sie überschreiben, und anders als die Lücke lässt sich diese Reihenfolge nicht nachträglich korrigieren.

Zwei Dinge gehören in dieselbe erste Stunde: Halten Sie schriftlich fest, wann Sie wovon erfahren haben — ab diesem Zeitpunkt laufen alle Fristen. Und sagen Sie nach außen nichts, was Sie nicht geprüft haben. „Das waren nur Testdaten“ ist die häufigste Erstreaktion und meistens ungeprüft. Wer sie zurücknehmen muss, hat ein zweites Problem, und dieses zweite ist öffentlich.

Was Sie dagegen nicht tun sollten: den Melder wie einen Angreifer behandeln. Eine Strafanzeige gegen jemanden, der freiwillig gewarnt hat, schließt keine Lücke. Sie sorgt dafür, dass beim nächsten Mal niemand mehr warnt. Dass Finder hier vorsichtig sind, hat einen realen Grund: Das Bundesjustizministerium hat einen Entwurf vorgelegt, der gutwillige Sicherheitsforschung vom Straftatbestand des Paragrafen 202a StGB ausnehmen soll. In Kraft ist er nicht. Wer Sie warnt, tut das bis heute in einer rechtlichen Grauzone.

Erreichbar sein, bevor es passiert

All das setzt voraus, dass die Meldung Sie überhaupt erreicht. Ohne hinterlegten Meldeweg landet eine Warnung im allgemeinen Kontaktformular, in der Rechnungs-Adresse oder im Spam-Ordner — und liegt dort, während die Lücke offen bleibt.

Der etablierte Weg dafür ist eine Datei namens security.txt nach dem Standard RFC 9116, abgelegt unter dem Pfad /.well-known/security.txt. Sie braucht zwei Angaben: eine Kontaktadresse und ein Ablaufdatum. Das ist eine Sache von Minuten.

Das BSI hat im August 2026 mitgeteilt, dass nur 1,8 Prozent der Webseitenbetreiber in Deutschland eine solche Datei bereitstellen, und gemeinsam mit der Allianz für Cyber-Sicherheit zur Umsetzung aufgerufen. Für Hersteller wird der Kontakt ohnehin zur Pflicht: Anhang I des Cyber Resilience Act verlangt eine Kontaktadresse für die Meldung von Schwachstellen. Die Verordnung schreibt die Datei nicht vor, wohl aber das, was in ihr steht.

Woran Sie erkennen, ob Sie vorbereitet sind

Sie brauchen dafür keinen Ernstfall. Drei Fragen genügen, und Sie können sie heute beantworten:

• Wie lange bewahren Ihre Systeme Protokolle auf, und weiß das jemand im Haus, ohne nachzusehen?
• Wer entscheidet bei Ihnen über eine Meldung an die Aufsichtsbehörde — und weiß diese Person, dass sie auch die Nicht-Meldung begründen muss?
• Wohin schreibt jemand, der Ihnen morgen eine Lücke melden will?

Wer alle drei beantworten kann, wird im Ernstfall eine unangenehme, aber geordnete Woche haben. Wer bei der ersten Frage ins Stocken gerät, entscheidet später über eine Meldepflicht, ohne die Grundlage dafür zu haben. Dieser Beitrag ordnet ein und ersetzt keine Rechtsberatung; ob im Einzelfall eine Meldepflicht besteht, gehört mit einem Anwalt oder Ihrem Datenschutzbeauftragten geklärt.