AVG Artikel 32: Beveiliging van de verwerking (2026)

AVG Artikel 32: Beveiliging van de verwerking

AVG artikel 32 verplicht verwerkingsverantwoordelijken en verwerkers om „passende technische en organisatorische maatregelen te treffen om een op het risico afgestemd beveiligingsniveau te waarborgen". Het is een risicogebaseerde, op resultaat gerichte verplichting — geen vaste checklist — maar het noemt vier maatregelen uitdrukkelijk: pseudonimisering en versleuteling; de permanente vertrouwelijkheid, integriteit, beschikbaarheid en veerkracht van systemen; het vermogen om de beschikbaarheid na een incident te herstellen; en een procedure om de doeltreffendheid van die maatregelen regelmatig te testen. Wat „passend" is, wordt beoordeeld tegen de stand van de techniek, de uitvoeringskosten, en de aard, omvang, context, doeleinden en het risico van de verwerking.

Artikel 32 is het artikel waarop een securityreview, een auditor of een toezichthoudende autoriteit u daadwerkelijk toetst. „Onvoldoende technische en organisatorische maatregelen om de informatiebeveiliging te waarborgen" is een van de meest beboete AVG-categorieën — 418 boetes met een gemiddelde van 2,0 miljoen euro, volgens de CMS GDPR Enforcement Tracker — en het aantal van dergelijke boetes steeg met meer dan 40 % tussen 2024 en 2025. Voor B2B-bedrijven schuilt de moeilijkheid niet in het weten dat beveiliging vereist is; ze zit in het aantonen dat uw maatregelen „passend" waren, zowel vóór als na een incident.

Belangrijkste punten

• De norm is „passend", niet „maximaal". Beveiliging moet in verhouding staan tot het risico — beoordeeld tegen de stand van de techniek, de kosten, en de aard, omvang, context en doeleinden van de verwerking (artikel 32(1)).
• Het bindt verwerkers rechtstreeks. Artikel 32 geldt voor zowel verwerkingsverantwoordelijken als verwerkers — dus als B2B-SaaS-leverancier is het uw wettelijke verplichting, niet alleen die van uw klant.
• Versleuteling en pseudonimisering worden uitdrukkelijk genoemd (artikel 32(1)(a)). Het zijn niet de enige maatregelen, maar het ontbreken ervan bij gevoelige gegevens is een terugkerende vaststelling in de handhaving.
• „Regelmatig testen" is een vereiste, geen extraatje (artikel 32(1)(d)) — een eenmalige set maatregelen voldoet niet aan het artikel.
• De maatregelen moeten aantoonbaar zijn. Het verantwoordingsbeginsel (artikel 5(2)) betekent dat een ongedocumenteerde maatregel voor handhavingsdoeleinden een maatregel is die niet bestaat.
• Boetes zijn reëel en fors: Meta 91 mln euro (sept. 2024, wachtwoorden in platte tekst — art. 32(1)); Capita 14 mln £ (Britse ICO, 2025 — art. 32); Vodafone Duitsland 45 mln euro (2025).

Ga naar:

• Wat artikel 32 vereist
• De risicogebaseerde afwegingstoets
• De vier genoemde maatregelen
• Is versleuteling verplicht?
• Hoe u naleving van artikel 32 aantoont
• ISO 27001 bijlage A ↔ artikel 32 in kaart
• Checklist naleving artikel 32
• Boetes en handhaving
• De positie van het VK en Noorwegen
• Artikel 32 operationeel maken

---

Wat artikel 32 vereist

Artikel 32(1) van Verordening (EU) 2016/679 formuleert de kernplicht:

„Rekening houdend met de stand van de techniek, de uitvoeringskosten, alsook met de aard, de omvang, de context en de verwerkingsdoeleinden en de qua waarschijnlijkheid en ernst uiteenlopende risico's voor de rechten en vrijheden van natuurlijke personen, treffen de verwerkingsverantwoordelijke en de verwerker passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen."

