Deze blog maakt deel uit van een serie blogs over Privacy by Design. In deze reeks gaan we steeds kort in op 1 van de 7 principes. Het eerste principe is “Proactive not reactive” . In dit principe gaat het om het proactief voorkomen van schendingen van privacy. Het gaat hier niet om ‘damage control’ nadat er een incident is geweest maar hoe je voorkomt dat een dergelijk incident gebeurt.
Met betrekking tot het programmeren van de software moeten ontwikkelaars preventieve technische maatregelen nemen voor de bescherming van persoonsgegevens. Uiteraard is een bedrijf zelf verantwoordelijk voor haar eigen processen om persoonlijke gegevens te waarborgen maar als software leverancier kun je al een heleboel fouten die soms nietsvermoedend worden gemaakt op dit gebied voorkomen. Hier zijn twee voorbeelden van waar het heel eenvoudig is om privacy preventief te beschermen:
Geef geen mogelijkheid. Een softwarepakket heeft een veld waarin iemands geloof of bijvoorbeeld kerkgenootschap genoteerd kan worden wat natuurlijk gevoelige persoonsgegevens zijn. Door dit simpelweg weg te halen voorkom je dat dit geregistreerd wordt. De gebruiker zou dit natuurlijk alsnog ergens kunnen registreren en de software hiervoor kunnen “misbruiken’ maar je geeft er bewust geen ruimte voor.
Waarschuw. Voor het noteren van iemands zijn BSN geeft de software een waarschuwing waarmee de gebruiker een herinnering krijgt dat dit om gevoelige persoonsgegevens gaat en ook een waarschuwing dat je als organisatie wel bevoegd moet zijn. Een andere optie is dat de klant bewust moet aanvinken dat ze dit mogen doen en pas na deze handeling het BSN mogen invullen.
In de praktijk
De standaardinstelling voor een nieuwe gebruikersgroep is “geen toegang”. Toegang moet actief worden verleend
Een voorbeeld van privacy by design in de praktijk bij KorènCRM is onze rechtenbeheer. Bij onze klanten zijn er verschillende gebruikersgroepen die gebruikmaken van de software. Bij het toevoegen van een nieuwe gebruikersgroep moeten alle rechten worden toegewezen. De standaardinstelling voor rechtenbeheer bij iedere gebruikersgroep is “Geen toegang” wat erop neerkomt dat er actief toestemming verleend moet worden in plaats van dat toestemming actief moet worden uitgezet. Hierdoor moet de applicatiebeheerder bewust bij een gebruikersgroep per module instellen waar de gebruikersgroep toegang toe heeft en wat ze na toegang voor acties kunnen ondernemen in de software. Er zijn vier opties:
A) Geen toegang B) Alleen lezen C) Kunnen wijzigen D) Kunnen verwijderen
Hiermee kun je aangeven wat een gebruiker per module en ook per module-deel in de module kan doen. Sommige gebruikers zullen bijvoorbeeld NAW gegevens kunnen aanpassen maar misschien niet bankgegevens en weer andere gebruikers kunnen relaties alleen lezen. Sommige kunnen bulkmail versturen, anderen mogen dat wel doen maar mogen geen ledenpas bulkmail versturen omdat ze deel uitmaken van de cursusafdeling van een organisatie. Deze laatste groep krijgt als startpagina de cursusmodule en kan niet bij andere modules kijken of iets wijzigen.