AVG voor ontwikkelaars

Nu we al een tijd met deze nieuwe wetgeving werken, kunnen we een eerste inventarisatie maken van het effect van de wetgeving op ontwikkelaars en ontwikkelteams. Wat is er veranderd en waar moeten we tegenwoordig rekening mee houden? In dit artikel een overzicht van de, in mijn ogen, belangrijkste aandachtspunten.

Architecten, teams en eigen verantwoordelijkheid
In de meeste organisaties waar stelselmatig software ontwikkeld wordt, is er voor het werken met gebruikersgegevens inmiddels beleid rondom de privacy wetgeving. Vaak in de vorm van richtlijnen vanuit de Enterprise Architectuur, soms aangevuld met werkinstructies geldend voor afdelingen of teams. Als team en individueel teamlid is dat vaak het eerste kader voor de ontwikkeling van software, maar dit betekent niet dat het daarmee geregeld is. Ook als individuele ontwikkelaar hebben we de verantwoordelijkheid scherp te zijn op de juistheid en rechtmatigheid bij de verwerking van persoonsgegevens en waar nodig vragen te stellen of onjuistheden te signaleren.

Persoonsgegevens
AVG betreft privacy en persoonsgegevens. Het gaat hier over het beschermen van natuurlijke personen bij de verwerking van persoonsgegevens. In andere woorden: in alle gevallen waar we gegevens van mensen verzamelen, verwerken, opslaan, bewaren, etc. Let op: er zijn voor bepaalde instanties en organisaties uitzonderingen gemaakt. Voor bijvoorbeeld politie en justitie kunnen andere of aanvullende bepalingen van toepassing zijn.

Grondslag
Het begint natuurlijk met de vraag waarom en welke persoonsgegevens nodig zijn om te verzamelen, bewerken en opslaan, de grondslag. Dit is vaak niet een beslissing die in een ontwikkelteam gemaakt wordt, maar is er juist een die vanuit de organisatie al is vastgesteld. Het gaat hier namelijk vaak om contractuele verplichtingen, wettelijke verplichtingen of zogeheten vitale belangen. Als klein team of zelfstandige ontwikkelaar kom je hier nog wel eens mee in aanraking. Je klant heeft een goed idee voor een stuk software dat gegevens verzamelt van haar klanten. In die gevallen kun je dus zeker voor elk van de verzamelde gegevens de nodige vragen stellen: • Hebben we toestemming van de gebruiker nodig? • Wat is het belang voor de organisatie (je klant)? • Is er een wettelijke verplichting? • Is er een contractuele verplichting (tussen de klant en haar klanten bijvoorbeeld)?

Toestemming gebruiker
Deze kennen we inmiddels. In de dagen na 25 mei zijn er miljoenen e-mails rondgestuurd door organisaties om klanten en relaties toestemming te vragen voor de opslag van de persoonsgegevens. Als software ontwikkelaar betekent dit, dat je nu ook aan schermen kunt werken voor het verkrijgen van deze toestemming van gebruikers. Bijvoorbeeld door het toepassen van “Privacy by design” of “Privacy by default”, waarbij gebruikers expliciet toestemming moeten geven door een vinkje te zetten (en dat dit dus niet standaard aangevinkt mag staan). Belangrijk hierbij: geldigheid van de toestemming, maar ook het scenario, dat gebruikers deze toestemming moeten kunnen intrekken.

Aanspreekpunt bij de klant
In sommige gevallen heeft de klant een verplichting om een Functionaris Gegevensbescherming (FG) aan te stellen. Dit is iemand die toezicht houdt op de toepassing en naleving van de Algemene Verordening Gegevensbescherming en kan voor ontwikkelaars een aanspreekpunt zijn wanneer er vragen zijn omtrent de AVG. Rijksoverheid, lokale overheden, publieke organisaties, zorg- en onderwijsinstellingen hebben altijd een dergelijke functionaris. Ook wanneer organisaties vanuit hun kernactiviteit op grote schaal individuen volgen of bijzondere eigenschappen vastleggen (etniciteit, geloofsovertuiging) is een dergelijke functionaris verplicht. Hoewel een FG niet voor alle organisaties verplicht is, hebben ze vaak toch 1 aanspreekpunt (in de vorm van een privacy expert).

Privacy Impact Assessment

Organisaties zijn verplicht om op periodieke basis interne systemen en processen te controleren op privacy risico’s en effecten. Een dergelijk assessment heeft als output een rapport, dat inzicht geeft in de compliance, effecten en risico’s van het beheer en verwerken van persoonsgegevens. Dit document wordt vaak door software architecten tijdens het ontwerpen gebruikt, maar is ook voor teams nuttig bij het maken van software.

Bewijslast
AVG is een verordening en in die zin ook gewoon wetgeving. Het is daarom belangrijk, dat we bij de ontwikkeling van de software (ontwerp, realisatie, uitlevering, etc.) zaken vastleggen. De motivatie voor beslissingen bijvoorbeeld. Maar ook de compliance aan regelgeving en de regelmatige evaluatie van de data beveiliging.