Twee kenmerken maken artikel 32 anders dan een voorschrijvende beveiligingsnorm. Ten eerste is de verplichting gedeeld: ze rust op de verwerkingsverantwoordelijke én de verwerker. Voor een B2B-SaaS-bedrijf dat klantgegevens verwerkt, is artikel 32 een rechtstreekse wettelijke plicht — u kunt haar niet delegeren aan uw klant of u verschuilen achter diens instructies. Ten tweede is ze risicogebaseerd en technologieneutraal: het artikel vermijdt bewust een vaste lijst van maatregelen, omdat „passende" beveiliging in 2016 niet dezelfde is als „passende" beveiliging vandaag. Wat van u wordt verwacht, schaalt mee met de gevoeligheid en omvang van wat u verwerkt.

Artikel 32(2) scherpt de risicolens aan door te verlangen dat in het bijzonder rekening wordt gehouden „met de risico's die de verwerking met zich meebrengt, met name als gevolg van de vernietiging, het verlies, de wijziging of de ongeoorloofde verstrekking van of ongeoorloofde toegang tot doorgezonden, opgeslagen of anderszins verwerkte gegevens, hetzij per ongeluk hetzij onrechtmatig". Artikel 32(4) voegt een personeelsdimensie toe: eenieder die onder uw gezag handelt, mag persoonsgegevens uitsluitend op instructie verwerken, niet naar eigen inzicht.

---

De risicogebaseerde afwegingstoets

De zinsnede die in artikel 32 het meeste werk verzet, is „op het risico afgestemd". Passendheid wordt bepaald door een afweging van vier factoren, die in het artikel zelf staan:

Factor	Wat het in de praktijk betekent
Stand van de techniek	Maatregelen moeten meebewegen met de actuele, breed toegepaste beveiligingspraktijk. De basislijn van gisteren (bijv. onversleuteld transport, SHA-1-hashing) is niet langer „passend".
Uitvoeringskosten	Kosten zijn een legitieme factor — maar worden afgewogen tegen het risico, niet gebruikt om goedkope-en-ontoereikende maatregelen te vergoelijken waar de gegevens gevoelig zijn.
Aard, omvang, context en doeleinden	Het verwerken van bijzondere categorieën gegevens, of grootschalige gegevens, verhoogt de lat. Een salarisplatform wordt aan een hogere norm gehouden dan een laagrisico-marketinglijst.
Risico voor rechten en vrijheden	De waarschijnlijkheid en ernst van de schade voor personen — identiteitsdiefstal, financieel verlies, discriminatie — bepalen het beoogde beveiligingsniveau.

Het EDPB One-Stop-Shop-casusoverzicht over beveiliging en datalekmelding laat zien hoe toezichthoudende autoriteiten dit in echte besluiten toepassen: autoriteiten hebben vastgesteld dat waar een dienst gegevens „over een groot aantal gebruikers" verwerkt, „hogere eisen aan de verwerkingsverantwoordelijke moeten worden gesteld". Het overzicht bevestigt ook een cruciale nuance van het Hof van Justitie — het loutere bestaan van een inbreuk bewijst op zichzelf niet dat de maatregelen ontoereikend waren. De vraag is altijd of de maatregelen passend waren gezien het risico, beoordeeld op het moment zelf.

Dat is het tweesnijdende karakter van artikel 32: het geeft u flexibiliteit, maar het betekent ook dat „we hadden een firewall" geen verweer is. U moet de risicobeoordeling kunnen reconstrueren die uw keuze voor bepaalde maatregelen rechtvaardigde.

---

De vier genoemde maatregelen (artikel 32(1)(a)–(d))

Artikel 32(1) noemt vier voorbeeldmaatregelen „waar passend". Het is geen uitputtende lijst, maar het zijn de ankers waaraan elke beoordeling begint:

• (a) Pseudonimisering en versleuteling van persoonsgegevens — het verminderen van de identificeerbaarheid van gegevens en het onleesbaar maken ervan voor onbevoegden.
• (b) Vertrouwelijkheid, integriteit, beschikbaarheid en veerkracht — de klassieke CIA-driehoek plus veerkracht: het permanente vermogen van systemen en diensten om ongunstige gebeurtenissen te weerstaan en ervan te herstellen. Dit vertaalt zich naar toegangsbeheer, MFA, netwerkbeveiliging en hoogbeschikbare architectuur.
• (c) Het tijdig herstellen van de beschikbaarheid en toegang na een fysiek of technisch incident — in de praktijk geteste back-ups en een capaciteit voor uitwijk en bedrijfscontinuïteit.
• (d) Een procedure om de doeltreffendheid regelmatig te testen, te beoordelen en te evalueren — penetratietests, kwetsbaarhedenbeheer en periodieke toetsing van maatregelen. In het EDPB-casusoverzicht merkte één autoriteit specifiek op dat artikel 32(1)(d) verlangt dat „alle waarschijnlijke uitkomsten" worden getest tijdens de ontwikkeling van software die persoonsgegevens verwerkt.

