Mijn klant eist DORA van mij. Wat nu?
Steeds vaker krijgen onze klanten vragen van hun klanten over DORA. Dit naar aanleiding van het in werking treden van de DORA verordening per 17 januari 2025 en de daarmee ontstane druk om “iets” te doen. Het risico ontstaat daarbij dat er, net als bij de andere verordeningen AVG en NIS2, onnodige onrust ontstaat en daarmee onnodig veel tijd en inspanning wordt besteed aan DORA. Hieronder leg ik kort uit hoe om te gaan met de vraag/eis van een klant om te voldoen aan DORA.
1. Wat is DORA?
De Digital Operational Resilience Act (DORA) is een Europese verordening die als doel heeft om de digitale weerbaarheid van de financiële sector te vergroten. De verordening is op 17 januari 2023 in werking getreden en is per 17 januari 2025 van toepassing. Belangrijk: deze verordening richt zich op Financiële Instellingen (die dus onder toezicht van de DNB vallen).
DORA richt zich op ICT-risicomanagement, ICT-incidenten, het periodieke testen van digitale operationele weerbaarheid, de beheersing van risico’s bij uitbesteding aan (kritieke) derden en de samenwerking rond uitwisseling van informatie over cyberdreigingen.
Deze Financiële Instellingen zijn dus verplicht bij uitbesteding van (kritieke) diensten aan derden, te zorgen dat alle risico’s beheerst zijn.
En daarmee komen we bij onze doelgroep: leveranciers van ICT diensten zoals beheer, onderhoud, SaaS diensten, etc. Van deze leveranciers eisen dat ze aan DORA moeten voldoen is een veel te algemene eis; er moet dus precies vastgesteld worden welke diensten de ICT leverancier levert en waar dat risico’s kan opleveren voor de opdrachtgever (Financiële Instelling).
Oftewel, er moet een heldere scope vastgesteld worden: waar en hoe kan de leverancier van ICT diensten het risico niveau van opdrachtgever beïnvloeden?
2. Hoe stel ik een heldere scope vast?
Om vast te stellen of en waar je als leverancier ICT risico’s veroorzaakt/kan veroorzaken, dient een zogenaamde BIA (= Business Impact Analyse) uitgevoerd te worden.
Processen:
- Elk proces wordt gewogen voor de aspecten Beschikbaarheid (hoe erg is het als het proces een tijdje niet beschikbaar is), Integriteit (hoe erg is het als de verwerkte gegevens gewijzigd worden) en Vertrouwelijkheid (hoe vertrouwelijk zijn de verwerkte gegevens)
- Het invullen is geen exacte wetenschap maar berust wel op kennis over afspraken met bv klanten (SLA’s) en inzicht in welke soorten data er verwerkt worden.
- In onderstaande voorbeeld (een ICT dienstverlener die ICT omgevingen optimaliseert in opdracht van o.a. Financiële Dienstverleners) is de BIA uitgevoerd voor alle processen (primaire en secundaire).
- Deze BIA is uitgevoerd als (verplicht!) onderdeel van de ISO27001 certificering en kan dus prima als basis dienen voor de DORA BIA
Conclusie uit bovenstaande voorbeeld:
- Er zijn maar 2 processen die primair zijn (dus direct betrekking hebben op eventuele risico’s bij de opdrachtgever). De overige zijn secundair en hebben geen impact op de DORA gerelateerde risico’s bij opdrachtgevers.
- Daarvan scoort één (Projecten) laag in de BIA en dus laag qua risico’s. Verklaring daarvoor in dit voorbeeld is dat optimalisatie van de ICT systemen alleen wordt uitgevoerd in testomgevingen van de opdrachtgever, onder beheer van de opdrachtgever en alleen met testdata.
- Het proces Service&Support scoort aanmerkelijk hoger: in dit voorbeeld wordt dat veroorzaakt doordat tijdens het verlenen van Service&Support, medewerkers toegang krijgen tot de operationele ICT omgeving van de opdrachtgever. Hiervoor zijn in het kader van de ISO27001 certificering al een reeks maatregelen getroffen om risico’s te vermijden (screening van medewerkers, gedragsregels, ingestelde controles, specifieke eisen aan gebruikte systemen, etc.)
- Conclusie: met de op deze wijze verkregen beperkte scope, is het veel gemakkelijker geworden om gericht met de opdrachtgever af te stemmen of alle risico’s effectief zijn bestreden en de ICT leverancier dus DORA-proof is.
- Uiteraard kan ook een BIA worden uitgevoerd voor Informatiesystemen, andere belangrijke Bedrijfsmiddelen en voor leveranciers. Overigens altijd een goed idee om kritische systemen, -bedrijfsmiddelen en -leveranciers goed tegen het licht te houden, ook zonder DORA.
3. DORA en ISO27001
Zoals uit bovenstaande voorbeeld al blijkt, is een ISO27001 certificaat een goede basis voor het voldoen aan DORA.
Ook bij het voldoen aan mogelijke andere DORA vereisten (ICT-risicomanagement, ICT-incidenten, het periodieke testen van digitale operationele weerbaarheid, de beheersing van risico’s bij uitbesteding aan (kritieke) derden en de samenwerking rond uitwisseling van informatie over cyberdreigingen), biedt het ISO27001 certificaat een goede uitgangspositie.
Auteur van dit blog: Eildert Karstens, ISO27001 Lead Auditor, ISO3100 Lead Risk Manager en partner bij IsoSecure bv
Meer weten? Neem contact met IsoSecure op via info@isosecure.nl of 06-22592010
