ik kreeg de volgende tekst aangeleverd van de PO-er "Datalekmeldingen zijn interne meldingen en vallen niet onder de definitie archiefbescheiden". 

Dit lijkt mij niet juist. hoelang moet je meldingen datalekken bewaren?

Weergaven: 1267

Hierop reageren

Berichten in deze discussie

Een datalek meld je toch aan de AP (en onder omstandigheden aan de betrokkenen)? Dan is het dus niet intern, tenzij je bij de AP werkt :-).

 Deze datalekken staan benoemd in de selectielijst bij categorie 29.1 (Aangifte doen - Afgehandeld). De termijn is 5 jaar na afhandeling.

Ik kan me voorstellen dat er wel een intern proces is, voordat de melding naar de AP gaat. Volgens mij kun je dit als onderdeel van het 'aangifte doen'-proces zien. Als je ze per se wilt opknippen, zou het interne proces (denk ik) een soort evaluatie zijn. Je evalueert dan op basis van een interne melding/controle of er sprake is van een datalek (waarna je aangifte doet).  Dan zit je in categorie 4.1 (10 jaar na afhandeling).

Hallo Hennie,

meldingen van datalekken kunnen ook door verwerkers aan de organisatie worden gemeld. Daarmee is het net geheel intern. De datalekken moeten vervolgens door de organisatie worden gemeld aan de Autoriteit Persoonsgegevens.

Dat interne meldingen geen archiefbescheiden zijn, is natuurlijk een hele rare opmerking. In theorie dien je zelf gegevens op een backup moeten zien als archiefbescheiden. Of iets intern of extern is, heeft niks met de archiefwaardigheid van de informatie te maken.

In de gemeentelijke selectielijst valt een datalek onder resultaat 29.1 met een bewaartermijn van 5 jaar. Dat heeft er mee te maken dat een betrokkene de organisatie drie jaar lang aansprakelijk kan stellen voor geleden schade.

De gemeente dient zich dus te verantwoorden voor een datalek en daarmee zijn het duidelijk archiefbescheiden.

Het bewaren van onderzoek na een melding van een datalek, is zoals anderen al stelden gewoon geregeld via de selectielijst. Dat betekent overigens niet dat het betreffende dossier voor iedereen beschikbaar moet zijn: bewaartermijn en geautoriseerde toegang zijn 2 kanten van dezelfde medaille.

Een datalek hoeft overigens lang niet altijd bij de AP gemeld te worden: er zijn meldingsplichtige datalekken en datalekken die dat niet zijn. De AP kan overigens ook niet-meldingsplichtige datalekken ontvangen. De praktijk is dat nog veel datalekken "voor de zekerheid" bij de AP gemeld worden. Voor de archivering is dit onderscheid niet relevant.

En het addertje zit hem in de "na afhandeling". Immers, een datalek, en dus ook de melding, kan van aard veranderen.

Dit slaat concreet op zaken als encryptie. De kans bestaat dat bij vaststelling van het lekken van versleutelde data de betreffende encryptie volledig voldoet aan de eisen van dat moment ("neem passende technische en organisatorische maatregelen", aldus de AP). Er wordt dus een melding gedaan bij de AP, zonder dat er verdergaande consequenties zijn, op dat moment

Echter, de techniek schrijdt voort, waardoor de gelekte en versleutelde data alsnog (eenvoudig) volledig leesbaar wordt gemaakt. Het datalek dat afgesloten leek, blijkt ineens toch een bestaand (en openstaand) datalek te zijn. De zaak dijt uit, mogelijk moet bijvoorbeeld alsnog wél melding bij eventueel gedupeerden worden gedaan.

In dergelijke gevallen is het zeer verstandig om toch nog te kunnen beschikken over alle (noodzakelijke) gegevens...

Peter,

Maak het a.u.b. niet nog ingewikkelder dan de AVG al heeft gedaan. Natuurlijk kan het scenario dat jij beschrijft werkelijkheid worden. De vraag is m.i. wel of je voor elk denkbaar scenario zo moet redeneren en daar je huidige archiveringsstrategie op moet richten.

Juridisch lijkt me zeer goed verdedigbaar dat met de kennis van vandaag wordt beoordeeld of er sprake is van een reële kans op misbruik. De beveiliging van vandaag is dan de norm, niet die van morgen. "Passende maatregelen" moeten dus door de organisatie aangetoond worden. Een encryptie die vandaag de dag algemeen als voldoende wordt beschouwd is dan de maatstaf. De FG moet zich m.i. daarin adviseren door de eigen CISO (eventueel geholpen door deskundigen als de IBD) en de richtlijnen of eventueel het adbies van de AP. Voor het laatste lijkt de AP momenteel niet veel tijd te hebben.

"Case closed" is dan ook het moment waarop het onderzoek van het datalek is afgesloten (met een besluit tot geen verdere actie), dan wel het moment dat de melding bij de AP is afgerond en lopende acties richting betrokenen, publiek, pers en bestuur zijn afgerond. Vanaf dat moment gaan 5 jaar tellen en daarna gaat de boel de vernietiger in, behalve als er tussentijds een vervolgzaak is gekomen die leunt op deze zaak. Jouw scenario is daar een voorbeeld van, mits blijkt dat aannemelijk is dat de gelekte data op een moment X ontsleuteld zijn en zich in verkeerde handen bevinden. Dat is m.i. aanleiding voor een nieuwe melding bij de AP. Ik schat dat de kans op dit scenario heel gering is.

Kortom: vernietiging van minstens 99,99% van de afgehandelde gebeurt gewoon op basis van de bewaartermijnen in de selectielijst.



Peter Glebbeek zei:

En het addertje zit hem in de "na afhandeling". Immers, een datalek, en dus ook de melding, kan van aard veranderen.

Dit slaat concreet op zaken als encryptie. De kans bestaat dat bij vaststelling van het lekken van versleutelde data de betreffende encryptie volledig voldoet aan de eisen van dat moment ("neem passende technische en organisatorische maatregelen", aldus de AP). Er wordt dus een melding gedaan bij de AP, zonder dat er verdergaande consequenties zijn, op dat moment

Echter, de techniek schrijdt voort, waardoor de gelekte en versleutelde data alsnog (eenvoudig) volledig leesbaar wordt gemaakt. Het datalek dat afgesloten leek, blijkt ineens toch een bestaand (en openstaand) datalek te zijn. De zaak dijt uit, mogelijk moet bijvoorbeeld alsnog wél melding bij eventueel gedupeerden worden gedaan.

In dergelijke gevallen is het zeer verstandig om toch nog te kunnen beschikken over alle (noodzakelijke) gegevens...

Antwoorden op discussie

RSS

© 2024   Gemaakt door Marco Klerks.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden