Olukord
Krediidiliit Šiauliais, Leedus: 45 töötajat, kaks kontorit ja liikmetele internetipank. IT-keskkond on väike: mõned serverid, välise tarnija majutatav põhipangandussüsteem ning Microsoft 365 e-posti ja dokumentide jaoks. IT eest vastutab üks inimene, kes haldas ka osa ärisüsteeme.
DORA määrus (EL 2022/2554) kehtib alates 17. jaanuarist 2025 ja krediidiliidud kuuluvad selle reguleerimisalasse. Plaanilise kontrolli käigus küsis järelevalveasutus IKT riskijuhtimise raamistiku dokumente, intsidentide registreerimise protsessi ja tõendeid vastupidavuse testimise kohta. Liidul oli varasemate aastate riskihindamine, mõned poliitikad ning varukoopiad, mida tehti, kuid mida polnud kunagi nullist taastatud.
Finantsdirektor pöördus meie poole konkreetse küsimusega: mida on vaja paberil ja mida tegelikkuses, et kontrollil ei leitaks rikkumisi? Tähtaeg oli kolm kuud, enne järelevalvega toimuvat järelkohtumist.
Mida oli vaja
- IKT riskiregister, mis on seotud äriprotsesside ja kriitiliste süsteemidega.
- Intsidentide haldamise protsess klassifikatsiooni ja järelevalveasutuse teavitamise tähtaegadega.
- Kolmandate osapoolte (IKT teenusepakkujate) register koos lepingute ülevaatuse ja riskihindamisega.
- Töötav taasteplaan: mitte ainult varukoopiad, vaid testitud taaste fikseeritud ajaga.
- Vastupidavuse testimise programm, mida saab igal aastal korrata ilma väliskonsultantideta.
- Kõik see väikese organisatsiooni ressurssidega ja ilma uue töötaja palkamiseta.
Mida me tegime
Nädalad 1–2: lünkade analüüs
Alustasime olemasolevate dokumentide ja taristu läbivaatamisest DORA nõuete kaardi suhtes. Koostasime kriitiliste funktsioonide nimekirja: hoiuste ja laenude arvestus, maksed, liikmete teenindus ning aruandlus järelevalveasutusele. Igale funktsioonile määrasime süsteemid, teenusepakkujad ja vastutavad inimesed. Selgus, et põhipangandussüsteemi tarnija lepingus puudus nii RTO kui ka auditiõigus, millest sai liidu juristiga eraldi töölõik.
Nädalad 3–5: riskiregister ja protsessid
Viisime läbi riskihindamise oma metoodika järgi, mis on kooskõlas ISO 27001 nõuete ja DORA IKT riskijuhtimise raamistikuga. Registrisse jõudis 38 riski, neist 7 kõrget. Koostasime intsidentide haldamise korra klassifikatsiooniga, mis järgib DORA loogikat olulistest intsidentidest teavitamisel, ning lihtsa registreerimisvormi liidu Microsoft 365 keskkonnas. Teenusepakkujate registris on 14 IKT teenusepakkujat, igaühel kriitilisuse hinnang ja lepingu ülevaatuse tulemus.
Paralleelselt koolitasime töötajaid: kahetunnised sessioonid intsidentide tuvastamisest ja registreerimisest ning eraldi sessioon juhtkonnale selle rollist taaste ajal. See on oluline, sest DORA nõuab mitte ainult dokumente, vaid ka tõendeid, et inimesed teavad, mida teha.
Nädalad 6–8: PlanB taaste
Tehniline osa oli PlanB taristu taastamine MDP CLOUD pilves. Liidu serverite varukoopiaid tehti juba Veeamiga, kuid ainult kohalikku salvestusse. Lisasime koopia meie andmekeskusesse Leedus ning PlanB keskkonnas valmistasime ette eelseadistatud võrgu, VPN-i ja domeenikontrolleri, et taaste ajal ei peaks midagi nullist ehitama. Kõige keerulisem oli põhipangandussüsteem välisel tarnijal: selle taaste sõltub tarnijast, seega lisasime plaani tarnija kontaktid, eskalatsiooniahela ja lepingulise RTO.
Nädalad 9–10: taastekatsed
Viisime läbi kaks taastekatset. Esimeses taastasime failiserveri ja domeenikontrolleri PlanB keskkonnas. See võttis 5 tundi, millest tund kadus vale DNS-kirje tõttu. Parandasime korra ja teises katses olid kõik liidu hallatavad süsteemid kättesaadavad 4 tunni jooksul. Mõlemal korral fikseerisime aja, osalejad, probleemid ja tehtud otsused, ning just sellist aruannet järelevalve küsib.
Tulemus
Liit esitas järelevalveasutusele dokumendikomplekti: IKT riskiregister, intsidentide kord, teenusepakkujate register 14 hinnatud teenusepakkujaga, tegevuspidevuse ja taasteplaan ning mõlema katse aruanded. Järelkohtumisel ei olnud IKT riskijuhtimise kohta märkusi. Põhipangandussüsteemi tarnija lepingut muudeti, lisades RTO kohustuse ja auditiõiguse. See võttis kõige kauem aega, kuid ilma selleta oleks teenusepakkujate register jäänud formaalsuseks.
Kõige olulisem number on 4-tunnine RTO, mis ei ole lubadus, vaid mõõdetud tulemus. Katsed toimuvad nüüd kaks korda aastas kokkulepitud kalendri järgi; järgmine on IT eest vastutava inimesega juba paigas ja meie osaleme ainult vaatlejatena.
„Seni oli meil varukoopiad ja me uskusime, et need töötavad. Nüüd on meil aruanne, mis ütleb, mitu tundi see võttis ja mis ei töötanud.“
Mõõtmine on lihtne: iga katse aruandes on fikseeritud tegelik taasteaeg ning riskiregistrit vaadatakse iga kvartal üle koos meie DORA konsultandiga.
Mida soovitaksime sarnases olukorras
- Alustage kriitilistest funktsioonidest, mitte dokumendimallidest. Järelevalve küsib, mis saab liikmetega, kui süsteem seiskub, mitte seda, mitu lehekülge poliitikal on.
- Kontrollige IKT teenusepakkujate lepinguid varakult. Puuduva RTO või auditiõiguse läbirääkimine võtab kuid.
- Testige taastet vähemalt kaks korda enne järelevalvele esitamist. Esimene katse toob peaaegu alati välja vea, mida plaanis polnud.
- Kirjutage katse aruanne nii, et juhatus sellest aru saaks: aeg, mis ei töötanud, mida muudeti.
