3.4.3 Risicobeoordeling

Informatiebeveiligingsspecialisten gaan ervan uit dat beveiliging nooit volledig kan zijn.1 Zij verrichten veel onderzoek naar de effectiefste manier om beveiliging vorm te geven. Er zijn verschillende manieren waarop beveiliging kan worden benaderd.2 Vaak worden er enkele standaardmaatregelen geïmplementeerd. Het systeem dat doorklinkt in het ISMS, en onderdeel uitmaakt van de beste praktijken in het algemeen, is de risicogebaseerde benadering. Beveiliging komt daarbij niet zozeer neer op het uitsluiten van alle denkbare beveiligingsincidenten, maar op het beheersen van de risico’s die in een concreet geval relevant zijn. Deze beheersing moet resulteren in op een situatie afgestemde en effectieve beveiliging die bovendien vaak minder kostbaar is dan het ongericht afdekken van beveiligingsrisico’s.

Vanwege deze invalshoek verschuift het focuspunt bij de vormgeving van een ISMS nadat de te beveiligen informatie­(verwerkingen) zijn geïdentificeerd naar de risico’s die zijn verbonden aan deze informatie(verwerkingen). Het begrip ‘risico’ wordt daarbij uitgelegd als het negatieve effect dat een onzekere factor op de informatie(verwerkingen) kan hebben.3 Deze risico-benadering lijkt, afgaande op art. 32 lid 2 AVG, in de AVG te zijn omarmd. Voor de verplichting tot het waarborgen van het passende beveiligingsniveau betekent dit dat verwerkingsverantwoordelijken en verwerkers niet alle beveiligings­incidenten hoeven te voorkomen. Een beveiligings­incident betekent dan ook niet automatisch dat de beveiliging gebrekkig is geweest.4 Wel beschouwt het Europees Comité voor gegevens­bescherming een beveiligingsincident een indicatie voor een zwakke beveiliging.5

Bij de afstemming van een beveiligingssysteem op de betrokken risico’s moeten verwerkingsverant­woordelijken en verwerkers de risico’s beoordelen. Zo kunnen ze de risico’s die zijn verbonden aan de door hen te verwerken persoonsgegevens identificeren en prioriteren. Om op een gestructureerde manier risicobeoordelingen te verrichten, dienen organisaties ingevolge de ISO-normen bij het ontwerp van hun ISMS twee sets criteria te formuleren, die tezamen een methode vormen die leidend is bij risicobeoordelingen. Een van deze sets betreft de momenten waarop de organisatie risicobeoordelingen verricht, de ander de daadwerkelijke beoordeling van deze risico’s.6 Bij het opstellen van deze laatste set criteria beslist een organisatie hoe zij risico’s nu en in de toekomst zal beoordelen, en welke kaders ze hanteert voor het beheersen en accepteren daarvan.7 Gezien het grote belang van risicobeheersing voor het te waarborgen beveiligingsniveau, stelt een organisatie zo de kaders voor het beveiligingsniveau dat zij uiteindelijk zal waarborgen.8 Verwerkingsverantwoordelijken en verwerkers dienen bij het opstellen van deze criteria dan ook aandacht te besteden aan de eisen die de AVG stelt. Zo zullen zij moeten kijken naar ‘verwerkingsrisico’s’ en ‘risico’s voor de grondrechten en fundamentele vrijheden’.9

Bij het vormgeven van de risicobeoordelingscriteria dienen verwerkingsverantwoordelijken en verwerkers niet alleen de mogelijke gevolgen van een risicoverwezenlijking (en dus wederom de aard, context en omvang van de verwerking) mee te nemen, maar is ook plaats voor alle andere elementen die in dit kader relevant zijn voor een organisatie, zoals een kosten-batenanalyse (de uitvoeringskosten). Het ISMS laat organisaties met andere woorden de ruimte om financiële motieven ten grondslag te leggen aan het besluit om een bepaald risico niet of beperkt te beheersen – wat ogenschijnlijk in lijn is met de AVG-beveiligingsbepalingen.10 Ook kunnen lage kosten juist een reden zijn om extra beveiliging te treffen. Relatief eenvoudige of goedkope maatregelen (zoals volgens de AP meerfactorauthenticatie)11, maken hierdoor in de regel eerder onderdeel uit van de beste praktijken dan kostbaardere en ingewikkeldere maatregelen. Andere belangen die bij risicobeoordelingen van belang kunnen zijn, zijn de functionaliteit en gebruiksvriendelijkheid van een product of (ICT-)infrastructuur.12 Beveiliging kan hieraan afdoen. Zo kan een sterke nadruk op de vertrouwelijkheid van bepaalde gegevens het gebruiksgemak en de functionaliteit van het systeem in de weg staan (bijv. doordat partijen tijdrovende handelingen moeten verrichten om de toegang tot deze gegevens te verkrijgen).13 Wanneer het essentieel is dat gegevens gemakkelijk toegankelijk zijn voor geautoriseerde personen (denk aan medische gegevens op de spoedeisende hulp) zal men dit belang dan ook moeten afwegen tegen het belang van vertrouwelijkheidswaarborging.14

