Kredītsabiedrība: DORA atbilstība un pārbaudīta PlanB atjaunošana 10 nedēļās

Kredītsabiedrībai bija nepieciešama atbilstība DORA: risku reģistrs, incidentu process un noturības testēšana. 10 nedēļās sagatavojām dokumentus, ieviesām PlanB atjaunošanu un pārbaudījām 4 stundu RTO.

Kredītsabiedrība: DORA atbilstība un pārbaudīta PlanB atjaunošana 10 nedēļās

Situācija

Kredītsabiedrība Šauļos, Lietuvā: 45 darbinieki, divas filiāles un internetbanka biedriem. IT vide ir neliela: daži serveri, ārēja piegādātāja mitināta pamata banku sistēma un Microsoft 365 e-pastam un dokumentiem. Par IT atbild viens cilvēks, kas administrēja arī daļu biznesa sistēmu.

DORA regula (ES 2022/2554) ir piemērojama kopš 2025. gada 17. janvāra, un kredītsabiedrības ietilpst tās darbības jomā. Plānotas pārbaudes laikā uzraudzības iestāde pieprasīja IKT risku pārvaldības ietvara dokumentus, incidentu reģistrēšanas procesu un pierādījumus par noturības testēšanu. Sabiedrībai bija iepriekšējo gadu risku novērtējums, dažas politikas un rezerves kopijas, kas tika veidotas, bet nekad netika atjaunotas no nulles.

Finanšu direktors vērsās pie mums ar konkrētu jautājumu: kas mums nepieciešams uz papīra un kas – īstenībā, lai pārbaudē netiktu konstatētas neatbilstības? Termiņš bija trīs mēneši, pirms atkārtotās tikšanās ar uzraudzības iestādi.

Kas bija nepieciešams

  • IKT risku reģistrs, kas saistīts ar biznesa procesiem un kritiskajām sistēmām.
  • Incidentu pārvaldības process ar klasifikāciju un termiņiem paziņošanai uzraudzības iestādei.
  • Trešo pušu (IKT pakalpojumu sniedzēju) reģistrs ar līgumu pārskatu un risku novērtējumu.
  • Strādājošs atjaunošanas plāns: ne tikai rezerves kopijas, bet pārbaudīta atjaunošana ar fiksētu laiku.
  • Noturības testēšanas programma, ko var atkārtot katru gadu bez ārējiem konsultantiem.
  • Viss tas ar mazas organizācijas resursiem un bez jauna darbinieka pieņemšanas.

Ko mēs izdarījām

1.–2. nedēļa: nepilnību analīze

Sākām ar esošo dokumentu un infrastruktūras pārskatīšanu pret DORA prasību karti. Sastādījām kritisko funkciju sarakstu: noguldījumu un aizdevumu uzskaite, maksājumi, biedru apkalpošana un pārskati uzraudzības iestādei. Katrai funkcijai piesaistījām sistēmas, pakalpojumu sniedzējus un atbildīgos cilvēkus. Izrādījās, ka pamata banku sistēmas piegādātāja līgumā nebija norādīts ne RTO, ne audita tiesības, un tas kļuva par atsevišķu darbu kopā ar sabiedrības juristu.

3.–5. nedēļa: risku reģistrs un procesi

Veicām risku novērtēšanu pēc savas metodikas, saskaņotas ar ISO 27001 prasībām un DORA IKT risku pārvaldības ietvaru. Reģistrā nonāca 38 riski, 7 no tiem augsti. Sagatavojām incidentu pārvaldības procedūru ar klasifikāciju, kas seko DORA loģikai nozīmīgu incidentu ziņošanai, un vienkāršu reģistrēšanas veidlapu Microsoft 365 vidē. Pakalpojumu sniedzēju reģistrā ir 14 IKT pakalpojumu sniedzēji, katram ar kritiskuma novērtējumu un līguma pārskata rezultātu.