De opname van (d) is de reden waarom artikel 32 een doorlopende verplichting is. Een set maatregelen die bij lancering passend was, verslijt: certificaten verlopen, afhankelijkheden krijgen CVE's, en de stand van de techniek beweegt. Artikel 32 vereist een procedure die blijft aantonen dat de maatregelen nog steeds werken.

---

Is versleuteling verplicht?

Strikt genomen is geen enkele maatregel in elk geval verplicht — artikel 32 is risicogebaseerd. Maar versleuteling is een van slechts twee maatregelen die in artikel 32(1)(a) worden genoemd, en in de praktijk behandelen toezichthoudende autoriteiten het als een standaardverwachting voor persoonsgegevens in rust en tijdens verzending. Het EDPB-casusoverzicht vermeldt dat autoriteiten een schending van artikel 32 vaststelden waar een bedrijf HTTPS gebruikte voor zijn website in het algemeen, maar niet op contactformulierpagina's die namen, e-mailadressen en vrije tekst verzonden — de ontbrekende versleuteling vormde op zichzelf al de inbreuk.

Het meest ingrijpende afzonderlijke handhavingsvoorbeeld is de boete van 91 miljoen euro die Meta van de Ierse DPC kreeg (september 2024) voor het opslaan van gebruikerswachtwoorden in platte tekst. De DPC stelde schendingen vast van de artikelen 5(1)(f), 32(1), 33(1) en 33(5) — de opslag in platte tekst was in de kern een falen onder artikel 32.

Versleuteling heeft ook een doorslaggevend gevolg verderop: onder artikel 34(3) neemt doeltreffende versleuteling die de gelekte gegevens onbegrijpelijk maakt, de plicht weg om de inbreuk aan de getroffen betrokkenen mee te delen. Sterke maatregelen onder artikel 32 zijn daarom niet alleen op zichzelf een nalevingsvereiste — ze zijn ook het feit dat het vaakst voorkomt dat een inbreuk een publiek, klantgericht voorval wordt.

---

Hoe u naleving van artikel 32 aantoont

Artikel 32 is slechts de helft van de verplichting. Het verantwoordingsbeginsel (artikel 5(2)) verlangt dat u naleving aantoont — wat betekent dat elke maatregel bewijs nodig heeft dat een klant, auditor of toezichthoudende autoriteit kan inzien. Hier schieten de meeste B2B-bedrijven tekort: de maatregelen bestaan, maar het bewijs is verspreid over screenshots, spreadsheets en kennis in hoofden.

Het praktische model is om elk onderdeel van artikel 32(1) te koppelen aan een concrete TOM en vervolgens aan de plek waar die TOM wordt bewezen — idealiter een openbaar of afgeschermd Trust Center waar prospects en auditors zichzelf kunnen bedienen:

Vereiste artikel 32	Concrete technische/organisatorische maatregel	Waar het staat (het bewijs)
32(1)(a) — Versleuteling & pseudonimisering	TLS 1.2+ tijdens verzending; AES-256 in rust; getokeniseerde identifiers	Beveiligingswhitepaper / TOM's-document in het Trust Center
32(1)(b) — Vertrouwelijkheid & toegangsbeheer	RBAC, SSO/SAML, afgedwongen MFA, least-privilege-reviews	Toegangsbeleid + logs van toegangsreviews
32(1)(b) — Integriteit & veerkracht	Wijzigingsbeheer, manipulatiebestendige logging, multi-AZ-uitrol	Architectuuroverzicht + logging-/monitoringbewijs
32(1)(c) — Beschikbaarheid herstellen	Geautomatiseerde versleutelde back-ups, geteste uitwijk-runbook, gedefinieerde RTO/RPO	Back-up- & bedrijfscontinuïteitsbeleid + datum laatste uitwijktest
32(1)(d) — Regelmatig testen	Jaarlijkse penetratietest, continue kwetsbaarhedenscanning, toetsing van maatregelen	Samenvatting pentest + bewijs kwetsbaarhedenbeheer
Overkoepelend — organisatorisch	Beveiligingsbeleid, medewerkerstraining, incidentresponsplan, leveranciersonderzoek	Beleidspakket + trainingsregistraties + subverwerkerslijst

