Handreiking

Handreiking

Handreiking Risicoregister en Risico Acceptatie Overeenkomst (RAO)

Een operationeel kennisproduct ter ondersteuning van de implementatie van de Baseline Informatiebeveiliging Overheid (BIO)

Colofon

Naam document

Handreiking Risicoregister en Risico Acceptatie Overeenkomst (RAO)

Versienummer

1.01

Versiedatum

juni 2020

Versiebeheer

Het beheer van dit document berust bij de Informatiebeveiligingsdienst voor gemeenten (IBD).

Vereniging van Nederlandse Gemeenten / Informatiebeveiligingsdienst voor gemeenten (IBD)

Tenzij anders vermeld, is dit werk verstrekt onder een Creative Commons Naamsvermelding-Niet Commercieel-Gelijk Delen 4.0 Internationaal licentie. Dit houdt in dat het materiaal gebruikt en gedeeld mag worden onder de volgende voorwaarden: Alle rechten voorbehouden. Verveelvoudiging, verspreiding en gebruik van deze uitgave voor het doel zoals vermeld in deze uitgave is met bronvermelding toegestaan voor alle gemeenten en overheidsorganisaties.

Voor commerciële organisaties wordt hierbij toestemming verleend om dit document te bekijken, af te drukken, te verspreiden en te gebruiken onder de hiernavolgende voorwaarden.

1. De IBD wordt als bron vermeld.

2. Het document en de inhoud mogen commercieel niet geëxploiteerd worden.

3. Publicaties of informatie waarvan de intellectuele eigendomsrechten niet bij de verstrekker berusten, blijven onderworpen aan de beperkingen opgelegd door de IBD en / of de Vereniging van Nederlandse Gemeenten.

4. Iedere kopie van dit document, of een gedeelte daarvan, dient te zijn voorzien van de in deze paragraaf vermelde mededeling.

Wanneer dit werk wordt gebruikt, hanteer dan de volgende methode van naamsvermelding: “Vereniging van Nederlandse Gemeenten / Informatiebeveiligingsdienst voor gemeenten”, licentie onder: CC BY-NC-SA 4.0.

Bezoek xxxx://xxxxxxxxxxxxxxx.xxx/xxxxxxxx/xx-xx-xx/0.0 voor meer informatie over de licentie.

Rechten en vrijwaring

De IBD is zich bewust van haar verantwoordelijkheid een zo betrouwbaar mogelijke uitgave te verzorgen. Niettemin kan de IBD geen aansprakelijkheid aanvaarden voor eventueel in deze uitgave voorkomende onjuistheden, onvolledigheden of nalatigheden. De IBD aanvaardt ook geen aansprakelijkheid voor enig gebruik van voorliggende uitgave of schade ontstaan door de inhoud van de uitgave of door de toepassing ervan.

Met dank aan

De expertgroep en de reviewgemeenten die hebben bijgedragen aan het vervaardigen van dit product.

Wijzigingshistorie

Versie	Datum	Wijziging / Actie
0.6	Augustus 2019	Eerste aanzet Risicoregister
0.7	September 2019	Diverse aanpassingen
0.8	November 0000	Xxxxxxxxxxxxxx naar aanleiding van regiobijeenkomsten
0.9	December 2019	Interne review verwerkt
1.0	Februari 2020	Externe review verwerkt
1.01	Juni 2020	Aan RAO voorbeeld een explain opgnomen bij acceptatie van het het Risico

Over de IBD

De IBD is een gezamenlijk initiatief van alle Nederlandse gemeenten. De IBD is de sectorale CERT / CSIRT voor alle Nederlandse gemeenten en richt zich op (incident)ondersteuning op het gebied van informatiebeveiliging. De IBD is voor gemeenten het schakelpunt met het Nationaal Cyber Security Centrum (NCSC). De IBD ondersteunt gemeenten bij hun inspanningen op het gebied van informatiebeveiliging en privacy / gegevensbescherming en geeft regelmatig kennisproducten uit. Daarnaast faciliteert de IBD kennisdeling tussen gemeenten onderling, met andere overheidslagen, met vitale sectoren en met leveranciers. Alle Nederlandse gemeenten kunnen gebruikmaken van de producten en de generieke dienstverlening van de IBD.

D
e IBD is ondergebracht bij VNG Realisatie.

Leeswijzer

Dit product is een nadere uitwerking voor gemeenten van de Baseline Informatiebeveiliging Overheid (BIO). De BIO is eind 2018 bestuurlijk vastgesteld als gezamenlijke norm voor informatiebeveiliging voor alle Nederlandse overheden.

