DORA Explored: ICT Risk Management in detail

In onze voorgaande artikelen hebben we naast de tijdlijn, ook op hoofdlijnen de vereisten van DORA toegelicht. In een volgende serie van verdiepende artikelen zullen wij DORA op onderwerpniveau toelichten, zodat duidelijker wordt wat nodig is om compliant te zijn met DORA en uiteraard de ICT risico’s te beheersen, zodat uw organisatie voldoende ‘digitaal operationeel weerbaar’ is.

In dit artikel zoomen we specifiek in op de vereisten uit art. 5 tot en met 15, oftewel ‘Hoofdstuk II: ICT Risk Management’. Time to explore!

Organisatie & Governance

DORA heet officieel Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector and amending Regulations (EC) No 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No 909/2014 and (EU) 2016/1011.

Het managen van risico’s en bedreigingen op de digitale operationele weerbaarheid staat centraal. Het is dan ook niet verwonderlijk dat DORA start met diverse vereisten rondom ICT Risk Management.

De essentie van Hoofdstuk II is dat ICT Risk Management aantoonbaar georganiseerd en ingericht moet zijn. De wetgever start dan ook met het verplichte interne governance- en controlekader (art. 5 lid 1). Wat dat precies is of moet zijn, is niet verder uitgewerkt in DORA. Op basis van onze ervaring is het governance-kader een gedocumenteerd dan wel geformaliseerde beschrijving van de verantwoordelijkheden en werkzaamheden inclusief de controle op de uitvoering. Simpel gezegd: Wie is eindverantwoordelijk voor ICT-risicomanagement? Wie voert welke werkzaamheden uit en wie controleert de kwaliteit van de werkzaamheden?

Controlekader

Een belangrijke bouwsteen voor een goed ICT-Risicobeheer is het hebben van een ‘controlekader dat een doeltreffend en prudent beheer van het ICT-risico waarborgt’. Met andere woorden: een controlekader waaruit blijkt welke risico’s de organisatie loopt, welk niveau van risico nog geaccepteerd kan worden, wat mitigerende maatregelen zijn en hoe de effectiviteit van de maatregelen vastgesteld wordt.

DORA biedt gelukkig veel handvatten wat betreft de inrichting van de diverse kaders. Organisaties zouden deze vereisten bijvoorbeeld kunnen verwerken in een (wellicht al aanwezig) governance document. Mocht deze er nog niet zijn, dan kan ook een specifieke IT Governance policy opgesteld worden. Uiteindelijk is het minder van belang in welk document de kaders zijn uitgewerkt, zo lang ze maar geformaliseerd zijn en goedgekeurd door een bestuur of directie en bij de gehele organisatie bekend zijn. 

Governancekader

Voor het governancekader geeft DORA in art. 5 lid 2 al enkele handvatten die wellicht zo vanzelfsprekend zijn dat ze wel eens over het hoofd gezien kunnen worden. Bijvoorbeeld dat de eindverantwoordelijkheid voor het beheer van ICT-risico bij het leidinggevend orgaan ligt. Dit zal veelal het bestuur of de directie van de onderneming zijn. In hetzelfde artikel worden diverse andere zaken aangehaald waarvoor het leidinggevende orgaan verantwoordelijk is (art. 5 lid 2 sub a tot en met i), namelijk het vaststellen en invoering van beleid, beschrijving van ICT taken en verantwoordelijkheden, vaststelling van de strategie met betrekking tot de digitale operationele weerbaarheid tot aan het goedkeuren van de auditplannen. Al deze elementen zullen dus duidelijk vastgelegd moeten zijn, bijvoorbeeld in een governance document, of AO/IC beschrijving. Hoewel dit vanzelfsprekend is, is het wel belangrijk dat dit gebeurt. Voor het opzetten en inrichten van adequaat risicomanagement is een duidelijke uiteenzetting van taken en verantwoordelijkheden immers elementair.

Opleidingsvereiste

