DORA Explored II: ICT Risk Management framework

ICT Risk Management framework

Hoofdstuk II van DORA bevat diverse randvoorwaarden die de basis leggen voor een effectief ingericht ICT Risk Management Framework. Deze randvoorwaarden hebben een duidelijke overlap met het NIST Cybersecurity Framework uit 2018 (zie onderstaande figuur).

In deze versie van het NIST Cybersecurity Framework ontbreekt Scholing en Ontwikkeling. De Engelstalige variant van DORA noemt dit art. 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. Hieronder gaan we in op ieder van deze fasen.

Identification

Art. 8 gaat zowel om het identificeren van de ICT risico’s als om het in kaart brengen van de processen en infrastructuur die bedreigd kunnen worden. Voor een goede risicoanalyse is het belangrijk om te weten wat bedreigd wordt en hoe deze bedreiging zich kan manifesteren en met welke impact en wie (lees: derde partijen) hierbij betrokken zijn. In de tabel hieronder zijn de diverse vereisten uiteengezet.

Protection & Prevention

Na de identificatie fase wil je als organisatie zoveel mogelijk voorkomen dat een risico zich manifesteert. Art. 9 van DORA beschrijft dan ook welke preventieve maatregelen genomen moeten worden. Deze zullen logischerwijs volgen uit de uitgevoerde risicoanalyse waarbij de implementatie aangepakt mag worden op een proportionele wijze naar de aard, omvang en complexiteit van de organisatie. Wij kunnen ons bijvoorbeeld voorstellen dat lang niet alle financiële entiteiten hun eigen software ontwikkelen, dus zal ‘Change Management’ in beperkte mate van toepassing zijn. Veelal wordt er geleund op het proces van de uitbestedingspartner, maar let op, iedere organisatie blijft verantwoordelijk voor een correcte uitvoering van changes. Het is daarom belangrijk om na te gaan welke controls of rapportages er zijn om aan te kunnen tonen dat de risico’s in dit proces beheerst worden

Voor het organiseren van deze maatregelen verwijst DORA naar het opzetten van een Informatiebeveiligingsbeleid.Hierin worden de algemene IT Beheersingsprocessen beschreven, waarbij de beschikbaarheid, authenticiteit, integriteit en vertrouwelijkheid van gegevens en ICT-activa centraal staan. Bijvoorbeeld bij (zie ook art. 9 lid 4):

• Identity Management;
• User Accountmanagement;
• Change Management;
• Patch Management.

Detectie

Het vroegtijdig opmerken van een afwijkende activiteit, bijvoorbeeld opvallende netwerkprestaties of ICT-incidenten, kan uiteindelijk de impact van een mogelijke cyberbedreiging beperken. Mede hierom stelt DORA in art. 10 dat een financiële entiteit meerdere detectiemechanismen geïmplementeerd moet hebben (lid 1) op meerdere controlelagen (lid 2). Uiteraard is het ook belangrijk om deze mechanismen regelmatig te testen. Dit is in art. 25 bepaald.

Bij detectie is het belangrijk om de ICT-inrichting te monitoren op mogelijke afwijkingen bij gebruikers, de ICT-infrastructuur, netwerkverkeer, etc. Idealiter worden er, in het geval van afwijkingen, automatisch waarschuwingen verstuurd naar bijvoorbeeld een Information Security Officer.

Response & Herstel

Voor een adequate inrichting van Response & Herstel verplicht DORA een continuïteitsbeleid te implementeren in art. 11. Zoals DORA bijna voor elk beleid en proces eist, moet ook dit periodiek/jaarlijks getest worden, onderhevig zijn aan een review van Internal Audit en rekening houden met eventuele doorwerking naar derde aanbieders.

Het continuïteitsbeleid bevat de uitgangspunten om de continuïteit van de organisatie en/of kritieke functies te verzekeren en op een passende wijze te reageren bij verstoringen. De uitwerking van deze maatregelen wil de wetgever terugzien in de diverse onderliggende plannen, zoals een bedrijfscontinuïteitsplan en response- & herstelplan.

Business Impact Analyse

Een essentieel onderdeel van het continuïteitsbeleid is de Business Impact Analyse die moet illustreren wat de exacte blootstelling van de organisatie is aan ernstige verstoringen van bedrijfsactiviteiten. Hierin moeten zowel kwalitatieve als kwantitatieve criteria opgenomen worden. Dit onderdeel moet niet licht opgevat worden, zeker omdat de toezichthouder zoals beschreven in art. 11 lid 10, op verzoek een inschatting van de jaarlijkse kosten door ICT-verstoringen kan opvragen.

