Wat moet je onder de AVG doen met ongewenst verkregen persoonsgegevens?

Een lezer vroeg me:

Af en toe krijgen wij als PC-reparateurs per mail allerlei persoonlijke informatie van klanten gemaild, ongevraagd. Denk aan een verslag wat er misging, maar soms ook medische of andere gevoelige gegevens. Soms zelfs van collegabedrijven die ons als tweedelijns ondersteuning inschakelen. Dat is een probleem onder de AVG, want die mail is natuurlijk onbeveiligd. Wat moeten wij daar mee?

Inderdaad ben je onder de AVG verplicht zorgvuldig met persoonsgegevens om te gaan die je binnenkrijgt, en het doet er niet toe of je gevraagd hebt om die gegevens. Maar het is niet zo dat je per direct een boete krijgt wanneer iemand je ongevraagd zijn medisch dossier mailt, of zelfs maar dat die persoon een schadeclaim kan indienen. Zolang je maar adequaat je mail monitort op dergelijke gegevens, en ze wist zodra duidelijk is dat ze irrelevant zijn.

Wanneer de gegevens van een collega komen, wordt het een iets ander verhaal. Die collega is verantwoordelijke voor die gegevens, en mag ze niet zomaar aan een derde verstrekken. Dat mag in dit soort situaties eigenlijk alleen als jij als verwerker (voorheen: bewerker) bent aangesteld en er een verwerkersovereenkomst tussen jou en hem is gesloten, waarin staat dat jij in de uitvoering van je PC-reparaties persoonsgegevens kan ontvangen, dat je daarmee zorgvuldig om zult gaan et cetera. Die zal er dus sowieso moeten komen.

Nog steeds ben je dan niet schadeplichtig als je die mails binnenkrijgt en er adequaat op reageert. Maar hij is dat wel: hij verstrekt persoonsgegevens aan derden zonder afdoende maatregelen te hebben genomen. Dus de bal ligt bij hem om hier wat aan te doen. Hooguit ontstaat voor jou een probleem als dit stelselmatig gebeurt en je nooit eens een escalatie opstart om hier een einde aan te maken (of een verwerkersovereenkomst te sluiten).

Arnoud

