'Privacy' is een onderwerp dat in organisaties vaak apart wordt gezien van de gewone (ICT) business. Systemen draaien gewoon, projecten worden uitgevoerd, en zo nu en dan bezoekt deze of gene collega een seminar over privacy – waaruit dan een alarmkreet klinkt dat het nu toch echt ernst wordt. Her en der wordt er dan binnen de organisatie geroepen dat privacy vanaf nu inderdaad 'goed moet worden gedaan', 'bij alle projecten moet worden ingebouwd, niet achteraf pas worden bezien' etc. De rol van de Privacy Officer (vaak een jurist) wordt herbevestigd, en na een paar maanden bezoekt deze of gene collega dan weer eens een seminar.

Kunnen we met zijn allen dit patroon doorbreken? We moeten wel.
Dit artikel zal in het kort de ' oorzaken' van de privacyproblemen in uw organisatie bespreken, waarna drie stappen worden beschreven om een en ander in de hand te krijgen. Met het besef dat er gewoonweg heel veel te doen is om privacy in control te krijgen … niks doen is geen optie.

Data. We Want More!

Misschien kunnen we het probleem verkleinen. Het probleem is namelijk dat we zoveel data in huis hebben, waarvan ook steeds een deel privacy-gevoelig is, en we er bij ieder project nog wel meer van dat soort gegevens bij willen hebben. Zeker in tijden van Big Data lijkt het wel alsof we niet genoeg kunnen verzamelen…

Al is het alleen al voor het gemak. Hoe meer data we van en over klanten verzamelen (identificerende gegevens, master data, en transactie- en gedragsgegevens), hoe gemakkelijker we onze systemen kunnen bouwen. Zien uit te vinden wat we als organisatie al aan gegevens hebben, is nogal eens een vermoeiende tijdverspiller zonder veel resultaat. En ook cookiewetgeving, van die rare bezwaren tegen het verzamelen van locatiegegevens en zo: Lastig, lastig.

Maar met alle verzameldrang komt dan 'privacy' om de hoek. Dat schuilt soms in enkele specifieke data-elementen maar is veeleer een 'emergent property' – iets dat je niet aan specifieke objecten in een systeem kan toekennen maar dat eruit opstijgt als een eigenschap van het geheel. Identificerende gegevens zijn wel de focus in technische zin, maar we moeten zelf proeven of de chocola die we er van maken (de betekenissen die we aan allerlei combinaties van gegevens toekennen) kan bijdragen aan het identificeren of beter leren kennen van personen.

Maar de klant wil minder

Vanaf de andere kant kunnen we een spiegelbeeld ophangen. De klant wil én privacy én gebruiksgemak (van de site), maar ziet zich vaak gesteld voor een “Hobson's Choice”; take it (all) or leave it. Zonder de 'benodigde' gegevens te leveren, komt een klant er niet. Kennelijk zijn we niet bang dat de klant wegloopt: De concurrent doet even slecht (sic) en de klant denkt ook niet zo over privacy na.
Maar hier is verandering op til; de wetgeving en handhaving worden strenger en de klant kritischer. De klant wil steeds minder identificatie- en andere privacy-gevoelige gegevens ophoesten, zeker als die niet relevant zijn voor de transactie.

De klant heeft sowieso steeds minder vertrouwen in het hele eCommerce-gebeuren. Als na het ene incident na het andere de conclusie doordringt dat de beloofde afscherming van privé- en privacygevoelige data een wassen neus was, zal de klant langzamerhand steeds minder willig zijn om telkens nog weer meer gegevens te delen. Dit teruglopend vertrouwen komt bovenop het al bestaande paniekvoetbal rond 'cyber'crime, onbetrouwbaarheid van browsers en websites, etc. Bedrijven die met een beveiligingsfoutje in het nieuws komen, ondervinden daar steeds meer last van. En als het bij u misgaat, zal intern wel deze en gene flink in de problemen komen. Waarom heeft dit kunnen gebeuren, terwijl nou net u als expert toch de hele organisatie had moeten verdedigen? De kunst is dus om zo min mogelijk in huis te hebben dat risico's zou kunnen vormen.

