GDPR voor developers: praktische tips

Er bestaat al gigantisch veel informatie over GDPR. Informatie voor CEO’s, CIO’s, marketing managers… maar GDPR voor developers? Amper. Daar willen we met deze blogpost verandering in brengen. Wat moet je als developer weten over GDPR? En welke praktische tips kunnen we je geven?

GDPR voor developers: wat is relevant?

GDPR voor developersGDPR draait om de bescherming van persoonsgegevens. Dus is het belangrijk om te weten wat GDPR beschouwt als persoonsgegevens. Het gaat om alle data die kan worden gebruikt om een ​​persoon, of gegevens die over een reeds geïdentificeerde persoon bestaan, te identificeren. Daarbij gaat het in de eerste plaats om gegevens die de gebruiker expliciet heeft verstrekt. Maar ook gegevens die je over hem hebt verzameld via derden of op basis van hun activiteiten (welke pagina’s bekeken ze, wat hebben ze gekocht, enz.)

Als we de volledige GDPR wettekst doorlopen kunnen we er de dingen uithalen die relevant zijn voor developers. Het gaat om een aantal basisprincipes en de daarbijhorende rechten die gebruikers krijgen. Uiteraard kunnen we hier niet alles in detail beschrijven, maar je krijgt wel de belangrijkste elementen mee.

De volgende basisprincipes uit GDPR zijn relevant voor developers:

  • Minimalisering van data (je mag niet meer persoonsgegevens verzamelen dan nodig)
  • Integriteit van data (persoonsgegevens moeten dus juist en volledig worden bijgehouden)
  • Vertrouwelijkheid van data (persoonsgegevens moeten vertrouwelijk behandeld worden)

Daaruit volgen een aantal rechten van gebruikers (in de GDPR-wetgeving zijn dat de “datasubjecten”) waar je als developer ook rekening mee moet houden:

  • actieve toestemming geven (een gebruiker moet actieve toestemming geven om zijn persoonsgegevens te bewaren en te gebruiken)
  • geinformeerd worden (een gebruiker heeft recht op een begrijpelijke en korte privacyverklaring in plaats van uitgebreide algemene voorwaarden)
  • gegevens inkijken (een gebruiker moet alle gegevens kunnen inzien die over hem verzameld zijn)
  • gegevens aanpassen (een gebruiker moet zijn gegevens zelf kunnen aanpassen of kan vragen om dat te doen)
  • gegevens verplaatsen (een gebruiker moet zijn gegevens zelf kunnen exporteren of kan vragen om dat te doen)
  • verwijderd worden (een gebruiker moet zijn gegevens zelf kunnen aanpassen of kan vragen om dat te doen)

Wat betekent dat concreet voor GDPR voor developers?

Als developer zal je een aantal features moeten voorzien die het gebruikers mogelijk maken om hun rechten te kunnen uitoefenen. Dat hoeven niet noodzakelijk volledig geautomatiseerde processen of features te zijn. Dat staat nergens in GDPR, maar het is logisch dat automatisering de zaken wel vereenvoudigt.

Actieve toestemming

Gebruikers moeten vanaf nu actieve toestemming geven om hun persoonsgegevens te bewaren en te gebruiken voor alle zaken die niet  contractgerelateerd zijn. Om het met een voorbeeld uit te leggen: wanneer je gegevens verzamelt om een verzending te doen of een factuur te sturen heb je daar geen toestemming voor nodig. Als je die gegevens wil gebruiken voor marketingdoeleinden of voor customer profiling wel.  Dat betekent dat er voor elke van deze activiteiten toestemming moet gevraagd worden. Dat kan via checkboxes, een keuzemenu, een profielpagina, enz. De keuzes mogen evenwel niet vooraf ingevuld zijn. Gebruikers moeten actief aangeven wat ze willen en moeten ook ten allen tijde hun keuze kunnen veranderen. Die actieve toestemming moet overigens gevraagd worden aan alle gebruikers, dus ook degene die nu al in je database zitten.

Gegevens inkijken/aanpassen

Je moet een proces of feature voorzien waarbij gebruikers de over hen bewaarde gegevens kunnen inkijken en/of aanpassen. Gebruikers moeten in staat zijn om alle gegevens over zichzelf aan te passen of te laten aanpassen. Dat is inclusief gegevens die je hebt verzameld uit andere bronnen. Een goede vuistregel: alle velden in je tabel van gebruikers zouden aanpasbaar moeten zijn via de gebruikersinterface. Technisch gezien mag een aanpassing handmatig worden uitgevoerd. Dat is uiteraard wel duurder dan via een formulier of een web interface.

