Raden van bestuur worden geacht toezicht te houden op de risico's van de hele organisatie, maar de informatie die ze krijgen, zit vaak verspreid over aparte registers, schalen en rapportagecycli. Een gedeelde methodologie voor organisatiebreed risicobeheer (ERM) maakt van die aparte risicoregisters één beeld waarmee de raad van bestuur aan de slag kan.

In een notendop. Raden van bestuur hebben niet nog een risicorapport nodig. Wat ze nodig hebben, is één gedeeld beeld dat over alle domeinen heen dezelfde scoringsmethodologie hanteert, bruto- en restrisico toont en de volgende beslissing helder maakt.

Risicotoezicht door de raad van bestuur zonder gedeeld beeld

NIS2 legt de verantwoordelijkheid voor risicobeheer uitdrukkelijk bij het bestuursorgaan. Artikel 20 verplicht bestuurders om de risicobeheersmaatregelen goed te keuren, toe te zien op de uitvoering ervan en zelf een opleiding te volgen. Het bepaalt ook dat ze aansprakelijk kunnen worden gesteld voor tekortkomingen. Artikel 21 legt vast wat die maatregelen ten minste moeten omvatten. DORA doet hetzelfde voor de financiële sector: het leidinggevend orgaan blijft eindverantwoordelijk voor het kader voor ICT-risicobeheer. ISO 27001 vraagt in de clausule over leiderschap dat de directie eigenaar is van het risicoproces, in plaats van er alleen over geïnformeerd te worden.

De regels zijn duidelijk over wie moet sturen. In de praktijk mist het management vaak het overzicht dat het daarvoor nodig heeft. Een directiecomité krijgt een auditrapport, een cyberdashboard, een nalevingsoverzicht en een financiële risicorapportage. Vier documenten, en geen enkel ervan beantwoordt de vraag die echt op tafel ligt: waar staan we als organisatie, en wat moeten we nu beslissen?

Waarom organisatiebreed risicobeheer in silo's blijft steken

De oorzaak is zelden onwil. Ze is structureel. Het IT-risico ligt bij de CIO, het cyberrisico bij de CISO, het operationele en financiële risico bij de CRO en het gegevensbeschermingsrisico bij de DPO. Elke rol werkt correct binnen het eigen kader, maar elk met een andere schaal, terminologie en tijdshorizon.

Organisatiebreed risicobeheer Verschillende eigenaars. Eén risicobeeld. Eén gedeelde methodologie maakt risico's vergelijkbaar in de hele organisatie.

CIO IT-risico
CISO Cyberrisico
CRO Operationeel & financieel risico
DPO Gegevensbeschermingsrisico

Eén gemeenschappelijke taal Gedeelde methodologie

Waarschijnlijkheid 1–5
Impact 1–5
Bruto- en restrisico

Eén beeld voor het bestuur Vergelijkbare risico's

Duidelijke eigenaars
Duidelijke beslissingen

Het gevolg is dat de cijfers niet op te tellen zijn. Een “hoog” cyberrisico op een driepuntsschaal en een “risicoklasse 4” uit een operationeel model zijn niet zinvol te vergelijken. Zonder gedeelde schaal kan de raad van bestuur ze niet tegen elkaar afwegen. De discussie valt dan terug op het risico dat het luidst wordt aangekaart of dat aan het meest recente incident gekoppeld is.

Als ik een risicoregister opzet, begin ik altijd bij de methodologie, niet bij de risico's. Zonder één afgesproken schaal is elke consolidatie schijnprecisie.

Thomas Baeck

Hoe een bruikbaar organisatiebreed risicoregister eruitziet

Het model dat ik in grote organisaties het nuttigst heb gevonden, is bewust eenvoudig. Neem een omgeving die in verschillende domeinen is ingedeeld.

De kernactiviteiten: gedeelde datadiensten, betalings- en financiële diensten, klantendiensten, IT-ondersteuning voor de hele organisatie en centrale ondersteunende diensten.

Twee transversale domeinen bestrijken informatiebeveiliging en gegevensbescherming.