Doel

Het doel van dit document is invulling geven aan het gestelde in paragraaf 4.2 van de BIO:
“De organisatie dient te beschikken over een registratie van overheidsmaatregelen waaraan niet of nog niet geheel kan worden voldaan. Dit zijn explains volgens het ‘comply or explain’ principe. Daarbij worden de daaruit voortvloeiende risico’s tevens aangegeven”.

Doelgroep

Dit document is van belang voor de CISO en het management van de gemeente.

Relatie met overige producten

• Baseline Informatiebeveiliging Overheid (BIO): aanpak

• Diepgaande risicoanalyse met MAPGOOD

• Handreiking Risicomanagement door lijnmanagers

• Factsheet Informatiebeveiliging voor lijnmanagers

Managementsamenvatting

Het inrichten van een risicomanagementproces heeft als doel het managen van risico’s. Dat moet ertoe leiden dat organisaties het overzicht niet verliezen op dreigingen die de dienstverlening kunnen verstoren of die een privacyrisico zijn voor inwoners. Enigszins verwarrend is dat er bij de inrichting van informatiebeveiliging volgens de Baseline Informatiebeveiliging Overheid (BIO) niet over risico’s of dreigingen wordt gerapporteerd, maar over ontbrekende overheidsmaatregelen. Vanuit compliancy is dat een uitstekende aanpak. Maar ‘ontbrekende overheidsmaatregelen’ zegt de gemiddelde manager niet zo veel in termen van risico’s. Want wat is de impact van een dreiging (het risico) als een overheidsmaatregel niet geïmplementeerd is?

Het voorliggende document geeft handvatten over hoe om te gaan met ontbrekende overheidsmaatregelen door ze te vertalen naar dreigingen en risico’s en daar actiehouders aan te koppelen. Samen vormt dat het risicoregister. Hierbij moet worden aangetekend dat dit register meteen ook gebruikt wordt als privacyrisicoregister. De aanpak is voor privacyrisico’s niet heel anders dan voor andere risico’s, met als groot onderscheid dat privacyrisico’s geaccepteerd zouden moeten worden door een inwoner. Aangezien dat geen werkbare aanpak is, maar de wet wel dwingend voorschrijft, is degene die het privacyrisico moet behandelen ook de proces- of systeemeigenaar (als vertegenwoordiger van de inwoner). Door met het register een administratie aan te leggen van alle risico’s die nog in behandeling zijn of die nog niet behandeld zijn, kan de organisatie effectief sturen op de risico’s die de bedrijfsresultaten of de impact op de inwoner negatief kunnen beïnvloeden. Dit register zorgt ervoor dat de organisatie kan prioriteren en dat er gerapporteerd kan worden aan het bestuur en de raad.

Risico’s worden opgenomen in het risicoregister door het invullen van een Risico Acceptatie Overeenkomst (RAO). Met deze overeenkomst wordt de verantwoordelijke manager op de hoogte gebracht van het betreffende risico, zodat er afspraken gemaakt kunnen worden over eventuele tijdelijke maatregelen, of en wanneer dat risico gemitigeerd gaat worden, of dat dit wellicht niet nodig is.

Voor de manager is van belang dat hij weet dat er onbehandelde risico’s zijn. Hij is degene die de RAO moet ondertekenen, waarmee de verantwoordelijkheid voor het risico is vastgelegd.

Door deze handelswijze te volgen wordt meteen ook voldaan aan de passage uit de BIO waarin staat dat de organisatie een register moet hebben van nog niet geïmplementeerde overheidsmaatregelen (paragraaf 4.2 uit de BIO):

“De organisatie dient te beschikken over een registratie van overheidsmaatregelen waaraan niet of nog niet geheel kan worden voldaan. Dit zijn explains volgens het ‘comply or explain’ principe. Daarbij worden de daaruit voortvloeiende risico’s tevens aangegeven”.

Inhoudsopgave

Management samenvatting 5

Inhoudsopgave 6

1. Inleiding 7

1.1 Risicoacceptatie 7

1.2 Werkwijze en leeswijzer 7

2. Het Risicoregister 8

2.1 Het belang van het register 8

2.2 Wat is risicomanagement en wat is een risico 8

2.3 Samenhang dreigingen en risico’s, context 8

2.4 ISO 27002 en de BIO 9

2.5 Hoe van maatregelen naar dreigingen 10

3. Vullen risicoregister 11

3.1 Xxxxxx’x komen van verschillende bronnen 11

