DORA: let’s explore ICT-related incident management

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 voor een goede afhandeling van een incident de volgende vragen beantwoorden:

• Wat is een incident? (art. 3 lid 8 DORA)
• Hoe weet ik dat er een incident heeft plaatsgevonden? (17 lid 3 DORA)
• Welke gevolgen heeft het incident? Oftewel: wat is de impact? (art. 18 DORA)
• Hoe beperken we de impact? En hoe doen we dit zo snel mogelijk? (art. 17 lid 3 sub f DORA)
• Hoe kunnen we voorkomen dat het incident nogmaals plaatsvindt? (art. 13 lid 2 DORA)
• Hoe leggen we een incident vast en aan wie rapporteren/melden we het incident? (art. 17 lid 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 een vroegtijdige detectie;
2. Onderliggende procedure om incidenten te identificeren, detecteren, categoriseren en te classificeren;
3. Duidelijke afspraken over de afhandeling van verschillende (standaard) incidenttypes;
4. Diverse (communicatie) plannen voor:
   1. Communicatie richting personeel, externe belanghebbenden en media;
   2. Mededelingen aan cliënten;
   3. Interne escalatie, inclusief klachten;
   4. Financiële entiteiten die optreden als tegenpartij (indien noodzakelijk);
5. Een procedure voor het melden van (ernstige) incidenten aan (hoger) management, inclusief de effecten/impact, response en aanvullende mitigerende controles;
6. Een response procedure om de negatieve effecten van een incident te minimaliseren en de dienstverlening 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 cyberbedreiging

Om de prioriteit van een incident te bepalen, moet het zo snel mogelijk geclassificeerd worden. Gaat het bijvoorbeeld om problemen met inloggen door onjuist wachtwoord , dan zal het incident de classificatie ‘laag’ krijgen (als dit al binnen de definitie van ICT-gerelateerd incident valt, dit is afhankelijk van de oorzaak). Kunnen echter meerdere personeelsleden op hetzelfde moment niet meer inloggen, dan is er mogelijk meer aan de hand en is spoed vereist. Een classificatie van ernstig (‘major’) is hier terecht, en dus is adequate reactie nodig.

Om deze incidenten te classificeren geeft DORA  in art. 18 een zevental criteria, en daarnaast wordt in de RTS ook een ‘threshold’ c.q. drempelwaarde voorgesteld voor de categorie ‘ernstig/major’.

De primaire criteria zijn:

1. ‘Clients, financial counterparts and transactions affected’
2. ‘Data losses’
3. ‘Duration and service downtime’

En de secundaire criteria zijn:

4. ‘Reputational impact’
5. ‘Geographical spread’
6. ‘Critical services affected’
7. ‘Economic 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:

• De drempelwaarden (“thresholds”) van twee primaire criteria zijn overschreden; of
• De drempelwaarden van drie of meer criteria zijn overschreden, waarvan 1 primair criterium.

Schematisch ziet dat er als volgt uit:

Aan de slag met ICT-gerelateerd incident management

Onlangs is de concept RTS aan de markt geconsulteerd. Diverse partijen, zoals de Pensioenfederatie en branchevereniging Dufas, hebben feedback gegeven aan de Europese Toezichthoudende Autoriteiten. Onder andere op de berekening van de drempelwaarden die een incident als significant kunnen bestempelen. Maar ook al zijn we het wellicht niet allemaal eens met de voorgestelde drempelwaarden of de methode van classificatie, we zullen allemaal erkennen dat classificatie wel degelijk moet plaatsvinden in het belang van adequaat incident management.

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

• Inventariseer en registreer uw IT-assets en bepaal uw kritische processen en -IT componenten en applicaties (art. 8 lid 4 DORA);
• Controleer welke beschikbare mechanismen of tooling je kunt inzetten om afwijken activiteiten zo spoedig mogelijk detecteren (art. 10 en 17 lid 3 sub a DORA) en of dit voldoende is;
• Controleer of uw response en herstelmaatregelen afdoende zijn (art. 11 DORA);
• Draag zorg voor een adequaat ingericht incident managementproces (art. 17 DORA en inclusief classificatie van incidenten, art. 18 DORA); en
• Weet hoe en wanneer de significante incidenten gerapporteerd moeten worden aan de toezichthouder (art. 19 DORA).

Rapportage van ernstige ICT-gerelateerde incidenten

Ernstige incidenten moeten aan de bevoegde autoriteiten gemeld worden, oftewel aan de toezichthouder. Het format waarin gerapporteerd moet worden de tijdslijnen waarbinnen dit moet gebeuren, worden op basis van art. 20 van DORA in een RTS geregeld. Deze RTS wordt uiterlijk op 17 juli 2024 bekendgemaakt. Vervolgens wordt deze voorgelegd aan de Europese Commissie. In ieder geval is uit artikel 19 af te leiden dat het gaat om:

• Een eerste kennisgeving;
• Een tussentijds verslag zodra de status van het incident ingrijpend is gewijzigd;
• Een eindverslag wanneer de analyse van de onderliggende oorzaken is afgerond en de werkelijk impactcijfers bekend zijn.

Voor vele vergunninghoudende partijen zal gelden dat incident afhandeling, zeker bij ernstige/significante incidenten, gedaan wordt door een externe service provider of een externe specialist. Denk bijvoorbeeld in het geval van een ransom-ware aanval. Het is dan ook toegestaan dat de verslagen uit bovenstaande opsomming door een derde gemaakt worden.

De moraal van het verhaal

Elk incident heeft een oorzaak. En deze oorzaak hoop je in het vervolg te kunnen voorkomen. Het is dus belangrijk om het incident achteraf te analyseren, zodat je een oorzaak vindt en hier lering uit kunt trekken. Hiervoor dienen de post-incidentevaluaties uit artikel 13 lid 2 DORA, die moeten worden uitgevoerd na verstoring van de kernactiviteiten van de organisatie als gevolg van een ernstig/significant incident. En ook hier geldt: documenteer, leg de analyse vast, definieer de verbeteracties en monitor voortgang!

Ook als je het complete IT landschap hebt uitbesteed, is het aan te raden om navraag te doen naar de ‘incident handling procedures’ en de periodieke incidentenrapportages. Verschillende ogenschijnlijk losstaande, kleine incidenten kunnen namelijk een grotere achterliggende oorzaak hebben en gezien worden als ‘recurring incidents’. Ze kunnen volgens art. 16 van de concept RTS alsnog een classificatie ‘ernstig’ krijgen op het moment ze op geaggregeerd niveau, over een periode van drie maanden, toch 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 vrijblijvend contact met ons op voor ondersteuning.

Wil je op jouw eigen tempo meer leren over de eisen die DORA stelt aan financiële entiteiten? Onze DORA Awareness e-learning maakt je wegwijs in deze nieuwe wet. De training gaat in op onder andere ICT-risicobeheer, de omgang met ICT-incidenten, het testen van digitale operationele weerbaarheid en het beheer ICT-risico derde aanbieders.