Encryptie AVG-verplichting: wanneer moet je data versleutelen?
Je weet dat encryptie belangrijk is. Maar is het ook verplicht? Niet altijd. Wel vaker dan de meeste mkb's denken. De AVG noemt encryptie expliciet als beveiligingsmaatregel, en de Autoriteit Persoonsgegevens verwacht dat je het serieus overweegt.
Dit artikel geeft je een helder overzicht: wanneer is encryptie verplicht, wanneer is het aanbevolen, en wat moet je als mkb minimaal regelen voor Artikel 32?
Wat zegt de AVG over encryptie?
Artikel 32 van de AVG schrijft voor dat je "passende technische en organisatorische maatregelen" treft om persoonsgegevens te beveiligen. Encryptie wordt in dat artikel expliciet genoemd als voorbeeld van zo'n maatregel, samen met pseudonimisering.
Dat betekent niet dat de wet encryptie altijd verplicht stelt. De AVG werkt risicogebaseerd: hoe gevoeliger de data, hoe steviger de beveiliging moet zijn. En encryptie staat daarbij hoog op de lijst.
Wat betekent dat in de praktijk? Als je persoonsgegevens verwerkt en encryptie technisch haalbaar is, moet je goed kunnen uitleggen waarom je het niet doet. "We zijn er nog niet aan toegekomen" overleeft geen audit.
Wanneer is encryptie verplicht onder de AVG? (En wanneer is het "aanbevolen")
De grens tussen verplicht en aanbevolen hangt af van een paar factoren.
Ten eerste: de gevoeligheid van de data. Bijzondere persoonsgegevens (gezondheid, religie, biometrische data) vragen altijd om sterke encryptie. Voor gewone contactgegevens is de lat lager, maar niet nul.
Ten tweede: het risico bij een lek. Stel dat de data op straat komt te liggen. Hoe groot is de schade voor de betrokkenen? Hoe groter de impact, hoe harder de eis.
En ten derde: de stand van de techniek. De AVG houdt rekening met wat technisch haalbaar en betaalbaar is. Encryptie is in 2026 goedkoop en breed beschikbaar. Dat maakt het lastig om te beargumenteren dat het niet kan.
Vuistregel: voor bijzondere persoonsgegevens, financiële data en BSN-nummers is encryptie in de praktijk verplicht. Voor overige persoonsgegevens is het sterk aanbevolen, zeker bij opslag en verzending buiten je eigen netwerk.
Welke typen data moeten versleuteld worden?
Niet alle data hoeft op dezelfde manier beschermd te worden. Het belangrijkste onderscheid:
Data at rest is opgeslagen data: bestanden op servers, in de cloud, op laptops, op USB-sticks en in backups. Als iemand fysiek of digitaal toegang krijgt tot die opslag, is versleuteling je laatste verdedigingslijn.
Data in transit is data onderweg: alles wat verstuurd wordt via internet, e-mail of interne netwerken. Denk aan formulieren op je website, e-mails met persoonsgegevens en API-verkeer tussen systemen.
In de praktijk zijn dit de scenario's waar encryptie er het meest toe doet:
- Laptops en mobiele apparaten (verlies of diefstal is een realistisch risico)
- Cloudopslag met persoonsgegevens
- E-mailverkeer met gevoelige bijlagen
- Backups, ook als die offsite staan
- Databases met klant- of personeelsgegevens
Welke encryptiestandaarden zijn acceptabel?
De AVG schrijft geen specifieke standaard voor, maar toezichthouders hebben wel duidelijke verwachtingen.
Voor data at rest is AES-256 de norm. Vrijwel alle cloudproviders ondersteunen het. Bij data in transit verwacht men TLS 1.2 of hoger, het protocol achter HTTPS. Oudere versies (TLS 1.0, 1.1) gelden als onveilig. En bij gevoelige communicatie hoort end-to-end encryptie. Denk aan tools als Signal voor interne berichten over privacygevoelige zaken.
Let op: versleuteling is alleen zo sterk als je sleutelbeheer. Als de encryptiesleutel naast de data ligt, heb je in feite niets. Sla sleutels gescheiden op en beperk de toegang ertoe.
Pseudonimisering is geen encryptie
Dit wordt vaak door elkaar gehaald. Bij pseudonimisering vervang je identificerende gegevens door een code of alias. De data blijft leesbaar, maar is niet direct herleidbaar naar een persoon. Bij encryptie is de data onleesbaar zonder de juiste sleutel.
Het zijn dus twee verschillende dingen. Pseudonimisering beperkt herleidbaarheid. Encryptie voorkomt toegang. Voor serieuze beveiliging wil je vaak beide.
Encryptie in de praktijk: wat moet je minimaal regelen?
Je hoeft als mkb geen militaire beveiliging op te tuigen. Maar dit moet je minimaal op orde hebben:
- HTTPS op al je webproperties. Geen uitzonderingen. Elk formulier, elke pagina, elk subdomein.
- Versleutelde opslag voor gevoelige bestanden. Gebruik de ingebouwde encryptie van je cloudprovider (Google Workspace, Microsoft 365, AWS) en controleer of die standaard aanstaat.
- Full-disk encryptie op laptops. BitLocker (Windows) of FileVault (Mac) zijn gratis en in een paar klikken ingeschakeld.
- Versleutelde e-mail voor gevoelige communicatie. Gebruik TLS-verificatie of een oplossing als Zivver als je regelmatig persoonsgegevens per e-mail verstuurt.
- Versleutelde backups. Controleer of je backupprovider encryptie at rest biedt en of je zelf de sleutels beheert.
- Veilige API-verbindingen. Alle dataverkeer tussen systemen via TLS 1.2+. Geen onversleutelde verbindingen, ook niet intern.
Wil je per leverancier en systeem vastleggen welke beveiligingsmaatregelen je hebt getroffen? In ComplianceHive documenteer je dat in het leveranciersbeheer en de systemeninventaris. Zo heb je bij een audit direct een actueel overzicht.
Wat als je een datalek hebt maar de data was versleuteld?
Hier wordt encryptie echt interessant vanuit compliance-oogpunt. Artikel 34, lid 3a van de AVG stelt dat je betrokkenen niet hoeft te informeren over een datalek als de gelekte data "onbegrijpelijk" is voor iedereen die er geen recht op heeft. Versleutelde data voldoet aan die voorwaarde.
Concreet: als een laptop met versleutelde harde schijf wordt gestolen, of als versleutelde backupbestanden uitlekken, hoef je in veel gevallen:
- De betrokkenen niet individueel te informeren
- De melding bij de AP wel te doen, maar met een lagere urgentie
Dat bespaart je tijd, geld en reputatieschade. Zelfs als encryptie strikt genomen niet verplicht is voor bepaalde data, is dit reden genoeg om het toch te doen.
Meer weten over wat je moet doen bij een datalek? Lees: Wat is een datalek en wat moet je doen?
Checklist: encryptie AVG-compliance
Gebruik dit als snelle controle. Loop de punten door en noteer per item of het in orde is, gedeeltelijk, of nog te doen. Meer over de brede AVG-aanpak vind je in de AVG-checklist voor mkb.
- [ ] HTTPS actief op alle webproperties en subdomeinen
- [ ] TLS 1.2+ op alle API-verbindingen en dataverkeer
- [ ] Full-disk encryptie op alle laptops en werkstations
- [ ] Versleutelde opslag bij cloudproviders ingeschakeld en gecontroleerd
- [ ] Versleutelde backups, inclusief offsite backups
- [ ] E-mailencryptie voor berichten met persoonsgegevens
- [ ] Sleutelbeheer: encryptiesleutels gescheiden van data opgeslagen
- [ ] Per leverancier en systeem gedocumenteerd welke encryptie wordt gebruikt
- [ ] Pseudonimisering toegepast waar herleidbaarheid beperkt moet worden
- [ ] Beveiligingsmaatregelen vastgelegd voor auditdoeleinden
In ComplianceHive leg je per tool en leverancier vast welke encryptiestandaarden worden gebruikt, of er een Verwerkersovereenkomst is en hoe de beveiliging is geregeld. Zo weet je bij een audit precies waar je staat, zonder te hoeven rommelen in spreadsheets.