3.2 Er zijn verschillende soorten risico’s 11

3.3 Risico kans en impact 11

3.4 Risico’s hebben gevolgen 11

3.5 Risico’s hebben verschillende oplossingsrichtingen (mitigatiestrategie) 11

3.6 Risico’s hebben een eigenaar 12

3.7 Risico’s moeten gemonitord worden 12

3.8 Het management moet weten dat er onbehandelde risico’s zijn 12

4. Inhoud risicoregister 13

4.1 Inleiding 13

4.2 Xxxxxxxx 00

5. Risico Acceptatie Overeenkomst (RAO) 14

5.1 Inleiding 14

5.2 De Risicoacceptatie overeenkomst opbouw 14

5.2.1 De Kop 14

5.2.2 Inleiding 14

5.2.3 Beschrijving Risico 14

5.2.4 Voorgestelde oplossingen 14

5.2.5 Advies 15

5.2.6 Overeenkomst ondertekening 15

Bijlage 1 Risico Acceptatie Overeenkomst gemeente X 16

Bijlage 2 Geraadpleegde literatuur 18

1.Inleiding

Nu we van de BIG overgaan naar de BIO ontstaat er een verandering naar de risicogedreven aanpak die bij de BIO past. Tegelijkertijd wordt er, bijvoorbeeld om compliant te zijn aan de BIO in het kader van de verantwoording via ENSIA, vaak gesproken over overheidsmaatregelen. Maar maatregelen op zich zeggen niets over risico’s. En juist risico’s zijn van betekenis voor de bedrijfsvoering. Met andere woorden: het is beter om te rapporteren over risico’s, dan te rapporteren over ontbrekende maatregelen.

Daarnaast ontstaan er ook los van de BIO allerlei risico’s die ergens moeten worden bijgehouden, zodat ze binnen een PDCA-cyclus gemanaged kunnen worden. Veelvoorkomende plekken waar risico’s ontstaan zijn: risicoanalyses, risicoafwegingen, incidenten als gevolg van niet onderkende risico’s, wijzigingen in de ICT-omgeving, aanschaf van nieuwe hard- en software, leveranciers, wetgeving en projecten. Daarnaast kennen we ook verschillende soorten risico’s, bijvoorbeeld privacyrisico’s.

Al die risico’s kunnen geregisteerd worden in een risicoregister. Risicoregisters worden al gebruikt in tal van disciplines; niet alleen binnen informatiebeveiliging, maar ook bijvoorbeeld binnen projectmanagement, Prince2, ITIL en het landelijke risicoregister gevaarlijke stoffen. Idealiter behoren alle risico’s geregisteerd te worden, ook degene die al gemitigeerd zijn. Maar dat is alleen zinvol als er met een ISMS of GRC-tool gewerkt wordt. De aanpak in dit document gaat uitsluitend over onbehandelde risico’s die vastgelegd kunnen worden in een spreadsheet, tenzij de organisatie al een ander hulpmiddel heeft voor het vastleggen van risico’s, bijvoorbeeld een GRC-tool of Naris.

1.1Risicoacceptatie

Als maatregelen niet meteen of helemaal niet geïmplementeerd worden, dan ontstaat er een risico dat voor kortere of langere tijd geaccepteerd moet worden door de bedrijfsvoering. Het is daarbij van belang dat de bedrijfsvoering dat risico kent en bewust accepteert. Want als het risico manifest wordt zal men willen weten wie het geaccepteerd heeft. Risicoacceptatie betekent dat men zich ervan bewust is dat er risico’s zijn waar (nog) geen maatregelen tegen genomen zijn.

1.2Werkwijze en leeswijzer

In het volgende hoofdstuk wordt het risicoregister nader toegelicht. In het daaropvolgende hoofdstuk wordt het proces om te komen tot een risicoregister nader toegelicht en aansluitend wordt de inhoud van het register uitgewerkt. Als laatste komt de Risico Acceptatie Overeenkomst aan bod als manier om het onbehandelde risico te delen met de bedrijfsvoering.

2.Het Risicoregister

2.1Het belang van het register

