LEES
Risk & Compliance

DORA: Een deepdive in ICT-gerelateerd incident management 

Datum:27 september 2023

Een artikel over de Digital Operational Resiliance Act kan niet zonder een citaat uit de gelijknamige stripfiguur 'Dora de ontdekkingsreiziger'. Elke aflevering bevat een herkenbare gebeurtenis, een oplossing en een moraal of les die geleerd is. Hetzelfde geldt voor incidenten binnen een organisatie. Elk incident brengt lessen met zich mee. 

Het beheren, classificeren en rapporteren van ICT-gerelateerde incidenten is het derde hoofdstuk in de DORA Verordening. In dit artikel gaan we dieper in op de vereisten van DORA en nemen we de ontwerpnormen voor regelgeving over dit onderwerp op. 

Inhoudsopgave

Beheerproces voor ICT-gerelateerde incidenten 

Bij het implementeren van nieuwe wet- en regelgeving spelen altijd twee vragen: 1) hoe zorgen we ervoor dat we voldoen aan de gestelde eisen? En 2) hoe richten we de bijbehorende processen in binnen de organisatie? Voor DORA's ICT Incident Management liggen deze twee in elkaars verlengde, wat de implementatie kan vereenvoudigen. 

Samengevat moet een organisatie de volgende vragen beantwoorden om een incident goed af te handelen: 

  • Wat is een incident (art. 3(8) DORA)? 
  • Hoe weet ik dat er een incident heeft plaatsgevonden? (17(3) DORA) 
  • Wat zijn de gevolgen van het incident? Met andere woorden, wat is de impact (art. 18 DORA)? 
  • Hoe beperken we de impact? En hoe doen we dat zo snel mogelijk? (art. 17, lid 3, onder f) DORA) 
  • Hoe kunnen we voorkomen dat het incident zich herhaalt? (art. 13 lid 2 DORA) 
  • Hoe registreren we een incident en aan wie rapporteren we het incident (art. 17(1) DORA)? 

De antwoorden op deze vragen vormen het beheerproces voor ICT-gerelateerde incidenten wat DORA vereist in art. 17 lid 1. Het tweede lid verplicht financiële entiteiten tot het registreren van hun ICT-incidenten en significante cyberbedreigingen. In lid 3 van hetzelfde artikel wordt de doelstelling van het ICT beheerproces verwoord. Deze schrijft voor dat het ICT-beheerproces de volgende punten moet bevatten:
 

1. Indicatoren voor vroegtijdige detectie; 

2. Onderliggende procedure voor het identificeren, detecteren, categoriseren en classificeren van incidenten; 

3. Duidelijke afspraken voor het afhandelen van verschillende (standaard) incidenttypes; 

4. Diverse (communicatie)plannen voor: 

  • Communicatie naar personeel, externe belanghebbenden en media; 
  • Communicatie naar klanten; 
  • Interne escalatie, inclusief klachten; 
  • Financiële entiteiten die optreden als tegenpartij (indien nodig); 

5. Een procedure voor het rapporteren van (ernstige) incidenten aan het (senior) management, inclusief gevolgen/impact, reactie en aanvullende mitigerende controles; 

6. Een reactieprocedure om de negatieve effecten van een incident te minimaliseren en de diensten zo snel mogelijk te hervatten. 

Samen vormen deze stappen een adequaat proces om een ICT-incident af te handelen. Toch zijn er nog enkele vraagtekens. Zo is het classificatievereiste uit artikel 17 lid 1 sub b uitgewerkt in artikel 18 van DORA en is de meldingsplicht aan bevoegde autoriteiten, zoals een AFM of DNB, geregeld in artikel 19. Voor beide artikelen is in juni 2023 een concept technische standaard (RTS of een 'Regulatory Technical Standard') gepubliceerd die een verdere, meer gedetailleerde uitwerking geeft. 

Classificatie van een ICT-gerelateerd incident of cyberdreiging 

Om een incident prioriteit te geven, moet het zo snel mogelijk worden geclassificeerd. Als het bijvoorbeeld gaat om problemen met inloggen door een onjuist wachtwoord, dan krijgt het incident de classificatie 'laag' (als het al onder de definitie van ICT-gerelateerd incident valt, hangt dit af van de oorzaak). Als echter meerdere medewerkers tegelijkertijd niet meer kunnen inloggen, dan kan er meer aan de hand zijn en is urgentie vereist. Een classificatie van ernstig ('major') is hier op zijn plaats en dus is adequate respons vereist. 

Om deze incidenten te classificeren, geeft DORA in artikel 18 zeven criteria en daarnaast stelt de RTS ook een 'drempel' of drempelwaarde voor de categorie 'ernstig/groot' voor. 

De primaire criteria zijn: 

  1. Betrokken klanten, financiële tegenpartijen en transacties". 
  2. Data verliezen 
  3. . "Duur en uitvaltijd 

En de secundaire criteria zijn: 

  1. Reputatie-impact 
  2. Geografische spreiding 
  3. Critical services affected 
  4. Economische impact". 

