Anforderungen
nach Art. 32 DSGVO
Technische und organisatorische Maßnahmen nach Art. 32 DSGVO sind insbesondere auf Basis ihrer "Geeignetheit", ihrer "Angemessenheit" und ihrer "Verhältnismäßigkeit" auszuwählen. Bei der Frage der Verhältnismäßigkeit, die auch die Angemessenheit im engeren Sinne beschreibt, spielt vor allem auch der Stand der Technik eine bedeutende Rolle.
Doch wie beurteilen die (europäischen) Aufsichtsbehörden die Angemessenheit der getroffenen Maßnahmen?
Dieser Frage widmet sich die Übersicht, die Eleni Kosta zusammengestellt hat und die über die Website des EDPB zum Abruf bereit steht. Viel überraschend Neues erfährt der informierte Leser dabei nicht, wohl aber eine Bestätigung für viele potentiell mögliche - und hoffentlich im Einzelfall auch wirksam umgesetzte - Maßnahmen.
Um einen Überblick über die Anforderungen nach Art. 32 DSGVO aus Sicht der Aufsichtsbehörden zu bekommen, ist die Lektüre daher sehr zu empfehlen. Allerdings merkt man auch, dass es nicht einfach ist, die technische Weiterentwicklung - also den Stand der Technik (sic!) - im Rahmen einer solchen Zusammenstellung zu berücksichtigen, da die zitierten Entscheidungen tlw. eben schon in die Jahre gekommen sind.
Mit anderen Worten: Was gestern Gültigkeit hatte, muss heute nicht mehr stimmen. Daher muss man die in dieser Zusammenfassung genannten technischen und organisatorischen Maßnahmen stets im Zusammenhang mit dem aktuellen (technischen) Stand der Dinge betrachten und ggf. eine Neubewertung vornehmen. Eine Sache, die im Zusammenhang mit dem Begriff "Stand der Technik" (sic!) ja eigentlich auch selbst verständlich sein sollte *Zwinkersmiley*
Zur Frist der NIS-2-Umsetzung
durch das NIS2UmsuCG
Die NIS-2-Richtlinie ist ja -übrigens im Gegensatz zu einer Verordnung- vom nationalen Gesetzgeber noch in nationales Recht umzusetzen. In jeder europäischen Richtlinie wird dazu eine Frist gesetzt, die der nationale Gesetzgeber grundsätzlich einzuhalten hat.
Bei der NIS-2-Richtlinie läuft diese Frist am 17. Oktober 2024 ab. Das der nationale Gesetzgebungsprozess bisher eher "schleppend" vorankommt, ist angesichts der Tatsache, dass die NIS-2-Richtlinie auf europäischer Ebene ja bereits am 16. Januar 2023 in Kraft getreten ist, schon verwunderlich.
Dass der nationale Gesetzgeber -wie in grundsätzlich vertrauenswürdigen Social Media-Kanälen zu lesen- aber bereits jetzt mitteilen muss, dass eine pünktliche Umsetzung in nationales Rech ausgeschlossen ist, verwundert doch sehr.
Dies gilt umso mehr vor dem Hintergrund, dass das BMI im Diskussionspapier zum NIS2UmsuCG auf Seite 57 zum Punkt "Inkrafttreten, Außerkrafttreten" wie folgt kommentiert:
Bei einer Verkündung im März 2024 stehen den Einrichtungen noch sechs Monate für die Umsetzung der in diesem Gesetz enthaltenen Verpflichtungen zur Verfügung. Der hier genannte Zeitpunkt ist der letzte Quartalsbeginn vor Ablauf der Umsetzungsfrist des Artikel 41 NIS-2-Richtlinie am 17. Oktober 2024. Im Übrigen sind die für die Verpflichtungen von wesentlichen und wichtigen Einrichtungen maßgeblichen Inhalte der NIS-2-Richtlinie bereits seit dem Kommissionsentwurf aus Dezember 2020 bekannt.
Da fragt man sich doch, ob nicht auch das BMI bereits seit geraumer Zeit von seiner Umsetzungsverpflichtung hätte wissen und sich entsprechend hätte vorbereiten müssen.
Aber sicher kommt das NIS2UmsuCG nur deshalb verspätet, damit den dadurch Verpflichteten mehr Zeit für die Umsetzung eingeräumt werden kann *Zwinkersmiley*
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.