Het risicoregister is de centrale plaats waar risico’s worden bijgehouden en beheerd. Mogelijk is er al een risicoregister vanuit een andere discipline binnen de gemeente aanwezig. Bijvoorbeeld in het kader van RI&E (Arbo), de jaarrekening (Financiën), of projectmanagement. Het register geeft overzicht en ondersteunt het rapporteren over nog niet behandelde risico’s die een bedreiging kunnen vormen voor de bedrijfsvoering of de dienstverlening van de organisatie. Binnen de BIO (paragraaf 2.4) is bepaald dat alleen de risico's bijgehouden worden die horen bij maatregelen waar niet of nog niet geheel aan wordt voldaan. Door middel van het register kunnen risico’s op een centrale plaats beheerd en gemonitord worden. Ook kunnen via het register managementrapportages worden gemaakt en kan er geprioriteerd worden.

2.2Wat is risicomanagement en wat is een risico

Van risicomanagement en risico bestaan verschillende definities. De definitie die in het kader van dit document wordt gebruikt is:

“Risicomanagement is het geheel aan activiteiten en maatregelen gericht op het expliciet en systematisch omgaan met en het beheersen van risico’s. Een risico is een onzekere gebeurtenis met ongewenste gevolgen voor de organisatie.”

Verder geldt dat een risico door de IBD beschouwd wordt als een gekwantificeerde dreiging in de formule: risico = dreiging (kans x impact). Dreigingen worden ontleend aan de dreigingenlijst uit de diepgaande risicoanalyse-methode volgens de classificatie van MAPGOOD. Een dreiging in dit verband is ‘een kans op schade’.

Een risico verbindt de zwakheid, de dreiging, de waarschijnlijkheid (kans) en de impact: de optelsom is de impact voor de organisatie. Dit is meteen de reden waarom een risicoanalyse niet door anderen dan de proces- of systeemeigenaar uitgevoerd kan worden; immers zij ervaren het risico anders dan de proceseigenaar of de systeemeigenaar.

Risico’s kunnen netto en bruto zijn. Brutorisico’s bestaan uit risico’s waarvoor nog geen maatregelen genomen zijn of waar het effect van maatregelen nog niet in verwerkt is. Bij het analyseren van risico’s wordt altijd uitgegaan van het brutorisico. Het nettorisico is wat er overblijft nadat beheersmaatregelen genomen zijn. Dit type risico noemen we ook wel restrisico. Als het effect van het restrisico te hoog is kunnen aanvullende beheersmaatregelen nodig zijn om het restrisico verder te verlagen.

2.3Samenhang dreigingen en risico’s, context

In de ISO 27032 (security techniques – guidelines for cybersecurity) is een hele mooie uitwerking gemaakt van hoe in algemene zin dreigingen en risico’s samenhangen met maatregelen, proceseigenaar en kwetsbaarheden. Deze zijn ook in context geplaatst zodat meteen duidelijk is wat invloed uitoefent op elkaar. In dit kader is zeker belangrijk, en dat blijkt ook uit het schema, dat een dreiging en risico altijd betrekking hebben op een bedrijfsmiddel. Bedrijfsmiddelen kunnen zijn: hardware (servers, laptops, telefoons), mensen, processen, informatie, informatiesystemen, software, geld, data.

Uit het plaatje volgt:

• Risico hoort bij een bedrijfsmiddel of de inwoner.

• Dreigingen verhogen het risico.

• Kwetsbaarheden leiden tot risico’s.

• Proceseigenaar wil het risico reduceren of beheersen.

• Maatregelen reduceren het risico.

• Dreigingen verhogen het risico.

• Reductie van het risico vermindert de mogelijke schade.

Dat betekent dat een risico altijd betrekking moet hebben op een bedrijfsmiddel of in het geval van privacyrisico op een inwoner. In het geval van de inwoner is nog steeds de proceseigenaar verantwoordelijk voor het risico. Zonder die context kan het risico niet behandeld worden en leidt het ook nergens toe.

2.4ISO 27002 en de BIO

De Baseline Informatiebeveiliging Overheid is gebaseerd op de ISO 27002:2017 (ISO). De BIO en de ISO-norm en zijn op controlniveau exact gelijk aan elkaar. De ISO 27002 is gebaseerd op een best practice normenset om de meest voorkomende dreigingen te mitigeren met maatregelen. Hierbij geldt wel dat de ISO techniek- en organisatieonafhankelijk geschreven is. Waar in de ISO maatregeldoelstellingen staan, worden deze in de BIO controls genoemd. Maar ze zijn exact gelijk aan elkaar. Het grote verschil is dat de BIO een aantal verplichte maatregelen kent bij de meeste controls (maar niet bij allemaal, afhankelijk van het BBN). Hierbij geldt: hoe groter het te beschermen belang, des te kleiner de speelruimte.

2.5Hoe van maatregelen naar dreigingen