Stap één: Waar we staan

Dat betekent dat we, stap één, flink moeten gaan spitten en nadenken om te weten hoe 'groot' de schade op dit moment eigenlijk is; dat we inzicht moeten zien te krijgen in welke data we nu al in huis hebben. Drie keer raden waarom zo'n overzicht er niet is, of zeer verouderd is. Inderdaad, omdat het een forse klus is zonder duidelijke directe voordelen. Niet iets waar mensen warm voor lopen of tijd en budget voor vrijmaken. Nu moeten we wel, steeds duidelijker om puur juridische complianceredenen.
Vervolgens moeten we uiteraard bezien of we al die gegevens wel nodig hebben; of er niet veel redundantie in zit. Dat dan wel in het licht van de moeite die het zou kosten om systemen te verbouwen zodat we meer lean and mean met gegevens zouden kunnen omgaan.
Waarbij we ons wel even achter de oren moeten krabben als het gaat om de relaties van de organisatie binnen een netwerk van business partners… Hoeveel aansluitingen op overheidsadministraties moeten we hebben? Met hoeveel third parties, leveranciers van allerhande IT-gerelateerde diensten, hebben we te maken? En het call center, en Marketing & Sales, en… en …? En dat alles op detainiveau terwijl we als we klaar zijn, zowat weer opnieuw kunnen beginnen.

Stap twee: Hek erom

Die inventarisatieslag zal daarom veel omvangrijker zijn dan we verwachtten. Misschien kan dan maar beter worden aangesloten bij werk wat we toch al moeten doen, in stap twee: beveiligen, die hap! Op een manier dat er in ieder geval geen misbruik van de gegevens kan worden gemaakt. Oneigenlijk gebruik buiten én binnen de organisatie voorkomen, en liefst aantoonbaar in control zijn, is hier het doel. Hoe minder gegevens onder dit regime vallen, hoe beter, maar ach als we toch bezig zijn kunnen we beter aan de veilige kant gaan zitten. Oh ja, daar hoort (wettelijk) ook control bij over de gegevens waar derden aan kunnen komen. Of die ergens in de cloud staan. Maar uw IAM is toch helemaal top, net als uw SIEM, ISO-XYZ-compliance etc, toch…? U hebt uiteraard volledig zicht op alle Advanced Persistent Threats. Alle informatiebeveiligingszaken waar we in het verleden met veel brandjes blussen nog wel een mager zesje op scoorden, moeten nu veel beter.

Stap drie: Kraan dicht by design

Verbetering van 'de' privacy is ook niet eenvoudig op te lossen door 'van buiten' door de privacy officer naar projecten te laten kijken als die al onderweg zijn. Want als een timmerman een stoel maakt, heeft het niet heel veel zin om halverwege het maakproces twee poten half af te zagen.
En die privacy officer is, door de bank genomen, meer een jurist of een bedrijfskundige dan een techie. Natuurlijk, dat is heel prettig om hoog in de staf over de compliance-fijnslijperij te kunnen meepraten, en daar enige autoriteit te (kunnen…) hebben. Maar het betekent ook dat als het erop aankomt, de communicatie binnen een project over privacy lastig blijkt; het denken over raw data, de emergent property privacy in het licht van identificeerbaarheid en andere gevoeligheid, en technische en logische slimmigheden om die data ofwel niet nodig te hebben ofwel goed te beveiligen, is een berg expert-werk.

We kunnen dus beter met Privacy By Design het voortouw nemen zodat het zich vernieuwende systemenlandschap toegroeit naar iets waar we qua privacy tevreden over kunnen zijn. Dat betekent flink wat specifieke aansturing en control maar dat kunt u beter in uw takenpakket houden dan dat daar een apart organisatiecircus voor moet worden opgetuigd dat zich alsnog over (sic) uw divisie buigt.