Gegevens exporteren

Je moet gebruikers toelaten om alle data van een datasubject of betrokkene te exporteren. Wat dat precies inhoudt, zal allicht van gebruiker tot gebruiker verschillen. Normaal zijn het op zijn minst de gegevens die je verwijdert met de “vergeet mij” -functionaliteit. Er kunnen echter nog extra gegevens zijn (bestellingen die een gebruiker heeft gedaan zal je niet verwijderen, maar moeten wel in de export zitten bijvoorbeeld). De structuur van de export is niet strikt gedefinieerd, maar moet leesbaar zijn. Denk dus aan JSON, XML, CSV of Excel. Als het exporteren van gegevens lang duurt, is het aangewezen om de gebruiker dat te laten weten. Je kan hem of haar  dan via e-mail op de hoogte te stellen wanneer de gegevens klaar zijn.

Gegevens bewaren

Als je gegevens voor een specifiek doel hebt verzameld (bijvoorbeeld registraties voor een evenement), moet je ze anonimiseren of verwijderen zodra je ze niet meer nodig hebt. Je hebt dus een scheduled job/cron nodig om op regelmatige basis de gegevens te anonimiseren of verwijderen. De GDPR-wetgeving geef geen concrete timing.

Gegevens verwijderen

Je moet een manier hebben om alle persoonlijke gegevens over een gebruiker te verwijderen, voor zover die zijn verzameld op basis van actieve toestemming of legitieme belang. Gegevens die nodig zijn voor contractgerelateerde redenen of omwille van een wettelijke verplichting mogen bewaard worden, maar ook hier moet een duidelijke levenscyclus van de data gedefinieerd worden (bijvoorbeeld tot enkele maanden na het einde van de contractduur). Vroeg of laat moeten persoonsgegevens dus altijd verwijderd kunnen worden. Deze mogelijkheid tot verwijdering is een verplichting. Een excuus als “ons datamodel staat het niet toe” gaat dus niet op.

Hoe zit het met back-ups? Idealiter zou je een afzonderlijke tabel moeten bijhouden met verwijderde gebruikers. Zo kan je  telkens wanneer je een back-up terugzet, die gebruikers opnieuw verwijderen. Dit betekent dat die tabel zich dus in een aparte database moet bevinden en een afzonderlijke back-up en herstelproces moet hebben.

Het is ook niet voldoende om de gegevens enkel uit je eigen database te verwijderen. Als je werkt met andere partijen (denk aan CRM- en ERP-systemen, Salesforce, Hubspot, maar ook cloud providers bijvoorbeeld) moeten ook daar de gegevens verwijderd worden. Daar zal dus een API call voor nodig zijn. Wanneer die gegevens ook ergens online te vinden zijn – via een Google zoekopdracht bijvoorbeeld – moet je ook zorgen dat ze daar onvindbaar worden.

Technische maatregelen

Dit alles impliceert uiteraard een aantal technische maatregelen. Daarbij de scheidingslijn tussen de developer en de systeembeheerder wat vager. GDPR gaat nergens concreet in op technische maatregelen. Een risicoanalyse kan bepalen wat je best doet. Onderstaand lijstje is dus geen verplichting, maar het kan zeker geen kwaad om deze dingen te overwegen of te implementeren.

  • Encrypteren van data in transit
  • Encrypteren van data in rust
  • Encrypteren van back-ups
  • Pseudonimisering
  • Authenticatie voor het aanpassen van data
  • Dataregister van verwerkingsactiviteit
  • Registratie van toegang tot persoongegevens (zowel read- als write-acties moeten gelogd worden)
  • Registratie van alle API’s
  • Integriteitschecks zoals verplichte Velden, rekenregels, dropdown lijsten,…

Let op: GDPR voor developersgaat niet enkel om de dingen die we in deze blogpost aanhalen. Als je dit allemaal doet ben je nog niet GDPR compliant. Bekijk dus zeker ook de rest van de wetgeving een keer in detail.

 

 

Maak het je gemakkelijk met iubenda

Iubenda is een tool die ontwikkeld is om ervoor te zorgen dat jouw website altijd in orde is met de GDPR. Zo schrijft iubenda een privacy en cookie policy voor jouw website én maak je er een cookiebanner mee in jouw huisstijl.

iubenda-scan