De toezichtseisen worden steeds strenger. Cyberdreigingen blijven zich ontwikkelen. Ad-hoc risicomonitoring, een spreadsheet hier, een e-mailconversatie daar, is voor geen van beide uitdagingen toereikend. Een framework voor risicobeheer biedt organisaties daarentegen een gestructureerd stappenplan. Het beschermt activa. En dat op een manier die meegroeit met de organisatie.

Dat is de echte meerwaarde. Niet alleen het signaleren van risico’s, maar het ook telkens op dezelfde manier aanpakken, ongeacht wie het werk uitvoert. Een framework biedt verschillende teams bovendien een gemeenschappelijke taal. Beveiliging, financiën en operationele zaken kunnen allemaal naar hetzelfde register verwijzen en bedoelen hetzelfde met ‘hoog risico’. Zonder die gemeenschappelijke taal lopen gesprekken over risico’s vaak vast op definities in plaats van op beslissingen.

Wat is een framework voor risicobeheer (RMF)?

Een framework voor risicobeheer is een herhaalbaar proces om organisatorische risico’s te identificeren, te beoordelen en te beperken. Het biedt voor elke risicobeslissing hetzelfde uitgangspunt: dezelfde categorieën, dezelfde beoordelingslogica, dezelfde beoordelingscyclus.

Die consistentie is wat versnipperde spreadsheets niet kunnen bieden. Een spreadsheet kan risico’s opsommen. Maar het kan niet afdwingen dat elk risico op dezelfde manier wordt beoordeeld, volgens schema wordt geëvalueerd of wordt geëscaleerd wanneer dat nodig is. Naarmate het aantal risico’s toeneemt en meer mensen het register raadplegen, verandert dit tekort in blinde vlekken. Een framework lost dit op door het proces eenmalig te definiëren en overal toe te passen.

De meeste frameworks hebben drie onderliggende componenten gemeen. Een gemeenschappelijke terminologie voor het beschrijven van risico’s. Een gedefinieerd proces om van een ruwe dreiging naar een beheerd risico te komen. En een manier om achteraf aan te tonen dat het proces daadwerkelijk heeft plaatsgevonden. Dat derde onderdeel is belangrijker dan het klinkt. Een toezichthouder of auditor vraagt zelden of u over een risico hebt nagedacht. Ze vragen u om het aan te tonen.

Een vereenvoudigd risicobeheerproces in vijf stappen

De onderstaande specifieke standaarden verschillen qua structuur en terminologie, en de activiteiten die erin zijn opgenomen, zijn niet altijd strikt opeenvolgend. Het NIST RMF hanteert zeven stappen. Het NIST CSF 2.0 hanteert zes functies. ISO 31000 hanteert vijf fasen met weer andere benamingen. Ondanks deze verschillen komen de meeste frameworks neer op dezelfde terugkerende activiteiten. Hier volgt een vereenvoudigde versie, die handig is om frameworks in één oogopslag te vergelijken, maar op zichzelf geen officieel model vormt:

1. Identificeren

Het opsporen van potentiële operationele, financiële, cyber- en compliance-bedreigingen voordat ze tot incidenten leiden. Deze stap is bewust breed opgezet. Een bedreiging die in deze fase niet op de lijst wordt opgenomen, wordt later nooit meer beoordeeld.

2. Beoordelen

Meten hoe waarschijnlijk een risico is en hoeveel impact het op dit moment zou hebben, of dat nu het inherente risico is als er nog niets is ondernomen, of het huidige risiconiveau als er al enkele controles bestaan. Die meting bepaalt of een risico überhaupt moet worden beperkt, of dat het binnen de grenzen valt die de organisatie al kan tolereren.

3. Beperken

Interne controles toepassen, risico's overdragen via verzekeringen of contracten, of risico's die binnen de tolerantie vallen formeel accepteren. Elke controle gaat gepaard met een verwacht restrisico: het niveau waarnaar het risico zou moeten dalen zodra de controle daadwerkelijk is geïmplementeerd. Niet elk risico vereist een controle. Sommige risico's zijn goedkoper om te accepteren dan om op te lossen, en een goed framework maakt dat tot een expliciete beslissing, niet tot een standaardprocedure.

4. Monitoren

Nagaan of het daadwerkelijke, resulterende risico overeenkomt met het restrisico dat de risicobeperkende maatregelen geacht werden te opleveren, en de controles aanpassen wanneer nieuwe bedreigingen opduiken. Een controle die vorig jaar nog werkte, kan ongemerkt zijn werking verliezen naarmate systemen, leveranciers en personeel veranderen. Door te monitoren wordt de kloof tussen het verwachte en het daadwerkelijke risico opgemerkt voordat er een incident plaatsvindt.

5. Besturen

Verantwoordelijkheid toewijzen op leidinggevend niveau en vaststellen hoe risico’s aan de raad van bestuur worden gerapporteerd. Zonder een aangewezen verantwoordelijke wordt het risico vaak automatisch toegeschreven aan degene die het als eerste aan de orde stelde, en niet aan degene die er daadwerkelijk verantwoordelijk voor is.

