Wat de IT-professional moet weten

Wat de IT-professional moet weten
Op grond van de nieuwe Europese Algemene verordening gegevensbescherming moet privacybescherming al tijdens de systeemontwikkeling worden meemeegenomen (‘Privacy by Design’, PbD). Ook zijn organisaties in bepaalde situaties verplicht om voorafgaande aan de gegevensverwerking een Privacy Impact Assessment (PIA) uit te voeren. Wat wordt onder PIA en PbD verstaan, en hoe hangen deze samen?
Op grond van de Wet bescherming persoonsgegevens (Wbp) dienen organisaties die persoonsgegevens verwerken “passende technische en organisatorische maatregelen ten uitvoer te leggen om deze gegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking. De maatregelen zijn er mede op gericht onnodige verzameling en verdere verwerking van persoonsgegevens te voorkomen”. Met de laatste zin wordt onder meer gedoeld op Privacy Enhancing Technologies (PET). In de nieuwe Europese Algemene verordening gegevensbescherming (hierna: Avg) is de impliciete verplichting uit de Wbp om privacyvriendelijke informatiesystemen te implementeren geëxpliciteerd. Op grond van de Avg dienen organisaties mechanismen te implementeren die er standaard voor zorgen dat wordt voldaan aan de privacyprincipes (‘Privacy by Default’).1,2 Dit betekent dat privacybescherming al tijdens de systeemontwikkeling zal moeten worden meegenomen (‘Privacy by Design’, PbD). In de Avg is ook de verplichting opgenomen dat organisaties in bepaalde situaties verplicht zijn om voorafgaande aan de gegevensverwerking een Privacy Impact Assessment (PIA) uit te voeren. PbD is niet alleen van belang vanuit juridisch perspectief, maar ook vanuit economisch en maatschappelijk perspectief. Het World Economic Forum (WEF) geeft aan dat de enorme groei in de hoeveelheid en kwaliteit van persoonsgege-vens die digitaal worden verwerkt significante mogelijkheden creëren voor nieuwe vormen van economische en sociale vooruitgang, maar dat de economische waarde van persoonsgegeven wordt bedreigd doordat de stakeholders steeds minder vertrouwen hebben in de gegevensverwerkingen als gevolg van grootschalige datalekken.3
Privacy Impact Assessment
Definitie PIA PIA is “een methodologie voor het vaststellen van de privacy-impact van een project, beleid, programma, dienst, product of ander initiatief en, in overleg met belanghebbenden, het nemen van eventueel noodzakelijke mitigerende acties om een negatieve impact te voorkomen dan wel te verkleinen”4(hierna wordt alleen nog project opgenomen). Met een PIA kan een organisatie privacyrisico’s van een project in een vroeg stadium op een gestructureerde en heldere manier in beeld brengen. Door vroegtijdig inzicht in de belangrijkste privacyrisico’s worden kostbare aanpassingen in processen, herontwerp van systemen of stopzetten van een project voorkomen, en worden juridische kosten en/of negatieve publiciteit gereduceerd. Daarnaast helpt de PIA bij het verhogen van privacybewustzijn binnen de organisatie en het verbeteren van de kwaliteit van gegevensverwerking. Een PIA helpt ook bij het anticiperen en reageren op maatschappelijke privacybezwaren en kan helpen bij het verkrijgen van maatschappelijk vertrouwen doordat de organisatie privacybescherming zichtbaar in het ontwerp van een project meeneemt. Een bijkomend voordeel van de PIA is dat de organisatie aantoonbaar compliant is met privacyregelgeving.
Opbouw PIA Aan de hand van een PIA-vragenlijst wordt vastgesteld wat voor het betreffende project de privacyrisico’s van de gegevensverwerking zijn voor de betrokkenen en voor de organisatie. De soort vragen en de omvang hangen af van zowel het gehanteerde raamwerk als de aard van de gegevensverwerking en de complexiteit van het project. Niet alle vragen zijn relevant voor elke gegevensverwerking en voor niet-complexe gegevensverwerkingen hoeven minder vragen, en vragen minder diepgaand, te worden beantwoord. In figuur 1 zijn de onderwerpen uit het ‘Toetsmodel PIA Rijksdienst’5 vergeleken met die uit de ‘Handreiking PIA’ van de NOREA (beroepsorgani-satie voor IT-auditors).6
Figuur 1. Vergelijking onderwerpen ‘Toetsmodel PIA Rijksdienst’ en ‘Handreiking PIA’. Ter indicatie zijn tussen haakjes het aantal vragen per onderwerp opgenomen.
 
