Het beschermen van gebruikersgegevens is niet alleen een onderdeel van goed gegevensbeheer: het is een wettelijke verplichting onder de GDPR. Datalekken kunnen bedrijven een boete kosten en hun reputatie schaden, dus het verwerken van gegevens op een veilige en vertrouwelijke manier is cruciaal voor bedrijven.
Natuurlijk is er geen pasklare oplossing om gegevensbeveiliging te garanderen, want de verwerkingsactiviteiten verschillen sterk van organisatie tot organisatie. Enkele basisrichtsnoeren gelden echter voor alle scenario's. We nemen de technische beveiligingsmaatregelen voor lief (hopelijk gebruikt u veilige authenticatiemechanismen, versleutelt u gegevens, enzovoort) en richten ons op wat er kan worden gedaan vanuit het oogpunt van gegevensbeheer.
- Ken uw gegevensstromen
- Ken uw verwerkers
- Voer een verantwoordelijk toegangsbeleid
- Wees voorzichtig met gegevensoverdracht
- Train uw personeel
- Houd rekening met menselijke fouten
- Stel een verstandig DSAR-verificatiebeleid vast
- Heb een beleid voor noodherstel van uw gegevens
- Verwerk minder gegevens
- Laatste gedachten
Laten we erin duiken
Ken uw gegevensstromen
Het startpunt voor de bescherming van gebruikersgegevens is goed gegevensbeheer, dat vereist dat u weet wat u met de gegevens doet. Dit lijkt misschien een triviaal punt, maar dat is het niet. Gegevensstromen zijn vaak complexer dan op het eerste gezicht lijkt: het is gemakkelijk om je alleen te richten op de gegevens waar je om geeft en andere categorieën gegevens over het hoofd te zien die ook samen met de "hoofdgegevens" worden verwerkt.
Laten we bijvoorbeeld zeggen dat de juridische afdeling van een bedrijf kopieën van fysieke contracten met de klanten in haar archiefsysteem opslaat. Deze operatie is complexer dan het lijkt. Er zijn toegangscodes voor het archiefsysteem nodig, en een systeembeheerder zal de toegangsrechten moeten beheren. Bovendien zal het bedrijf zeker de toegang tot de gegevens willen controleren, wat betekent dat het archiefsysteem voor elke gebruiker metadata moet genereren en opslaan. Als men zich te veel op de CV's concentreert, verliest men gemakkelijk het grotere geheel uit het oog.
In de praktijk liggen de zaken waarschijnlijk ingewikkelder: andere personeelsleden kunnen verschillende toegangsrechten hebben, het IT-personeel kan toegang tot het systeem nodig hebben om zijn werk te doen, er kunnen verwerkers van derden bij betrokken zijn, enzovoort. Het is niet eenvoudig om met al deze variabelen rekening te houden, vooral wanneer het gaat om complexe gegevensarchitecturen.
Het in kaart brengen van gegevensstromen heeft vele voordelen. Een nauwkeurige en uitgebreide kaart
- belicht problemen met toegang en beveiliging die u kunt aanpakken
- laat mogelijkheden zien om uw gegevensarchitectuur efficiënter te maken
- helpt nieuwe gegevensstromen op een coherente manier te implementeren binnen de bestaande architectuur
- helpt ervoor te zorgen dat uw toegangsbeleid de manier weerspiegelt waarop gegevens daadwerkelijk worden verwerkt
- maakt het gemakkelijker om uw verwerkingsactiviteiten bij te houden (een vereiste voor sommige bedrijven onder de GDPR1)
- helpt u te voldoen aan verzoeken om toegang en verwijdering, omdat u weet welke gegevens u beheert en waar deze binnen uw systemen te vinden zijn.
Het in kaart brengen van gegevensstromen kan ingewikkeld zijn voor grote bedrijven waar verschillende teams verwerken. Andere categorieën persoonsgegevens zijn klantgegevens, webanalysegegevens, werknemersgegevens, betalingsinformatie, enz. De gegevensarchitectuur van een bedrijf wordt in de loop der tijd ook steeds complexer, dus hoe later u deze in kaart brengt, hoe moeilijker het wordt. Idealiter worden kaarten vanaf het begin opgesteld en periodiek bijgewerkt.
De zaak Meta is heel leerzaam. Rechtszaken tegen het bedrijf brachten aan het licht dat niemand bij Meta precies weet hoe gegevens worden verwerkt. Facebook bestaat al bijna twee decennia, maar Meta probeerde (en faalde) pas vorig jaar na een gerechtelijk bevel zijn gegevensstromen in kaart te brengen. De gegevensarchitectuur van Meta is zo waanzinnig complex dat het praktisch onmogelijk is om deze vanaf nul in kaart te brengen.
Ken uw verwerkers
Veel bedrijven vertrouwen op een derde partij om op de een of andere manier gegevens te verwerken, of het nu gaat om cloudopslag, een Platform-as-a-Service, een e-maildienstverlener of een aannemer die belast is met IT-onderhoud.
Onder de GDPR zijn deze partijen gegevensverwerkers en moeten ze een gegevensverwerkingsovereenkomst (DPA) met u ondertekenen. Denk eraan dat u aansprakelijk kunt worden gesteld voor alle schade die uw verwerker kan veroorzaken door de GDPR te schenden2- inclusief schendingen die zij kunnen oplopen!
Zorg ervoor dat u alleen vertrouwt op betrouwbare verwerkers met goed gegevensbeheer en een strikt openbaarmakingsbeleid. Hetzelfde geldt voor elke betrokken subverwerker (dat wil zeggen elke verwerker die voor uw verwerker werkt). Indien haalbaar verdient interne verwerking voor bepaalde categorieën gegevens de voorkeur (bijvoorbeeld bedrijfsgeheimen en gevoelige persoonsgegevens zoals medische informatie).
Voer een verantwoordelijk toegangsbeleid
Als vuistregel geldt: hoe meer mensen toegang hebben tot de gegevens, hoe meer er mis kan gaan. Rolgebaseerde toegangscontrole zorgt ervoor dat de gegevens alleen toegankelijk zijn voor het personeel dat ze daadwerkelijk nodig heeft. Dit is vooral belangrijk voor grote bedrijven met een complexe structuur: HR heeft ziekteverzuimgegevens over werknemers nodig, en management en marketing niet.
Wees voorzichtig met gegevensoverdracht
Onder de GDPR kunt u uw gegevens buiten de EU/EER overdragen. Sommige doorgiften zijn echter ingewikkelder dan andere. Doorgifte naar landen waarvoor een adequaatheidsbesluit geldt, is eenvoudig en brengt geen nalevingskosten met zich mee - hoewel u er nog steeds voor moet zorgen dat een betrouwbare verwerker de gegevens ontvangt.
Het wordt lastiger wanneer u niet kunt vertrouwen op een adequaatheidsbesluit. We gaan niet in detail in op de doorgifte van gegevens, maar in het kort komt het erop neer dat doorgifte buiten de EU/EER gepaard gaat met een aantal nalevingslasten (zoals standaardcontractbepalingen). Deze lasten moeten niet worden benaderd als een vormoefening: het is uw plicht als verantwoordelijke voor de verwerking om ervoor te zorgen dat welk overdrachtsmechanisme u ook gebruikt, het in de praktijk voldoende bescherming biedt. Dit kan problematisch zijn met betrekking tot landen die wijdverspreide bewaking toestaan, zoals de VS. Dit is de kern van de aanhoudende problemen van Google Analytics met gegevensoverdrachten en de GDPR.
Als u nieuwsgierig bent, kunt u onze blog lezen voor meer informatie over de Google Analytics-saga en gegevensoverdrachten in het algemeen.
Train uw personeel
Hoewel sommige gegevenslekken het gevolg zijn van geavanceerde hackaanvallen, worden veel lekken veroorzaakt door phishing, en nog andere door menselijke fouten. Investeren in technische beveiliging is een no-brainer om gegevens veilig te houden, maar training van personeel is net zo belangrijk. U hoeft niet van elke werknemer een privacyadvocaat te maken, maar het personeel dat met persoonsgegevens omgaat, moet weten wanneer het die gegevens wel of niet moet vrijgeven. En cruciaal is dat ze een gekwalificeerde medewerker kunnen vragen wanneer ze niet zeker weten wat ze moeten doen.
Houd rekening met menselijke fouten
Mensen maken fouten. U moet daar rekening mee houden en de gegevensverwerking zo inrichten dat het risico op menselijke fouten tot een minimum wordt beperkt. Vraag uzelf af: welke fouten zijn het meest waarschijnlijk in mijn bedrijf? Is er een manier waarop ik die fouten kan voorkomen?
Bijvoorbeeld: een Italiaans ziekenhuis werd onlangs beboet voor het lekken van de e-mailadressen van honderden neurologiepatiënten. Hoe is dat gebeurd? Een werknemer nam per ongeluk de e-mails van de patiënten op in het veld CC in plaats van BCC bij het doorsturen van een nieuwsbrief (oeps!). Dit soort fouten is niet onwaarschijnlijk wanneer werknemers dagelijks tientallen e-mails versturen. Het datalek had voorkomen kunnen worden door de e-mailclient zo in te stellen dat BCC als standaardinstelling wordt gebruikt, waarbij een extra stap (zoals gebruikersbevestiging) nodig is om CC te gebruiken.
Stel een verstandig DSAR-verificatiebeleid vast
Onder de GDPR; een betrokkene kan de verwerkingsverantwoordelijke verzoeken om bepaalde informatie te verstrekken over de verwerking van zijn gegevens en om zelf een kopie van de gegevens te verstrekken3. Deze verzoeken worden doorgaans aangeduid als data subject access requests of DSAR's. Ontevreden verzoekers dienen soms een klacht in bij een gegevensbeschermingsautoriteit, dus een snelle en adequate behandeling van DSAR's is belangrijk.
Bedrijven moeten echter weten dat DSAR's kunnen worden misbruikt om illegaal toegang te krijgen tot andermans gegevens. Met andere woorden, valse DSAR's zijn een phishing-instrument - en een zeer effectief instrument! Als u in een valse DSAR trapt, loopt u een datalek op, dus u moet ervoor zorgen dat verzoeken niet afkomstig zijn van een imitator.
Tegelijkertijd moeten bedrijven verzoeken binnen een bepaalde termijn behandelen4 en tegelijkertijd de uitoefening van de rechten van de verzoeker vergemakkelijken5. Het verzoenen van al deze verplichtingen is niet eenvoudig en er is geen standaardoplossing. Elk bedrijf moet een geschikte middenweg vinden op basis van zijn specifieke situatie en de aard van de gegevens die het verwerkt. Maar als vuistregel moet u kiezen voor de minst belastende en invasieve verificatie die in uw geval betrouwbaar genoeg is6. Als u bijvoorbeeld een DSAR krijgt van iemand die beweert een geregistreerde gebruiker van uw website of bedrijf te zijn, kunt u eisen dat hij het verzoek doorstuurt vanaf het e-mailadres waarmee hij zich heeft geregistreerd. Je zou ook een knop kunnen opnemen om een DSAR door te sturen in het persoonlijke gedeelte van de gebruiker op je website (Instagram doet dit bijvoorbeeld). Idealiter zou je alleen als laatste redmiddel een ID of andere persoonlijke informatie moeten vragen.
Heb een beleid voor noodherstel van uw gegevens
Bij datalekken denken mensen meestal aan datalekken: situaties waarbij persoonlijke gegevens door een onbevoegde partij worden bekeken of gekopieerd. Gegevensverlies kwalificeert echter ook als een datalek onder de GDPR7. Dit betekent dat elk gegevensbeveiligingsbeleid een rampherstelplan voor uw gegevens moet bevatten. Idealiter heeft een organisatie een back-up, of het nu een fysieke back-up is of een cloud-gebaseerde disaster recovery service.
Verwerk minder gegevens
Het spreekt voor zich dat hoe meer gegevens u verwerkt, hoe meer er potentieel mis kan gaan. Naast de kosten van de exploitatie en het onderhoud van uw gegevensverwerkingssystemen, heeft de verwerking van gegevens inherente kosten in termen van nalevingslasten en nalevingsrisico's, en hoe ingewikkelder uw verwerkingsactiviteiten, hoe hoger die kosten zijn. U moet zich altijd afvragen: heb ik deze gegevens echt nodig, of verzamel ik ze alleen omdat iedereen in mijn branche dat doet?
Soms is het gebruik van minder gegevens de beste optie. Er valt veel te zeggen over de waarde die een mentaliteit van gegevensminimalisering kan hebben voor uw bedrijf - en we hebben er hier over geschreven.
Uiteraard moet uw bedrijf zich ook houden aan een verstandig gegevensbewaringsbeleid en de gegevens wissen die het niet meer nodig heeft. Dit is zowel een wettelijke vereiste onder de GDPR8 als een goede praktijk voor gegevensbeveiliging - alle gegevens die je niet hebt, zijn gegevens die je niet kunt lekken.
Laatste gedachten
Goede data governance en een privacy mindset kunnen waarde toevoegen aan je bedrijf, en vertrouwen op privacy-vriendelijke tools is een goed begin. Dit is ook een van de pijlers waarop Simple Analytics is gebouwd. Wij geloven dat u inzichten over uw websitebezoekers kunt verzamelen zonder dat u daarvoor persoonlijke gegevens nodig hebt. Zo krijg je de inzichten die je nodig hebt, terwijl je 100% GDPR-compliant bent. Wij geloven in een onafhankelijk internet dat vriendelijk is voor websitebezoekers. Als dit met u resoneert, probeer ons dan gerust uit!
#1 Art. 30 GDPR [^2]: Art. 82(2) GDPR. De voor de verwerking verantwoordelijke is vrijgesteld van aansprakelijkheid wanneer hij niet verantwoordelijk was voor het veroorzaken van de schade (art. 82(3)), maar hij draagt de bewijslast - wat in de praktijk zeer riskant is. [^3]: Art. 15 GDPR [^4]: Art. 12(3) GDPR. [^5]: Art. 12(2) GDPR. [^6]: Dit is ook de aanbeveling van de EDPB: zie Richtsnoeren 01/2022 over rechten van betrokkenen - Recht op toegang, par. 65. [^7]: Art. 4(12) GDPR. [^8]: Art. 5(1)(e) GDPR.