Einde inhoudsopgave
De beveiliging van persoonsgegevens (O&R nr. 135) 2022/3.4.1
3.4.1 Inleiding
mr. J.A. Hofman, datum 01-07-2022
- Datum
01-07-2022
- Auteur
mr. J.A. Hofman
- JCDI
JCDI:ADS660995:1
- Vakgebied(en)
Privacy (V)
Voetnoten
Voetnoten
Zie §2.3.2. De Nederlandse wetgever heeft in het kader van de omzetting van de Dataprotectierichtlijn in de Wbp gekozen voor dezelfde systematiek. De wetgever achtte het voorschrijven van specifieke beveiligingsverplichtingen niet aan hem, omdat de maatregelen tijdsgebonden zouden zijn en het voorschrijven ervan aan het nagestreefde niveau van beveiliging af zou doen (Kamerstukken II 1997/98, 25892, 3, p. 98-99 (MvT)).
Zie §3.2.1, §3.3.2, §3.3.3 en §3.3.4, en voor meer over beveiligingsmaatregelen §3.5. Dit komt o.a. doordat verschillende (ICT-)infrastructuurelementen moeten worden beveiligd (zoals hardware, software, netwerken en natuurlijke personen). In dit kader speelt ook mee dat beveiligingsinbreuken vele verschillende oorzaken kunnen hebben. Zo kan het verlies van gegevens bijv. het gevolg zijn van een hack, van een brand die hardware vernietigt en van een fout van een (geautoriseerd) persoon. Deze uiteenlopende risico’s kunnen alleen worden beperkt door uiteenlopende beveiligingsmaatregelen. Zie in dit kader ook de zogenoemde ‘Defense in Depth’-methodologie (bijv. Cleghorn 2013).
De technische bezwaren hebben ermee te maken dat beveiligingsmaatregelen elkaar en het gebruiksgemak en de functionaliteit van systemen kunnen tegenwerken. Gordon & Loeb 2002, p. 439; Cranor & Garfinkel 2005, i.h.b. inleiding; Nurse e.a. 2011, p. 21 e.v.; Cordes 2011, p. 5; Stallings & Brown 2015, p. 35.Vgl. Lichtenbaum & Schneck 2002, p. 48; Whitman & Mattord 2011, p. 155 en 441.
Zie §2.3.4.
Zij klinken daardoor ook sterk door in de Richtsnoeren beveiliging van persoonsgegevens van de (voorganger van) AP, zie CBP 2013.
CBP 2013, §2 (inleiding). De andere twee randvoorwaarden zijn het uitvoeren van een risicoanalyse en het inbedden van de beveiliging in een zogenoemde plan-do-check-act cyclus, waarop ik hierna in de hoofdtekst verder inga.
Zie ook CBP 2013, §2.5.
Dit systeem wordt beschreven in ISO 27001, en verder uitgewerkt in de normen die daarop aansluiten (zie bijv. ISO 27005:2018). Het ISMS komt echter ook terug in andere (niet door de ISO vormgegeven) normen (zie Stuart Broderick 2005, p. 27).
Stuart Broderick 2006, p. 26; Disterer 2013, §5.1; ISO 27000:2020, §4.2.1. Een ISMS gaat er vanuit dat beveiliging niet alleen kan bestaan uit technische maatregelen, maar ook de regulering van processen en het menselijk handelen vereist (Disester 2013, figuur 4; ISO 27001:2017, §10.2; ISO 27000:2020, §4.5.7).
De huidige ISO-normen gaan, in tegenstelling tot hun voorgangers, niet uitdrukkelijk van de PDCA-cyclus uit (zie Awesta 2020, §3.2.2). Dit betekent dat er ook een ISO-certificaat kan worden verleend aan organisaties die hun risicomanagementsysteem zonder gebruikmaking van deze cyclus vormgeven. Desalniettemin klinken de verschillende fases die in deze cyclus worden omarmd nog wel in deze normen door. Zie uitgebreid over de PDCA-cyclus in het kader van informatiebeveiliging Jentjes & De Graaf 2004. Zie voor een toepassing van deze cyclus door de AP, AP Boetebesluit UWV 2021, p. 19.
CBP 2013, inleiding.
ISO 27001:2017, §6.
Ik ga dus niet in op meer sectorspecifieke regels (zoals die voor de zorg, zie ook §3.2.2). Voor een uitgebreidere behandeling van de normen, zie Disester 2013; Awesta 2020, §3.2.2.
De AVG laat verwerkingsverantwoordelijken en verwerkers zelf beslissen hoe ze hun persoonsgegevens(verwerkingen) beveiligen.1 Er bestaan veel verschillende beveiligingsmaatregelen die ze kunnen treffen. De meeste zijn slechts in staat een deel van de betrokken (ICT-)infrastructuur te beveiligen en een deel van de relevante beveiligingsdreigingen voor een deel te ondervangen. Qua effect lopen ze dus sterk uiteen. Geen van allen biedt volledige beveiliging.2 Informatiebeveiligingssystemen bestaan daarom uit meerdere maatregelen. Verwerkingsverantwoordelijken en verwerkers moeten kiezen welke maatregelen ze wel, en welke ze niet treffen. Deze keuze zullen ze moeten afstemmen op hun eigen behoeften en op de AVG-beveiligingseisen, die hierbij als minimum gelden. Tegen het treffen van alle mogelijke maatregelen bestaan echter technische en financiële bezwaren.3
Verwerkingsverantwoordelijken en verwerkers moeten analyseren wat de AVG-beveiligingsbepalingen in hun specifieke geval meebrengen. Blijkens de tekst en preambule van deze verordening moeten ze hierbij verschillende elementen meenemen en spelen risico’s een centrale rol.4 Zo moeten verwerkingsverantwoordelijken en verwerkers hun keuze maken op basis van een risicobeoordeling,5 en wordt het te waarborgen beveiligingsniveau ook wel aangeduid als het ‘op het risico afgestemde beveiligingsniveau’.6 Hoe beveiliging op grond van de AVG vorm moet krijgen en tot in welke mate risico’s moeten worden beheerst, blijft echter de vraag.
Dat de AVG geen inzicht biedt in de in een concreet geval te waarborgen beveiliging, betekent niet dat verwerkingsverantwoordelijken en verwerkers geen enkel houvast hebben wanneer zij hun persoonsgegevensbeveiligingssystemen inrichten. Er bestaan vele informatiebeveiligingsnormen en certificeringsmechanismen die hen bij de vormgeving van hun beveiliging kunnen ondersteunen. Zij gaan, net als art. 5 lid 1 onder f en 32 AVG, uit van risicomanagement, en bieden de mogelijkheid juridische eisen mee te nemen bij de vaststelling van de beveiligingsbehoeften.7 Hun belang voor de vormgeving van een AVG-conform beveiligingssysteem kan dusdanig groot zijn dat de AP hun toepassing als een van de drie randvoorwaarden ziet om aan de AVG-beveiligingseisen te voldoen.8 Ook meer in het algemeen zijn normen en certificeringsmethodes relevant, doordat ze inzicht verschaffen in de manier waarop beveiliging volgens informatiebeveiligingsspecialisten moet worden vormgegeven om tot goede resultaten te leiden. Hierdoor zijn zij niet alleen in een concreet geval behulpzaam bij de vormgeving van een AVG-conforme beveiliging, maar kunnen zij ook in het algemeen houvast bieden bij de uitleg van de AVG-beveiligingsbepalingen.9
In deze paragraaf ga ik in op het houvast dat informatiebeveiligingsnormen en -certificaten bieden voor de vormgeving van beveiliging. Als uitgangspunt neem ik de breedst omarmde informatiebeveiligingsnormen; de ‘Code voor Informatiebeveiliging-’ of ISO 27000-reeks (zie over de relevantie van deze normen §3.2.2). Net als vele andere beveiligingsnormen schrijven zij niet voor welke maatregelen moeten worden getroffen, maar begeleiden ze het beveiligingsproces. Hiertoe laten zij organisaties een eigen informatiebeveiligingsmanagementsysteem vormgeven, een ISMS (naar Information Security Management System).10 Eenmaal opgesteld, begeleidt dit systeem organisaties op een systematische wijze en op managementniveau bij het vaststellen van beveiligingsbehoeften, het achterhalen van de beveiligingsmaatregelen die daarop aansluiten en het beoordelen en verbeteren van beveiligingssystemen.11 Hiertoe is zij gericht op een voortdurend verbeteringsproces.
Een ISMS gaat vaak uit van de zogenoemde ‘risicomanagementcyclus’, ook wel de Plan-Do-Check-Act cycle (hierna: PDCA-cyclus).12 Volgens de AP is de inbedding van deze cyclus “in de dagelijkse praktijk van de organisatie noodzakelijk”.13 Ik beschrijf de stappen van de ISO-normen ook aan de hand van dit systeem. De ‘plan’-fase geeft het meeste inzicht in de manier waarop kan worden vastgesteld wat passende beveiliging is. Hierin vindt de vaststelling van de beveiligingsbehoeften en de beoordeling van de in dat kader relevante risico’s in eerste instantie plaats. Ik behandel haar daarom het uitgebreidst.14 Zij is op te delen in verschillende stadia, die ik afzonderlijk bespreek. Het gaat om de contextbepaling (§3.4.2), de risicobeoordeling (§3.4.3) en de risicobehandeling (§3.4.4). De overige onderdelen van de PDCA-cyclus omvatten het uitvoeren, controleren en verbeteren van het ISMS en bespreek ik tezamen (§3.4.5). Ik beperk mij tot de grote, algemene lijnen van risicomanagement.15