DORA: Een deepdive in ICT-gerelateerd incident management 

Een artikel over de Digital Operational Resiliance Act kan niet zonder een quote van het gelijknamige tekenfilmfiguur ‘Dora the explorer’. Iedere aflevering bevat een herkenbare gebeurtenis, een oplossing en een moraal of geleerde les. Datzelfde geldt voor incidenten die zich voordoen binnen een organisatie. Ieder incident brengt lessen met zich mee.
 

‘Beheer, classificatie en rapportage van ICT-gerelateerde incidenten’ is het derde hoofdstuk uit de DORA Verordening. In dit artikel gaan we dieper in op de vereisten uit DORA en betrekken hierbij ook de concept Regulatory Standards over dit onderwerp.
 

Inhoudsopgave

Beheerproces voor ICT-gerelateerde incidenten 

Bij de implementatie van nieuwe wet- en regelgeving spelen altijd twee zaken: 1) hoe zorgen we dat we voldoen aan de opgelegde vereisten? En 2) hoe richten we de bijbehorende processen binnen de organisatie in? Voor DORA’s ICT Incidentenmanagent liggen deze twee aardig 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. 

Deze stappen samen zorgen voor een adequaat proces om een ICT-incident af te handelen. Toch zijn er nog enkele vraagtekens. Zo wordt het classificatie vereiste uit art. 17 lid 1 sub b uitgewerkt in artikel 18 van DORA en is de meldplicht aan de bevoegde autoriteiten, zoals een AFM of DNB, geregeld in artikel 19. Voor deze beide artikelen is in juni 2023 een concept technische standaard (RTS oftewel een ‘Regulatory Technical Standard) gepubliceerd die een nadere, gedetailleerdere 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 verkeerd 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/major' voor. 

De primaire criteria zijn: 

1. Clients, financial counterparts and transactions affected". 
2. Data losses 
3. Duration and service downtim
    

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 op een geaggregeerd niveau, over een periode van drie maanden, de drempelwaarden van de criteria overschrijden. 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.