Nadat verwerkingsverantwoordelijken en verwerkers hun risicobeoordelingscriteria hebben vormgegeven, kan de eerste uitvoerende stap van de risicobeoordeling plaatsvinden: de risico-identificatie.15 Hierbij moeten ze in kaart brengen welke risico’s in het algemeen in relatie tot de eerder vastgestelde dreigingen en kwetsbaarheden bestaan.16 Bevindingen van de AP, zoals dat datalekken die het gevolg zijn van hacking, malware en phishing toenemen,17 zijn hierbij relevant.18

Nadat de algemene risico’s zijn geïnventariseerd, kunnen verwerkingsverantwoordelijken en verwerkers de relevante risico’s voor het betreffende ISMS analyseren. Hierbij moeten ze per geïdentificeerd risico onderzoeken wat de kans is dat het zich realiseert (de waarschijnlijkheid), en wat de mogelijke gevolgen zouden zijn indien het zich zou realiseren (de impact). Dit wordt vaak weergegeven als risico = impact * kans.19 In de AVG komt dit terug als ‘de qua waarschijnlijkheid en ernst uiteenlopende risico’s’. Bij de beoordeling van de impact kunnen uiteenlopende gevolgen worden meegenomen, zoals juridische en financiële gevolgen en de gevolgen voor de reputatie van de organisatie, het milieu en de gezondheid. Deze worden vaak uitgedrukt met een getal op de schaal van nul tot vijf. De waarschijnlijkheid wordt uitgedrukt in kwalitatieve termen, zoals frequent, waarschijnlijk, soms en uitzonderlijk.20 Door de impact en waarschijnlijkheid samen te nemen, wordt vastgesteld in hoeverre deze risico’s zijn verbonden aan de informatie(verwerkingen) waarop het ISMS ziet.21 Aan de hand hiervan kunnen verwerkingsverantwoordelijken en verwerkers per informatiegroep of (ICT-)infrastructuurelement kijken naar het risico op een schending van een van de in de §3.3 besproken beveiligingsdoelen. Zo kunnen zij per doel inschatten of het risico op een schending ervan ‘laag’, ‘gemiddeld’ of ‘hoog’ is.22

De laatste fase van de risicobeoordeling is de risico-evaluatie. Hierbij moet een organisatie bepalen in hoeverre zij de geïdentificeerde en geanalyseerde risico’s zal gaan beheersen. Gedurende dit proces moet een organisatie aan de hand van de eerder opgestelde criteria per geïdentificeerd risico beslissen hoe zij de risico’s gaat beheersen.23 Ze kan een risico accepteren, ontwijken, middels een verzekering afwentelen of beperken.24 De (delen van de) risico’s die blijven bestaan nadat de beveiligingsmaatregelen zijn getroffen zijn de zogenoemde restrisico’s. De mate waarin de risico’s worden beheerst, is aldus bepalend voor het beveiligingsniveau dat daadwerkelijk wordt gewaarborgd.

De risico-evaluatie vereist de vergelijking van de risicoanalyse met de eerder opgestelde criteria betreffende de beoordeling en acceptatie van risico’s. Zo kan de organisatie aan de hand van haar eigen ISMS beoordelen in hoeverre de risico’s die haar mogelijk raken, moeten worden beheerst. Om duidelijkheid te verkrijgen omtrent de afwegingen die in het kader van het treffen van beveiligingsmaatregelen moeten worden gemaakt, zal zij deze risico’s in het kader van risicobeheer tot slot prioriteren.25

Net als bij de contextbepaling helpen informatiebeveiligings­normen bij de vormgeving van de risicobeoordeling, maar stellen ze geen inhoudelijke eisen. Dat een dergelijke standaard is gevolgd, zegt (in beginsel) dan ook nog niet dat de inhoud van de beveiligingssystemen inhoudelijk voldoet aan de eisen die de wet of de praktijk hieraan stelt. Voor wat betreft de praktische eisen kan dit anders zijn in het geval er een certificaat is uitgereikt, zie ook §3.2.2 en §6.5.