De ISO bevat zeer veel voorbeelden van maatregelen die genomen kunnen worden om een maatregeldoelstelling te halen. Maar wat ontbreekt zijn de risico’s en dreigingen. Met andere woorden: wat was de dreiging? Waarom doen we het? De MAPGOOD-lijst bevat 114 incidenten langs de componenten/bedrijfsmiddelen:

-Mens

-Apparatuur

-Programmatuur

-Gegevens

-Organisatie

-Omgeving

-Diensten

Al deze incidenten kunnen worden gerelateerd aan dreigingen die op hun beurt weer kunnen worden gerelateerd aan maatregeldoelstellingen.

Een voorbeeld:

Dreiging id1 (MAPGOOD): Mens valt voorzienbaar weg als gevolg van ziekte of ontslag.

Risicovraag: Hoe vaak komt dit voor en hoe erg is dit dan?

Zonder de juiste context is deze vraag niet te beantwoorden! Een medewerker in de buitendienst? De griffier? Een baliemedewerker van Burgerzaken?

3.Vullen risicoregister

3.1Risico’s komen van verschillende bronnen

Xxxxxx’x zijn gekwantificeerde dreigingen en kwetsbaarheden. Xxxxxx’x komen in beeld bij het uitvoeren van een risicoanalyse, het uitvoeren van PIA’s, maar ook als gevolg van incidenten, uitgevoerde pentesten, kwetsbaarhedenscans, risico-evaluaties, en ook vooral als gevolg van het niet geïmplementeerd hebben van maatregelen uit de BIO.

3.2Er zijn verschillende soorten risico’s

Risico’s worden vaak ingedeeld naar soort. Het soort risico geeft vaak aan in welk gebied het risico thuishoort. Zo kennen we informatiebeveiligingsrisico’s, privacyrisico’s, financiële risico’s, personele risico’s, gevaarlijke-stoffenrisico’s, strategische risico, operationele risico’s. Er zijn legio mogelijkheden voor soorten risico’s, maar meestal hangen ze samen met het ontstaansgebied of de plaats binnen de organisatie.

3.3Risico, kans en impact

Om het eenvoudig te houden classificeren we kans en impact op een schaal van Laag-Midden-Hoog. Zie voor verdere uitleg ons document over de diepgaande risicoanalyse vanaf hoofdstuk 3.1¹.

Uiteindelijk geeft de score kans*impact het effect weer van het risico. Deze score helpt om risico’s te prioriteren, maar ook om de mitigatiestrategie te bepalen (zie Oplossingsrichtingen).

3.4Risico’s hebben gevolgen

Risico’s hebben een oorzaak en een gevolg. Voor oorzaken maken we gebruik van de MAPGOOD-dreigingentabel uit de eerdergenoemde diepgaande risicoanalyse. Maar voor gevolg (de schade) bestaat er geen aparte tabel. Er kan wel gebruikgemaakt worden van de schadetabellen (en hun link naar BBN) uit de BIO. Zie ook de BIO op onze website², deel 2, bijlage 2 basisbeveiligingsniveau, schadetabellen.

Door het gevolg eruit te lichten en dat te beschrijven op een bedrijfsproces, informatiesysteem of afdeling gaat het risico leven voor managers!

3.5Risico’s hebben verschillende oplossingsrichtingen (mitigatiestrategie)

Als het effect van risico’s bekend is kunnen verschillende oplossingsrichtingen gekozen worden:

• Door het risico te accepteren. In dat geval wordt het risico niet of slechts beperkt van invloed verklaard op het informatiesysteem, of passen de mitigatiekosten niet bij het risico. Dit wordt vastgelegd in een Risico Acceptatie Overeenkomst (RAO).

• Door het risico te vermijden. Dat kan door het bedrijfsproces op een zodanige manier aan te passen dat de kans dat een geïdentificeerd risico zich voordoet afneemt.

• Door het risico te beheersen. In dit geval worden maatregelen genomen die de kans dat een bedreiging zich voordoet verminderen, of worden maatregelen genomen om de gevolgschade als het risico zich voordoet te beperken. Een voorbeeld van het verminderen van een risico is het plaatsen van een slot op de deur, wat de kans op onbevoegde toegang vermindert. Een voorbeeld van het beperken van gevolgschade is het plaatsen van een brandblusser in een opslagruimte.

• Door het risico over te dragen aan een andere partij. Dat kan bijvoorbeeld door een verzekering af te sluiten, die de gevolgschade van het optreden van een risico dekt. Overdracht van het risico is ook mogelijk door het uitbesteden van de taak of dienst aan een externe partij.

