Column


IT-jurist Peter van Schelven over...

Agile en PIA’s: hoe moet dat?

Al eerder wees ik op knelpunten tussen security en een ‘agile’ aanpak van systeemontwikkeling. De kern van een agile werkwijze is, zoals bekend, dat per sprint van bijvoorbeeld twee of vier weken werkende software wordt opgeleverd. Een agile project kent meerdere sprints en aan het begin van iedere sprint worden de prioriteiten van de gewenste functionaliteit steeds opnieuw afgesproken. Bij een dergelijke wijze van systeemontwikkeling ligt de nadruk veelal op werkende functionaliteit, waardoor al snel het risico ontstaat dat de aandacht voor security achterblijft.

Er is echter nog een ander deelonderwerp dat met betrekking tot een agile wijze van werken tot knelpunten leidt. Dat gaat over de zogeheten Privacy Impact Assessment (PIA). De bron van het probleem is de Algemene Verordening Gegevensbescherming (AVG), die door sommigen in Europa soms veel te letterlijk wordt genomen.

Nieuwe technologie
Wat is het probleem? De AVG heeft een nieuw, inmiddels veelgebruikt instrument voor risicoanalyse geïntroduceerd: de PIA. De AVG zegt dat een organisatie verplicht is een PIA uit te voeren als zij gebruik wenst te gaan maken van ‘nieuwe technologieën’ die ‘waarschijnlijk een hoog risico’ voor de privacy van de betrokken burger inhouden. Een tamelijk open bewoording dus. Met een PIA worden de mogelijke privacyrisico’s in beeld gebracht en het is daarom dan ook niet vreemd dat de AVG voorschrijft dat een PIA in beginsel uitgevoerd moet worden voordat de betrokken persoonsgegevens worden verwerkt.

De gedachte dat een PIA in een vroegtijdig stadium moet worden uitgevoerd, klinkt logisch. Op die manier kan je reeds bij het opstellen van de ontwerpeisen rekening houden met privacy- en securityvriendelijke maatregelen die je in het nieuwe product opgenomen wenst te zien. In modieus jargon: privacy & security by design.

Maar hoe doe je dat dan als de wensen en eisen voor een nieuw systeem niet op één moment in de tijd in één allesomvattend ontwerpdocument worden vastgelegd, maar wanneer over het ontwerp successievelijk op verschillende momenten wordt besloten, bijvoorbeeld bij de start van elke nieuwe sprint? Moet in dat geval steeds per sprint weer opnieuw een (deel van een) PIA worden uitgevoerd?

Flexibiliteit en wendbaarheid
Dat laatste lijkt niet echt verstandig. Een per fase of per sprint uitgevoerde PIA ondermijnt de flexibiliteit en wendbaarheid die eigen is aan een agile manier van werken. Naar ik mij heb laten vertellen komt het – ingegeven door angst die de AVG bij sommige letterknechten kennelijk oproept – voor dat agile projecten belast worden met meerdere tussentijdse PIA’s. Een slechte ontwikkeling, die naar het lijkt is ingegeven door de tekst in de AVG over PIA’s, die niet echt lijkt aan te sluiten bij eigentijdse vormen van projectbesturing. Heeft de Europese wetgever niet echt stilgestaan bij agile werkvormen toen de regeling over de PIA’s werd gemaakt?

En dan spreek ik hier nog maar niet van de door menige privacyjurist gepredikte uitgebreide vastlegging van de onderzoeksresultaten van een PIA. Ook dat frustreert een werkwijze die weinig flexibel is en die op gespannen voet staat met agile werkvormen zoals Scrum. Bovendien verplicht de AVG tot het inwinnen van advies bij de Functionaris voor de Gegevensbescherming (FG), zo die in de organisatie is aangesteld. Ook die verplichting staat op gespannen voet met een goede manier van agile werken.

PIA vereist?
Hoe moet het dan wel? Ten eerste moet binnen veel organisatie nog eens goed worden gekeken of een PIA wel in alle gevallen nodig is. Mijn indruk is dat talloze bedrijven en organisaties – wederom uit angst – nodeloos vaak het instrument van de PIA inzetten. Men vergeet dan al snel dat niet ieder ICT-project tot nieuwe technologie leidt. Heel wat PIA’s worden in de praktijk dan ook louter op vrijwillige basis uitgevoerd.

Ten tweede kan in de gevallen waarin de AVG wel een PIA verlangt op voorhand – dus nog voordat met het agile project gestart wordt – een goed algemeen kader voor privacy- en securityrisico’s worden opgesteld. Waar mogelijk gebeurt dat samen met de FG die is aangesteld. Zo’n kader vormt een belangrijk vertrekpunt voor de verdere systeemontwikkeling en dat kader beheerst vervolgens alle sprints. Dus geen volstrekte vrijheid-blijheid in de sprints. Wie dat met het oog op privacy en security niet ver genoeg vindt gaan, kan er ook voor kiezen om per sprint bijvoorbeeld 20 procent van de beschikbare tijd aan privacy en security te besteden.

Kortom, er zijn mogelijkheden te over om ook in agile projecten PIA’s een verantwoorde plaats te geven. Voor een rigide, tamelijk krampachtige benadering die is ingegeven door de letterlijke tekst van de AVG, ontbreekt een harde noodzaak.


IT-jurist Mr. Peter van Schelven, BIJ PETER – Wet & Recht, laat wekelijks zijn licht schijnen over een opmerkelijke uitspraak of wetgeving binnen het IT-recht. Heeft u een concrete vraag voor Peter? Dan kunt u mailen naar peter.van.schelven@gmail.com. 

Kijk hier voor de eerdere bijdragen van Peter van Schelven.


Lees meer over