Het hebben van een back-up mogelijkheid en een adequaat ‘back-up & restore’ beleid zorgt voor een minimale uitval en verstoring van (kritische) bedrijfsfuncties en een minimaal verlies van data. Dit is dus een belangrijk proces dat goed op orde moet zijn als je wilt dat ‘response en herstel’ goed functioneert.

Het bepalen van de ‘Recovery Time Objective/RTO’ en de ‘Recovery Point Objective/RPO’ sluit aan bij de eisen vanuit de business voor de (kritische) ICT-toepassingen en -processen. Art. 13 stelt dat er een back-up beleid ontwikkeld moet worden met onderliggende procedures waarin staat op welke gegevens de minimale frequentie van de back-up wordt toegepast. Dit back-up beleid moet aansluiten op de RPO. Ook moet erin staan wat de terugzettings-/herstelprocedures zijn, zodat de RTO gehaald kan worden. Een aandachtspunt hierin, is dat de back-ups beschermd moeten zijn tegen ongeoorloofde toegang.

Voor de communicatie tijdens een verstoring richting werknemers, klanten, maar ook de toezichthouders, dient een crisiscommunicatieplan opgesteld te worden. De vereisten hiervoor zijn opgenomen in art. 14.

Learning & Evolving

Oftewel ‘Scholing en Ontwikkeling’, zoals de Nederlandse tekst van DORA dit in art. 13 noemt, draait om het lerend vermogen en de continue verbetering van de organisatie en haar medewerkers. Kennis over kwetsbaarheden en cyberbedreigingen moet op niveau gehouden worden. Incidenten en de afhandeling daarvan moeten achteraf geëvalueerd worden, een zogenaamde ‘post-incidentevaluatie’. Uit een dergelijke evaluatie volgen ‘lessons learned’ en suggesties voor aanpassingen in bijvoorbeeld procedures. Deze post-incidentevaluaties en de daaropvolgende wijzigingen ter verbetering moeten op verzoek van de toezichthouder aangeleverd kunnen worden.

In art. 13 lid 6 wordt specifiek verwezen naar het opbouwen van kennis over cyber en ICT gerelateerde bedreigingen voor het personeel van financiële entiteiten. In het kort stelt dit artikel dat het verplicht is om een bewustwordingsprogramma te hebben en een opleidingsprogramma te implementeren, waarbij de digitale weerbaarheid van de organisatie een verplichte module is. Uiteraard in proportie en aansluitend bij het niveau en takenpakket van de medewerker, waarbij hoger leidinggevend personeel specifiek wordt genoemd. Ook stelt dit artikel dat het relevant kan zijn om derde aanbieders van ICT-diensten te betrekken in bewustwordingsprogramma’s en opleidingen.

Regulatory Technical Standards (RTS)

Op uiterlijk 17 januari 2024 komen de Europese Toezichthoudende Autoriteiten met nadere invulling (“technische reguleringsnormen/technical standards”) van enkele onderwerpen die betrekking hebben op Hoofdstuk 2 van DORA. Het gaat hier specifiek om:

Stappen richting een DORA compliant organisatie

In hoofdstuk II schetst DORA de vereisten voor een kader van ICT-risicobeheersing en de organisatorische vereisten voor borging in de organisatie. Het proces voor identificatie, bescherming & preventie, detectie, response & herstel en continue verbetering, wordt in art. 8 tot 14 nader uitgewerkt. DORA verplicht tot het hebben van diverse beleidsdocumenten en procedures, en stelt soms ook eisen aan de inhoud ervan.

Ook al volgt er voor sommige elementen nog een nadere technische reguleringsnorm, er valt gezien de opbouw van DORA en de elementen uit beveiligingsstandaarden zoals het Cybersecurity Framework van NIST, wel een onderbouwde inschatting te maken van de inhoud. Denk hierbij bijvoorbeeld aan de ISO 27001 en 27002 standaard.

De eerste stap richting een DORA compliant organisatie zal bestaan uit een analyse: is het vereiste beleid en zijn de benodigde documentatie aanwezig? Enkele voorbeelden hebben wij in dit artikel met een dikgedrukt lettertype aangegeven. Daarna volgt een diepere analyse op de bestaande documentatie, die moet uitwijzen of de vereisten vanuit DORA al afgedekt worden in deze stukken. Een dergelijke aanpak hebben we in een vorig artikel opgenomen. Heeft u vragen over DORA, of hulp nodig bij uw voorbereiding? Wij helpen u graag. U heeft nog 19 maanden de tijd!

DORA Awareness

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.