Ik snap in diet verhaal 2 dingen niet: waarom heeft een developer eigenlijk toegang tot die database (voor development en testing verwacht je een test dataset en geen echte gegevens), en hoe komt het dat hoe de gebuikeraantallen er uit zien afhangt van die database, dus: wie hebben er dan nog meer toegang?

Wat mij betreft is je verantwoordelijkheid hier om het kenbaar te maken bij de functinoaris gegevensbescherming binnen je organisatie, dan heb jij je "plicht" gedaan.

Die zal "een gamebedrijf" wellicht niet hebben, zeker niet als het een klein bedrijf is.
Of het is een deelfunctie ergens in de directie. Wellicht zijn baas, die heeft ie al geinformeerd.

AVG conflicten,
Daar ken ik er meerdere van.
Bedrijven die in Nederland security events organiseren en hun vrijwilligers Linkedin, Facebook, Werk.nl* laten schrapen voor mobiele nummers, email adressen, data enz visite kaartjes verzamelen en dit alles samen met interesse, skills, werkgever en wat nog meer. Wat vervolgens in een Googel document komt.

Mag niet maar gebeurd gewoon onder ogen van de Nederlandse wet.


*werk.nl van het UWV dat volstaat met Cv's en contact gegevens van ICT'ers

Je zit als developer dus helemaal klem als je dit soort overtredingen wilt voorkomen?

Allerlei hiërarchieën in bedrijven kunnen toch geen belemmering zijn voor mensen te handelen in de geest van de wet?


Hoe zit het in ziekenhuizen als een manager zou verbieden patiënten pijnstillers te geven en je doet het toch? Je bent dokter, je hebt de plicht mensen niet te laten lijden, en je geeft paracetamol. Dat is je werk.

Je bent systeembeheerder en je gooit gegevens weg omdat ze niet bewaard mogen worden. Wat is het verschil precies?

Ik begrijp het probleem niet. De oplossing is zo simpel.

Je kan zonder problemen alle oude records anonimiseren door er willekeurige troep in te gooien. De database blijft bestaan, de aantallen blijven gelijk, enkel de oude records zijn vernaggeld en dus niet meer te herleiden naar de oorspronkelijke data. De data is effectief verwijderd.

Dit kan in de database gedaan worden, maar ook in logfiles. Backups mogen maar bepaalde tijd bewaard blijven en desnoods haal je de backups ook door een anonimiseerproces. Problem solved.

De werknemer had dit bij de baas moeten neerleggen als optie.
De baas had dat ook allang moeten kunnen verzinnen.

Braaf zo, meneer Engelfriet. U heeft uzelf ook weer netjes ingedekt. En potentiële melders van misstanden schijnbaar ontmoedigd.

Maar als iemand gaat klokkenluiden, dan moet-ie het natuurlijk wel slim doen. Dus bij wijze van spreken niet de methode Manning/Assange (traceerbaar dumpen), en zelfs niet de methode-Snowden (netjes overhandigen aan een krant met een tijdelijke exit-strategie voor zichzelf; en door Snowden ook nog eens briljant uitgevoerd), maar op zo'n manier dat er niet alleen geen bewijs is, maar zelfs geen verdenking van de kant van de baas jegens de betreffende werknemer.

Om te beginnen zou de werknemer de zaak niet eens bij de baas onder de aandacht moeten brengen. Tuurlijk, volgens het boekje moet dat wel, maar we weten allemaal dat de baas ook niet volgens het boekje met de klokkenluider zal omgaan. Het beste is dat de potentiële klokkenluider eerst een eigen inschatting maakt van wat de baas ervan zou vinden. Zonder zekerheid dat de baas instemt met verwijdering van de gegevens, niet klagen, maar voorzorgshalve meteen plan B verzinnen.

Plan B moet inhouden dat de zaak niet alleen anoniem naar buiten komt, maar ook op zo'n manier dat het lijkt of het zonder hulp van de betreffende werknemer is gebeurd. In dit geval zou je kunnen denken aan een actie waarbij de werknemer van het data-bedrijf een onderzoeksjournalist benadert, en aan die journalist pas concrete info verstrekt nadat er is afgesproken dat die journalist twee dingen doet: ten eerste vragen aan het bedrijf stellen, bijvoorbeeld over aantallen accounts i.v.m. de viability van het bedrijf, en ten tweede een "willekeurige buitenstaander" benaderen die als "mystery guest" een account aanmaakt bij het bedrijf, en na enige tijd het account weer opzegt. En die vervolgens, nadat de bewaartermijn al flink is verstreken, onschuldig vraagt of hij zijn data mag inzien. Het bedrijf voldoet vervolgens netjes aan dat verzoek (want willen geen moeilijkheden krijgen), waarmee het bewijs in handen is van de mystery guest, die het doorspeelt aan de onderzoeksjournalist. Die gaat vervolgens opnieuw vragen aan het bedrijf stellen, en daarover publiceren.

Deze methode heeft vier grote nadelen. Het kost tijd, het kost werk, het vereist vertrouwen tussen werknemer, onderzoeksjournalist en mystery guest, en het vereist een behoorlijke professionaliteit van de werknemer, de onderzoeksjournalist en de mystery guest.

Ik heb nog nooit gezien dat deze methode van klokkenluiden in de praktijk is toegepast. Maar dat is ook logisch, want als dit goed gebeurt, ziet een buitenstaander er niks van.

Meestal begint het proces van klokkenluiden rommelig, met aan de kant van de klokkenluider veel naïviteit over dat de baas en de instanties enigszins correct met een melding zullen omgaan. Het "Huis voor Klokkenluiders" is slechts het laatste debacle, de meest recente poging om het eindelijk goed te regelen die werd gesaboteerd, zodat het uitdraaide op de zoveelste fuik om klokkenluiders niet mee te beschermen, maar mee te vangen en ze kapot te maken.

Maar inmiddels beseffen steeds meer mensen hoe het in de realiteit werkt. Succesvol klokkenluiden is mogelijk, maar alleen voor wie bereid en in staat is dat op een professionele wijze te doen. Waarschijnlijk zijn dat maar heel weinig mensen. En ze moeten ook nog voldoende gemotiveerd zijn om er zoveel tijd en moeite aan te besteden. Dat betekent dat er in de praktijk al wel meer aan de hand moet zijn in zo'n bedrijf, voordat er een bekwame klokkenluider zal opstaan, en voordat een bekwame journalist erin geïnteresseerd zal raken.

Disclaimer: ik heb het zelf ooit gedaan, maar was te naïef en meldde het wel eerst netjes intern. Wat er daarna gebeurde, houd ik voor mezelf, behalve één ding: het duurde vele jaren.