De reden dat de RTS een onderscheid maakt in primaire en secundaire criteria, is zodat deze twee typen criteria verschillend kunnen worden meegewogen bij de beoordeling van een incident. Er is sprake van een ernstig incident zodra de volgende condities zijn vervuld:
 

  1. De drempelwaarden ("thresholds") van twee primaire criteria worden overschreden; of 
  2. De drempelwaarden van drie of meer criteria zijn overschreden, waaronder één primair criterium. 

Schematisch ziet dit er als volgt uit: 

Bron: DORA ontwerp RTS 

Aan de slag met ICT-gerelateerd incidentbeheer 

Onlangs is de concept RTS aan de markt geraadpleegd. Verschillende partijen, zoals de Pensioenfederatie en branchevereniging Dufas, hebben feedback gegeven aan de Europese toezichthouders. Onder andere over de berekening van de drempels die een incident als significant kunnen kwalificeren. Maar ook al zijn we het misschien niet allemaal eens met de voorgestelde drempels of de methode van classificatie, we zullen allemaal erkennen dat classificatie wel degelijk moet plaatsvinden in het belang van adequaat incidentmanagement.  

Ons advies is dan ook om niet te wachten met het opzetten van ICT-gerelateerd incidentmanagement, maar de volgende stappen te nemen: 

  • Inventariseer en registreer je IT-activa en bepaal je kritieke processen en -IT-componenten en -toepassingen (art. 8(4) DORA); 
  • Ga na welke beschikbare mechanismen of hulpmiddelen je kunt inzetten om anomalieactiviteiten zo snel mogelijk te detecteren (art. 10 en 17, lid 3, onder a) DORA) en of dit voldoende is; 
  • Controleer of je reactie- en herstelmaatregelen adequaat zijn (art. 11 DORA); 
  • Zorg voor een adequaat ontworpen incidentmanagementproces (art. 17 DORA en inclusief classificatie van incidenten, art. 18 DORA); en 
  • Weten hoe en wanneer ze belangrijke incidenten moeten melden aan de toezichthouder (art. 19 DORA). 

Rapporteren van ernstige ICT-gerelateerde incidenten 

Ernstige incidenten moeten worden gemeld aan de bevoegde autoriteiten, of toezichthouder. Het formaat waarin de meldingen moeten worden gedaan en de termijnen waarbinnen dit moet gebeuren, worden geregeld in een RTS op basis van artikel 20 van van DORA. Deze RTS wordt uiterlijk 17 juli 2024 gepubliceerd. Daarna zal het worden voorgelegd aan de Europese Commissie. In ieder geval case kan uit art. 19 worden afgeleid dat het gaat om: 

  • Een eerste melding; 
  • Een tussentijds rapport zodra de status van het incident aanzienlijk is veranderd; 
  • Een eindrapport zodra de oorzakenanalyse is afgerond en de werkelijke impactcijfers bekend zijn. 

Voor veel vergunningplichtige partijen zal gelden dat incidentafhandeling, met name voor ernstige/significante incidenten, wordt gedaan door een externe dienstverlener of een externe specialist. Denk bijvoorbeeld aan case van een ransom-ware aanval. Het is dus toegestaan dat de meldingen uit bovenstaande lijst door een derde partij worden gedaan. 

De moraal van het verhaal 

Elk incident heeft een oorzaak. En deze oorzaak hoop je in de toekomst te vermijden. Het is dus belangrijk om het incident achteraf te analyseren, zodat je een oorzaak kunt vinden en ervan kunt leren. Hiervoor zijn de evaluaties na een incident uit artikel 13, lid 2 DORA bedoeld, die moeten worden uitgevoerd na een verstoring van de kernactiviteiten van de organisatie als gevolg van een ernstig/ernstig incident. En nogmaals: documenteer, leg de analyse vast, bepaal verbeteracties en bewaak de voortgang! 

Zelfs als je het hele IT-landschap hebt uitbesteed, is het raadzaam om te informeren naar 'incidentafhandelingsprocedures' en periodieke incidentrapportages. Verschillende schijnbaar ongerelateerde kleine incidenten kunnen inderdaad een grotere onderliggende oorzaak hebben en kunnen worden gezien als 'terugkerende incidenten'. Ze kunnen nog steeds worden geclassificeerd als 'ernstig' volgens Art. Ze kunnen nog steeds worden geclassificeerd als 'ernstig' volgens Art. 16 van de ontwerp RTS op het moment dat ze de drempelwaarden van de criteria overschrijden op een geaggregeerd niveau, over een periode van drie maanden. Let dus op de kleintjes! 

Meer weten? 

Heb je vragen over DORA of hulp nodig bij de voorbereiding? Neem gerust contact met ons op voor ondersteuning. 

Wil je in je eigen tempo meer leren over DORA vereisten voor financiële entiteiten? Onze DORA Awareness e-learning leidt je door deze nieuwe wet. De training behandelt onder andere ICT- risk management, omgaan met ICT-incidenten, testen van digitale operationele veerkracht en het beheren van ICT-risk externe leveranciers.