Privacy is niet iets wat je makkelijk achteraf aan een applicatie kunt toevoegen. Zeker bij nieuwe software of functionaliteit is het dus belangrijk hier direct bij het ontwerp al mee te beginnen. Welke aspecten hier een rol spelen hangt natuurlijk helemaal af van het type oplossing, maar in het algemeen zullen de volgende onderdelen een rol gaan spelen:

Ethiek
Ethische vraagstukken spelen steeds meer een rol bij het ontwerpen van software. Gaan we goed om met de gegevens van onze eindgebruikers en nemen we geen onnodige risico’s. Stappen we niet te gemakkelijk over misbruikrisico’s heen en programmeren we defensief genoeg? Neemt de software beslissingen op basis van afkomst of overtuiging? Gerichte antwoorden zijn hier niet op te geven, maar het gebeurt nogal eens dat teams onder druk (werkdruk of sociale druk) hier niet voldoende rekening mee houden. Hierbij ontstaat soms de situatie, dat ontwikkelaars werk moeten verrichten dat tegen de AVG in gaat en er voorzieningen moeten komen om dit op te lossen. Denk hierbij bijvoorbeeld aan het kunnen melden bij een Privacy Officer of de eigen People Manager.

Data beveiliging
Het beveiligen van gegevens is niet nieuw (gelukkig), maar er valt altijd wat over te zeggen. De manier waarop systemen en gegevens afgeschermd zijn, moet natuurlijk voldoende gedocumenteerd zijn. Maar data veiligheid gaat ook over het niet onnodig opslaan van gegevens. Het zoveel mogelijk weglaten van identificeerbare gegevens is bijvoorbeeld een prima standaard maatregel.

Data kwaliteit
De kwaliteit van de opgeslagen data moet passen bij het beoogde doel. Het gebeurt soms, dat we uitgebreide persoonsgegevens opslaan voor bijvoorbeeld statistische doeleinden. In die gevallen is het vaak beter om de gegevens in kwaliteit te laten afnemen (bijvoorbeeld door te consolideren) in plaats van in ruw formaat te bewaren. Houdbaarheid en relevantie Het is belangrijk gegevens te kunnen bewaren zolang ze van belang zijn (zie Grondslag). Maar als gegevens niet meer nodig zijn, mogen deze niet onnodig bewaard worden. Het zelfde geldt voor niet-relevante gegevens.

In het software ontwikkelingsproces is het belangrijk, dat het team (en de individuele ontwikkelaar) op de hoogte is van de verantwoordelijkheid die hoort bij het werken met persoonsgegevens. Documenten als het Privacy Impact Assessment Report kunnen hier goed bij helpen, maar een basis kennis van de AVG blijft een vereiste. Gebruik hier voor bijvoorbeeld speciale kennis sessies of maak checklists en integreer deze in het acceptatie proces. Daarnaast is het ook “common sense”. Er zijn veel voorbeelden te bedenken: • We beperken ons tot de noodzakelijke gegevens en slaan niets extra’s op. • Er komen geen direct tot een persoon herleidbare gegevens in logfiles terecht. • Ontwikkelaars hebben geen toegang tot productie gegevens.

De AVG zegt ook iets over het onderhoud van de eigen persoonsgegevens. Dit zijn de bekende 5 rechten: Recht op inzage, Recht op wijzigen, Recht om vergeten te worden, Recht op overdracht en Recht op informatie. In de praktijk betekent dit vaak, dat we hier functionaliteit voor realiseren in onze toepassingen. Denk aan schermen voor het beheren en downloaden van onze persoonlijke gegevens. Ten behoeve van testen of analyseren van data zal een organisatie verzamelde gegevens bewerken alvorens het hiervoor te gebruiken. Technieken als maskeren, anonimiseren, pseudonimiseren en versleutelen spelen hier een belangrijke rol. Ook hoeft er niet altijd echte data gebruikt te worden, maar kan er gewerkt worden met gegenereerde of artificiële data. Hoewel dit zich vaak buiten het zicht van de ontwikkelaars afspeelt, komen ze hier wel mee in aanraking. Bijvoorbeeld bij het gebruik van een OTAP omgeving waarbij de OTA omgevingen gemaskeerde data gebruiken.

Tot slot
De AVG gaat over het beschermen van privacy bij het werken met persoonsgegevens. Deze wetgeving is belangrijk en geldt (op enkele uitzonderingen na) voor alle organisaties in Europa. Maar ook organisaties buiten Europa moeten zich aan deze wet houden wanneer zij werken met persoonsgegevens van Europese burgers. Van software ontwikkelaars en software architecten mag verwacht worden, dat zij ten minste een basis kennis van de AVG hebben, hier naar te handelen en de verantwoordelijkheid nemen onjuistheden tijdig te signaleren. Hulp nodig bij het werken met de AVG in ontwikkelteams? Neem contact op met VX Company voor meer informatie.

• Infographic: AVG voor ontwikkelaars
• Meer informatie over de AVG