De tijd nadert snel dat bijna alle vergunninghoudende financiële organisaties zullen moeten voldoen aan de Digital Operational Resilience Act (DORA). DORA is de eerste Europese verordening die concrete eisen stelt op het gebied van ICT. Als verordening heeft DORA rechtstreekse werking in elke lidstaat, zonder dat omzetting in nationale wetgeving nodig is. We krijgen steeds meer vragen van onze klanten over DORA:
In onze vorige artikelen hebben we naast de tijdlijn ook de vereisten van DORA uiteengezet. In een volgende reeks diepgaande artikelen zullen we DORA op onderwerpniveau toelichten, waardoor het duidelijker wordt wat er nodig is om te voldoen aan DORA en natuurlijk om ICT-risico's te beheren zodat uw organisatie voldoende 'digitaal operationeel weerbaar' is.
In dit artikel kijken we specifiek naar de vereisten in de artikelen 5 tot en met 15, oftewel 'Hoofdstuk II: ICT Risk Management'. Tijd om te verkennen!
In DORA staat het beheren van risico's en bedreigingen voor de digitale operationele veerkracht centraal. Het is dan ook geen verrassing dat DORA begint met een aantal eisen met betrekking tot ICT risk management.
De essentie van hoofdstuk II is dat het beheer van ICT risk aantoonbaar georganiseerd en vastgelegd moet zijn. De wetgever begint daarom met het verplichte interne governance- en controlekader (art. 5 lid 1). Wat dit precies is of zou moeten zijn, wordt niet nader gespecificeerd in DORA. In onze ervaring is het governancekader een gedocumenteerde of geformaliseerde beschrijving van verantwoordelijkheden en activiteiten, inclusief het toezicht op de implementatie. Eenvoudig gezegd, wie is uiteindelijk verantwoordelijk voor het beheer van ICT risk ? Wie doet welk werk en wie controleert de kwaliteit van het werk?
Een belangrijke bouwsteen voor goed ICT risico management is het hebben van een "control framework dat zorgt voor effectief en prudent management van ICT risico's". Met andere woorden, een controlekader dat laat zien welke risico's de organisatie loopt, welk niveau van risico aanvaardbaar is, welke risicobeperkende maatregelen er zijn en hoe de effectiviteit van de maatregelen wordt bepaald.
Een belangrijke bouwsteen voor goed ICT risicobeheer is een 'controleraamwerk dat zorgt voor effectief en voorzichtig beheer van ICT risico's'.
Gelukkig biedt DORA veel richtlijnen voor het opzetten van de verschillende kaders. Organisaties kunnen deze vereisten bijvoorbeeld opnemen in een governancedocument (dat misschien al bestaat). Als dit nog niet bestaat, kan ook een specifiek IT-governancebeleid worden opgesteld. Uiteindelijk is het minder belangrijk in welk document de kaders zijn vastgelegd, zolang ze maar geformaliseerd zijn, goedgekeurd zijn door een bestuur of directie en bekend zijn in de hele organisatie.
Voor het governance kader geeft DORA in artikel 5, lid 2, al enige richtlijnen, die misschien zo voor de hand liggend zijn dat ze over het hoofd worden gezien. Bijvoorbeeld dat de eindverantwoordelijkheid voor het beheer van ICT risk bij het bestuur ligt. Dit zal vaak de raad van bestuur of het senior management zijn. In hetzelfde artikel worden verschillende andere zaken genoemd waarvoor het bestuursorgaan verantwoordelijk is (artikel 5, lid 2, onder a) tot en met i)), namelijk het vaststellen en uitvoeren van beleid, het beschrijven van ICT-rollen en -verantwoordelijkheden, het bepalen van de strategie voor digitale bedrijfsweerbaarheid en het goedkeuren van auditplannen. Al deze elementen moeten dus duidelijk worden gedefinieerd, bijvoorbeeld in een governancedocument of AO/IC-beschrijving. Dit lijkt voor de hand liggend, maar het is belangrijk dat het gebeurt. Een duidelijke beschrijving van rollen en verantwoordelijkheden is immers van fundamenteel belang voor het opzetten en onderhouden van adequaat risk beheer.
Aangezien het beheersorgaan al deze taken en verantwoordelijkheden heeft, is het logisch dat het over voldoende kennis en vaardigheden op het gebied van ICT-risico's beschikt. Regelmatige deelname aan specifieke training (in overeenstemming met de risk die moet worden beheerd) is daarom een vereiste in artikel 5, lid 4. 5(4). Dit betekent echter niet dat van directeuren gedetailleerde technische kennis wordt verwacht.
Naar onze mening is het niet realistisch voor een bestuurder om in technisch detail te weten hoe bijvoorbeeld een ransomware-aanval werkt. Het is echter belangrijk voor bestuur en directeuren om precies te weten wat een ransomware-aanval is, hoe een aanval kan plaatsvinden, welke factoren een rol spelen, wat de mogelijke gevolgen zijn en welke risicobeperkende maatregelen er zijn om de waarschijnlijkheid te verminderen en de impact te beperken. Dit is namelijk de enige manier waarop een directeur adequate begeleiding kan bieden en de risico's kan beheersen.
Nadat in artikel 5 wordt uiteengezet hoe en door wie het ICT risk beheersproces moet worden beheerd, gaat DORA verder met het ICT risk beheerskader zelf. Art. 6 kan worden gezien als het basisontwerp van het ICT Risk Management proces. Dit artikel beschrijft hoe het proces moet worden ingebed in de organisatie en waaruit het kader moet bestaan. Volgens lid 2 van Art. 6 moet het ICT risk beheerskader ten minste bestaan uit strategieën, beleid, procedures en ICT-protocollen en ICT risk beschermingsinstrumenten (nader beschreven in artikel 7).
Het doel van het ICT risk management framework is om de impact van ICT risico's te minimaliseren.
Het doel van het ICT risico management framework (en dus van de onderliggende elementen uit de vorige opsomming) is om de impact van ICT-risico's te minimaliseren. Ergens zal het dus nodig zijn om te identificeren en vast te leggen wat een aanvaardbaar minimum is voor de organisatie. In risico managementterminologie wordt dit 'risico tolerantie' genoemd. De combinatie van het ICT risico managementraamwerk en actuele informatie over ICT-risico's kan worden vereist door de toezichthouder. In dit case verwachten we dat de toezichthouder zal vragen om documenten met betrekking tot het opzetten van ICT risico management, bijvoorbeeld een ICT risico charter, maar vooral een actuele risico analyse.
Binnen het ICT risico managementraamwerk is de 'business', of eerste lijn, verantwoordelijk voor ICT-risico's en het leveren van de actuele status ervan. De tweede lijn, de controlefunctie, is echter vaak verantwoordelijk voor het beheren en bewaken van ICT-risico's. Dit is om mogelijke belangenconflicten tussen een business en een controlefunctie te voorkomen. Dit is om potentiële belangenconflicten tussen een business en een controlefunctie te vermijden. Dit is precies wat Art. 6(4) wil terugzien binnen een organisatie: hoe wordt een passende scheiding en onafhankelijkheid van de ICT risico managementfuncties, controlefuncties en interne auditfuncties tot stand gebracht? Er wordt verwezen naar het 'three lines of defence'-model, nu ook bekend als het 'drie-lijnen-model'.
Zodra een organisatie een ICT risk management framework heeft opgesteld, moet het ook jaarlijks worden geëvalueerd. Artikel 6(5) vereist ook dat er een beoordeling wordt uitgevoerd na
Merk op dat een verslag van deze evaluatie ook deel uitmaakt van de informatie die de toezichthouder kan opvragen!
Zoals beschreven in de vorige paragraaf, kunnen de conclusies van auditverslagen gebieden aanwijzen die voor verbetering vatbaar zijn in het ICT risk management framework. Daarom moet er een formeel follow-up proces worden ingesteld (paragraaf 7). De periodiciteit van interne audits (paragraaf 6) is niet voorgeschreven, behalve dat ze regelmatig en in overeenstemming met het auditplan moeten zijn.
Art. In artikel 8, lid 6, wordt beschreven dat het ICT risk management framework een strategie moet omvatten die het volgende toelicht
De daaropvolgende subparagrafen (a) tot (h) geven natuurlijk meer uitleg. De strategie moet bijvoorbeeld beschrijven:
Om aan dit artikel te voldoen, moet deze digitale operationele veerkrachtstrategie worden ontwikkeld als onderdeel van het ICT risk managementraamwerk. Voor onze klanten vatten we de verplichte elementen van artikel 5 en 6 samen in een document dat we het ICT Risk Charter noemen. Hierin geven we ook paragraaf 9 van artikel 6 over de ICT-multivendorstrategie weer, waarin belangrijke afhankelijkheden van externe ICT-dienstverleners worden behandeld.
Hoofdstuk II van DORA gaat verder met verschillende randvoorwaarden voor een effectief ontworpen ICT risico management raamwerk. Deze randvoorwaarden worden in een later artikel uitgebreider besproken. Wil je er zeker van zijn dat je nooit een artikel van ons mist? Volg ons dan op LinkedIn!
Heb je vragen over DORA of heb je hulp nodig bij de voorbereiding op de inwerkingtreding? Onze consultants helpen u graag. Aarzel niet om contact met ons op te nemen.