Het patroon dat bedrijven die de inkoopfase doorstaan onderscheidt van bedrijven die vastlopen, zijn niet sterkere maatregelen — het is actueel, opvraagbaar bewijs. Wanneer het securityteam van een prospect vraagt „hoe voldoet u aan artikel 32(1)(d)?", moet het antwoord een link zijn naar een gedateerde samenvatting van een penetratietest, niet een e-mailconversatie van drie weken.

---

ISO 27001 bijlage A ↔ artikel 32 in kaart

De efficiëntste manier om artikel 32 operationeel te maken, is het inrichten van een ISO/IEC 27001 Information Security Management System (ISMS). ISO 27001 is wettelijk niet verplicht op grond van de AVG, maar artikel 32(3) staat uitdrukkelijk toe dat het aansluiten bij een goedgekeurd certificeringsmechanisme wordt gebruikt als een element om naleving aan te tonen — en de bijlage-A-maatregelen van ISO 27001:2022 sluiten zuiver aan op de vier onderdelen van artikel 32:

Vereiste artikel 32	ISO/IEC 27001:2022 bijlage-A-maatregelen
32(1)(a) Versleuteling / pseudonimisering	A.8.24 Gebruik van cryptografie
32(1)(b) Vertrouwelijkheid & toegangsbeheer	A.5.15 Toegangsbeheer; A.8.2 Rechten voor bevoorrechte toegang; A.8.3 Beperking van toegang tot informatie; A.8.5 Veilige authenticatie
32(1)(b) Integriteit & veerkracht	A.8.16 Monitoringactiviteiten; A.8.32 Wijzigingsbeheer; A.8.6 Capaciteitsbeheer
32(1)(c) Beschikbaarheid herstellen	A.8.13 Back-up van informatie; A.5.29 Beveiliging tijdens verstoring; A.5.30 ICT-gereedheid voor bedrijfscontinuïteit
32(1)(d) Regelmatig testen	A.8.8 Beheer van technische kwetsbaarheden; A.8.29 Beveiligingstests bij ontwikkeling en acceptatie; A.5.35 Onafhankelijke toetsing van informatiebeveiliging

Deze koppeling is de kern van de aanpak van ISMS-plus-Trust-Center: het ISMS levert u de interne governance die passende maatregelen voortbrengt, en het Trust Center levert de externe aantoonbaarheid die artikel 5(2) verlangt. Een ISO 27001-certificaat en verklaring van toepasselijkheid (SoA) worden een kortschrift dat uw klanten al vertrouwen — wat de reden is dat „ISO 27001-gecertificeerd" een van de eerste dingen is waar een Europees inkoopteam naar zoekt.

---

Checklist naleving artikel 32

Gebruik dit als een snelle zelfbeoordeling. Elk item moet aantoonbaar zijn, niet alleen geïmplementeerd:

• Risicobeoordeling die documenteert waarom uw maatregelen passend zijn bij het risico van uw verwerking
• Versleuteling van persoonsgegevens tijdens verzending (TLS 1.2+) en in rust (bijv. AES-256)
• Pseudonimisering waar die het risico vermindert zonder het doel te frustreren
• Toegangsbeheer — RBAC, SSO, afgedwongen MFA en periodieke least-privilege-reviews
• Logging en monitoring die volstaan om beveiligingsgebeurtenissen te detecteren en te reconstrueren
• Geteste back-ups en een gedocumenteerd, beoefend uitwijk-/bedrijfscontinuïteitsplan (RTO/RPO gedefinieerd)
• Een programma voor regelmatig testen — ten minste een jaarlijkse penetratietest plus continue kwetsbaarhedenscanning
• Beveiligingsbeleid en bewijs van beveiligingsbewustzijnstraining voor medewerkers
• Een getest incidentresponsplan gekoppeld aan uw workflow voor datalekmelding onder artikel 33
• Leveranciers-/subverwerkersonderzoek, zodat uw toeleveranciers aan een gelijkwaardige norm voldoen
• Actueel, opvraagbaar bewijs voor elk van bovenstaande items, gehost op een plek waar klanten en auditors het kunnen vinden