De meest voorkomende soorten frameworks voor risicobeheer

Elk van de onderstaande frameworks is ontwikkeld om een ander probleem op te lossen. Dat is de belangrijkste reden om de verschillen te kennen. Als u het verkeerde framework kiest, lost u een probleem op dat u in werkelijkheid niet hebt.

ISO 31000

ISO 31000 is een wereldwijde norm die principes en een proces voor risicobeheer beschrijft, en geen checklist waarmee u een certificaat kunt behalen. Het proces omvat het vaststellen van de context, risicobeoordeling, risicobeheersing, monitoring en evaluatie, waarbij communicatie en overleg een doorlopende rol spelen. De norm is van toepassing op elke organisatie, ongeacht de omvang of branche, waardoor het het meest gangbare uitgangspunt is voor een algemeen risicoprogramma.

Omdat de norm niet certificeerbaar is, wordt er geen audit op basis van ISO 31000 uitgevoerd, zoals dat wel het geval is bij ISO 27001. Voor de meeste organisaties is dat een voordeel, geen beperking. Het betekent dat u de onderdelen kunt toepassen die bij u passen en de formaliteiten die niet van toepassing zijn kunt overslaan, zonder dat u daarvoor een externe audit hoeft te doorstaan om dit aan te tonen.

NIST RMF en NIST CSF

Dit zijn twee afzonderlijke NIST-publicaties, en het door elkaar halen ervan is een veelgemaakte fout. NIST RMF, officieel SP 800-37, omvat zeven stappen (Voorbereiden, Categoriseren, Selecteren, Implementeren, Beoordelen, Autoriseren, Monitoren) om individuele informatiesystemen te certificeren en te autoriseren. Het wordt het meest gebruikt binnen de Amerikaanse federale overheid en onder aannemers, hoewel de structuur ervan ook ver daarbuiten is overgenomen.

NIST CSF is een afzonderlijk, breder framework voor de algehele cyberbeveiligingspositie van een organisatie. De huidige versie, CSF 2.0, die in februari 2024 is uitgebracht, verdeelt de werkzaamheden in zes functies: Besturen, Identificeren, Beschermen, Detecteren, Reageren en Herstellen. Met name ‘Besturen’ is in deze versie toegevoegd, wat aangeeft hoeveel gewicht governance nu in het hele framework heeft.

Geen van beide is een certificering die u kunt behalen. In plaats daarvan bieden ze u een gemeenschappelijke terminologie voor cyberbeveiligingsrisico’s. Veel organisaties maken uiteindelijk gebruik van beide: RMF voor autorisatie op systeemniveau, CSF voor het bredere programma dat daarboven staat.

COSO ERM

Het Enterprise Risk Management-framework van COSO, dat in 2017 is bijgewerkt, is bedoeld voor een andere doelgroep dan de twee hierboven genoemde. Het richt zich op de integratie van risico’s in de bedrijfsstrategie, prestaties en bedrijfscultuur, en niet op technische controles. Het is onderverdeeld in vijf onderdelen: Governance en cultuur, Strategie en het stellen van doelstellingen, Prestaties, Evaluatie en herziening, en Informatie, communicatie en rapportage, die samen 20 onderliggende principes omvatten.

COSO ERM kent, net als ISO 31000, geen certificering. Raden van bestuur en directieteams passen het vrijwillig toe om aan te tonen dat risico’s daadwerkelijk zijn geïntegreerd in de bedrijfsvoering en niet als een losstaand onderdeel zijn toegevoegd. Daardoor is het minder bruikbaar voor specifiek cyberbeveiligingsgerelateerd werk, maar wel nuttiger wanneer de risicodiscussie plaatsvindt met de raad van bestuur in plaats van met een IT-team.

COBIT

COBIT, dat wordt beheerd door ISACA, is specifiek ontwikkeld voor IT-governance en niet zozeer voor risicobeheer in het algemeen. De huidige versie, COBIT 2019, omvat 40 governance- en managementdoelstellingen, verdeeld over vijf domeinen. Eén domein heeft betrekking op governance zelf. De overige vier hebben betrekking op managementactiviteiten zoals het plannen, opzetten, beheren en monitoren van IT.

Organisaties maken vaak gebruik van COBIT wanneer het doel is om technologische beslissingen af te stemmen op bedrijfsdoelstellingen. Risicobeheer komt naar voren als een rode draad die door dat bredere governancewerk loopt, niet als het primaire doel van het framework. COBIT wordt vaak omschreven als een framework voor het beheren van andere frameworks. Het staat boven tools zoals ISO 27001 of NIST, in plaats van deze te vervangen.

Frameworks voor risico’s van derden en AI

Zowel relaties met leveranciers als AI-systemen hebben elk hun eigen specifieke frameworks gekregen, omdat geen van beide naadloos in de bovenstaande frameworks past. Risicobeheer met betrekking tot derde partijen (TPRM) heeft betrekking op het risico dat een leverancier of dienstverlener voor uw organisatie met zich meebrengt. Het is een gebied waarvan regelgeving zoals DORA en NIS 2 in toenemende mate verwacht dat organisaties dit formeel beheren, in plaats van het risico zomaar weg te wuiven. De zwakke beveiligingspositie van een leverancier wordt uw risico op het moment dat deze in aanraking komt met uw gegevens of uw systemen.