Paralēli apmācījām darbiniekus: divu stundu sesijas par incidentu atpazīšanu un reģistrēšanu un atsevišķu sesiju vadībai par tās lomu atjaunošanas laikā. Tas ir svarīgi, jo DORA prasa ne tikai dokumentus, bet arī pierādījumus, ka cilvēki zina, ko darīt.

6.–8. nedēļa: PlanB atjaunošana

Tehniskā daļa bija PlanB infrastruktūras atjaunošana MDP CLOUD mākonī. Sabiedrības serveru rezerves kopijas jau tika veidotas ar Veeam, bet tikai uz lokālo glabātuvi. Pievienojām kopiju mūsu datu centrā Lietuvā un PlanB vidē sagatavojām iepriekš konfigurētu tīklu, VPN un domēna kontrolieri, lai atjaunošanas laikā nekas nebūtu jāveido no nulles. Sarežģītākā daļa bija pamata banku sistēma pie ārējā piegādātāja: tās atjaunošana ir atkarīga no piegādātāja, tāpēc plānā iekļāvām piegādātāja kontaktus, eskalācijas ceļu un līgumā noteikto RTO.

9.–10. nedēļa: mācības

Veicām divas atjaunošanas mācības. Pirmajā PlanB vidē atjaunojām failu serveri un domēna kontrolieri. Tas aizņēma 5 stundas, no kurām stunda tika zaudēta nepareiza DNS ieraksta dēļ. Procedūru izlabojām, un otrajās mācībās visas sabiedrības pārvaldītās sistēmas bija pieejamas 4 stundu laikā. Abas reizes fiksējām laiku, dalībniekus, problēmas un pieņemtos lēmumus, un tieši tādu atskaiti uzraudzības iestāde pieprasa.

Rezultāts

Sabiedrība iesniedza uzraudzības iestādei dokumentu komplektu: IKT risku reģistru, incidentu procedūru, pakalpojumu sniedzēju reģistru ar 14 novērtētiem sniedzējiem, darbības nepārtrauktības un atjaunošanas plānu un abu mācību atskaites. Atkārtotajā tikšanās reizē piezīmju par IKT risku pārvaldību nebija. Pamata banku sistēmas piegādātāja līgums tika grozīts, iekļaujot RTO saistību un audita tiesības. Tas ilga visilgāk, taču bez tā pakalpojumu sniedzēju reģistrs būtu palicis formalitāte.

Svarīgākais skaitlis ir 4 stundu RTO, kas nav solījums, bet izmērīts rezultāts. Mācības tagad notiek divreiz gadā pēc saskaņota kalendāra; nākamās jau ir ieplānotas kopā ar par IT atbildīgo cilvēku, mums piedaloties tikai kā novērotājiem.

„Līdz tam mums bija rezerves kopijas un mēs ticējām, ka tās darbojas. Tagad mums ir atskaite, kurā rakstīts, cik stundu tas aizņēma un kas nedarbojās.”

Mērījums ir vienkāršs: katras mācību atskaitē tiek fiksēts faktiskais atjaunošanas laiks, un risku reģistrs tiek pārskatīts katru ceturksni kopā ar mūsu DORA konsultantu.

Ko mēs ieteiktu līdzīgā situācijā

  • Sāciet ar kritiskajām funkcijām, nevis dokumentu veidnēm. Uzraudzības iestāde jautā, kas notiek ar biedriem, ja sistēma apstājas, nevis cik lappušu ir politikai.
  • IKT pakalpojumu sniedzēju līgumus pārbaudiet agri. Trūkstošu RTO vai audita tiesību saskaņošana prasa mēnešus.
  • Atjaunošanu pārbaudiet vismaz divreiz pirms iesniegšanas uzraudzības iestādei. Pirmajās mācībās gandrīz vienmēr atklājas kļūda, kuras plānā nebija.
  • Mācību atskaiti uzrakstiet tā, lai to saprastu valde: cik ilgi tas aizņēma, kas nedarbojās un kas tika mainīts.