5.12.5. Privacyrealisatiebeginselen in het systeemontwerp

Het systeemontwerp dient de privacyrisico 's die zijn vastgesteld in de privacybedreigings analyse, af te dekken. Uit de privacybedreigingsanalyse (zie in paragraaf 4.9 de pentagonale aanpak) is gebleken, dat de relevante bepalingen uit de privacywetgeving vaak door ontwerpers worden vergeten, terwijl uit de wetgeving rechtstreeks een aantal relevante bedreigingen zijn te distilleren. De privacywetgeving dient dan ook een sterke invloed op het ontwerp te hebben. De systeemontwerper zal de rechten en verplichtingen voortvloeiende uit de privacy-richtlijnen in het systeem zodanig moeten construeren dat deze in het verwerkingsproces niet omzeild kunnen worden.1 De onderzoekers in het PISA-project stelden vast dat de privacywetgeving complex is en vele uitzonderingen op de regels kent. De ontologie ontwerpers hadden geen softwaremiddelen tot hun beschikking om de complexe en verfijnde juridische taal één-op-één in de programmatuur in te voeren. De privacyrichtlijnen werden niet alleen als complex, maar ook als te abstract beschouwd om direct daaruit technische specificaties te genereren. Een te hoog abstractieniveau kan tot te veel van elkaar afwijkende interpretaties leiden. Dit kan ernstige fouten in de architectuur tot gevolg hebben. De oplossing die de onderzoekers kozen, was om te werken met een vereenvoudiging van de wetgeving. Die werd voornamelijk gevonden in het gebruik van de stabiele privacyrealisatiebeginselen (zie hoofdstuk 2), zonder de mogelijkheid te verliezen om later meer aspecten van de wet te integreren wanneer de omstandigheden dat zouden vereisen. Bijvoorbeeld: medische persoonsgegevens worden beschouwd als privacygevoelige gegevens waarvan de wet vereist dat een strikt regime bij de verwerking van deze gegevens wordt gevolgd. De vertaling van de rechtsregels (door de onderzoekers als `legal instantiation' bestempeld)2 door middel van 'privacy knowledge engineering'3 werkt als volgt:

Eerst wordt door de juridische experts de 'overbodige' tekst, die bijvoorbeeld in de overwegingen van de privacyrichtlijnen kan worden gevonden, verwijderd. Dit leidt tot de kerntekst (corpus) van de 95/46/EG en 2002/58/EG. Daarna vindt de verdere vereenvoudiging van de wettekst plaats door de aaneenschakeling (`chaining') van geselecteerde artikelen van deze richtlijnen, die de gekozen privacyrealisatiebeginselen4 weergeven. Neem bijvoorbeeld het principe van transparantie, dat vereist dat de betrokkene geïnformeerd moet worden over wat er met zijn persoonsgegevens wordt gedaan. Dit principe kan worden gevonden in de artikelen 10 a, b en c en 11, lid 1, a, b, c en 11, lid 2 en artikel 13, lid 1, a, c, d, e, f en g en lid 2 van de richtlijn 95/46/EG.5

Uit het corpus worden de regels en de uitzonderingen op de regels geselecteerd, nader geanalyseerd en van elkaar gescheiden. Vervolgens wordt de tekst opgesplitst in eenvoudige zinnen, zoals "individuen moeten over de verwerking van hun gegevens worden geïnformeerd"; "de individuen hebben het recht de gegevens te raadplegen"; "de individuen hebben het recht correcties te vragen" en "de individuen hebben het recht tegen de verwerking in bepaalde omstandigheden bezwaar te maken". De bron van deze zinnen wordt apart geregistreerd, bijvoorbeeld dat de bovenstaande zinnen zijn ontleend aan overweging 25 en de artikelen 10 en 11 van de Richtlijn 95/46/EG. Na de aaneenschakeling van de artikelen van de privacyrichtlijnen per privacyrealisatieprincipe, is de volgende stap de beginselen in de elementen te verdelen. Aldus worden de beginselen gedeconstrueerd in een reeks van elementen die de nadruk op de context (wat is de bron van deze tekst) en het doel (wat moet worden bereikt) leggen. Er wordt naar gestreefd de interpretatieruimte zo veel mogelijk te reduceren, zodat latere softwarerisico's voorkomen worden bij het opstellen van de bouwspecificaties.

Bijvoorbeeld: Om transparantie in het informatiesysteem te realiseren is het noodzakelijk dat:

Op dezelfde manier vindt vanuit de rol van de verantwoordelijke of vanuit de strekking van een bepaald privacyrealisatiebeginsel (bijvoorbeeld doelbinding) of betreffende de privacyvoorkeuren van de DS de uitsplitsing plaats. Bijvoorbeeld: met betrekking tot de expliciete toestemming van DS; de gebruiks- en bewaartermijn van de PIJ; de statistische verwerking van de gegevens; etc.7 Voor dit werk zijn juridische deskundigen onmisbaar. Zij zorgen voor de argumentatie bij de juridische specificaties en de opsplitsing van de privacyrealisatiebeginselen. Ontwerpers zijn soms moeilijk te overtuigen van de juridische noodzaak.

De volgende stap wordt uitgevoerd door ontologie ontwerpers en is gericht op een verdere abstractie van de aldus verkregen korte privacybeschermende beschrijvingen. Deze privacystatements (beweringen) worden nu nog verder gereduceerd tot zeer eenvoudige zinnen die de essentie (`elementary fact') weergeven. Het criterium van een `elementary fact' is dat de zin niet verder in kleinere bestanddelen is op te splitsen zonder zijn betekenis te verliezen. Dit proces leidt tot een set van generieke elementen (`instances') en 'triples'.8 Een triple is een zo'n kort mogelijke zin met een onderwerp (subject) -,. werkwoord (verb), en voorwerp (object) (SVO) structuur.9 Daarnaast vindt er regel (rule) abstractie plaats, waarbij de regel wordt gesubstitueerd met superklassen of supereigenschappen van deze regels en een samenvattende term, die staat voor de termen van de subklassen of voor de termen die de subeigenschappen weergeven. Bijvoorbeeld de term 'wit' kan samengevat worden in de term 'kleur' op een lager niveau en in een object beschrijving op hoger niveau bijvoorbeeld: 'trilling'. Het gehele proces eindigt in `lexon engineering'.10 De basis voor de uiteindelijke privacyontologieën.

Wanneer dit voor alle privacyrealisatiebeginselen is uitgevoerd, dan is de grens van de 'privacy knowledge engineering' bereikt met betrekking tot het genereren van technische vereisten die uit de privacywetgeving voortspruiten. Een verdere verfijning is dan niet meer mogelijk en het meest elementaire niveau van het beschrijven van de Richtlijnen in specificaties is bereikt. De overgebleven artikelen die niet behoren tot het domein van de privacyrealisatiebeginselen worden niet in het systeemontwerp opgenomen. Deze artikelen spelen wel een vitale rol met betrekking tot de verklaring en interpretatie zoals bijvoorbeeld de artikelen 2 a tot en met h (definities), 3 lid 1, 3 lid 2, 4, lid 1 a, b, c, 4 lid 2, 5, 9, 15 lid 1, van de Richtlijn 95/46/EG en beïnvloeden indirect de systeemarchitectuur. Sommige artikelen zijn niet relevant voor de architectuur, zoals de vereisten voor de toezichthouder, de juridische remedies etc.