---

Boetes en handhaving

Overtredingen van artikel 32 vallen in de lagere boetecategorie onder artikel 83(4): tot 10 miljoen euro of 2 % van de totale wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is. Maar „lagere categorie" is misleidend — beveiligingsboetes behoren tot de meest frequente in de AVG:

• Meta — 91 miljoen euro (Ierse DPC, september 2024): voor het opslaan van gebruikerswachtwoorden in platte tekst — uitdrukkelijk een schending van artikel 32(1) (naast de artikelen 5(1)(f), 33(1) en 33(5)).
• Capita plc — 14 miljoen £ (Britse ICO, oktober 2025): na een cyberaanval in 2023 waarbij gegevens van circa 6,6 miljoen personen werden geëxfiltreerd; de ICO stelde schendingen vast van de artikelen 5(1)(f), 32(1) en 32(2) UK GDPR (een aanvankelijk voorgestelde 45 miljoen £, verlaagd bij schikking).
• Vodafone Duitsland — 45 miljoen euro (BfDI, 2025): onder meer boetes voor beveiligingsgebreken en ontoereikend toezicht op gegevensverwerkers.
• Meta — 251 miljoen euro (Ierse DPC, december 2024): voor het Facebook-datalek uit 2018 dat circa 29 miljoen gebruikers trof — opgelegd wegens gegevensbescherming door ontwerp en door standaardinstellingen (artikel 25) en falen bij de datalekmelding (artikel 33), een herinnering dat zwakke beveiligingsengineering over meerdere artikelen wordt beboet, niet alleen artikel 32.

De categorie doet er meer toe dan enige afzonderlijke zaak. „Onvoldoende technische en organisatorische maatregelen om de informatiebeveiliging te waarborgen" is goed voor 418 boetes met een gemiddelde van 2,0 miljoen euro volgens de CMS Enforcement Tracker, en het aantal van dergelijke boetes steeg met meer dan 40 % tussen 2024 en 2025 (van 69 naar 97 zaken volgens de analyse van Surfshark). De cumulatieve AVG-boetes bereikten in januari 2026 7,1 miljard euro, waarvan ongeveer 1,2 miljard euro alleen al in 2025 werd opgelegd, aldus de DLA Piper GDPR Fines and Data Breach Survey (januari 2026).

---

De positie van het VK en Noorwegen

Artikel 32 is een Europese norm, en de beveiligingsplicht bij de verwerking is opmerkelijk consistent in het bredere Europese compliancelandschap.

Verenigd Koninkrijk. De UK GDPR behoudt de beveiligingsplicht van artikel 32 in identieke inhoud, gehandhaafd door de Information Commissioner's Office (ICO). De ICO heeft enkele van de grootste beveiligingsgerelateerde boetes van Europa opgelegd — waaronder British Airways (20 miljoen £) en Marriott (18,4 miljoen £), beide gericht op ontoereikende beveiliging — en de Capita-boete uit 2025 bevestigt dat de honger niet is bekoeld. De Data (Use and Access) Act 2025 (koninklijke goedkeuring op 19 juni 2025) hervormde delen van de Britse gegevensbescherming, maar verzwakte de beveiligingsplicht niet, en de Europese Commissie ging over tot vernieuwing van het adequaatheidsbesluit voor het VK na toetsing van de hervormingen, zodat de EU-VK-gegevensstromen doorgaan.

Noorwegen en de EER. Noorwegen past de AVG toe via de EER-overeenkomst (van kracht sinds juli 2018), zodat artikel 32 Noorse verwerkingsverantwoordelijken en verwerkers in identieke bewoordingen bindt, onder toezicht van het Datatilsynet. De praktische conclusie voor elk bedrijf dat in de EU, de EER en het VK actief is, is dat u één beveiligingsbasislijn moet ontwerpen op de norm van „passende maatregelen" — die wordt niet lager door een grens over te steken, en de handhavingsgeschiedenis van de ICO laat zien dat ze duurder kan worden.