Het laatste domein omvat gebouwen en facilitair beheer.

Risico-ID	Omschrijving	Categorie	W	I	Bruto	Mitigerende maatregelen	Rest-W	Rest-I	Restrisico	Eigenaar
ENT-01	Kernprocessen hangen af van verouderende legacycomponenten, onderhouden door een steeds kleinere groep mensen.	Technologie en continuïteit	4	4	16 · Kritiek	Stapsgewijs uitfaseringsprogramma; architectuurroadmap; kennisborging.	3	3	9 · Matig	[Naam van de persoon]
SDS-01	Fouten in de datakwaliteit vervuilen de berekeningsbasis van een kernproces.	Data- en informatiekwaliteit	4	5	20 · Kritiek	Validatieregels bij de invoer; afstemming met de brongegevens.	2	5	10 · Hoog	[Naam van de persoon]

Die tabel bevat voor elk risico dezelfde kolommen: risico-ID, omschrijving, categorie, waarschijnlijkheid (1–5), impact (1–5), brutoscore, mitigerende maatregelen, restwaarschijnlijkheid, restimpact, restrisico en een eigenaar met naam en toenaam. Vier elementen maken het verschil.

Eén taxonomie. De waarschijnlijkheid is verankerd in frequentie, van “minder dan eens in de vijf jaar” tot “maandelijks of vaker”. De impact wordt op meerdere dimensies tegelijk gescoord. Bijvoorbeeld: financiële impact in bandbreedtes in euro; operationele impact op dienstverlening en naleving; en reputatie-impact, waarbij de zwaarst wegende dimensie de score bepaalt.
Vier niveaus vatten het resultaat samen: Laag (1–4), Matig (5–9), Hoog (10–14), Kritiek (15–25).
Brutorisico tegenover restrisico als bewijs. Het brutorisico is de blootstelling zonder maatregelen. Het restrisico is wat overblijft zodra de maatregelen genomen zijn. Het verschil tussen beide is het enige bewijs dat een investering in beheersing ook maar enig effect had.
Financiële vertaling. Omdat de impactschaal aan drempels in euro gekoppeld is, wordt een technisch risico bespreekbaar in de taal die een directiecomité al spreekt.
Een eigenaar met naam en toenaam. Geen afdeling. Een persoon.

Daarboven staat één overzichtstabblad: per domein het aantal risico's, de hoogste bruto- en restscore, en een heatmap die elk risico-ID in het raster waarschijnlijkheid × impact plaatst. Dat is het beeld dat de raad van bestuur nodig heeft. Eén blad, alle domeinen, uitschieters meteen zichtbaar.

Het laatste onderdeel is de beslissingsboom, en die vertrekt bewust van het restrisico, niet van het brutorisico. De vereiste reactie wordt zo expliciet:

Restrisico 1–4: het directiecomité neemt kennis van het risico, dat daarna periodiek wordt opgevolgd.
Restrisico 5–9: de eigenaar volgt op, met een halfjaarlijkse evaluatie en rapportage zonder beslissing.
Restrisico 10–14: het directiecomité valideert het mitigatieplan, wijst een eigenaar en een deadline toe en maakt middelen vrij.
Restrisico 15–25: onmiddellijke escalatie, met een beslissing over budget of externe ondersteuning.

Bruto- en restrisico: een voorbeeld

Neem een risico dat elke grote organisatie herkent: kernprocessen die afhangen van verouderende legacycomponenten, onderhouden door een steeds kleinere groep mensen. Waarschijnlijkheid 4 — verstoringen komen meerdere keren per jaar voor. Impact 4 — een uitval treft een kernproces en de financiële gevolgen zijn ernstig. Bruto 16, dus Kritiek.

De maatregelen zijn bekend: een stapsgewijs uitfaseringsprogramma, een architectuurroadmap en kennisborging, zodat de afhankelijkheid van individuen afneemt. Na herbeoordeling komt de restwaarschijnlijkheid op 3 en de restimpact op 3, dus een restrisico van 9, Matig. Voor het directiecomité is dat een duidelijke beslissing. Geen escalatie, wel een eigenaar met een deadline en een halfjaarlijkse evaluatie.

