Over anderhalf jaar wordt de Digital Operational Resilience Act (DORA) van kracht. Bent u zich daar al op aan het voorbereiden? Wij kunnen u daarbij helpen. In een reeks diepgaande artikelenlichten we DORA per onderwerp toe. In het vorige artikel hebben we ons gericht op de vereisten van artikel 5 tot en met 7, ook wel bekend als 'Hoofdstuk II: ICT Risk Management'.. In dit artikel gaan we, net als op DORA, dieper in op het raamwerk voor ICT risk beheer, zoals beschreven in de artikelen 8 tot en met 15.
Hoofdstuk II van DORA bevat verschillende randvoorwaarden die de basis leggen voor een effectief ontworpen 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 zijn Training en Ontwikkeling niet opgenomen. In de Engelse versie van DORA wordt hiernaar verwezen als artikel 13, Learning & Evolving. Naar onze mening heeft dit een iets andere betekenis, maar het maakt wel duidelijk dat dit betrekking heeft op de feedbackloop voor het implementeren van 'continue verbetering' in het ICT Risk Management framework.
DORA stelt verschillende eisen aan de organisatie en inhoud van elk van deze fasen. Hieronder bespreken we elk van deze fasen in detail.
Artikel 8 behandelt zowel de identificatie van ICT-risico's als het in kaart brengen van processen en infrastructuur die bedreigd kunnen worden. Hieronder geven we een gedetailleerd overzicht van de verschillende vereisten.
Het is essentieel om de hardware/software/systemen/applicaties, etc. die deze functies ondersteunen in kaart te brengen. Merk op dat deze inventarisatie naar verwachting minstens jaarlijks plaatsvindt.
De wetgever benadrukt de noodzaak om aandacht te besteden aan mogelijke risico's die ook andere financiële entiteiten (direct of indirect) zouden kunnen treffen. Het beoordelen van bedreigingen verwijst naar het uitvoeren van een risk analyse, die ook jaarlijks moet worden herzien. DORA herhaalt deze evaluatie-eis in artikel 8, lid 7, specifiek voor 'legacy' ICT-systemen.
Wanneer er grote veranderingen worden doorgevoerd, zoals in het netwerk of applicaties, is een inschatting van de impact van de verandering op de beveiliging van relevante bedrijfsfuncties noodzakelijk. We raden aan de beoordeling te documenteren, zodat de resultaten kunnen worden gedeeld met het management of toezichthouders.
In tegenstelling tot punt 1 gaat het hier specifiek om pure ICT-apparatuur, zoals netwerkcomponenten zoals firewalls. In ICT-terminologie wordt dit ook wel 'configuratiebeheer' genoemd.
Dit vereist een dieper inzicht door interconnecties aan te geven met providers die kritieke of belangrijke functies ondersteunen. Deze inventaris zal de basis vormen voor de analyse van het beheer van ICT third-party risk .
Als organisatie wil je zoveel mogelijk voorkomen dat risico's zich manifesteren. Artikel 9 van DORA beschrijft de preventieve maatregelen die moeten worden genomen, logisch afgeleid van de uitgevoerde risk analyse.
Voor het organiseren van deze maatregelen verwijst DORA naar het opstellen van een informatiebeveiligingsbeleid. Dit beleid schetst de algemene IT-governanceprocessen, gericht op de beschikbaarheid, authenticiteit, integriteit en vertrouwelijkheid van data en ICT-middelen. Bijvoorbeeld in (zie ook artikel 9, lid 4):
Vroegtijdige detectie van abnormale activiteiten, zoals merkbare netwerkprestaties of gerelateerd aan ICT-incidenten, kan uiteindelijk de impact van potentiële cyberdreigingen beperken. Daarom vereist DORA in artikel 10 dat een financiële entiteit meerdere detectiemechanismen geïmplementeerd moet hebben (paragraaf 1) op meerdere controlelagen (paragraaf 2). Natuurlijk is het ook essentieel om deze mechanismen regelmatig te testen, zoals bepaald in artikel 25.
Vroegtijdige detectie van abnormale activiteiten, zoals merkbare netwerkprestaties of gerelateerd aan ICT-incidenten, kan uiteindelijk de impact van potentiële cyberdreigingen beperken.
Wat detectie betreft, is het cruciaal om de ICT-inrichting te monitoren op mogelijke afwijkingen in gebruikers, ICT-infrastructuur, netwerkverkeer, enz. Idealiter worden bij case van afwijkingen automatische waarschuwingen verstuurd naar bijvoorbeeld een Information Security Officer.
Voor een adequate opzet van Response & Recovery vereist DORA in artikel 11 de implementatie van een continuïteitsbeleid. Zoals DORA vereist voor bijna elk beleid en proces, moet dit ook periodiek/jaarlijks worden getest, worden beoordeeld door Interne Audit en rekening worden gehouden met mogelijke implicaties voor externe leveranciers.
Het continuïteitsbeleid bevat de principes om de continuïteit van de organisatie en/of kritische functies te waarborgen en adequaat te reageren op verstoringen
Het continuïteitsbeleid bevat de principes om de continuïteit van de organisatie en/of kritieke functies te waarborgen en om adequaat te reageren op verstoringen. De implementatie van deze maatregelen moet worden weerspiegeld in verschillende onderliggende plannen, zoals een bedrijfscontinuïteitsplan en respons- en herstelplannen.
Een essentieel onderdeel van het continuïteitsbeleid is de Business Impact Analyse, die de exacte blootstelling van de organisatie aan ernstige verstoringen van bedrijfsactiviteiten moet illustreren. In deze analyse moeten zowel kwalitatieve als kwantitatieve criteria worden opgenomen. Dit onderdeel mag niet lichtvaardig worden opgevat, vooral omdat artikel 11, lid 10, de mogelijkheid biedt aan toezichthouder om de werkelijke kostenramingen van ICT-verstoringen op te vragen.
De Business Impact Analyse moet de exacte blootstelling van de organisatie aan ernstige verstoringen van de bedrijfsactiviteiten illustreren.
Het hebben van een back-upmogelijkheid en een adequaat back-up- en herstelbeleid zorgt voor minimale uitvaltijd en verstoring van kritieke bedrijfsfuncties en minimaal data verlies. Dit is dus een cruciaal onderdeel dat goed moet zijn om "reactie en herstel" effectief te laten functioneren.
Het bepalen van de Recovery Time Objective (RTO) en de Recovery Point Objective (RPO) sluit aan bij de bedrijfsvereisten voor kritieke ICT-toepassingen en -processen. Artikel 13 stelt dat er een back-upbeleid moet worden ontwikkeld met onderliggende procedures die de minimale back-upfrequentie specificeren die wordt toegepast op data. Dit back-upbeleid moet worden afgestemd op de RPO. Het moet ook de herstel/recovery-procedures beschrijven om de RTO te bereiken. Een belangrijke overweging hierbij is dat back-ups ook beschermd moeten worden tegen ongeautoriseerde toegang.
Voor communicatie tijdens een verstoring naar werknemers, klanten en toezichthouders moet een crisiscommunicatieplan worden ontwikkeld, zoals gespecificeerd in artikel 14.
Learning & Evolving, zoals vermeld in artikel 13 van DORA, richt zich op het lerend vermogen en de voortdurende verbetering van de organisatie, met inbegrip van haar werknemers. Kennis over kwetsbaarheden en cyberbedreigingen moet op een passend niveau worden gehouden. Incidenten en de afhandeling ervan moeten na het incident worden geëvalueerd. De lessen die uit dergelijke evaluaties worden getrokken en suggesties voor verbeteringen van bijvoorbeeld procedures moeten op verzoek worden verstrekt aan toezichthouder .
Leren & Evolueren, zoals vermeld in artikel 13 van DORA, richt zich op het lerend vermogen en de voortdurende verbetering van de organisatie, met inbegrip van haar werknemers.
Artikel 13, lid 6, verwijst specifiek naar het opbouwen van kennis over cyber- en ICT-gerelateerde bedreigingen voor werknemers van financiële entiteiten. Samengevat stelt dit artikel dat het verplicht is om een awareness programma te hebben en een trainingsprogramma te implementeren, waarbij digitale weerbaarheid een verplichte module is. Deze programma's moeten proportioneel zijn en afgestemd op het niveau en de verantwoordelijkheden van de werknemer, met een specifieke vermelding van hoger managementpersoneel. Daarnaast kan het relevant zijn om externe ICT-dienstverleners te betrekken bij awareness programma's en training.
Uiterlijk op 17 januari 2024 zullen de Europese toezichthoudende autoriteiten via "technische reguleringsnormen" nadere bijzonderheden verstrekken over verschillende onderwerpen die verband houden met hoofdstuk 2 van DORA. Dit omvat met name:
Hoofdstuk 2 van DORA beschrijft de vereisten voor een ICT risk management kader en de organisatorische vereisten voor implementatie binnen de organisatie. Het proces voor identificatie, bescherming & preventie, detectie, respons & herstel, en continue verbetering wordt verder uitgewerkt in artikelen 8 tot 14. DORA mandateert verschillende beleidsdocumenten en procedures, en specificeert soms ook de inhoud ervan.
Hoewel sommige elementen verder technisch zullen worden gereguleerd via RTS, is het mogelijk om een eerste beoordeling te maken op basis van de structuur van DORA en beveiligingsnormen zoals het NIST Cybersecurity Framework en ISO 27001/27002.
De eerste stap om DORA compliant te maken is een analyse: Zijn de vereiste beleidsregels en documentatie aanwezig?
De eerste stap om DORA compliant te maken is een analyse: Zijn de vereiste beleidsregels en documentatie aanwezig? Een diepere analyse van de bestaande documentatie zal bepalen of DORAal aan de vereisten voldoet. In een eerder artikel hebben we al een soortgelijke aanpak beschreven. Als u vragen hebt of hulp nodig hebt bij het voorbereiden van de implementatie van DORA , staan onze consultants klaar om u te helpen. Zij kunnen begeleiding, ondersteuning en expertise bieden om ervoor te zorgen dat uw organisatie klaar is om binnen de resterende anderhalf jaar te voldoen aan de vereisten van DORA .
Als je meer wilt weten over de eisen DORA die aan financiële instellingen worden gesteld, kan onze e-learning DORA Awareness uitkomst bieden. Deze e-learning behandelt onderwerpen zoals ICT risk management, omgaan met ICT-incidenten, testen van digitale operationele veerkracht en het beheren van ICT risk met externe leveranciers. Voor meer informatie en hulp kunt u contact opnemen met onze consultants. De deadline voor compliance nadert - je hebt nog maar anderhalf jaar...
Projective Group is opgericht in 2006 en is een toonaangevende veranderspecialist voor de financiële sector. Met diepgaande expertise op practices in Data, Payments, Transformatie en Risk & Compliance.
We worden binnen de sector erkend als een provider van complete oplossingen, die samenwerkt met klanten in de financiële dienstverlening om oplossingen te bieden die zowel holistisch als pragmatisch zijn. We hebben ons ontwikkeld tot een betrouwbare partner voor bedrijven die willen gedijen en bloeien in een steeds veranderend landschap van financiële dienstverlening.