Wanneer uit het antwoord op een van de vragen uit de PIA-vragenlijst blijkt dat er sprake is van een verhoogd risico, dan zou moeten worden vastgesteld wat dit betekent en hoe hier mee wordt omgegaan. Hierbij kunnen de privacyprincipes van de OECD (Organisation for Economic Cooperation and Development) als kapstok dienen. Op welk van de OECD-privacyprincipes heeft dit risico betrekking, en hoe kan het risico worden verminderd? De OECD-privacyprincipes zijn:7
• limitering van datacollectie
• datakwaliteit
• doelbinding
• limitering van gebruik van data
• beveiliging
• transparantie
• rechten van de betrokkenen
• verantwoording In het rapport dat naar aanleiding van het beantwoorden van de PIA-vragenlijst wordt geschreven, moet duidelijk naar voren komen welke privacyrisico’s zijn gesignaleerd en wat hiermee is gedaan om de risico’s te verminderen.
Tijdstip uitvoeren PIA
De PIA is meer dan een tool dat uiteindelijk leidt tot een rapport; het is een proces waarmee in een zo vroeg mogelijk stadium zou moeten worden begonnen. Zowel de Canadese als de Ierse Autoriteit persoonsgegevens waarschuwen in hun PIA-handleiding dat een PIA ook niet te vroeg moet worden uitgevoerd. De resultaten zullen dan te vaag zijn, omdat er nog onvoldoende informatie beschikbaar is over het project, de scope, de voorgestelde informatiestromen, om de privacy-impact goed te kunnen vaststellen waardoor de PIA later alsnog moet worden bijgesteld. Met het PIA-proces zou volgens Wright moeten worden aangevangen wanneer het projectvoorstel klaar is, maar voordat grote voortgang of investeringen zijn gedaan.4
Deelnemers PIA Het heeft de voorkeur dat de PIA-vragenlijst door een team wordt ingevuld omdat de verschillende deelnemers vanuit hun eigen invalshoek het project kunnen bekijken. In de ‘Handreiking PIA’ van de NOREA6 worden de onderstaande rollen onderkend:
• opdrachtgever/initiatiefnemer en investeerder van het project
• opdrachtnemer/verantwoordelijke uitvoering van het project
• opdrachtnemer/verantwoordelijke uitvoering van de PIA
• meedenkers/experts: personen die de organisatie en/of het project goed kennen; experts die deskundig zijn op het onderwerp (onder andere techniek, informatiebeveiliging, privacy, juridische aspecten en organisatorische aspecten); uitvoerders (onder andere systeemontwikkelaars, architecten, productontwikkelaars en beleidsmakers)
• meekijkers/beoordelaars (PIA-assessor)
Niet alle personen zullen continu betrokken zijnbij de PIA-activiteiten. De samenstelling van het PIA-team en de betrokken meedenkers/experts kunnen gedurende de verschillende fasen van het project wijzigen. De IT-professional zal met name in de rol van expert en/of uitvoerder in het PIA-team deelnemen. Naast bovengenoemde interne partijen is het verstandig om ook externe belanghebbenden – bijvoorbeeld (potentiële) betrokkenen – te betrekken bij de PIA waardoor mogelijk ook nieuwe risico’s en impacts worden benoemd. Consultatie is niet alleen een manier om de door de organisatie vastgestelde impact van elk risico en de voorgestelde mitigerende maatregelen met een frisse blik te laten beoordelen, maar hierdoor wordt ook gewaarborgd dat niet alleen rekening wordt gehouden met juridische eisen ten aanzien van privacy maar ook met maatschappelijke tendensen, waarden en acceptatie.
Verplichting PIA Bij de Rijksoverheid is het verplicht om bij de ontwikkeling van wetgeving en beleid – en daarmee gepaard gaande bouw van ICT-systemen en aanleg van databestanden – een PIA uit te voeren.5
Voor de overige sectoren geldt deze verplichting nog niet. In de Avg lijkt die verplichting er wel te komen in de gevallen dat een verwerking van persoonsgegevens bijzondere risico’s ten aanzien van de rechten en vrijheden van de betrokkenen met zich meebrengt. In tegenstelling tot de Rijksoverheid is dit een meer risico-georiënteerde aanpak. Deze verplichting komt terug in alle drie de versies van de Avg (Europese Commissie, Europese Parlement en Raad van Ministers).1,8,9 Afhankelijk van de versie is ofwel in de Avg expliciet aangeven wanneer er sprake is van een bijzonder risico, dan wel is in de Avg opgenomen dat de Autoriteit persoonsgegevens moet vaststellen wat een bijzonder risico is en dat zij deze lijst moet publiceren. Bij bijzondere risico’s kan worden gedacht aan:
• profiling
• verwerking van gegevens over het seksuele leven, de gezondheid, ras of etnische afkomst, et cetera
• bewaking van openbaar toegankelijke ruimte (videobewaking)
• het verwerken van grote bestanden met persoonsgegevens betreffende kinderen, genetische of biologische gegevens
• verwerking van persoonsgegevens die betrekking hebben op meer dan vijfduizend betrokkenen
Privacy by Design
Definitie PbD Op grond van de Wbp moeten organisaties maatregelen treffen om onnodige verzameling en verdere verwerking van persoonsgegevens te voorkomen. Zoals eerder aangegeven, wordt hiermee onder meer gedoeld op Privacy Enhancing Technologies (PET). Het College bescherming persoonsgegevens (CBP, gaat voortaan Autoriteit persoonsgegevens heten) definieert PET als een samenhangend geheel van ICT-maatregelen dat de persoonlijke levenssfeer van burgers beschermt door het elimineren of verminderen van opslag van persoonsgegevens of door het voorkomen van onnodig, dan wel ongewenst gebruik van persoonsgegevens, zonder verlies van functionaliteit (www.cbpweb.nl/Pages/th_pbd_pet. aspx). Aanvankelijk werd de toepassing PET gezien als de oplossing om privacyvriendelijke informatiesystemen te bouwen. Er is echter een meer fundamentele benadering nodig. PET-oplossingen toepassen op bestaande systemen blijkt in de praktijk lastig. Veelal is het een ingrijpende systeemaanpassing en daarom betrekkelijk kostbaar.10 In de jaren 90 introduceerde Ann Cavoukian het concept PbD. PbD is een systeemontwikke-lingsfilosofie dat tot doel heeft het verbeteren van de privacyvriendelijkheid van IT-systemen.11 PbD is een concept waarbij als uitgangspunt geldt dat privacy een van de ontwerpparameters is van het systeem, waar al rekening mee wordt gehouden in de beginstadia van het systeemontwerp. Dit is onafhankelijk van de gekozen ontwikkelingsmethodiek; het geldt zowel voor de watervalmethode als voor agile. In alle drie de versies van de Avg1,8,9 wordt aangegeven dat de verantwoordelijke intern beleid moet vaststellen en passende maatregelen moet implementeren om te voldoen aan de principes van Privacy by Design en Privacy by Default, maar nergens in de Avg wordt aangegeven wat dit precies inhoudt. Van Rest e.a. hebben de volgende, uitgebreide definitie beschreven voor PbD: 12
“Het principe van PbD betekent dat privacy en gegevensbescherming ingebed zijn in de gehele levenscyclus van technieken, vanaf de eerste ontwerpfase tot aan het uitrollen, gebruik en uiteindelijke uitfasering. Als PbD gehanteerd wordt, moet een ontwerpmethode worden gekozen die al die fases omvat.
Privacy en gegevensbescherming zou ingebed moeten worden door het hanteren van ontwerppatronen die goed begrepen zijn en die gelden als ‘best practice’ voor hun doel en gebruiksdomein. Het resulterende ontwerppatroon en systeem moet alle privacyschendende activiteiten omvatten en hun consequenties beperken volgens de zeven principes van PbD”.
Fundamentele principes PbD De zeven principes van PbD waarnaar in de genoemde definitie wordt verwezen, zijn de door Ann Cavoukian beschreven fundamentele principes.11 Deze principes zijn:
1. Proactief in plaats van reactief – preventief in plaats van herstellend: De PbD-benadering wordt gekarakteriseerd door het nemen van proactieve maatregelen in plaats van reactief. Het anticipeert op, en voorkomt inbreuken op iemands privacy voordat deze feitelijk plaatsvinden.
2. Privacy als standaard: PbD streeft naar een maximale privacy door te verzekeren dat persoonsgegevens in een informatiesysteem automatisch afdoende zijn beveiligd.
3. Privacy geïntegreerd in het ontwerp: PbD is geïntegreerd in het ontwerp en de architectuur van informatiesystemen. Het is er niet als los onderdeel aan vastgeplakt, bijvoorbeeld nadat er een privacyschending heeft plaatsgevonden.
4. Volledige functionaliteit – ‘positive-sum’ in plaats van ‘zero-sum’: PbD streeft er naar alle legitieme belangen en doelstellingen op de wijze van een ‘positieve sum’ (oftewel ‘win-win’) te faciliteren, en niet door middel van de ouderwetse ‘zero sum’ benadering, waar onnodig compromissen worden gemaakt.
5. Veiligheid van begin tot eind – bescherming tijdens de volledige levenscyclus: PbD, geïntegreerd in een systeem nog voordat er enige informatie is verzameld, verspreidt zich over de gehele levenscyclus van de betrokken gegevens; krachtige veiligheidsmaatregelen zijn essentieel voor het behoud van privacy, van begin tot eind.
6. Zichtbaarheid en transparantie – houd het open: PbD streeft ernaar alle belanghebbenden bij elke technologie of handelspraktijken ervan te verzekeren dat het systeem feitelijk opereert conform de oorspronkelijk gedane beloftes en doelstellingen, dit geheel ter verificatie door onafhankelijke derden.
7. Respect voor de privacy – laat de gebruiker centraal staan: PbD heeft boven alles architecten en ontwikkelaars nodig die de belangen van het individu als hoogste prioriteit beschouwen, door maatregelen te implementeren zoals krachtige privacy-instellingen, passende informatievoorziening en gebruiksvriendelijke opties.
De zeven principes van Cavoukian zijn minder geschikt als handvatten voor de praktisch/operationele invulling van PbD maar meer ter inspiratie over PbD. Bij de invulling zullen de OECD-privacyprincipes als handvat kunnen worden gebruikt.
Relatie PbD en informatiesysteemontwikkelingsproces Ter ondersteuning van de te nemen PbD-besluiten in de verschillende fasen van het informatiesysteemontwikkelingsproces (conceptontwikkeling, analyse, systeemontwerp, systeembouw, testen en evaluatie) maakt Hoepman13 onderscheid in drie categorieën van hulpmiddelen, te weten:
• ‘Privacy Design Strategies’ (fasen concept-ontwikkeling en analyse);
• ‘Privacy Design Patterns’ (fase systeem-ontwerp); en
• ‘Privacy Enhancing Technologies’ (fase systeembouw).
De mate van detaillering en oplossingsgerichtheid van de drie categorieën van hulpmiddelen neemt van boven naar beneden toe. In figuur 2 is de relatie weergegeven tussen de drie categorieën en de fasen van de informatiesysteemontwikkelingscyclus. Het informatiesysteemontwikkelingsproces is een cyclisch proces waarbij na de evaluatie het concept zo nodig wordt aangepast. De indeling naar hulpmiddelen maken ook het verschil tussen PbD en PET inzichtelijk. PbD omvat alle fasen van het systeemontwikkelingsproces, terwijl PET een categorie van hulpmiddelen is die tijdens de fase systeembouw wordt toegepast. Daarnaast hanteert PbD ter bescherming van de verwerking van persoonsgegevens niet alleen technische maatregelen (zoals PET) maar ook organisatorisch en fysieke. Er zijn op dit moment vele PET-toepassingen beschikbaar die min of meer ‘off the shelf’ toegepast kunnen worden. Ten opzichte van PET-toepassingen zijn er veel minder Privacy Design Patterns beschikbaar. Aan het begin van het project, tijdens de conceptontwikkeling en de analyse, staat de ontwikkelaar op dit moment nog zo goed als met lege handen.13 Naar Privacy Design Strategies moet nog verder onderzoek plaatsvinden.
Figuur 2. Relatie informatiesysteemontwikkelingsfasen en categorieën hulpmiddelen ondersteuning PbD-besluiten
 