3.6Risico’s hebben een eigenaar

Net zoals informatie niet zonder eigenaar kan, kan een risico niet zonder eigenaar. Want als een risico geen eigenaar heeft, bestaat de kans dat het risico niet juist behandeld wordt. De BIO heeft daarin voorzien door de gemeentesecretaris of CIO als eindverantwoordelijke eigenaar aan te wijzen voor alles wat niet bij een andere eigenaar belegd is. Dus als niemand eigenaar van de informatie of het risico wil zijn, dan ligt het eigenaarschap bij de gemeentesecretaris of de CIO. Dit is afhankelijk van waar de verantwoordelijkheden voor de interne bedrijfsvoering belegd zijn. Als een risico meerdere eigenaren heeft omdat het meerdere systeem- of proceseigenaren raakt, dan is het verstandig om of het risico een niveau hoger te behandelen binnen de organisatie of om één penvoerder te benoemen onder alle eigenaren.

3.7Risico’s moeten gemonitord worden

Een doel van het risicoregister in het kader van de BIO-aanpak is het bijhouden van onbehandelde risico’s, zodat deze centraal gemonitord worden en zodat er een overzicht is waarbinnen prioriteiten kunnen worden aangegeven. In die zin wijkt deze aanpak af van de standaard, want normaal gesproken worden alle risico’s bijgehouden, ongeacht hun status. De BIO heeft in paragraaf 4.2 deze uitzondering nadrukkelijk beschreven omdat het belangrijk is om een administratie te voeren van onbehandelde risico’s: deze kunnen dan binnen een PCDA-cyclus gemanaged worden. Het risicoregister is een instrument dat onder beheer staat van de CISO. De CISO is weliswaar niet de eigenaar van de risico’s, dat moet altijd iemand uit de organisatie zijn, maar de CISO is wel de persoon die het centrale overzicht heeft en erover kan rapporteren, los van wat het management in de lijn rapporteert.

3.8Het management moet weten dat er onbehandelde risico’s zijn

Als een risico wordt opgenomen in het register, dan zal van een dergelijk risico ook een Risico Acceptatie Overeenkomst (RAO) afgesloten zijn met de proceseigenaar of de systeemeigenaar³. Ook als er geen RAO afgesloten is, moet daarover gerapporteerd worden aan het bestuur of de directie (afhankelijk van hoe dat lokaal bepaald is). Want ook het niet hebben van een risico-eigenaar is een risico voor de organisatie. Daarnaast kan het bestuur of de directie de proces- of systeemeigenaar overrulen en besluiten dat het risico niet (tijdelijk) geaccepteerd mag worden.

Door in het risicoregister met kleuren te werken, zie je duidelijk of de effecten van een risico hoog of laag zijn. Het advies is om de rapportage en daarmee de management behandelfrequentie eenmaal per drie maanden te doen.

4.Inhoud risicoregister

4.1Inleiding

Het risicoregister kan een spreadsheet zijn of onderdeel van een ISMS of GRC-tooling. Er zijn veel voorbeelden van risicoregisters te vinden op internet. Veel disciplines kennen het gebruik van een centraal risicoregister om risico’s te kunnen beheersen en dat is waar het bij risicomanagement om gaat.

Voor de BIO gebruiken we een vereenvoudigd model; voldoende om onbehandelde risico’s te beheersen. Natuurlijk is het beter om alle risico’s te beheren, ook die waarvoor een oplossing bestaat, maar dat is niet wat de BIO vraagt. De BIO vraagt om het bijhouden van de uitzonderingen, de onbehandelde risico’s of die risico’s waar nog iets mee moet gebeuren.

4.2Kolommen

Uniek nummer	Een uniek volgnummer
Datum	Datum van invullen
Dreiging/kwetsbaarheid	Welke dreiging of kwetsbaarheid hoort bij het risico
Bron	Waar komt het risico vandaan? (BIG/BIO/incident/privacy impact/datalek/RD melding/externe audit/interne controle/FG/CISO)
Kans	Hoe vaak komt het voor (L/M/H)4
Impact	Hoe erg is het dan (L/M/H) 5
Risico classificatie	(Kans * impact) bijvoorbeeld MM, MH, HH < geeft de prioriteit aan6
Soort risico	Privacy/ financieel/ informatiebeveiliging/ compliance/ imago
Risico omschrijving	Omschrijving van het risico
Schade	De werkelijke geschatte schade als het risico optreedt
Weerstandsvermogen	Invloed op weerstandsvermogen? (dit betekent negatieve financiële impact)
Control	Link met de BIO
Privacy control	Link met AVG
Risico eigenaar	Van wie is het risico?
Planning	Hoe lang/tot wanneer wordt het geaccepteerd?
Soort oplossing/beheersmaatregel	Oplossingen kunnen zijn: beleid/procedureel/hardware/software/bewustwording/niets doen/uitbesteden/verzekeren/overdragen/maatregelen nemen
Kosten oplossing	Wat kost de oplossing?
Datum review	Wanneer kijken we er weer naar
Geaccepteerd Risico Overeenkomst datum	Wanneer is er een overeenkomst gemaakt met risico-eigenaar?