Aangezien het leidinggevende orgaan al deze taken en verantwoordelijkheden heeft, is het logisch dat zij over voldoende kennis en vaardigheden moet beschikken op het vlak van ICT-risico’s. Het regelmatig volgen van specifieke opleidingen (in verhouding tot het te beheren risico) wordt dan ook als eis gesteld in art. 5 lid 4.. Dit betekent niet dat van bestuurders technische kennis tot in het kleinste detail wordt verwacht.

In onze ogen is het onrealistisch dat een bestuurder bijvoorbeeld tot in de technische details weet hoe een ransomware-aanval in zijn werk gaat. Wel is het voor directieleden en bestuurders belangrijk om te weten wat een ransomware-aanval is precies is, hoe een aanval plaats kan vinden, welke factoren van invloed zijn, wat mogelijke gevolgen zijn en welke mitigerende maatregelen bestaan om de kans te verminderen en de impact te verkleinen. Alleen op deze manier kan een bestuurder namelijk ook adequaat aansturing geven en de risico’s beheersen.

ICT Risk Management Framework

Nadat art. 5 uiteen heeft gezet hoe en door wie het proces van ICT-risicobeheer gemanaged moet worden, gaat DORA door met het ICT-risicobeheer kader zelf. Art. 6 kan gezien worden als de basisinrichting voor het ICT Risk Management proces. Dit artikel beschrijft hoe het proces ingebed moet zijn in de organisatie en waar het kader uit moet bestaan. Het ICT-risicobeheer kader bestaat volgens lid 2 van artikel 6 tenminste uit:

• Strategieën;
• Beleidslijnen;
• Procedures;
• ICT-protocollen en instrumenten ter bescherming van de ICT-risico’s (nader uitgewerkt in art. 7).

Het doel van het ICT-risicobeheerkader (en dus ook voor de onderliggende elementen uit de voorgaande opsomming) is het beperken van de impact van ICT-risico’s tot een minimum. Er zal dus ergens bepaald en vastgelegd moeten worden wat een acceptabel minimum is voor de organisatie. In Risk Management terminologie spreken we dan over een ‘risk tolerance’. De vastlegging van de combinatie van het kader van ICT-Risicobeheer en actuele informatie over de ICT-risico’s kan opgevraagd worden door de toezichthouder. Wij verwachten dat de toezichthouder in dat geval zal vragen om stukken met betrekking tot de inrichting van ICT Risk Management, bijvoorbeeld een ICT Risk Charter, maar ook voornamelijk een actuele risicoanalyse.

Three lines model

Binnen het ICT Risk Management Framework is de ‘business’, oftewel de eerste lijn, verantwoordelijk voor de ICT risico’s en het geven van een actuele stand van zaken hierover. Maar,de tweede lijn, de controlefunctie, is vaak verantwoordelijk voor het beheer en toezicht op de ICT-risico’s. Dit ter voorkoming van mogelijke belangenconflicten tussen een uitvoerende en controlerende functie. Dit is dan ook precies wat art. 6 lid 4 terug wil zien binnen een organisatie: hoe is een passende scheiding- en onafhankelijkheid van de ICT-risicobeheerfuncties, controlefuncties en interne auditfuncties, ingericht? Er wordt verwezen naar het ‘3-lines of defense model’ tegenwoordig ook bekend als het ‘three lines model’.

Als een organisatie eenmaal een kader voor ICT-Risicobeheer heeft opgezet, dan moet dit ook jaarlijks geëvalueerd worden. Art. 6 lid 5 stelt ook de eis dat een evaluatie moet plaatsvinden na:

• het voordoen van ernstige ICT-gerelateerde incidenten;
• toezichtsinstructies; of
• conclusies die voortvloeien uit relevante test of auditrapporten.

Let op, ook een vastlegging van deze evaluatie behoort tot de informatie waar de toezichthouder om kan verzoeken!

Zoals in vorige paragraaf beschreven staat, kunnen de conclusies van auditrapporten zorgen voor verbeterpunten in het ICT-risicobeheerkader. Hier moet dan ook een formeel follow-up proces voor ingericht zijn (lid 7). De periodiciteit van de interne audits (lid 6) is niet voorgeschreven, anders dan dat er regelmaat moet in zitten en het in overeenstemming is met het auditplan.

