Is er sprake van een datalek als persoonsgegevens door een storing tijdelijk niet beschikbaar zijn?
Heb jij een interessante vraag op het snijvlak van privacy, cybersecurity en recht? Stuur je vraag naar juridischevraag@security.nl. Elke week geeft ict-jurist Arnoud Engelfriet in deze rubriek antwoord.
Juridische vraag: Onder de AVG is een datalek (volgens mij) ook als data onbeschikbaar is voor geautoriseerde gebruikers. Mijn bedrijf slaat persoonsgegevens op die klanten zelf uploaden en biedt tools voor het bewerken daarvan. Als ik door een storing deze tijdelijk niet beschikbaar heb, is dat dan een datalek en is het meldplichtig?
Antwoord: Het lijkt me goed om even terug te vallen op de definitie van wat een “datalek” precies is. De AVG noemt het een “inbreuk in verband met persoonsgegevens” (artikel 4 lid 12):
een inbreuk op de beveiliging die per ongeluk of op onrechtmatige wijze leidt tot de vernietiging, het verlies, de wijziging of de ongeoorloofde verstrekking van of de ongeoorloofde toegang tot doorgezonden, opgeslagen of anderszins verwerkte gegevens;
Er moet dus sprake zijn van een inbreuk (schending) op de beveiliging. Die moet leiden tot vernietiging, verlies, wijziging of verstrekking van persoonsgegevens. En dat moet op onrechtmatige wijze of per ongeluk gebeuren.
De EDPB (de verzamelde AVG-toezichthouders) heeft in een advies in 2022 duidelijk gemaakt wanneer ook onbeschikbaarheid een datalek kan zijn:
Therefore, a security incident resulting in personal data being made unavailable for a period of time is also a type of breach, as the lack of access to the data can have a significant impact on the rights and freedoms of natural persons. To be clear, where personal data is unavailable due to planned system maintenance being carried out this is not a ‘breach of security’ as defined in Article 4(12) GDPR.
Kern is dus ook hier dat sprake is van een beveiligingsincident. Dat kan een simpele storing zijn (een ongeplande reboot) tot een regelrechte ramp (je hele netwerk zit vol malware, alles moet weken offline tot je vanaf veilige backups kon herstellen).
Hoofdregel is dat ieder datalek moet worden gemeld. Ja, dus ook je ongeplande reboot waardoor 3 minuten lang niemand kon inloggen. Maar gelukkig is er een uitzondering: “tenzij het niet waarschijnlijk is dat de inbreuk in verband met persoonsgegevens een risico inhoudt voor de rechten en vrijheden van natuurlijke personen.” Die drie minuten downtime gaan (meestal) heus geen problemen geven, dus dan hoef je dat niet te melden.
Drie weken offline vanwege malware is wél meldingsplichtig, lijkt me. Al die tijd niet met je data kunnen werken kan wel degelijk problemen geven. Uiteraard is het afhankelijk van het systeem: het medischdossierbeheersysteem van een ziekenhuis zal eerder weer online moeten komen dan de backend van een personal fitness app en die weer eerder dan een datumpriktool.
Arnoud Engelfriet is Ict-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. Hij schreef twee boeken, De wet op internet en Security: Deskundig en praktisch juridisch advies.
Ik zie de rechtszaak met belangstelling tegemoet.
Ik zie de rechtszaak met belangstelling tegemoet.
KPN die er een week uit ligt dan? had je geen uitwijk bij een ander geregeld dan?
Microsoft die Azure een dagje op vakantie stuurt? wel eens van AWS gehoord?
Overmacht...
Reboot is alleen lastig als je je failover of dual-system niet hebt ingericht.
Dat los je op door de gebruiker te informeren over je service, en dat je een uptime garandeert uit het jaar kruik. Daarna kun je rebooten en knutselen wat je wilt. ;-) Downtime in een afgesproken (!=medegedeeld) servicewindow is geen downtime.
B = beschikbaarheid. Als afnemer van ICT-diensten maak je daar afspraken over met de leverancier van die diensten.
Afwijkingen daarvan zijn dan idd een datalek.
Zou "niet beschikbaar" "misschien" (binnen de context) kunnen duiden op het lekken van informatie (hetgeen zo centraal staat in deze wet), en niet over bedrijfsvoering?
Als in: select "Simon Carmiggelt" in alle gebruikers -> 0 rows = aha, hij heeft nog geen uitvaartverzekering bij firma X.
Het "lijkt" mij bizar dat een afwijking van een QoS inherent is aan "datalek".
Tenzij dat iets als een missende en essentiele blokkade zou betreffen, waardoor gevoelige info juist onbedoeld beschikbaar is.
Ik zie de rechtszaak met belangstelling tegemoet.
KPN die er een week uit ligt dan? had je geen uitwijk bij een ander geregeld dan?
Microsoft die Azure een dagje op vakantie stuurt? wel eens van AWS gehoord?
Overmacht...
Reboot is alleen lastig als je je failover of dual-system niet hebt ingericht.
Dat los je op door de gebruiker te informeren over je service, en dat je een uptime garandeert uit het jaar kruik. Daarna kun je rebooten en knutselen wat je wilt. ;-) Downtime in een afgesproken (!=medegedeeld) servicewindow is geen downtime.
Tenzij ze bewijs hebben dat de aansprakelijkheid ook is overgedragen bij uitgeven van een dienst zijn ze nog steeds verantwoordelijk voor hun data en bereikbaarheid. Enig onstane schade zullen ze moeten vergoeden richting de klant en vervolgens los daarvan weer hun gelijk halen bij de betrokken leverancier wat in de praktijk nog lastiger is.
Maar oh wat graag willen al die bedrijven consumenten en klanten overtuigen dat ze niet aansprakelijk zijn.
Om maar even een voorbeeld te geven persooneels tekort is tenzij officieel erkend (wat zelden gebeurd) niet een geldige Force majeure. Je had meer personeel in kunnen huren je had meer kunnen inzetten op recruiting je had meer kunnen bieden aan applicanten. En dat geldt ook voor langdurige ziekte van key personel, stakingen en andere situaties.
De enige vorm van echte overmacht waar bijna nooit discussie over komt is vanuit de natuur. Een natuurlijke overstroming die je voorzieningen wegblaast is overmacht. Een kapotte leiding daarin tegen waardoor je gebouw onder water staat is geen overmacht tenzij anders bewezen.
Terugkomend op het voorbeeld als een klant een contract heeft met bedrijf A en Bedrijf A neemt diensten af bij Bedrijf B waar nu problemen optreden heeft Bedrijf A te maken met tekortkomingen die het moet oplossen en de klant hoeft nergens boodschap aan te hebben dat Bedrijf A dit niet zelf kan oplossen. Dat was namelijk de keuze van Bedrijf A om B er bij te betrekken en niet van de klant. Tenzij de klant zelf dus heeft aangedrongen op samenwerking met bedrijf B heeft Bedrijf A geen poot om op te staan met verantwoordelijkheid wegwuiven.
In de praktijk gaat niemand natuurlijk voor een kortstondige verstoring een rechtzaak beginnen tenzij het een kritieke dienst was maar het kan wel als het bedrijf contractueel aansprakelijk dus niet tot een gezamenlijke oplossing komt.
En ja uptime garantie is in meeste gevallen dan ook een farce en altijd geweest. Een bedrijf dat garantie geeft van 99,98% uptime heeft de zelfde verplichtingen als een bedrijf dat 99,99% garandeerd want je levert namelijk een dienst en de klant mag verwachten dat je die gedurende het contract levert en niet op bepaalde momenten tenzij zo door beide partijen exact overeengestemd.
De rest is meestal marketing bshit en de hoop dat iemand akkoord gaat met de lachwekkende vergoedingen die ze standaard rekenen omdat ze geen zin in een conflict hebben die vergeoedingen houden vaak jurdisch ook geen stand en eindigen veel hoger.
Kom het wel tot een zaak dan zal een rechter meestal terugvallen op bepaling via Haviltex-criterium tenzij contractueel is vastgesteld dat beide partijen afzien van het Haviltex-criterium en dat is zeer situationeel en meer uitzondering dan regelmaat.
Terwijl als je zelfs met iets dringens naar een rechter stapt, het rustig nog twee weken kan duren voor er een vonnis uit de bus komt. Wat overigens bepaald niet onverstandig is. Want vooral met instant satisfaction kun je de stomste fouten maken. Daarnaast, als eindelijk de uitslag komt, het gevoel van beloning veel groter is.
Ik kan het vrij eenvoudig aantonen trouwens. Ik reboot niet (dat is op mijn spullen denk ik niet meer dan een minuutje), maar ik gooi gewoon de boel een paar uur plat. De hele zooi. Gewoon omdat ik er zin in heb. Of ik wacht gewoon tot Aleid Wolfsen belt om foei en mag niet te zeggen. En dan geef ik ook nog toe dat hij ook recht heeft op een eigen mening maar dat ik er gewoon zin in had. Maar dat ik alles zo weer aanzet, ik altijd al bereikbaar ben geweest, ook voor alle privevragen. En dat ik sneller zal handelen dan zelfs heels die AP bijmekaar. Plus dat alle data tijdens de downtime nog veiliger heeft gestaan dan het al was. Hoe langer ik down ben, hoe opgeluchter de gebruikers dat alles gelukkig weer werkt!
En dan? De kieteldood of zo? Van Aleid Wolfsen met een AVG zweepje?
Dat altijd maar gelijk en meteen beschikbaar moeten zijn. Dààr krijg je de meeste zeurpieten mee. De meeste stress. Als iets niet echt dringend is, laat ik het meestal juist om die reden even liggen. Over een uurtje is ook goed. Of morgenochtend. Dat vind ik al knap zat. Ik zit er zelf achter, ik gebruik geen chatbots, of andere kunstmatige afserveer en sodemieterop systemen. Met valse namen en zo. Je moet letterlijk voor elke trut of lul zo lief en netjes mogelijk zijn. Maar noooooit teveel haast hebben. Want dan heb je mensen die daar een spelletje van maken, en dan doe je geen oog meer dicht. Waardoor je naar van die chatbots gaat zoeken en zo.
Het recht op instant satisfaction staat niet in mijn grondwet. Punt uit. Dat krijg je ook niet bij de rechter en ook niet bij de AP. Men heeft al mazzel dat ik geen parlement heb, want smoesjes als we gaan eerst een onderzoekscommissie instellen of een enquete en hoe heeft dit nu kunnen gebeuren gaan we allemaal pas over twee jaar in een prachtig dik rapport lezen.
Als ik reboot, dan reboot ik.
Wat een onzin allemaal.
Een risico is er altijd wel, het zou fijn zijn geweest wanneer de AVG in deze had gesproken over een 'hoog' risico om nog enigzins kaders te schetsen en te voorzien in onderbouwing.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.