Onder meer Nu.nl haakte er op in met samengevat de berichtgeving dat 60% van de (sinds 2016) 181 datalekken niet worden gemeld bij de privacy toezichthouder Autoriteit Persoonsgegevens.
Minder datalekken gemeld, goede of slechte ontwikkeling?
Alhoewel een privacy datalek niet altijd gemeld hoeft te worden, was het percentage niet gemelde datalekken in 2018 met 73,6% zelfs groter dan het gemiddelde van 60%. De toezichthouder is niet op de hoogte van de redenen van het niet melden van een datalek. Deze kunnen immers uiteenlopen en ondertussen gegrond zijn.
Betekent dit automatisch dat dit een slechte ontwikkeling is? In onze optiek niet. Een verandering in de AVG, is dat datalekken te allen tijde (intern) gedocumenteerd moeten worden, ook wanneer het niet aan de toezichthouder wordt gemeld.
Goede AVG ontwikkeling
De stijging van niet gemelde datalekken, zou een positieve ontwikkeling kunnen zijn bij provincies. Het is mogelijk dat het aantal gedocumenteerde datalekken toenam, bijvoorbeeld doordat datalekken met geringe impact voor privacy van betrokkenen vaker werden gedocumenteerd;
Waarom pas in 2018? Wellicht omdat door de AVG deadline op 25 mei 2018, provincies toen pas een beter beleid had liggen, bijvoorbeeld doordat er toen pas sprake was van handhaving of betere richtlijnen voor het melden van datalekken.
Indien dit het geval is, hebben we te maken met een positieve invloed en dus positieve ontwikkeling. Er zou geconcludeerd kunnen worden dat men beter documenteert en wellicht ook betere afwegingen maakt met het oog op de privacy van betrokkenen;
Slechte AVG ontwikkeling
Het is mogelijk dat men minder snel geneigd is om een datalek te melden bij de toezichthouder, bijvoorbeeld wegens angst voor sancties of boetes. In dit geval hebben we te maken met een slechte ontwikkeling. Je kunt immers een datalek beter tijdig melden, dan helemaal niet (c.q. te laat). Dit bewees Uber met een datalek in 2016, die pas in 2017 werd gemeld. Dit zorgde voor een boete van EUR 600.000.
Het scenario dat van toepassing is in het geval van datalekken bij de provincies, is zonder verdere kennis van de type datalekken niet vast te stellen. In die zin sluiten we ons aan bij AP-voorzitter Aleid Wolfsen:
"Dan zou je eigenlijk onderzoek moeten doen naar wat voor type melding het is".
Datalek-boetes door de AP
Onder de AVG wetgeving is het voornamelijk belangrijk dat een datalek binnen 72 uur wordt gemeld bij de Autoriteit Persoonsgegevens. Laat je dit termijn verstrijken, dan wordt de kans op een boete onder de AVG groter.
Meld je het op tijd? Dan zal er een onderzoek worden ingesteld door de toezichthouder. Hier zal wellicht een eis uit voort komen dat een systeem dat bij een verwerkingsproces betrokken is, verbeterd moet worden.
Is er ook sprake van nalatigheid bij verwerker of verwerkingsverantwoordelijke, of zijn verwerkingsregisters of verwerkersovereenkomsten niet op orde, dan kan ook een waarschuwing, sanctie of boete volgen.
Organisatorische lekken lessen
De lering die vooral getrokken kan worden uit de lekken bij de provincie Gelderland, is: betere inrichting en/of gebruik van informatiesystemen. Omroep Gelderland meldt dat verzuimd werd om iedereen een eigen account te geven. Dit heeft als gevolg dat je niet de juiste systeem-beperkingen kunt opleggen, doordat de ene persoon meer moet kunnen doen dan de andere. Een gedeelde account/login is dan niet praktisch. Hierdoor kan er bovendien niet voldaan worden aan verantwoordingsplicht (accountability) onder de AVG wetgeving.
Ook wanneer medewerkers niet meer in dienst zijn, zijn er aanvullende handelingen nodig die eenvoudig vergeten kunnen worden bij gebrek aan juiste organisatorische maatregelen. Denk aan wachtwoord wijzigen of een account op non-actief zetten.
De Functionaris voor de Gegevensbescherming voor de provincie Gelderland sluit af met het volgende: Van de mogelijkheid om in meer dossiers te kijken dan nodig, is geen misbruik gemaakt. Maar omdat niet is vast te stellen of iemand geoorloofd informatie heeft geraadpleegd wegens gedeelde accounts, kan de waarheid van die uitspraak niet gegarandeerd worden.
Voor de juiste technische en organisatorische maatregelen, denken we graag met uw organisatie mee en kunnen we de juiste scans toepassen
Noteer Datalekken in correcte registers
Naast het eerder genoemde artikel, publiceerde de Autoriteit Persoonsgegevens ook een verduidelijking hoe datalekken gemeld en genoteerd moeten worden. Zo bleek uit hun onderzoek dat:
Slechts 60% van de onderzochte registers bevat een complete omschrijving van de verplichte elementen van een datalekmelding (de feiten, de gevolgen en de genomen maatregelen). Ook hebben de organisaties vaak geen strakke regels om datalekken te registeren. Dat maakt het lastig voor de organisaties om structurele fouten aan te pakken.
AVG Cloud Register biedt hierin dé oplossing. Zo voldoet onze AVG Cloud Register datalek-module aan de 10 tips voor betere datalek-registratie van de AP.
Denk hierbij aan tips zoals:
- Overzichtelijk noteren van het incident, van vermoeden van potentieel datalek, tot de uiteindelijke afhandeling en maatregelen om soortgelijke incidenten te voorkomen.
- Welke partijen/organisaties zijn betrokken bij het datalek.
- Of de Autoriteit Persoonsgegevens geïnformeerd is over het lek en wat daarin de afweging is geweest.
- Of betrokkenen zijn geïnformeerd van het datalek. Zo ja, koppel dan het bewijs van die mededeling meteen in je registratie.
- Maar de belangrijkste tip: voorkom versnippering van informatie. Zorg ervoor dat datalekken op een centraal punt worden gemeld en afgehandeld en werk hierin samen.
Onze tooling helpt je hier graag mee. Noteer en monitor datalekken, koppel ze aan de juiste afdelingen en verwerkingen en behoudt overzicht voor je gehele organisatie, niet alleen bij datalekken, maar ook rechten betrokkenen, verwerkingsregisters en DPIA's. Voldoe aan de genoemde AVG documentatieplichten in een centrale en altijd bereikbare cloud-omgeving.
Nog geen oplossing om registers of datalekken te beheren of beoordelen? Start vandaag of neem contact met ons op voor meer informatie.
- ± 4 minutes
LinkedIn
