Ja jūs vadāt krājaizdevu sabiedrību, maksājumu iestādi, apdrošināšanas brokeru uzņēmumu vai ieguldījumu fondu pārvaldītāju, DORA uz jums jau attiecas. Ja esat IT uzņēmums, kas uztur serverus, sniedz mākoņpakalpojumus vai izstrādā programmatūru šādiem klientiem, DORA līdz jums nonāk caur klientu līgumiem, visbiežāk kā pārsteigums – ar lūgumu divu nedēļu laikā parakstīt jaunu līguma papildinājumu.
DORA ir ES Regula 2022/2554 par digitālo darbības noturību finanšu sektorā, kas piemērojama kopš 2025. gada 17. janvāra. Atšķirībā no direktīvas regula ir tieši piemērojama, to nepārņemot nacionālajos tiesību aktos, tāpēc finanšu uzraudzības iestāde, Latvijā – Latvijas Banka, to uzrauga tieši tā, kā tā uzrakstīta.
Šajā rakstā vienkāršā valodā izskaidrojam regulas piecus pīlārus, parādām, ko tie praksē nozīmē IT pakalpojumu sniedzējam, un pastāstām, kā mēs ar tiem strādājam savu klientu labā.
Pieci DORA pīlāri
Regula balstīta uz piecām jomām. Katrai no tām ir dokumentācijas puse un tehniskā puse.
IKT risku pārvaldība
Finanšu iestādei jābūt augstākās vadības apstiprinātai informācijas un komunikācijas tehnoloģiju (IKT) risku pārvaldības sistēmai: aktīvu reģistram, risku novērtējumam, aizsardzības pasākumiem, atklāšanas spējām un reaģēšanas un atjaunošanas plāniem. Par visu to atbild vadība, nevis IT nodaļa. Praksē tas nozīmē, ka vadībai jāsaprot, kuras sistēmas ir kritiskas, kas notiek, kad tās apstājas, un cik ilgi iestāde var strādāt bez tām.
Incidentu pārvaldība un ziņošana
Visi ar IKT saistītie incidenti tiek reģistrēti un klasificēti pēc ietekmes, bet nozīmīgie – paziņoti uzraudzības iestādei stingros termiņos: sākotnējais paziņojums dažu stundu laikā, vēlāk starpposma un galīgais ziņojums. Iestādei jāspēj ātri novērtēt, cik klientu cieta, cik ilgi pakalpojums nebija pieejams un vai notika datu noplūde. Bez žurnāliem un monitoringa tas nav iespējams.
Digitālās darbības noturības testēšana
Ar aizsardzības esamību nepietiek, to regulāri jātestē. Bāzes līmenis ietver ievainojamību skenēšanu, konfigurāciju pārskatus, rezerves kopiju atjaunošanas testus un scenāriju mācības. Lielākām un sistēmiski nozīmīgām iestādēm jāveic arī uz draudiem balstīta penetrācijas testēšana, kurā speciālisti imitē reālu uzbrukumu. Testu rezultāti tiek dokumentēti, un vājās vietas novērstas pēc plāna.
Trešo pušu IKT risku pārvaldība
Šis ir pīlārs, kas visvairāk skar IT pakalpojumu sniedzējus. Iestādei jāuztur visu tās IKT pakalpojumu sniedzēju reģistrs, jānovērtē katra sniedzēja risks, jāiekļauj līgumos obligātie noteikumi un jābūt iziešanas stratēģijai gadījumam, ja sniedzējs pārstāj sniegt pakalpojumu. Pakalpojumi, kas atbalsta kritiskas funkcijas, piemēram, grāmatvedības sistēmas mitināšana vai rezerves kopiju glabāšana, tiek vērtēti īpaši rūpīgi.
Informācijas apmaiņa
Iestādes tiek mudinātas savā starpā un ar iestādēm apmainīties ar informāciju par draudiem un ievainojamībām. Mazai iestādei tas parasti nozīmē piedalīšanos nozares grupās un Nacionālā kiberdrošības centra (CERT.LV) brīdinājumu uzraudzību.
Ko tas nozīmē IT pakalpojumu sniedzējam
Ja sniedzat IT pakalpojumus finanšu iestādei, klients nevar ar jums strādāt, ja neatbalstāt tā DORA pienākumus. Mūsu pieredzē sniedzēja pusē tas ir trīs konkrēti jautājumi.
Līgumi
Līgumā ar finanšu iestādi jābūt skaidriem nosacījumiem: precīzi aprakstīti pakalpojumi un pakalpojumu līmeņi, datu glabāšanas vieta (ES robežās vai ārpus tām), termiņi, kādos klients tiek informēts par incidentiem, klienta un uzraudzības iestādes tiesības veikt auditu, noteikumi par apakšuzņēmēju izmantošanu un izbeigšanas nosacījumi ar pārejas periodu. Ja jūsu standarta līgumā to nav, klients atsūtīs savu papildinājumu. Labāk ir iepriekš sagatavot savu.
Reģistrs
Klients aizpilda sniedzēju reģistru noteiktā formātā, un tam būs vajadzīga informācija par jums: juridiskās personas dati, pakalpojuma veids, kritiskums, datu atrašanās vieta un apakšuzņēmēji. Sniedzējam jābūt gatavam atbilžu komplektam, jo dažādu klientu anketas ievērojami pārklājas.
Iziešanas plāni
Katrai iestādei jāspēj pāriet no viena sniedzēja pie cita bez darbības traucējumiem. Jūsu pienākums ir aprakstīt, kā atdosiet datus, kādā formātā, cik ilgā laikā un ko izdzēsīsiet pēc nodošanas. Sniedzējs, kas nevar skaidri pateikt, kā klients saņem savus datus atpakaļ, aizejot, ir risks, un to nomainīs.
Vēl viena lieta, ko sniedzēji bieži pārredz, ir apakšuzņēmēji. Ja klientam sniedzat rezerves kopiju glabāšanas pakalpojumu un kopijas fiziski atrodas pie trešās puses, klientam par to jāzina un jābūt tiesībām iebilst. Apakšuzņēmēju ķēde jāapraksta līgumā un jāatjaunina, kad tā mainās.
Zemāk redzams, kā tās pašas prasības izskatās no abām pusēm.
| Prasība | Finanšu iestāde | IT pakalpojumu sniedzējs |
|---|---|---|
| Risku pārvaldība | Risku reģistrs, vadības lēmumi | Pierādījumi par savām drošības politikām un kontrolēm |
| Incidenti | Paziņojums uzraudzības iestādei noteiktajos termiņos | Paziņojums klientam vienošanās termiņā, žurnāli |
| Testēšana | Testu plāns un rezultāti | Dalība atjaunošanas testos, ievainojamību novēršana |
| Trešās puses | Sniedzēju reģistrs, iziešanas stratēģija | Līguma papildinājums, apakšuzņēmēju saraksts, iziešanas plāns |
| Informācijas apmaiņa | Draudu uzraudzība, dalība grupās | Brīdinājumi klientam par aktuāliem draudiem |
Rezerves kopijas un atjaunošana: kur visbiežāk neizdodas
DORA prasa ne tikai rezerves kopijas, bet arī pierādījumu, ka no tām darbību var atjaunot noteiktā laikā. Iestādei jānosaka atjaunošanas laika un atjaunošanas punkta mērķi (RTO un RPO) katrai kritiskajai sistēmai, un rezerves kopijām jābūt fiziski un loģiski atdalītām no pamatvides.
Visbiežākā kļūda ir glabāt rezerves kopijas tajā pašā tīklā vai pie tā paša sniedzēja tajā pašā datu centrā. Izspiedējvīruss, kas šifrē serverus, šifrē arī tās. Otra kļūda ir atjaunošana, kas nekad nav pārbaudīta, un incidenta laikā izrādās, ka rezerves kopija ir nepilnīga vai ka atjaunošana aizņem dienas, nevis stundas.
Saviem klientiem piedāvājam nemaināmas rezerves kopijas, ko nevar mainīt un kas no tīkla nav redzamas, bet kritiskām sistēmām – PlanB infrastruktūras atjaunošanu, kad visu vidi var palaist mūsu mākonī, ja primārā vide kļūst nepieejama. Pēc pieprasījuma rezerves kopijas glabājam arī Amazon datu centrā Vācijā, lai ģeogrāfiskā atdalīšana būtu reāla, nevis tikai deklarēta.
Kā palīdz MDP CLOUD
Strādājam no abām pusēm: esam IT pakalpojumu sniedzējs finanšu iestādēm un palīdzam citiem IT sniedzējiem sagatavoties klientu prasībām. Mūsu komandai ir spēkā esoši ISACA sertifikāti (CISA, CISM, CRISC un citi), un pakalpojumus sniedzam saskaņā ar ISO 27001 prasībām, tāpēc atbildes uz klientu anketām mums jau ir sagatavotas.
Finanšu iestādei palīdzam izveidot IKT aktīvu un sniedzēju reģistrus, veikt risku novērtēšanu, sagatavot incidentu pārvaldības procedūru ar paziņojumu veidnēm, kā arī plānot un veikt noturības testus. IT pakalpojumu sniedzējam palīdzam sagatavot līguma papildinājumu, drošības politiku komplektu, iziešanas plāna veidni un tehniskos pierādījumus, ko pieprasīs klients.
No kā sākt
- Noskaidrojiet, vai DORA uz jums attiecas tieši (esat finanšu iestāde) vai caur klientiem (esat sniedzējs). No tā ir atkarīga darbu secība.
- Uzskaitiet savas kritiskās funkcijas un tās atbalstošās sistēmas un sniedzējus. Tas ir reģistra un risku novērtējuma pamats.
- Pārskatiet līgumus ar sniedzējiem vai klientiem un atzīmējiet, kuru nosacījumu trūkst.
- Pārbaudiet savas rezerves kopijas: kur tās atrodas, vai ir atdalītas no galvenā tīkla un kad tās pēdējo reizi reāli atjaunotas.
- Sagatavojiet incidentu paziņošanas procedūru ar kontaktiem un termiņiem, lai incidenta laikā neviens nemeklētu, kam zvanīt.
Pilnu ceļu no pirmā soļa līdz gatavībai uzraudzības iestādei aprakstījām DORA pakalpojuma lapā. Ja labāk vēlaties sākt ar sarunu, sazinieties ar mums, un pirmajā tikšanās reizē pateiksim, kuras prasības jums ir svarīgas un par kurām varat vairs neuztraukties.