PIA in combinatie met PbD
PIA als input voor PbD Kan de PIA als input worden gebruikt voor PbD? In het ‘Toetsmodel PIA Rijksdienst’ staat dat de uiteindelijke beantwoording van de PIA-vragen uit het toetsmodel als basis zal moeten dienen voor technische, beleidsmatige en juridische verantwoording van keuzen.5 In de verordeningversie van het Europees parlement is als amendement opgenomen dat de uitkomsten van de PIA als verplichte input moet worden meegenomen voor PbD.8
Het antwoord op de vraag “Kan de PIA als input worden gebruikt voor PbD?”, lijkt dus met ja te moeten worden beantwoord. Hierbij moeten naar mijn mening wel de volgende kanttekeningen worden geplaatst. Allereerst bestaat het gevaar dat als gevolg van de formulering van de vragen in de PIA-vragenlijst te veel de nadruk wordt gelegd op het wel/niet voldoen aan privacywet-en regelgeving, terwijl het niet voldoen aan de eigen organisatie-en/of maatschappelijke waarden mogelijke een grotere negatieve publiciteit oplevert. Denk maar aan de maatschappelijke verontwaardiging die ontstond toen Equens in 2013 met het idee kwam om pingegevens van klanten door te verkopen, of toen de ING in 2014 een proef wilde doen met het aanbieden van persoonlijke advertenties van derden aan klanten van de ING op basis van hun betaalgedrag. Daarnaast bestaat het gevaar dat bij het zoeken naar oplossingen om de in de PIA gesignaleerde privacyrisico ’s te verlagen, direct wordt gekozen voor het implementeren van mitigerende maatregelen. In dat geval is er niet altijd sprake zijn van een privacyvriendelijker informatiesysteem omdat het product zelf nog steeds privacyonvriendelijk kan zijn. Het PIA-team zou allereerst moeten vaststellen op welk van de OECD-privacyprincipes het risico betrekking heeft. Op basis van ‘Privacy by default’ (Avg) en ‘Privacy as the default setting’ (fundamenteel principe PbD 3) zou, bij gelijkblijvende functionaliteit (fundamenteel principe PbD 4), moeten worden bepaald hoe het inherente privacyrisico kan worden verkleind. Als het risico bijvoorbeeld ligt op het principe van dataminimalisatie, dan zou eerst moeten worden beoordeeld of het mogelijk is om met minder gegevens te werken. Als het echt niet mogelijk is, én het is juridisch en maatschappelijk toegestaan, zou pas moeten worden gekeken welke technische en/of organisatorische maatregelen de organisatie kan inrichten om de kans te verkleinen op het zich voordoen van het risico. Die technische maatregelen zouden dan meegenomen moeten worden bij de conceptontwikkeling, analyse, ontwerp en bouw van het informatiesysteem.
PIA en product-/ informatiesysteemontwikkeling PbD wordt vaak gekoppeld aan het informatiesysteemontwikkelingsproces. De ‘end to end’benadering van PbD betekent volgens mij niet dat je over privacy begint na te denken bij de conceptontwikkeling-en analysefase, maar al bij de beginfase van het product-/dienstontwikkelingsproces. Een te ontwikkelen informatiesysteem staat immers niet op zich, maar staat ten dienste van een te ontwikkelen product/service/dienst/ beleid (hierna wordt alleen product genoemd). De PIA kan/moet dus input leveren aan beide ontwikkelingsprocessen, die immers in elkaar overlopen. In figuur 3 is dit grafisch weergegeven.
 
 
Figuur 3. PIA in relatie tot productontwikkeling en informatiesysteemontwikkeling
 