De strategie voor digitale operationele weerbaarheid

Art. 8 lid 6 beschrijft dat het kader voor ICT-risicobeheer een strategie moet bevatten die uitlegt:

• hoe uitvoering gegeven wordt aan het ICT-risicobeheerkader; en
• welke methoden en doelstellingen gebruikt worden om de ICT-risico’s aan te pakken.

Uiteraard wordt hier in de daaropvolgende sub a tot en met h meer duiding aan gegeven. Zo moet in de strategie beschreven staan:

1. Hoe het kader voor ICT-risicobeheer de bedrijfsstrategie en -doelstellingen ondersteunt;
2. Dat er een risicotolerantieniveau (risk tolerance) wordt vastgesteld die past bij de risicobereidheid (risk appetite) van de organisatie;
3. Duidelijke doelstellingen met betrekking tot informatiebeveiliging, inclusief key performance indicators en key risk metrics;
4. Een toelichting op de ICT-referentiearchitectuur en eventuele noodzakelijke wijzigingen om specifieke bedrijfsdoelstellingen te bereiken (nadere uitwerking in art. 8);
5. Mechanismen om ICT gerelateerde incidenten te detecteren, de impact te mitigeren en te voorzien in de bescherming (nadere uitwerking in art. 9 en 10);
6. Een uiteenzetting van de huidige situatie op het gebied van digitale operationele weerbaarheid op basis van het aantal gemelde ernstige ICT-gerelateerde incidenten en doeltreffendheid van preventieve maatregelen;
7. Het verrichten van testen van de digitale operationele weerbaarheid zoals beschreven in hoofdstuk IV van DORA;
8. Een communicatiestrategie bij ICT-gerelateerde incidenten als deze volgens art. 14 openbaar gemaakt moeten worden (nadere uitwerking in artikel 14).

Om compliant te zijn met dit artikel, zou deze digital operational resilience strategy ontwikkeld moeten worden als onderdeel van het ICT Risk Management Framework. Voor onze klanten vatten we de verplichte elementen uit art. 5 en 6 samen in een document dat wij het ICT Risk Charter noemen. Hier laten we dan ook lid 9 van art. 6 met betrekking tot de ICT multi-vendor Strategy in terugkomen, waarbij belangrijke afhankelijkheden met derde aanbieders van ICT-diensten aandacht krijgen.

Randvoorwaarden

DORA gaat in Hoofdstuk II verder met diverse randvoorwaarden die je ook in vraagvorm zou kunnen zetten. De antwoorden vormen dan de basis voor een effectief ingericht ICT Risk Management Framework.

Deze vragen en onderwerpen hebben een duidelijke overlap met het NIST Cybersecurity Framework uit 2018 (zie figuur hieronder). Het zijn vragen die iedere organisatie zal hebben.

In deze versie van het NIST Cybersecurity Framework uit 2018 (een update is momenteel in ontwikkeling) ontbreekt Scholing en Ontwikkeling. De Engelstalige variant van DORA noemt dit artikel 13, Learning & Evolving. Dit heeft in onze optiek net een andere betekenis, maar maakt wel duidelijk dat dit de feedback loop betreft om ‘continuous improvement’ in te richten voor het ICT Risicobeheer kader.

DORA stelt voor elk van deze fasen diverse eisen rondom de inrichting en inhoud. Deze lichten we in een volgend artikel verder toe.

Meer weten?

U heeft nog 20 maanden te gaan tot u DORA compliant moet zijn. Heeft u vragen over DORA, of hulp nodig bij uw voorbereiding? Onze consultants helpen u graag.

Wilt u meer weten over de eisen die DORA stelt aan financiële instellingen? Onze DORA Awareness e-learning maakt u wegwijs in deze nieuwe wet. De e-learning gaat in op onder andere ICT-risicobeheer, de omgang met ICT-incidenten, het testen van digitale operationele weerbaarheid en het beheer ICT-risico derde aanbieders.