6.4. Naast privacyrechten: privacyplichten

Zoals uit het bovenstaande blijkt, dient er met zeer veel specificaties bij het ontwerpen van PRIVIS en andere privacyveilige applicaties rekening gehouden te worden. Naast de privacyrechten van degenen die de persoonsgegevens verstrekken, staan de (waar wettelijk vereist) expliciete toestemmingen van de betrokkenen betreffende de verwerking van hun persoonsgegevens en de privacyplichten van de verantwoordelijke. Deze drie elementen dienen uiteindelijk in de architectuur van PRIVIS hun plaats te krijgen. In feite leiden deze drie elementen tot een doelgerichte beperking van de ontwerpvrijheid doordat de beperkingen tot niets anders mogen leiden, dan tot de realisatie van het beoogde privacyveilige informatiesysteem.1

Dietz & Mulder merken over dit soort architectuurbeginselen op dat binnen de 'Enterprise Architecture' hiervan veelvuldig gebruik wordt gemaakt. Hun functie is om te dienen als referentiekader voor implementatieprojecten. Een architectuurprincipe heeft een naam, een omschrijving, een reden en beschrijft de implicaties. De doelstelling van het formuleren van architectuurprincipes is om de vrijheidsgraden van de onderliggende niveaus zodanig in te perken dat de ontwerpen voor deze niveaus in lijn zijn met de strategische doelstellingen voor de organisatie als geheel (bijvoorbeeld de borging van cruciale informatiestromen tussen domeinen). Deze inperking kan zowel positief als negatief worden geformuleerd. Positief geformuleerde beginselen geven aan hoe de onderliggende oplossingen eruit moeten zien, bijvoorbeeld alle gegevens zijn via een portaal te benaderen. Negatief geformuleerde beginselen hebben het karakter van verboden, bijvoorbeeld onzichtbare koppelingen zijn verboden. Ter wille van de maximaal mogelijk bereikbare privacybescherming is de standaard uitgangspositie van het ontwerp van PRIVIS dat daar waar dat mogelijk is, alle interacties met en binnen PRIVIS a priori anoniem of onder pseudoniemen geschieden.

De vraag is nu hoe al die (complexe) privacyplichten gekoppeld aan de verwerking van persoonsgegevens in het ontwerp kunnen worden geïncorporeerd zodat een privacyveilige toegangscontrole, een privacyveilige behandeling van de persoonsgegevens en een privacyveilig beheer gedurende de levenscyclus van de verwerkte en opgeslagen persoonsgegevens kan worden gerealiseerd. Hoe complex en multidimensionaal dit vraagstuk is, blijkt uit figuur 6.1.2

In deze figuur wordt in twee gedeeltelijk overlappende voorbeelden geïllustreerd met welke factoren rekening gehouden moet worden. In het voorbeeld zijn dat de naleving van de verplichting, de periode waarbinnen de verplichting moet worden uitgevoerd, de aard van de verplichting (bijvoorbeeld wettelijk), de omstandigheden die voor de verplichting van kracht zijn, zoals: geldt er een toegangscontrole voor het individu van wie de persoonsgegevens zijn of het bedrijf dat de gegevens verwerkt, en de context waarbinnen de verplichting valt. Het donkergrijze vlak in de figuur betreft de privacyplicht om de gebruiker via een bepaald type e-mail in te lichten wanneer zijn gegevens zijn ingezien en het lichtgrijze vlak gaat over de privacyplicht om de persoonsgegevens XYZ na zeven jaar volledig uit het informatiesysteem te verwijderen. Om dergelijke en andere privacyplichten goed te beheren is het Obligation Management System (OMS) ontworpen. Dit systeemcomponent regelt en ondersteunt het beheer, de planning, handhaving en monitoring van de privacyplichten betreffende de persoonsgegevens binnen PRIVIS. De privacyplichten in dit systeem bestaan uit een reeks van beperkingen voortvloeiend uit de privacy- en andere wetgeving die op de verzamelde persoonsgegevens moeten worden toegepast, met daarnaast de wensen van de eindgebruikers en de plichten van de medewerkers die zich met de bescherming van de persoonsgegevens bezighouden.3 De privacyplichten dwingen softwarematig een privacybewust en privacyveilig levenscyclusbeheer van persoonsgegevens binnen PRIVIS af. In het PRIVIS-systeem zijn privacyplichten geformuleerd als een `reactive rule' bestaande uit drie kernaspecten:

Deze privacyplichten kunnen in relatie tot de handhaving van korte en lange termijn van aard zijn, en kunnen óf een eenmalige handhaving vereisen óf, in het geval van lopende verplichtingen, binnen een bepaald tijdsbestek, een repeterende en veelvoudige handhaving vereisen.4 Bovendien wordt aan een dergelijke privacyverplichting ook gekoppeld wie verantwoordelijk is voor het uitvoeren van de privacyplicht, de mogelijke uitzonderingen en de speciale gevallen.5 In een meer abstracte zin wordt in het systeem een privacyplicht geconstrueerd als een verzameling van alle unieke identificerende gegevens (i), een verzameling van alle mogelijke doelen (t), een verzameling van alle mogelijke gebeurtenissen (e) en een verzameling van alle mogelijk te nemen acties (a) waarbij voor de gebeurtenissen alle logische combinaties (AND, OR, NOT) worden gedefinieerd en voor de acties de operationele combinaties, zoals de volgorde van de te nemen acties, worden vastgesteld.6 Dit systeem is geen toekomstmuziek. Inmiddels heeft het PRIME-project7 een werkend OMS-prototype opgeleverd en zijn er commerciële aanbieders (zoals IBM en HP) die dit systeemcomponent hebben geïntegreerd in de door hen aangeboden privacymanagementsysteemprogrammatuur.