5.Risico Acceptatie Overeenkomst (RAO)

5.1Inleiding

De risicoacceptatie is een manier om bewust risico te accepteren en dat vast te leggen in een overeenkomst. Zo weet de risico-eigenaar dat er een risico geaccepteerd is en weet de organisatie dat er ergens een risico is dat mogelijk ooit of nooit behandeld gaat worden. Vooral dat laatste is van belang: het totaal van alle geaccepteerde risico’s mag nooit de risk appetite van de organisatie overstijgen. Maar de organisatie moet in het kader van risicomanagement ook de risico’s beheersen en beheren. Ook dat wordt onder andere gedaan met een Risico Acceptatie Overeenkomst (RAO).

Idealiter staan alle risico’s in een risicoregister - zie de hoofdstukken hiervoor - en is er voor ieder risico een mitigatiestrategie bedacht. Mitigatiestrategieën zijn:

• Vermijden

• Reduceren

• Overdragen

• Accepteren

Hierbij geldt de hierboven aangehouden volgorde. Dus eerst proberen te vermijden, daarna proberen te reduceren, als dat ook niet lukt dan overdragen en als laatste het risico accepteren.

5.2De Risico Acceptatie Overeenkomst opbouw

De Risico Acceptatie Overeenkomst bevat een kop die opgebouwd is uit een aantal regels uit het risicoregister en een aantal tekstblokken waarbinnen vrije tekst opgenomen is. Juist op die vrije tekst komt het aan!

1. De Kop

Aan	<verantwoordelijke voor systeem/eigenaar>/ Risico eigenaar
Xxx	Xxxx, Security Officer/CISO
Afdeling	Van CISO
CC	Gemeentesecretaris / CIO
Datum	Datum van opstellen
Onderwerp	Risico Acceptatie Overeenkomst: procesnaam/risiconaam
Applicatie	Betrokken applicaties
Classificatie	Is er een classificatie?
Privacy gerelateerd?	Is het ook privacy?
BIO control	Welke BIO-controls zijn betrokken
Geldig tot	Einddatum van de overeenkomst
Volgnummer	Volgnummer uit risicoregister

2. Inleiding

In de inleiding nemen we een tekstblok op over de plaats van het risico binnen de organisatie en het doel van de RAO.

3. Beschrijving Risico

Nu komt het aan op de skills van de invuller! Hier moet in heldere taal het risico beschreven worden zodat iedere manager het begrijpt: wat is de impact, waar is de impact, waardoor is het ontstaan, waarom moeten we er iets mee doen.

4. Voorgestelde oplossingen

Geen probleem zonder oplossing. In dit tekstblok moet een aantal oplossingen beschreven worden. Let op: niets doen is ook een mogelijke oplossing! Hier wordt ook beschreven wat het effect is van de strategie/oplossing, in die zin dat het overblijvende (rest)risico beschreven wordt. Noteer bij iedere oplossing ook de kosten van de oplossing.

5. Advies

Geen keuze zonder professioneel advies. In dit tekstblok doet de CISO een voorstel uit de eerder opgesomde oplossingsmogelijkheden. Noteer weer de kosten, maar ook de baten!

6. Overeenkomst ondertekening

In dit tekstblok wordt de optie geboden om iets te doen of niets te doen. In ieder geval staan bij het iets de oplossing en een einddatum (belangrijk voor het register).

Bijlage 1 Risico Acceptatie Overeenkomst gemeente X

Aan

Van

Afdeling

CC

Datum

Onderwerp

Applicatie

Classificatie

Privacy gerelateerd?

BIO control

Geldig tot

Volgnummer

Inleiding

Huidige wetgeving en het gemeentelijk beleid vereisen het treffen van passende maatregelen ter bescherming van informatie en systemen die onder verantwoordelijkheid van <verantwoordelijke voor systeem/eigenaar> vallen. Binnen dit systeem/werkwijze/proces is een risico aanwezig als gevolg van: <risicobeschrijving>.

