Zur 72-Stunden-Frist
nach Art. 33 Abs. 1 DSGVO
Zur Frage, wann eine 72-Stunden-Frist nach Art. 33 Abs. 1 DSGVO endet und ob bzw. wie dabei ggf. die EU-Fristenverordnung (EU Verordnung Nr. 1182/71) anzuwenden ist, gibt es unterschiedliche Auffassungen. Klar ist insoweit, dass die Fristen-VO grundsätzlich Anwendung findet. Uneinigkeit besteht jedoch darüber, ob die 72-Stunden-Frist auch Wochenenden und Feiertage beinhaltet.
Jetzt hat die LDI NRW klargestellt, dass dies der Fall ist. Denn auch wenn es in Art. 3 Abs. 5 Fristen-VO heißt: "Jede Frist von zwei oder mehr Tagen umfasst mindestens zwei Arbeitstage", findet diese Regelung im konkreten Fall keine Anwendung, da es sich bei der Frist in Art. 33 Abs. 1 DSGVO explizit um eine Stundenfrist handelt. Wörtlich schrieb mir die LDI NRW dazu:
Art. 3 Abs. 5 Fristen-VO findet nach hiesiger Einschätzung keine Anwendung auf Stundenfristen.
Und für eben diese Stundenfristen gilt Art. 3 Abs. 5 Fristen-VO nicht, da sich dieser - nach Auffassung der LDI NRW- ausschließlich auf Tagesfristen bezieht.
Ich muss gestehen, dass ich zunächst naiverweise gedacht hatte, dass 72 Stunden eben auch drei Tage sind. So wie bspw. auch Carlo Piltz und Melanie Pradel in ihrem Aufsatz in der ZD 4/2019, der im Übrigen den Sachverhalt noch deutlich differenzierter betrachtet und deswegen zur Lektüre empfohlen wird.
Diese Interpretation ist aber wohl - zumindest aus Sicht der LDI NRW - nicht richtig, denn nicht ohne Grund unterscheiden sowohl die DSGVO als auch die Fristen-VO explizit zwischen Stundenfristen, Tagesfristen und Wochenfristen.
Ist ja eigentlich auch logisch *Zwinkersmiley* oder doch nicht?
Nun, so ganz unlogisch klingt die Argumentation der LDI NRW nicht. Aber man kann schon kritisch hinterfragen, ob das die richtige Auffassung der Sachlage ist. Denn warum differenzieren Abs. 1 bis 4 in Art. 3 Fristen-VO explizit zwischen Fristen, die nach "nach Stunden", "nach Tagen" sowie "nach Wochen, Monaten oder Jahren" bemessen sind, Art. 3 Abs. 5 Fristen-VO soll aber ausnahmslos für "Jede Frist..." gelten und dennoch nicht für Stundenfristen anwendbar sein?
Nach Ansicht der LDI NRW bleibt es jedenfalls dabei, dass die berühmten "Data Breaches" vom Freitag um 16:30 Uhr einen Fristbeginn am Freitag um 17:00 Uhr auslösen und in der Regel bis zum folgenden Montag um 17:00 Uhr zu melden sind. Die LDI NRW schrieb mir dazu aber auch in einem Nachsatz:
Sofern die Meldung nicht innerhalb der 72-Stunden-Frist erfolgt, so ist dies gemäß Art. 33 Abs. 1 DS-GVO zu begründen.
Mit anderen Worten: Eine spätere Meldung ist grundsätzlich zulässig, muss aber entsprechend begründet werden können. Dabei ist aber etwas wie "Oh, die interne Informationsweitergabe hat sich verzögert." sicher kein ausreichender Grund, sondern nur ein Beleg für unzureichende interne Prozesse.
„security.txt“
nach RFC 9116
Schon mal etwas von der Möglichkeit gehört, eine "security.txt" nach RFC 9116 auf dem Webserver zu platzieren? Nein? Dann einfach mal fix weiterlesen *Zwinkersmiley*
Findet jemand eine Sicherheitslücke, so sollte man ihm sinnvollerweise auch die Gelegenheit geben, diese dem Verantwortlichen kurzfristig mitteilen zu können. Doch an wen konkret wendet man sich in einem solchen Fall? Häufig wird das nicht transparent kommuniziert und allein die entsprechenden Informationen zu finden, wird schon zur ersten Herausforderung für den Meldenden.
Hier möchte das RFC 9116 Abhilfe schaffen und stellt mit der so genannten "security.txt" eine standardisierte und (theoretisch auch) automatisiert auswertbare Informationsquelle für die Meldung von Sicherheitsproblemen zur Verfügung. In der "security.txt" werden dazu verschiedene Informationen platziert, bspw. die URL, wo die "security.txt" selbst zu finden ist, die Kontaktdaten des Ansprechpartners für die Meldung sowie ggf. auch schon kryptographisches Schlüsselmaterial für eine sichere Kommunikation. Eine "security.txt" MUSS dabei nach RFC 9116 unter dem Pfad "/.well-known/" platziert werden. Für meine Domäne we.secure-your.it lautet der vollständige Pfad somit "https://we.secure-your.it/.well-known/security.txt". Dies in aller Kürze, alle weiteren Vorgaben und Möglichkeiten lassen sich natürlich im RFC 9116 nachlesen.
Aber Achtung: Wenn man eine sichere Kommunikationsmöglichkeit -bspw. durch Verwendung eines Public-Key-Pairs- zur Verfügung stellen möchte, sollte auch sichergestellt sein, dass alle jeweiligen Ansprechpartner über das notwendige Schlüsselmaterial -in diesem Fall also den zugehörigen Private Key- verfügen, denn nur dann ist eine (lesbare) Kommunikation sichergestellt. Es kann durchaus hilfreich sein, das genaue Vorgehen und das notwendige Schlüsselmaterial erst nach einem erfolgreichen Erstkontakt -in dessen Verlauf natürlich keine brisanten Informationen übermittelt werden sollten- auszutauschen.
Vortrag zum Thema
„Löschen nach DSGVO“
Am 14. März 2024 halte ich anlässlich der am 14. und 15. März 2024 in Hamburg stattfindenden "Datenschutz-Fachtagung" des TÜV Nord am ersten Veranstaltungstag zusammen mit Joerg Heidrich einen Vortrag zum Thema "Datenschutzkonformes Löschen: Konzept, technische Möglichkeiten und rechtliche Implikationen".
In diesem interdisziplinären Vortrag diskutieren wir die Fragen, was überhaupt "datenschutzkonformes" Löschen ist, wann man personenbezogene Daten konkret löschen muss und ob bzw. wie man diese eigentlich datenschutzkonform löschen kann. Das klingt erst einmal trivial, entpuppt sich aber bei näherer Betrachtung oft als große Herausforderung, denn nahezu in jedem Unternehmen gibt es eine Vielzahl von Verarbeitungsprozessen und Speicherorten für personenbezogene Daten, die muss man erst einmal alle kennen.
Hinzu kommen Löschfristen, die je nach Anwendungsfall völlig unterschiedlich sein können. Und insbesondere beim Cloud-Computing stellt sich bspw. die Frage, ob und wie man Daten in der Cloud überhaupt datenschutzkonform löschen kann.
Bei all diesen Fragen kann übrigens ein Löschkonzept sehr hilfreich sein und daher ist dieses Thema ebenfalls Bestandteil unseres Vortrags.
KRITIS-DachG-E:
Ablösung der BSI-KritisV?
Wer sich den aktuellen Entwurf zur Umsetzung der europäischen RCE-Richtlinie, das neue KRITIS-Dachgesetz (KRITIS-DachG), schon genauer angeschaut hat, wird in Abschnitt B des Entwurfs vlt. so wie ich über folgende Formulierung gestolpert sein:
Um ein Auseinanderfallen kritischer Anlagen im Sinne des BSIG einerseits und im Sinne des KRITIS-DachG andererseits zu vermeiden, werden Betreiber kritischer Anlagen künftig nur noch durch das KRITIS-DachG und die dazugehörige Rechtsverordnung bestimmt. Mit der Rechtsverordnung wird ersichtlich, welche Verpflichtungen für Betreiber kritischer Anlagen und weiterer Einrichtungen im Hinblick auf physische Resilienzmaßnahmen nach dem KRITIS-DachG und im Hinblick auf die IT-Sicherheit nach dem BSIG gelten.
Dies bedeutet dann wohl, dass die bisherige BSI-KritisV durch die noch zu erstellende Rechtsverordnung nach § 16 KRITIS-DachG-E abgelöst werden wird.
Diese Vereinheitlichung ist sicherlich auch geboten und wünschenswert, insbesondere wenn man vor Augen hat, welche "Unstimmigkeiten" es bereits bei den Entwürfen des NIS2UmsCG und des KRITIS-DachG gegeben hat.
Und das, obwohl dasselbe Ministerium federführend in der Ausgestaltung ist und man doch erwarten sollte, dass es hier eine entsprechende interne Abstimmung der einzelnen zuständigen Abteilungen bzw. Personen gibt. Es bleibt also zu hoffen, dass die Konsolidierung der Rechtsverordnungen hier einen echten Mehrwert schafft, also mehr ist, als das reine "Zusammenschreiben" von zwei nicht miteinander abgestimmten Verordnungen *Zwinkersmiley*
Denn nur so lassen sich Unstimmigkeiten vermeiden. Zugleich sollte sichergestellt werden, dass die Verordnung durch regelmäßige und öffentlich einsehbare Evaluierungen auch am "Puls der Zeit" bleibt.