16 reacties

  1. Hoe werkt dat eigenlijk met oude facturen e.d. Ik neem aan dat (als je het netjes/veilig doet) wel gewoon een archief mag hebben voor je administratie. Clubs e.d. hebben vaak ook een leden/contributie administratie waar gegevens van oud leden in staan, die worden soms tijdens feestelijkheden benadert etc.

    1. Natuurlijk mag je een archief hebben voor je administratie; sterker nog dat móet je. Zo’n wettelijke plicht betekent automatisch dat je de gegevens niet hoeft te wissen. De wisplicht (en het recht te worden vergeten) gelden altijd pas als er geen recht meer is de gegevens te hebben.

      Een administratie met oud-leden is wat spannender. Die betalen niet en hebben geen verplichtingen, wat doen die in je administratie? Ik denk dat je daar echt een apart bestand van moet maken en in je privacyverklaring moet melden hoe lang je oud-leden in het snotje houdt (en hoe ze verzet kunnen uitoefenen tegen jouw jaarlijkse oproep voor de reünie).

  2. Begrijp ik het goed dat een bedrijf als de Media Markt met elke leverancier waar ze mogelijk een defect apparaat naar toe gaan sturen waar persoonsgegevens op kunnen staan (pc, laptop, telefoon, tablet, mediaspeler etc) een verwerkersovereenkomst gesloten moet hebben. En dat geldt dan natuurlijk ook voor elke PC- en telefoonboer op de hoek.

      1. Wij lopen na helpdesk vragen tegen het feit aan dat sommige van onze klanten BSN hebben opgeslagen in commentaar velden, omdat dat zo handig is.

        Dit is dus niet de bedoeling. Wij hebben bewust geen veld voor BSN nummers in de invoer/database, omdat er ons inziens geen wettelijke grond voor is. Daarnaast hebben wij geen mogelijkheid om dit te controleren als het in een algmeen commentaarveld is toegevoegd.

        Feit is dat wij zo dus wel onbedoeld zonder wettelijke grondslag BSN nummers opslaan voor onze klanten. En verwerken van bijzondere persoonsgegevens vereist ook een strenger privacy beleid onder zowel de huidige als de nieuwe richtlijn. Waarschijnlijk binnenkort een mailing eruit dat dit echt niet de bedoeling is en het verzoek dit niet (meer) te doen en deze gegevens te wijzigen, maar wie zegt dat iedereen daar gehoor aan geeft?

          1. We zouden de 11 proef op ieder getal uit de tekst kunnen toepassen.

            Dit veld wordt echter ook vaak gebruikt wordt om tweede unieke indentificatie mee te geven en zou gezien de hoeveelheid records gegarandeerd vele false positives opleveren.

            Dan kunnen we wellicht een waarschuwing tonen bij het invoeren. Blokkeren is echter geen optie, niet alles wat aan de 11 proef voldoet is een BSN.

            En handmatig controleren gaat in tegen de overeenkomst met de klant, wij hebben standaard de toegang niet om in hun data te kijken, dat kan alleen de database beheerder. Het is economisch niet haalbaar dit handmatig te doen, als we de toegang al hadden.

            1. Oké, dan zou ik zeggen: 11-proef gevolgd door een clientside waarschuwing “Het lijkt erop dat u een BSN heeft ingevuld in dit veld. Het versturen van BSNs via dit formulier is wettelijk verboden. Als dit getal geen BSN is, vink dan onderstaand vakje aan.” bijvoorbeeld?

              Als je geen toegang hebt tot hun data, dan is het toch ook geen issue dat er een BSN in hun data zit?

                1. 7% van de 9 cijferige nummers voldoen aan de 11-proef (inclusief nummers met voorloop nullen). De kans op een botsing met een BSN is dus vrij reëel.

                  Als een partij besluit een eigen unieke Id te hanteren die hetzelfde aangepaste systeem hanteert als voor het BSN nummer, dan is het geen BSN nummer en krijg je 100% false positives.

                  Tevens kan een vrij veld ook gebruikt worden voor BTW nummers, maar dat zou je kunnen afvangen door op een Bxx suffix te testen.

                  Ik zou dus niet te snel roepen dat het wel mee zal vallen.

              1. Uiteindelijk heb je als de beheerder van de database als het moet altijd een ingang. In ons geval de database beheerder. Contractueel mogen anderen er niet in en daar zien we op toe. De database beheerder snuffelt ook niet rond, al zou hij dat wel kunnen.

                Was het bij de helpdesk niet boven tafel gekomen, dan hadden wij dus ook niet geweten van de opslag van BSN nummers. Het probleem : nu weten we dat het gebeurten heb ik het idee dat we het niet zomaar kunnen negeren. Het idee van cijfer invoer checken met de 11-proefen actief laten afvinken dat het geen BSN is/de waarschwing is gelezen bevalt mij wel. Ik zou het dan wel maar 1 keer per dossier doen, als iemand de waarschuwing gelezen heeft en actief negeert lijkt het mij zijn verantwoordelijkheid.

          2. Dat lijkt me toch de omgekeerde wereld. Wie moeten dat dan allemaal gaan implementeren, en welke checks moeten daar nog meer bijkomen? Er is geen houden aan. Ga jij een BSN-check toevoegen aan je blog-software? Mensen kunnen hier ook hun BSN posten.

  3. En hoe ga je dat doen als een e-mail zowel privé gegevens bevat die je niet nodig hebt voor de uitvoering van een opdracht als gegevens bevat die nodig zijn? Die combinatie komt voor en het gelijk verwijderen van die e-mail maakt het uitvoeren van de opdracht mogelijk zelfs onmogelijk, helemaal als je discussie krijgt over de opdracht wordt dat relevant.

      1. Nee want je moet een mailarchief bijhouden om je opdrachten terug te kunnen traceren, al was het maar in het geval van geschillen. Volgens mij valt ‘documentatie/bewijsmateriaal voor het geval er een geschil is’ onder noodzaak voor de uitvoering. Ik denk dat als je die mail ergens opslaat na afhandeling en er verder niks mee doet, dat je dan niet meer hebt gedaan dan noodzakelijk.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.