Wat AI betreft, verdeelt het NIST framework voor AI-risicobeheer, gepubliceerd in 2023, AI-specifieke risico’s in vier functies: Besturen, in kaart brengen, meten en beheren. Het is vrijwillig en er is geen audit of certificaat aan verbonden. Voor organisaties die in plaats daarvan een certificeerbaar equivalent willen, dekt ISO 42001 AI-beheersystemen op dezelfde manier als ISO 27001 informatiebeveiliging dekt. Verwacht dat meer organisaties om het een of het ander zullen vragen naarmate AI-systemen een standaardonderdeel worden van beveiligingsbeoordelingen van leveranciers.

Hoe kiest u het juiste framework voor uw organisatie?

Deze drie factoren spelen de belangrijkste rol bij het maken van een keuze:

Sector- en wettelijke vereisten

Een zorgorganisatie en een softwareleverancier hebben te maken met verschillende verplichtingen, en die verplichtingen wijzen vaak in de richting van verschillende frameworks. Financiële dienstverleners die onder DORA vallen, hebben bijvoorbeeld een framework nodig dat ICT-risico’s kan opvangen op de manier die DORA verwacht, waardoor de meeste van hen de voorkeur geven aan een NIST-achtige of op ISO 31000 gebaseerde aanpak in plaats van COBIT.

Omvang en complexiteit van de organisatie

Een kleinere organisatie met één risicobeheerder en een handvol systemen heeft de 40 doelstellingen van COBIT niet nodig. Deze organisatie heeft iets nodig dat daadwerkelijk consistent kan worden toegepast. Een grotere organisatie met meer onderdelen kan meer structuur aan en heeft die vaak nodig om risico’s binnen alle afdelingen zichtbaar te houden.

Uw huidige compliance-stack

Als u ISO 27001 al hebt behaald, zorgt voortbouwen op ISO 31000 ervoor dat uw risicojargon consistent blijft. Als u zich richt op NIS 2 of een federaal contract dat is afgestemd op NIST, bieden NIST RMF of CSF u controles die directer aansluiten. Het kiezen van een framework dat haaks staat op uw bestaande stack in plaats van deze uit te breiden, leidt tot dubbel werk dat de volgende keer dat u deze taak uitvoert weer terugkomt.

Geen van deze factoren staat op zichzelf. Een middelgroot financieel dienstverleningsbedrijf dat onder DORA valt, bevindt zich bijvoorbeeld op een grensvlak. Een gereguleerde sector, matige complexiteit en vaak al een bestaande ISO 27001-certificering. Die combinatie wijst meestal in de richting van het uitbreiden van wat er al is. Het wijst zelden in de richting van iets dat voor een andere context is ontwikkeld, zoals de focus op IT-governance van COBIT of de benadering op bestuursniveau van COSO.

Voorbeelden van frameworks voor risicobeheer per gebruiksscenario

Simpel gezegd werkt het per gebruiksscenario als volgt:

Dit zijn uitgangspunten, geen definitieve antwoorden. De meeste organisaties kiezen er uiteindelijk voor om twee frameworks te combineren in plaats van er precies één te kiezen, net zoals NIST RMF en CSF vaak samen worden gebruikt

Frameworks voor risicobeheer beheren met Formalize

De meeste organisaties beginnen hun risicoregister in een spreadsheet, maar groeien daar uiteindelijk uit. Een spreadsheet kan weliswaar een lijst met risico’s bevatten, maar kan een risico niet automatisch opnieuw beoordelen wanneer een controle mislukt, een verantwoordelijke er niet aan herinneren dat een evaluatie achterstallig is, of een auditor geen actueel, consistent overzicht tonen in plaats van de export van het vorige kwartaal.

Deze tekortkoming komt vaak op het slechtst mogelijke moment aan het licht, meestal vlak voor een audit of een beoordeling door de raad van bestuur, wanneer iemand zich realiseert dat de spreadsheet niet meer is bijgewerkt sinds drie mensen het team hebben verlaten.

Met de geïntegreerde risicobeoordelingstool van Formalize kunnen teams aangepaste of vooraf gedefinieerde risicocontroles in kaart brengen, risico’s consistent beoordelen en deze continu monitoren, in plaats van de procedure elk kwartaal handmatig te moeten herhalen. Voor organisaties die risico’s beheren binnen meerdere frameworks in plaats van slechts één, houdt het alles-in-één risicobeheerplatform van Formalize dat werk bij in één enkel systeem in plaats van in parallelle spreadsheets per framework. En omdat leveranciersrisico’s zelden lang gescheiden blijven van de rest van het risicoregister, houdt de functionaliteit voor risicobeheer van derden van Formalize leveranciersrisico’s in hetzelfde systeem als al het andere, in plaats van in een eigen, losstaand proces.