Veel middelgrote en kleinere financiële instellingen zijn nog niet gestart met de voorbereiding op de nieuwe Europese regelgeving Digital Operational Resilience Act: DORA, gepubliceerd als Regulation (EU) 2022/2554. DORA beoogt de Digital Operational resilience te vergroten van bedrijven en instellingen werkzaam in de financiele diensverlening binnen de EU.
De regelgevers – ESMA, EIOPA en EBA – moeten nog komen met de meer gedetailleerde Regulatory Technical standards (RTS)(1) . Echter, omdat DORA van kracht wordt op 17 januari 2025 is wat nodig is om te implementeren voor die tijd niet alleen complex, maar vereist ook deels een cultuur- en werkwijzeverandering en samenwerking tussen verschillende 1e en 2e lijns afdelingen. En last but not least, al het werk nodig voor DORA komt bovenop de toch al volle veranderagenda van veel financiële instellingen en hun (kritieke) leveranciers.
Zeker de genoemde financiële instellingen moeten daarom niet wachten op de RTS-en, maar doen er verstandig aan nu al een analyse te maken van de huidige situatie en te starten met praktische verbeteringen. In dit artikel geven wij daarom een aantal praktische tips om nu al aan de slag te gaan met DORA. Quick wins en no-regrets moves dus.
Wat is DORA
In een eerder artikel schreven wij al meer uitgebreid over de aanleiding, tijdslijnen en de belangrijkste vereisten van DORA. Daarom hier alleen een korte samenvatting.
De EU Digital Operational Resilience Act (DORA) voor de financiële sector, is van kracht geworden op 16 januari dit jaar. Het doel van deze regelgeving is om de weerbaarheid (resilience) van de Europese sector te vergroten tegen ICT-risico’s zoals IT-falen en cyberattacks. Dit wordt gedaan door het introduceren van standaard security requirements voor Information & Communication Technologie. DORA is niet alleen van toepassing op de financiële sector zelf, maar ook op veel van de ICT-dienstverleners aan deze sector.
Alle bedrijven die vallen onder de DORA regelgeving hebben tot 17 januari 2025 om deze regelgeving te implementeren.
De DORA regelgeving bevat de in onderstaand figuur weergegeven vijf hoofdonderwerpen.
Overview of the 5 focus points of the Digital Operational Resilience Act DORA
Krediet Instellingen
Voor krediet instellingen – banken – zijn veel van de onderwerpen die in DORA worden behandeld, al vastgelegd in andere regelgevingen. DORA voegt echter nieuwe regels toe of wijkt daar van af. Wij hebben een vergelijking gemaakt met de bestaande regelgeving en onderstaande de high level overeenkomsten en verschillen weergegeven:
Overview of the 5 focus points of the Digital Operational Resilience Act DORA
Hieruit blijkt duidelijk dat alleen een beperkt aantal onderwerpen helemaal onveranderd blijft, hoewel de verschillen op veel vlakken beperkt zijn. Ons advies aan banken is daarom – voor zover nog niet gedaan – een GAP analyse uit te voeren zodat ruim van te voren bekend is wat er gedaan moet worden en welke inspanning daarvoor nodig is, en deze te herhalen na publicatie van iedere RTS.
Quick wins en no-regrets moves voor andere financiele instellingen
De situatie voor andere financiële instellingen dan banken kan significant anders zijn, omdat de strikte regulering die geldt voor banken niet of slechts deels op hen van toepassing is. Natuurlijk geldt: hoe groter de financiële instelling, hoe waarschijnlijker het is dat professionele standaarden en best practices al zijn geïmplementeerd. Maar vooral de kleine en middelgrote organisaties zullen in de praktijk vaak nog niet voldoen aan de DORA vereisten. En omdat DORA consequenties kan hebben voor policies, processen, procedures, technische implementatie, contracten en zelfs cultuur binnen een organisatie, menen wij dat het niet verstandig is te wachten tot het moment dat de RTS-en meer duidelijkheid zullen verschaffen. Er zou dan immers maximaal 6 tot 12 maanden beschikbaar zijn voor alle analyse, planvorming en implementatie. Met alle veranderingen die er al spelen bij veel Financiële instellingen, kan dit teveel worden voor de beperkte tijd.
Onderstaand belichten wij daarom een aantal onderwerpen waarmee deze financiële instellingen nu al aan de slag kunnen.
I. Governance en organization (Hoofdstuk 2,artikel 5)
DORA vereist dat de Management body (RvB) verantwoordelijk is om het ICT Risk Management Framework te definiëren, goed te keuren, budget voor te alloceren en overzicht over te houden. Dat betekent dat het bestuur van de organisatie als basis voldoende kennis dient te hebben van ICT en ICT-risico management. Deze kennis bij slechts 1 RvB lid laten zal onvoldoende zijn. De eerste no-regrets moves zijn daarom:
- No-regrets move 1: Indien het management als geheel nog onvoldoende kennis heeft van ICT en ICT-risico management, organiseer masterclasses ICT en ICT-risicomanagement. Neem hierin ook mee een awareness sessie over DORA.
- No-regrets move 2: Indien de ICT-risico’s en daarvoor mitigerende maatregelen nog niet besproken worden in de Management Body, voeg een pagina toe aan het risk report waarin bijvoorbeeld de ICT-risico’s, ICT-grote incidenten en ICT-maatregelen toegelicht worden, zodat het onderwerp ICT aan de orde komt. Zo went het management aan de complexiteit van ICT, wat in de loop van de tijd het begrip voor de complexiteit van de in DORA genoemde maatregelen vergroot.
- No-regrets move 3: Onder DORA zullen rollen zoals bijvoorbeeld degene die verantwoordelijk zijn voor het monitoren van ICT third party service providers, helder moeten zijn belegd. Het nieuwe “Three Lines Model” (voorheen three lines of defense) zoals gepubliceerd door de IIA(2) is een wijd geaccepteerde standaard, dus het is zeer waarschijnlijk dat regulatory parties en auditors zullen verwachten dat dit voor financiële instellingen wordt gehanteerd. Indien nog niet – of nog niet volledig -geimplementeerd (3) : implementeer het model, dan kan DORA daarop voortborduren.
II. Policies, procedures, strategies , protocols (hoofdstuk 2 o.a. artikel 9 en 11)
In DORA zijn requirements opgenomen voor onderwerpen waarvoor een onderneming procedures, tools, strategies e.d. dient te hebben. En deze moeten er aantoonbaar zijn, dus gedocumenteerd en in het juiste gremium zijn goedgekeurd (policies). Hoewel de gedetailleerde eisen in de RTSen nog niet bekend zijn, kunt u zich nu al voorbereiden en op deze manier tijd besparen gedurende de implementatie.
- No-regrets move 4: Verzamel alle ICT gerelateerde policies, procedures en dergelijke en voer een pre-assessment uit. Bepaal of het huidige gremium waarin ze worden goedgekeurd, overeenstemt met de DORA vereisten (artikel 5) en of alle onderwerpen zoals genoemd in DORA (bijv. artikel 9 sub 3 en 4, artikel 11 sub 2) door de bestaande documenten worden afgedekt. Zo niet, leg dit tenminste vast, als er dan later meer details komen, ligt de basis er.
III. Backup en recovery strategie (Hoofdstuk 2, artikel 12)
Artikel 12 van DORA stelt eisen aan de back-up, restoration en recovery van een financiële instelling. Er zal straks voldaan moeten worden aan eisen zoals niet wijzigbare back-ups, fysiek en logisch afgescheiden restore omgeving, secondary processing site, periodiek testen van de back-up en restore procedures. Veel kleinere financiële instellingen (en hun leveranciers) voldoen nog niet aan deze vereisten en hebben nog nooit doorleefd wat dit inhoudt, wie waarvoor verantwoordelijk is, waarom dit nodig is.
- No-regrets move 5: organiseer een tabletop oefening waarin het scenario “ransomware” op systemen en data wordt nagespeeld. Naast de “wie doet wat vragen”, stel daarin ook vragen als: hoe weet je dat je systemen die je weer opbrengt niet gelijk weer geïnfecteerd raken, hoe weet je zeker dat je back-ups niet zijn aangetast, hoe stel je vast vanaf welk moment de systemen (en data) waren geïnfecteerd, hoe ga je de data en systemen na dat moment herstellen
IV. Communicatie policy en -plan naar klanten en medewerkers (hoofdstuk 2, artikel 14)
In geval van een grote verstoring vereist DORA dat er een communicatieplan is waarin o.a. staat wat wanneer wordt gecommuniceerd met klanten en eigen medewerkers. Bovendien dient de verantwoordelijkheid daarvoor bij tenminste 1 persoon te zijn belegd.
- No-regrets move 6: omdat dit toch al een verstandig is om te doen: maak dit communicatieplan of beoordeel het bestaande communicatieplan. Indien de verantwoordelijkheid nog niet eenduidig is belegd, doe dit. Let hierbij ook op de samenhang met het Business Continuity Plan, waarin communicatie ook een onderwerp is.
V. Threat led Penetration testing (red team testing) (hoofdstuk 4, art 26)
DORA vereist in artikel 26 een “threat led penetration test”. Dit komt overeen met een red team test op de produktieomgeving, en is inclusief gebouwbeveiliging, awareness van medewerkers e.d. en in principe (4) inclusief de omgeving van leveranciers. Uitzondering (5) daargelaten, dient deze red team test te worden uitgevoerd door een externe partij die aan de in artikel 27 genoemde vereisten (6) voldoet.
- No-regrets move 7: doe een scan welke “external threat intelligence providers” er zijn waar gebruik van kan worden gemaakt. Onderzoek welke externe penetration testing providers er zijn waar de organisatie gebruik van kan maken.
- No-regrets move 8: Indien nog nooit een red team test is uitgevoerd: doe dit. Het is een andere werkwijze en vereist veel voorbereiding, dus kost in onze ervaring best wel gewenning.
- No-regrets move 9: neem alvast contact op met uw belangrijkste ICT-leveranciers en start de discussie hoe zij aan deze vereisten denken te gaan voldoen.
VI. ICT Third Party Risk (chapter 5, artikel 28 e.v.) – uitbesteding –
DORA stelt heel wat eisen aan de uitbesteding van (kritieke) ICT-dienstverlening. Basis voor dit alles is een goed overzicht van de ICT-dienstverlening die is uitbesteed, welke daarvan kritiek zijn en vervolgens waaraan deze leveranciers hun dienstverlening weer hebben uitbesteed (7) . Volgens de European Banking Authority’s (EBA) Guidelines on outsourcing arrangements gepubliceerd in februari 2019 (EBA Guidelines), en de European Insurance and Occupational Pensions Authority’s (EIOPA), zou dit overzicht er al moeten zijn en worden bijgehouden in een register.
- No-regrets move 10: Check of alle uitbestede ICT-dienstverlening – die kritieke of belangrijke functies betreft – in dit register staat en actueel is.
- No-regrets move 11: Check of de contractuele voorwaarden in uw modelcontracten voldoen aan de eisen uit artikel 28 e.v van DORA.
- No-regrets move 12: Van sommige serviceproviders kan nu al worden ingeschat dat deze conform artikel 31 sub 1a en 2, systeem relevant zijn. Denk aan grote cloud providers (Amazon, Microsoft). Deze moeten een dochteronderneming in de EU hebben. Bepaal alvast welke leveranciers dit waarschijnlijk zijn en vraag hoe zij zich voorbereiden op DORA.
DORA is belangrijke wetgeving voor de EU, zeker met alle cyberaanvallen en politieke onrust die er wereldwijd nu is. Wij verwachten daarom dat de regulators nadat de regelgeving in januari 2025 van kracht is geworden, snel over zullen gaan tot een strikte handhaving. Tegelijk duurt het nog lang voordat de Regulatory Technical Standards definitief zullen zijn. Het is daarom onzes inziens beter nu al te beginnen met tenminste bovengenoemde quick wins en no-regrets moves. Zodat u in de laatste 6 tot 12 maanden niet voor een onmogelijke opgave komt te staan.
Heeft u vragen? Bel ons gerust!
Voetnoot
- De verwachting is dat deze gepubliceerd worden 12 tot 18 maanden na de publicatie van DORA. Het betreft in ieder geval Regulatory Technical Standards over Risk Managment Framework (draft: januari 2024), ICT Policy (draft: januari 2024) en een RTS on subcontracting kritische of belangrijke functies (draft: juni 2024).
- IIA. (2020). The IIA’s Three Lines Model. An Update of the Three Lines of Defense.
- Al gebruikelijk bij grote financiële instellingen, maar bij kleinere en bij leveranciers is het regelmatig niet of nog niet optimaal ingevoerd
- Ook hier een uitzondering voor de ondernemingen zoals genoemd in artikel 26 (1)
- Zie artikel 27( 1) point a
- Kort samengevat: goede reputatie en deskundigheid, technische en organisatorische capaciteiten, gecertificeerd of onderschrijft een formele code of conduct, in staat om een onafhankelijk auditreport/ assurance te leveren en is verzekerd.
- inzicht in de hele keten, zodat o.a. concentration risk bepaald kan worden