Eerst PIA? Liever in PBD

Inhoudelijk is er overigens best wel wat meer te doen dan alleen maar een Privacy Impact Assessment voor de compliance-bühne. Zo'n PIA wordt nogal eens verwacht buiten de details van een systeemontwerp om. Dat kán, maar dan wordt juist de mogelijkheid gemist om privacyverbeterende ontwerpkeuzes in te bouwen.

Het wordt pas echt wat als u zich in het privacy-by-systeemontwerp richt op de volgende punten:

  1. Minimalisatie; net als in stap 1 hierboven, wat je niet in huis hebt, hoef je niet te beveiligen. Dit betekent natuurlijk niet dat juist alle gevoelige gegevens maar de cloud in moeten op hoop van zegen dat de beveiliging daar in orde zou moeten zijn. Het gaat hier meer om slim nadenken of bepaalde gegevens nou echt wel nodig zijn voor de beoogde overall functionaliteit van een (nieuw) systeem.  En anonimiseer en gebruik zo mogelijk pseudoniemen, dan is er al minder in huis waarmee iets zou kunnen misgaan.
  2. Een tweede belangrijke stap is natuurlijk zorgen voor goede afscherming – door de architectuur. Dat betekent ervoor zorgen dat de gegevensverwerking zo veel mogelijk 'onder water' gebeurt. Gebruikers die detailgegevens niet hoeven te zien, hoeven ze niet te zien, tenslotte. En transparante encryptie kan zorgen voor afscherming van de datasets als collectief.
  3. Werk waar mogelijk met reeds geaggregeerde gegevens. Hoe 'eerder' de details van gegevens niet eens meer nodig zijn en hoeven te worden verwerkt (en dus ook niet over netwerken hoeven te worden getransporteerd), hoe beter. Door alleen een 'tussenstand' (aggregatie over tijd) van bepaalde gegevens bij te houden bijvoorbeeld blijven identificerende (gedrags)patronen buiten beeld.
  4. Doe de gegevensverwerking zoveel mogelijk gedistribueerd. Het gaat hier om, in tabellentaal, horizontale splitsing … voor zover mogelijk. Dit voorkomt dat iemand die ongewenste toegang heeft tot gegevens op een lokatie, al te veel gegevens ineens te pakken kan krijgen. Tabellen van databases kunnen apart worden gehouden, geografische scheiding van de personen waarop gegevens betrekking hebben, kan vaak evenzo gespreid plaatsvinden. Waar de verwerking van alle gegevens tezamen nodig is, kan dit alsnog, al of niet met geaggregeerde gegevens.

De keuzes die we zo maken, hebben een sterke invloed  op de mogelijke, haalbare privacy. Een PIA doen zonder deze details in het oog te houden, levert dan ook vaak gemeenplaatsen op met onvoldoende handvatten voor verstandige ontwerpkeuzes. Een PIA hanteren als graadmeter voor de privacy-kwaliteit van een systeem dat we aan het ontwerpen zijn, helpt daarentegen heel veel om de privacy daar te brengen waar we dat willen en moeten hebben. In die volgorde.

Begin met aftellen

Samenvattend kunnen we dus al met drie stappen thuis zijn. Waarbij het aftellen beter met Drie kan beginnen… Ja zelfs uw auditors zullen moeten accepteren dat In Control zijn niet betekent foutloos te zijn, maar de verbeterpunten te kennen en daar planmatig aan te werken. First things first; eerst de kraan van nieuwe systemen under control krijgen qua privacy, dan dweilen aan de huidige plas gebreken, als die niet al vanzelf opdroogt. Maar wel zelf aan de gang gaan, voor het te laat is; liever zelf sturen dan gestuurd worden.