Het geval waarin de impact niet beweegt, is even leerrijk. Bij fouten in de datakwaliteit die de berekeningsbasis van een kernproces vervuilen, brengen validatieregels en afstemming de waarschijnlijkheid terug van 4 naar 2. De impact blijft 5: de gevolgen blijven even zwaar. Een brutorisico van 20 wordt een restrisico van 10 — nog altijd Hoog, dus nog altijd een zaak voor het directiecomité. Het verschil tussen de waarschijnlijkheid verlagen en de impact verlagen, is precies het gesprek dat een raad van bestuur hoort te voeren.

Waarom een organisatiebreed risicoregister de spreadsheet ontgroeit

Zulke registers bouw ik bewust eerst in Excel. Het dwingt discipline af, het kost niets en het maakt de methodologie zichtbaar voor iedereen die eraan werkt. Maar zodra het register moet blijven leven, loopt het vast.

Versies stapelen zich op, en het is niet langer vanzelfsprekend welke versie geldt. De spreadsheet heeft geen workflow of herinneringen, dus de opvolging hangt af van de agenda van één persoon. Maatregelen verwijzen niet naar de beheersmaatregelen die ze implementeren, noch naar het bewijs dat die beheersmaatregelen werken. Het register is een momentopname: het toont geen trend, geen aggregatie doorheen de tijd en geen audittrail van wie wat wanneer heeft gewijzigd. Dezelfde risico's en maatregelen moeten handmatig worden hergebruikt voor NIS2, CyFun, DORA en AVG, werk dat bij elke wijziging opnieuw begint.

Wat een GRC-platform verandert

Dat is wat we met Euraika GRC bouwen: dezelfde logica — domeinen, taxonomie, bruto- en restrisico, eigenaars, beslissingsboom — maar dan levend gehouden. Risico's zijn gekoppeld aan de beheersmaatregelen die erop gericht zijn, en aan de frameworks waarin die beheersmaatregelen voorkomen, zodat één maatregel meerdere verplichtingen afdekt. Eigenaars krijgen opvolgtaken in plaats van een e-mail. Het bewijs zit bij de maatregel, niet in een aparte map. Het restrisico wordt herberekend wanneer de onderliggende beoordeling of maatregel verandert. De rapportage voor het directiecomité ligt klaar, in plaats van elk kwartaal handmatig te worden samengesteld. Het oordeel bij het scoren zelf blijft waar het hoort: AI assisteert, mensen beslissen.

Wat CIO's, CISO's en CRO's van risicorapportage nodig hebben

CIO: maak technische schuld en ketenafhankelijkheden zichtbaar in euro. Een legacydossier dat op de heatmap als restrisico Hoog staat, leidt tot een ander gesprek dan hetzelfde dossier dat begraven ligt in een architectuurnota.

CISO: vertaal cyberrisico naar bedrijfstaal en naar rapportage op bestuursniveau. Niet omdat de raad van bestuur de technologie niet aankan, maar omdat hij budgetbeslissingen moet nemen met dezelfde schaal die hij voor operationeel en financieel risico gebruikt.

CRO: leg één methodologie vast waarmee risico's over de domeinen heen vergelijkbaar worden. Dat is de voorwaarde voor alles wat daarna komt.

Bouwt u een organisatiebreed risicoregister, of probeert u een bestaande spreadsheet nieuw leven in te blazen? In één uur kunnen we Euraika GRC met u overlopen of de methodologie achter een bruikbaar organisatiebreed risicobeeld bespreken. Beide brengen u verder dan nog een versie van hetzelfde bestand.

Thomas Baeck is securityspecialist met praktijkervaring in securityarchitectuur en als CISO. In publieke en private organisaties bouwt hij risicoregisters, ISMS'en en NIS2-programma's die het directiecomité bereiken, en werkt hij aan Euraika GRC, het platform dat naleving van een periodieke inspanning omzet in een doorlopend proces.

Eén risicobeeld voor de raad van bestuur, geen tien aparte registers