Privacyrecht is code
Einde inhoudsopgave
Privacyrecht is code (R&P nr. ICT1) 2010/6.2.1:6.2.1. Juridische specificaties
Privacyrecht is code (R&P nr. ICT1) 2010/6.2.1
6.2.1. Juridische specificaties
Documentgegevens:
drs. J.J.F.M. Borking, datum 26-05-2010
- Datum
26-05-2010
- Auteur
drs. J.J.F.M. Borking
- JCDI
JCDI:ADS580007:1
- Vakgebied(en)
Civiel recht algemeen (V)
Toon alle voetnoten
Voetnoten
Voetnoten
Deze ordening van privacyuitoefeningsbeginselen is door de Landesbeauftragter für den Datenschutz in Schleswig-Holstein (ULD) opgesteld voor het doen van privacyevaluaties in het kader van de programma van de ULD betreffende de '`Giltesieger voor IT Producten en Diensten', https://www.datenschutzzentrum.de/guetessiegel/.
S. Paulus is Senior Vice President Product Security Governance bij SAP.
Paulus, 2008, p.6-7, beschikbaar op hnp://prise.oeaw.ac.aticonf contrib.htm.
Deze functie is alleen te gebruiken als je bent ingelogd.
Om een PRIVIS te ontwerpen, dienen de in paragraaf 2.13 vermelde juridische specificaties,1 in het ontwerp te worden meegenomen:
Beginselen die aan de basis van PRIVIS-ontwerp ten grondslag liggen:
Gegevensminimalisatie (maximale anonimiteit, zo min mogelijk gegevens en zo vroeg mogelijke verwijdering van data).
Transparantie of openheid betreffende de verwerking.
Beveiliging conform de privacyrisico-, bedreigings- of impactanalyse.
Beginselen met betrekking tot de rechtmatige verwerking. De verwerking in het informatiesysteem dient zodanig te zijn ingericht dat de volgende privacyrealisatiebeginselen worden gerealiseerd:
Rechtmatigheid (bijvoorbeeld toestemming)
Bescherming van speciale categorieën persoonsgegevens.
Finaliteit, doelbinding van de te verwerken persoonsgegevens.
Kwaliteit van gegevens. Voor een uitvoerige opsomming van de vereisten onder deze specificatie wordt verwezen naar paragraaf 2.5.8.
Rechten van het persoonsgegevens genererende individu. Het systeemontwerp dient twee situaties te onderscheiden:
De persoonsgegevens die worden verkregen van de betrokkene.
De persoonsgegevens worden op een andere manier verkregen.
De inrichting van het systeem dient zodanig te zijn dat voldaan wordt aan:
Informatievereisten o.a. over wie de verantwoordelijke is.
Melding van de verwerking van persoonsgegevens.
Inzage, correctie, verwijdering, blokkering.
Verzet tegen verwerking.
Gegevensverkeer met landen buiten de EU en EEA. De overdracht van persoonsgegevens aan een derde land (d.w.z. niet een lidstaat van de EU, EEA of land of instantie waarvan de adequate bescherming van persoonsgegevens door de EU-Commissie is vastgesteld) is slechts toegestaan als het land in kwestie een adequate mate van bescherming biedt. Derhalve dient in het systeem de bestemming van de gegevens geverifieerd te worden en wanneer de gegevens niet verzonden mogen worden, dient de verwerking te worden geblokkeerd.
Specifieke restricties op bepaalde vormen van gegevensverwerking ex Richtlijn 2002/58/EG2 en speciale eisen uit de Richtlijn 2006/24/EG.
Van belang is Overweging 46 van Richtlijn 95/46/EC, die benadrukt dat:
"the protection of the rights and freedoms of the individuals with regard to the processing of personal data requires that appropriate technical and organisational measures be taken, both at the time of the design of the processing system and at the time of the processing itself' en
Overweging 30 van Richtlijn 2002/58/EC waarin staat dat:
"systems for the provision of electronic communications networks and services should be designed to limit the amount of personal data necessary to a strict minimum".
Paulus3 wijst erop dat de juridische vereisten evenwel niet direct bruikbaar zijn als technische ontwerpvereisten voor software engineering, als niet vooraf zowel de verantwoordelijkheid als het concrete technische gebruik is vastgesteld. Voor generieke softwarepakketten is dat een probleem. Is de bouwer, de systeemintegrator of degene die het systeem heeft aangeschaft en gebruikt verantwoordelijk (afhankelijke van de gesloten overeenkomst) of zijn zij dat allemaal? Het antwoord op deze vraag heeft gevolgen voor het ontwerp. Bijvoorbeeld: de functie in de applicatie die te maken heeft met het verwijderen van data kan in het ontwerp worden ingebouwd. De systeemintegrator kan het gebruik van deze functie in het systeem configureren, maar de feitelijke beslissing om de data te laten verwijderen, is de verantwoordelijkheid van degene die het systeem gebruikt. Of moet deze functie zo worden gebouwd dat de verwijdering altijd automatisch plaatsvindt?
Een ander voorbeeld: het privacyrealisatiebeginsel, dat gegevens moeten worden opgeslagen conform het doel waarvoor de data zijn verzameld, dient in de programmatuur in functies te worden gedefinieerd. Deze juridische formulering verbiedt bijvoorbeeld niet dat 'data warehousing' na de opslag plaatsvindt. Ten slotte: als de ontwerpspecificatie inhoudt dat door het systeem op het scherm de boodschap moet worden weergegeven "verwijder privacy gerelateerde data", dan moet eerst de verwijderfunctie worden ontwikkeld en vervolgens zal het begrip "privacy gerelateerde data" sluitend moeten worden gedefinieerd zodat iedere ontwerper op dezelfde wijze ermee om kan gaan. Anders bestaat er geen zekerheid dat inderdaad alle "privacy gerelateerde data" zijn verwijderd.4
Samenvattend: het ontwerp van PRIVIS dient rekening te houden met de hiervoor vermelde juridische specificaties, de uitkomsten van de privacyrisico-, privacybedreigings- of privacyimpactanalyse, het daarbij noodzakelijke beveiligingsniveau en de in te zetten PET-maatregelen.