Eerder in dit artikel is de vraag over het tijdstip van uitvoeren van de PIA aan bod gekomen en is op de schaalbaarheid van de PIA ingegaan. Mijn voorstel ten aanzien van het tijdstip van het uitvoeren van de PIA is niet of/of maar en/en; ten aanzien van de schaalbaarheid van de PIA-vragenlijst is het voorstel deze niet alleen afhankelijk te laten zijn van de aard van de gegevens/betrokkenen, maar ook van het tijdstip. In het begin van het productontwikkelingsproces een ‘light version’ PIA (initiële PIA) en vlak voor de besluitvorming een ‘full scope’ PIA (uitgebreide PIA). De initiële PIA zou tijdens de scopingfase gebruikt kunnen worden om op basis van enkele belangrijke privacyrisico’s een schifting te kunnen maken tussen welke nieuwe productvoorstellen wel/niet verder worden uitgewerkt. Een van de op te leveren ‘deliverables’ van de businesscase-fase zou de uitgebreide PIA moeten zijn. Om vast te stellen dat de uiteindelijk gekozen oplossingsrichtingen tijdens de bouw van het informatiesysteem de onderkende privacyrisico’s hebben weggenomen, dan wel gemitigeerd, wordt geadviseerd om een PIA opnieuw te laten uitvoeren tijdens de ‘testen en validatie’-fase; herijking PIA.
PIA en PbD in relatie tot audit
In de Avg is de verplichting opgenomen dat organisaties aan moeten kunnen tonen dat ze voldoen aan de regelgeving (‘demonstrate compliance’). Dit geldt ook voor de verplichtingen die ontstaan uit de principes van ‘Privacy by Design and Default’. Hoe kan een organisatie aantoonbaar compliant zijn aan wetgeving meenemen bij het ontwerpen van informatiesystemen? Dat wordt een hele lastige gezien het eerder genoemde dat in de verordening geen definitie is opgenomen van PbD. Vanuit auditperspectief zou de organisatie in ieder geval moeten kunnen aantonen dat ‘Privacy by Design and Default’ is geborgd en dat het ze de principes toepast bij specifieke gege vensverwerkingen. Om vast te stellen dat ‘Privacy by Design and Default’ is geborgd in de organisatie zou kunnen worden beoordeeld of de organisatie een privacybeleid heeft (overigens verplicht op grond van de Avg). En zo ja, of daarin is opgenomen dat de organisatie PbD toepast voor de gehele levenscyclus van de gegevensverwerking; dat in het beleid is opgenomen wanneer en voor welke typen gegevensverwerkingen/betrokkenen een PIA moet worden uitgevoerd; welke functionarissen deel uitmaken van het PIA-team; welke vragen worden gebruikt om de privacy-impact te bepalen; hoe wordt omgegaan met het verlagen van gesignaleerde privacyrisico’s (Privacy by Default); et cetera. Daarnaast zou voor specifieke gegevensverwer king moeten worden vastgesteld of wordt voldaan aan de externe en interne privacyregelgeving. Zien we terug dat voor de gehele levenscyclus van de gegevensverwerking is nagedacht over de privacy-impact van de verwerking, en dat ‘Privacy by Default’ de maatstaf is hoe de organisatie hiermee is omgegaan. Dit betekent bijvoorbeeld ook dat de resultaten uit de (initiële en vervolg) PIA, inclusief de gemaakte afwegingen ten aanzien van het wegnemen van het initiële risico’s en/of het implementeren van mitigerende maatregelen, goed moeten zijn gedocumenteerd. Tevens moet zichtbaar zijn dat tijdens alle fasen uit de informatiesysteemontwikkeling de resultaten uit de PIA zijn meegenomen. Goede documentatie is noodzakelijk. Het is zowel richting toezichthouders als betrokkenen (lees: maatschappij) belangrijk dat de organisatie kan aantonen dat zij zorgvuldigheid heeft betracht bij de invulling van de (open) normen uit de privacyregelgeving. Toetsing, respectievelijk maatschappelijke acceptatie zal naar verwachting hierdoor welwillender zijn.
Conclusie
Het is belangrijk dat de IT-professional direct vanaf het begin betrokken is en niet pas bij de bouw van het informatiesysteem. Dit betekent dat de IT-professional deel moet uitmaken van het PIA-team. Hierbij moet hij ervoor waken dat het team niet in de valkuil valt door voor gesignaleerde privacyrisico’s meteen met mitigerende technische en organisatorische maatregelen te komen. Er zal eerst moeten worden geanalyseerd of het inherente privacyrisico, met behoud van functionaliteit, niet kan worden weggenomen/ worden verminderd. De IT-professional moet er vervolgens voor zorgen dat tijdens alle fasen van de informatiesysteemontwikkeling ‘Privacy by Default’ als uitgangspunt geldt voor gekozen oplossingen, waarbij de resultaten van de PIA het startpunt zijn.
 