Dit risico is in de volgende paragraaf verder uitgeschreven en vanuit risicomanagement wordt een advies gegeven hoe met het onderkende risico moet worden omgegaan. Zowel de proceseigenaar als het MT van de verantwoordelijke afdeling wordt gevraagd het voorgestelde besluit te nemen.

Deze Risico Acceptatie Overeenkomst (RAO) is geldig tot de afgesproken datum en wordt in het risicoregister opgenomen. Hierna moet deze opnieuw geëvalueerd worden. In het geval van een significante wijziging in de risico's zal deze evaluatie eerder plaatsvinden.

Beschrijving Risico

De afdeling / het systeem / het proces / persoon heeft een risico als gevolg van een risicoclassificatie op een dreiging x. Dit risico is ontstaan als gevolg van het niet implementeren van een BIO-maatregel/een incident/een risicoanalyse/etc. Dit risico zorgt ervoor dat er een kans bestaat op <>. De gevolgen van het manifest worden van het risico zijn <>. In het uiterste geval kan dit ervoor zorgen dat <>. De schade kan in dit geval kan oplopen tot <>. <Het is een meldplichtig datalek.> <Betrokkenen moeten worden geïnformeerd.>

Voorgestelde oplossingen

Het onderkende risico kan het beste opgelost worden door het nemen van een maatregel <> / maatregelen <><>. Deze maatregelen zorgen voor <> waarmee de kans / impact wordt verkleind tot een acceptabel risico (voor het proces/systeem/betrokkene).

Advies

Vanuit security management wordt geadviseerd het risico op <termijn> te behandelen omdat het niet uit te leggen is dat <risico> optreedt. De schade voor de gemeente/betrokkene is <>. Zolang het risico niet behandeld is wordt geadviseerd tijdelijke maatregelen te overwegen <>. De kosten voor het nemen van de oplossing worden geschat op <geld>, <tijd> en hiervoor is de gemeente afhankelijk van <>. Het probleem strekt zich uit buiten/binnen de gemeente/in de keten x. Als de kosten niet gemaakt worden dan bestaat de kans op een schade ter hoogte van <>/ bestaat de kans op reputatieschade.

Hiermee verklaren de ondergetekenden

• Kennis te hebben genomen van het advies en de voorgestelde oplossingen.

• Het risico wordt (doorhalen wat niet van toepassing is):

  • geaccepteerd en er worden verder geen maatregelen genomen;

  • gemitigeerd op de kortst mogelijke termijn;

  • tijdelijk opgelost totdat de voorgestelde maatregelen geïmplementeerd kunnen worden.

Motivatie bij acceptatie van het risico

Er worden geen maatregelen genomen om het risico te mitigeren, omdat <invullen>.

Systeemeigenaar/proceseigenaar	Afdelingsmanager/directeur
Naam:	Naam:
Functie:	Functie:
Datum:	Datum:
Handtekening	Handtekening

Bijlage 2 Geraadpleegde literatuur

• Handreiking risicomanagement door Lijnmanagers, IBD

• Diepgaande risicoanalysemethode met MAPGOOD, IBD

• BIR explain procedure voor ICCIO (EAR-online), 0000

• Xxxxxxxx, Risicomanagement, 2019

• VO-Raad, Handboek Risicomanagement, 2013

• NEN, ISO 27005, 2018

Xxxxxxxxxx 00

0000 XX Xxx Xxxx

CERT: 070 204 55 11 (9:00 – 17:00 ma – vr)

CERT 24x7: Piketnummer (instructies via voicemail)

xxxx@XXXXxxxxxxxx.xx / xxxxxxxx@XXXXxxxxxxxx.xx

Kijk voor meer informatie op:

xxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxx.xx

1 xxxxx://xxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxx.xx/xxxxxxx/xxxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxxxxx-xxxxxxx-xxxxxxxxx/

2 xxxxx://xxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxx.xx/xxxxxxx/xxxxxxxx-xxxxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxx/

3 Als er geen eigenaar van het risico aan te wijzen valt, is uiteindelijk de gemeentesecretaris of de CIO verantwoordelijk voor de behandeling of de acceptatie van het risico.

4 5 In plaats van met L M H kan ook gewerkt worden met 1,2 of 3 of eender welke getallenreeks.

5

6 Als met getallen gewerkt wordt komt hier dus de vermenigvuldiging van de twee voorgaande waarden.