---

Artikel 32 operationeel maken in een Trust Center

Artikel 32 is waar beveiligingsengineering en juridische verantwoording samenkomen. De maatregelen zijn het werk van het securityteam; het aantonen ervan — vóór een deal, tijdens een audit en na een inbreuk — is waar het artikel wordt gewonnen of verloren. Drie capaciteiten veranderen artikel 32 van een periodieke stormloop in een permanent bezit:

1. Een levend TOM's-document gekoppeld aan artikel 32(1)(a)–(d), actueel gehouden in plaats van vóór elke audit herschreven — zodat „wat zijn uw technische en organisatorische maatregelen?" één gezaghebbend antwoord heeft.
2. Bewijs dat zichzelf ververst. Continue monitoring houdt het bewijs van versleuteling, toegangsreviews, back-ups en tests actueel, en voldoet tegelijk aan het onderdeel „regelmatig testen" van artikel 32(1)(d) én aan de verantwoordingsplicht van artikel 5(2).
3. Een zelfbedieningsomgeving voor kopers en auditors. Een Trust Center laat het securityteam van een prospect uw positie onder artikel 32 bevestigen zonder een vragenlijstcyclus — hetzelfde bewijs dat een due-diligence-toets beantwoordt, is het bewijs dat een toezichthoudende autoriteit na een incident opvraagt.

Dit is het ISMS-en-Trust-Center-model in de praktijk: een ISMS brengt passende maatregelen voort; een Trust Center maakt ze aantoonbaar. Het Trust Center-platform van Orbiq houdt de TOM's, certificeringen, subverwerkerslijst en testbewijzen op één steeds actuele plek, zodat uw verhaal over artikel 32 klaarligt voordat iemand ernaar vraagt — voor een prospect, een auditor of het Datatilsynet.

Artikel 32 beloont dezelfde discipline als de rest van het beveiligingsregime van de AVG: doe het onopvallende werk vooraf, houd het bewijs actueel, en het artikel houdt op een risico te zijn en wordt iets waar u een klant naartoe kunt verwijzen.

Toon uw naleving van artikel 32 aan met Trust Center-bewijs. Ontdek hoe het Trust Center-platform van Orbiq werkt →

---

Bronnen & referenties

1. Verordening (EU) 2016/679 (AVG) — Volledige tekst (EUR-Lex ELI) — Publicatieblad van de Europese Unie; artikel 32 in context.
2. gdpr-info.eu — Artikel 32 (Beveiliging van de verwerking) — Artikeltekst en overwegingen.
3. EDPB — One-Stop-Shop-casusoverzicht: beveiliging van de verwerking en datalekmelding — Hoe toezichthoudende autoriteiten „passende" TOM's in de praktijk beoordelen.
4. CMS GDPR Enforcement Tracker Report 2025/2026 — Numbers and Figures — Boetecategorieën en de Meta-beveiligingsboete van 251 mln euro.
5. DLA Piper GDPR Fines and Data Breach Survey: januari 2026 — 7,1 miljard euro cumulatief; 1,2 miljard euro in 2025.
6. Surfshark Research: GDPR fines 2025 — Artikel 32-boetes met 40 %+ gestegen (69 → 97 zaken); Meta 251 mln euro + 91 mln euro.
7. ICO — A guide to data security (UK GDPR) — Britse richtsnoeren voor beveiliging van de verwerking.
8. Datatilsynet — Noorse toezichthouder gegevensbescherming — Beveiligingsrichtsnoeren (Noorwegen / EER).

---

Verder lezen

• AVG-compliance in 2026: beginselen, rechten en hoe u het aantoont
• AVG-compliance voor B2B-SaaS: artikelen 28–34 uitgelegd
• AVG Artikel 28: verwerkersverplichtingen & verwerkersovereenkomst
• AVG Artikel 33: de 72-uursmeldplicht bij datalekken
• AVG Artikel 34: betrokkenen informeren bij een datalek
• Beste ISMS-software voor Europese bedrijven
• Continue monitoring