mr. drs. Jeroen van Puijenbroek RE werkt als expert auditor bij de Audit Rabobank Groep van de Rabobank. Van Puijenbroek is voornamelijk werkzaam op het gebied van het ontwikkelen en (mede)uitvoeren van compliance audits. Daarnaast is hij verbonden aan de Radboud Universiteit Nijmegen waar hij als externe promovendus onderzoek doet naar ‘Privacy by Design’ (J.vanPuijenbroek@cs.ru.nl).
 
[1] Proposal for a Regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), EC, COM (2012) 11 final (25.01.2012)
[2] Wisman, N.M., “De EU Algemene verordening gegevensbescherming: de stand van zaken”, Privacy & Informatie, 2013-2
[3] World Economic Forum. Rethinking personal data: Strenghtening trust, May 2012.
[4] Wright, D., “The State of the art in privacy impact assessment”, Computer Law & Security review, 2012, 28: 54-61
[5] Toetsmodel Privacy Impact Assessment (PIA) Rijksdienst, juni 2013, www.rijksoverheid.nl
[6] Privacy Impact Assessment; Introductie, handreiking en vragenlijst, NOREA, 2013
[7] OECD Guidelines Governing the Protection of Privacy and transborder flows of personal data, C(80)58/Final, 11 July 2013
[8] European Parliament legislative resolution of 12 March 2014 on the Proposal for a Regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), EC, COM (2012) 11 final (25.01.2012)
[9] Council of the European Union preparation for a general approach of 11 June 2015 on the Proposal for a Regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), EC, COM (2012) 11 final (25.01.2012)
[10] Privacy Enhancing Technologies – Witboek voor beslissers, Ministerie van Binnenlandse Zaken en Koninkrijkrelaties, december 2004
[11] Cavoukian, A., “Privacy by design – The 7 foundational principles”, Office of the Information and Privacy Commissioner of Ontario (IPC), January 2011 (revised version)
[12] Rest, J.H.C. van, M.H. Everts, M. van Rijn en R.J.G. van Paassen, “Het ontwerp van Privacy by Design”, Privacy & Informatie, 2012-6
[13] Hoepman, J-H., “Privacy Design Strategies”, IFIP Advances in Information and Communication Technology, Volume 428, 2014, pp 446-459
 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag