DORA Lietuvoje taikomas nuo 2025 m. sausio 17 d. Finansų sektoriaus subjektui svarbu ne tik turėti IRT saugumo politiką, bet ir gebėti parodyti, kaip jis išlaikys paslaugas sutrikus sistemoms, valdys tiekėjų priklausomybes ir laiku praneš apie didelį incidentą. Atsakomybė neišnyksta todėl, kad infrastruktūra priklauso debesijos teikėjui arba visos grupės sistemas administruoja patronuojančioji bendrovė.
Šiame vadove aptariamas praktinis reglamento taikymas Lietuvos finansų subjektui. Teisinė ir Lietuvos banko skelbiama informacija patikrinta 2026 m. rugsėjo 28 d. Bendras DORA atitikties vadovas anglų kalba gali padėti tarptautinei komandai, tačiau Lietuvos ataskaitų kanalus, subjekto statusą ir priežiūros paskirstymą reikia vertinti atskirai.
Pirmiausia nustatykite, ar ir kaip DORA taikomas
Reglamento (ES) 2022/2554 2 straipsnyje išvardytos subjektų kategorijos. Tarp jų yra kredito, mokėjimo ir elektroninių pinigų įstaigos, investicinės įmonės, tam tikri fondų valdytojai, draudimo įmonės, sutelktinio finansavimo paslaugų teikėjai ir pagal MiCA leidimą gavę kriptoturto paslaugų teikėjai. Vien pavadinimas „fintech“ nepasako, kuri kategorija taikoma. Reikia susieti juridinį asmenį, turimą leidimą ir faktiškai teikiamas paslaugas.
Reglamentas numato ir konkrečias išimtis. Pavyzdžiui, 2 straipsnio 3 dalyje išskiriami tam tikri alternatyviųjų investicinių fondų valdytojai, nedideli profesinių pensijų subjektai ir draudimo tarpininkai, kurie yra labai mažos, mažos ar vidutinės įmonės. Todėl teiginys, kad DORA vienodai taikomas visoms finansų įmonėms, būtų netikslus. Išimtį reikia pagrįsti atitinkama kategorija ir jos sąlygomis, o ne vien mažu darbuotojų skaičiumi.
Proporcingumas pagal 4 straipsnį siejamas su dydžiu, bendru rizikos profiliu, paslaugų pobūdžiu, mastu ir sudėtingumu. Jis leidžia pritaikyti priemones, tačiau pats savaime nesuteikia teisės pasirinkti bet kokį supaprastintą režimą. 16 straipsnio supaprastinta IRT rizikos valdymo sistema skirta jame nurodytoms kategorijoms, įskaitant mažas ir tarpusavyje nesusijusias investicines įmones bei tam tikras išimtis turinčias mokėjimo ir elektroninių pinigų įstaigas.
Praktinis rezultatas turėtų būti trumpas taikymo sprendimas: kuri kategorija nustatyta, kokios išimtys išnagrinėtos, ar taikomas 16 straipsnis ir kokios pareigos lieka. Grupėje šis vertinimas atliekamas kiekvienam juridiniam asmeniui. Vienos licencijuotos bendrovės išvada nebūtinai tinka jos technologijų paslaugų bendrovei ar kitoje valstybėje veikiančiam subjektui.
Lietuvos bankas ir Europos priežiūros institucijos
Lietuvos banko DORA skiltis pateikia vietos ataskaitų teikimo informaciją, techninius dokumentus ir nuorodas į papildomus ES aktus. Lietuvos banko prižiūrimas subjektas turėtų turėti atsakingą asmenį, kuris seka šių reikalavimų pasikeitimus ir palaiko prieigą prie reikiamų sistemų. Tai ypač svarbu, kai teikimo veiksmus atlieka grupės darbuotojas užsienyje.
Vis dėlto Lietuvos banko nereikėtų vadinti vienintele institucija, atsakinga už visus DORA subjektus ir visas pareigas. 46 straipsnyje kompetencija paskirstyta pagal sektorių, įskaitant ECB vaidmenį reikšmingų kredito įstaigų priežiūroje. Kritinių IRT trečiųjų šalių paslaugų teikėjų priežiūrai taikoma atskira Europos priežiūros institucijų sistema. Finansų įmonės priežiūra ir jos paslaugų teikėjo priežiūra yra susijusios, bet skirtingos funkcijos.
Incidentų atveju 19 straipsnis nustato pranešimą atitinkamai kompetentingai institucijai. Reikšmingų kredito įstaigų pranešimai pagal šį straipsnį teikiami atitinkamai nacionalinei institucijai ir perduodami ECB. Todėl prieš incidentą verta sudaryti savo subjekto gavėjų bei kanalų schemą, užuot krizės metu spėjus, ar reikia kreiptis tiesiogiai į kiekvieną Europos instituciją.
Valdymas prasideda nuo finansinės paslaugos
Įprasto DORA režimo 5 straipsnis suteikia valdymo organui atsakomybę už IRT rizikos valdymo sistemos nustatymą, patvirtinimą, priežiūrą ir įgyvendinimą. Valdyba turi suprasti, kokių paslaugų sutrikimas labiausiai paveiktų klientus, kokia rizika priimtina ir kokių išteklių reikia jai valdyti. Šios pareigos negalima įvykdyti vien persiuntus techninę ataskaitą informacinių technologijų vadovui.
Pradinis žemėlapis turėtų jungti paslaugą su ją palaikančiomis sistemomis, duomenimis, darbuotojais ir tiekėjais. Pavyzdžiui, mokėjimų vykdymas gali priklausyti nuo autentifikavimo, klientų duomenų bazės, ryšio su partneriu ir vidinių patvirtinimo teisių. Atskirai veikianti atsarginė duomenų bazė nepadės, jeigu darbuotojai negalės prisijungti prie atkurtos aplinkos arba nebus aišku, kurie pavedimai jau įvykdyti.
Dokumentuose reikia suderinti toleruojamą sutrikimo poveikį, atkūrimo prioritetus ir realias technines galimybes. Tai reiškia, kad verslo savininkas ir techninė komanda turi sutarti dėl priimtino duomenų praradimo bei paslaugos atkūrimo. Skaičius atkūrimo plane nėra įrodymas, kad tikslas pasiekiamas; jam pagrįsti reikia bandymo rezultatų ir nustatytų trūkumų taisymo.
Valdymo organui naudingesnė aiški neišspręstų rizikų apžvalga negu vien žali pažangos žymekliai. Jei tiekėjas negali atkurti paslaugos per nustatytą laiką, turi būti matomas sprendimas: mažinti priklausomybę, keisti architektūrą, derėtis dėl sąlygų arba pagrįstai persvarstyti tikslą. Priimta rizika turėtų turėti atsakingą asmenį ir peržiūros momentą.
Informacijos registras nėra vien tiekėjų sąrašas
DORA 28 straipsnio 3 dalis reikalauja tvarkyti ir atnaujinti informaciją apie visus sutartinius susitarimus dėl IRT paslaugų naudojimo, atskiriant paslaugas, palaikančias ypatingos svarbos ar svarbias funkcijas. Registras tvarkomas subjekto ir, kai taikoma, subkonsoliduotu bei konsoliduotu lygmenimis. Vien svarbiausių debesijos sutarčių sąrašo nepakanka, jei kiti susitarimai taip pat patenka į šią apimtį.
Registrui reikia patikimų ryšių tarp sutarties, paslaugos, tiekėjo ir naudojančio subjekto. Vienas tiekėjas gali teikti kelias skirtingas paslaugas; viena sutartis gali apimti kelias grupės įmones. Jei šie ryšiai neišskiriami, klaidingai įvertinama tiek koncentracija, tiek paveiktų funkcijų mastas. Pirkimų duomenys padeda rasti sutartis, bet paprastai nepaaiškina jų svarbos finansinei veiklai.
Reglamentas numato bent metinį tam tikros informacijos apie naujus susitarimus teikimą ir viso registro ar jo dalių pateikimą institucijai paprašius. Tai reikia atskirti nuo konkretaus Lietuvos banko surinkimo. Lietuvos bankas 2026 m. informaciją pagal 2025 m. gruodžio 31 d. duomenis prašė pateikti kovo 16–balandžio 3 d. imtinai, individualiu lygmeniu. Tai jau praėjęs konkretus laikotarpis, o ne automatiškai kiekvieniems būsimiems metams galiojantis terminas.
To paties 2026 m. surinkimo instrukcijose nurodyta REGATA sistema, xBRL-csv formatas ir subjekto LEI kodas. Šiuos teikimo reikalavimus reikia derinti su galiojančiais registro šablonais ir tikrinimo taisyklėmis. Sėkmingas failo priėmimas parodo techninį pateikimą, tačiau neįrodo, kad klasifikacija ar sutartinių ryšių turinys teisingi. Prieš teikimą verta sutikrinti registrą su pirkimų, teisės ir veiklos savininkų informacija.
Tiekėjo sutartis turi veikti sutrikimo metu
Pagal 28 straipsnį finansų subjektas išlieka atsakingas už savo DORA pareigų laikymąsi. Tiekėjo sertifikatas, audito ataskaita ar sutartinis pažadas gali būti įrodymų dalis, tačiau nepakeičia pasirinkimo ir stebėsenos. Reikia žinoti, kas nutiktų tiekėjui sustabdžius paslaugą, pakeitus subrangovą arba apribojus duomenų eksportą.
30 straipsnyje atskiriami bendri sutartiniai reikalavimai ir papildomos sąlygos paslaugoms, palaikančioms ypatingos svarbos ar svarbias funkcijas. Bendri klausimai apima paslaugų aprašymą, teikimo bei duomenų tvarkymo vietas, duomenų apsaugą, prieigą ir grąžinimą, pagalbą incidento metu, bendradarbiavimą su institucijomis bei nutraukimą. Svarbioms funkcijoms papildomai reikšmingi tikslūs paslaugos rodikliai, auditai, testavimas ir perėjimo sąlygos.
Sutartyje pažadėta pagalba neturi likti neaiški. Finansų subjektui reikia suprasti, kaip greitai bus gauta pradinė informacija, kas pateiks žurnalus ir kas padės nustatyti paveiktas paslaugas. Teisinio pranešimo terminas gali pradėti eiti anksčiau, nei tiekėjas parengs galutinę priežasties analizę. Todėl incidentų bendradarbiavimą verta aptarti atskirai nuo įprastų klientų aptarnavimo užklausų.
Koncentracijos vertinimas pagal 29 straipsnį taip pat negali apsiriboti tiekėjų pavadinimų skaičiavimu. Du skirtingi partneriai gali naudoti tą pačią infrastruktūrą ar priklausyti tai pačiai grupei. 28 straipsnio 8 dalies išėjimo strategijai, kai ji taikoma svarbias funkcijas palaikančioms paslaugoms, reikia alternatyvos, pereinamojo laikotarpio ir patikrinamo duomenų perkėlimo. Vien galimybė nutraukti sutartį paslaugos tęstinumo neužtikrina.
Incidento klasifikavimas ir tikslūs terminai
DORA atskiria IRT incidentą, didelį IRT incidentą ir didelę kibernetinę grėsmę. Pranešimas apie didelę grėsmę pagal 19 straipsnį gali būti savanoriškas, o didelis incidentas patenka į privalomo pranešimo procesą. Klasifikavimas remiasi 18 straipsniu ir deleguotojo reglamento 2024/1772 kriterijais bei ribomis. Vien tai, kad darbuotojai įvykį pavadino kritiniu techniniame biliete, dar neišsprendžia teisinės klasifikacijos.
Deleguotojo reglamento (ES) 2025/301 5 straipsnyje pradinis pranešimas reikalaujamas kuo anksčiau, bet per keturias valandas nuo priskyrimo dideliam IRT incidentui ir ne vėliau kaip per 24 valandas nuo sužinojimo apie IRT incidentą. Jei incidentas per pirmas 24 valandas nebuvo priskirtas dideliam, tačiau taip klasifikuojamas vėliau, taikoma atskira taisyklė: keturios valandos nuo vėlesnio klasifikavimo.
Tarpinis pranešimas pateikiamas ne vėliau kaip per 72 valandas nuo pradinio pranešimo, net jei incidento būklė ar valdymas nepasikeitė. Atnaujintas tarpinis pranešimas teikiamas nepagrįstai nedelsiant ir bet kuriuo atveju atkūrus įprastą veiklą. Galutinis pranešimas teikiamas ne vėliau kaip per mėnesį nuo tarpinio arba, kai taikoma, paskutinio atnaujinto tarpinio pranešimo. Tai skirtingi atskaitos taškai, kuriuos sistemoje reikia saugoti atskirai.
Savaitgalių ir švenčių taisyklė nėra visuotinė. 5 straipsnio 4 dalis leidžia tam tikrais atvejais pateikti pranešimą iki kitos darbo dienos vidurdienio, tačiau pradiniams ir tarpiniams pranešimams nustatytos išimtys kredito įstaigoms, pagrindinėms sandorio šalims, prekybos vietų operatoriams ir atitinkamiems NIS2 esminiams ar svarbiems subjektams. Kompetentinga institucija gali šios lengvatos netaikyti ir kitiems reikšmingiems subjektams, apie tai juos informavusi. Todėl budėjimo grafiko negalima kurti remiantis prielaida, kad savaitgalį pranešti nereikės.
Negalint laikytis termino, institucija informuojama nepagrįstai nedelsiant, bet ne vėliau kaip iki atitinkamo termino, paaiškinant vėlavimą. Tai nėra automatinis leidimas atidėti pateikimą. Lietuvos bankas skelbia REGATA formas ir technines taisykles; prieigas, pavaduojančius asmenis ir veiksmus neveikiant įprastam kanalui būtina parengti iš anksto.
Incidento eiga turi būti atkuriama iš faktų
Tarkime, mokėjimo įstaiga pastebi, kad dalis klientų negali patvirtinti pavedimų, o tiekėjas praneša tiriantis ryšio sutrikimą. Pirmiausia reikia fiksuoti, kada įstaiga sužinojo apie incidentą, kokios paslaugos ir klientai paveikti bei kokia informacija tuo metu buvo žinoma. Atskirai užrašomas sprendimas dėl didelio incidento klasifikavimo ir jo pagrindas. Pradinė tiekėjo žinutė gali būti svarbi, tačiau ji nepakeičia pačios įstaigos vertinimo.
Jei vėliau paaiškėja platesnis poveikis, klasifikacija peržiūrima remiantis naujais duomenimis. Chronologijoje turi matytis, kada tie duomenys gauti ir kas priėmė naują sprendimą. Taip galima paaiškinti vėlyvą klasifikavimą, jo nepaverčiant dirbtiniu būdu atidėti pranešimą. Komanda turėtų išsaugoti ir ankstesnius vertinimus, o ne perrašyti juos pagal galutinę išvadą taip, kad nebeliktų sprendimų sekos.
Tarpiniam pranešimui gali reikėti duomenų iš klientų aptarnavimo, operacijų ir techninių komandų. Vienas atsakingas asmuo turėtų suderinti skaičiavimo metodą, kad paveiktų klientų ar operacijų skaičius nebūtų sumuojamas kelis kartus. Nežinomus rodiklius geriau aiškiai pažymėti ir vėliau atnaujinti, negu pateikti nepagrįstai tikslius skaičius. Pranešimų versijas bei pateikimo patvirtinimus verta susieti su tuo pačiu incidento įrašu.
Atkūrus ryšį, dar reikia patikrinti neįvykdytus ar galimai pasikartojusius pavedimus, suderinti klientų informavimą ir įvertinti likutinį poveikį. Techninis sistemos pasiekiamumas ne visada reiškia, kad įprasta veikla visiškai atkurta. Galutinė analizė turėtų parodyti priežastį, pritaikytas priemones ir atsakingus už likusį taisymą. Šis hipotetinis pavyzdys yra darbo organizavimo paaiškinimas; ar konkretus įvykis didelis, sprendžiama pagal taikomus teisinius kriterijus, o ne pagal vieną jo aprašymo požymį.
Testavimas ir TLPT turi skirtingą apimtį
24 straipsnis numato išsamią skaitmeninio atsparumo testavimo programą subjektams, kurie nėra labai mažos įmonės. Šiems subjektams bent kasmet turi būti tinkamai testuojamos IRT sistemos ir taikomosios programos, palaikančios ypatingos svarbos ar svarbias funkcijas. Labai mažoms įmonėms 25 straipsnio 3 dalyje numatytas atskiras, rizika ir ištekliais pagrįstas testavimo požiūris. Mažas dydis nereiškia, kad atkūrimo ar kitų svarbių priemonių veikimo galima visai netikrinti.
TLPT yra pažangus grėsmėmis grindžiamas skverbimosi testavimas. Pagal 26 straipsnį jis taikomas kompetentingos institucijos atrinktiems subjektams, su šiame straipsnyje numatytomis išimtimis labai mažoms įmonėms ir 16 straipsnio kategorijoms. Atranka remiasi poveikiu finansų sektoriui, finansinio stabilumo klausimais, IRT rizikos profiliu ir technologine branda. Tai nėra vien įmonės sprendimas pasivadinti kritine.
Atrinkti subjektai tokį testavimą atlieka bent kas trejus metus; institucija pagal riziką ir veiklos aplinkybes gali keisti dažnumą. Apimtis siejama su realiomis svarbiomis funkcijomis ir jas palaikančiomis veikiančiomis sistemomis. Tiekėjų dalyvavimas, testavimo rizikos kontrolė ir trūkumų taisymas yra proceso dalis. Įprastas pažeidžiamumų skenavimas savaime nėra užbaigtas TLPT.
Vertę sukuria patikrintas taisymas. Aptikus, kad atsarginė kopija atkuriama, bet naudotojų teisės neveikia, reikia taisyti atkūrimo grandinę ir pakartoti atitinkamą bandymą. Dokumentuose turi būti matoma, kas priėmė rezultatą ir kokie trūkumai liko. Vien užsakytos testavimo paslaugos sąskaita neparodo, kad paslauga atkuriama saugiai.
DORA, BDAR ir NIS2 sprendimai nesusilieja
DORA 1 straipsnio 2 dalis nustato jo, kaip specialiojo sektoriaus ES akto, santykį su NIS2 4 straipsniu atitinkamiems finansų subjektams. Todėl iš vieno DORA incidento negalima automatiškai daryti išvados apie privalomą trečią pranešimą NKSC pagal NIS2. NIS2 Lietuvoje vadovas padeda atskirai įvertinti subjektą ir veiklą, kuri gali nepatekti į tą patį specialųjį režimą.
BDAR lieka atskira asmens duomenų apsaugos sistema. IRT sutrikimas nebūtinai yra asmens duomenų saugumo pažeidimas, o tokio pažeidimo pranešimas priklauso nuo rizikos. Pagal BDAR 33 straipsnį pranešama nepagrįstai nedelsiant ir, jei įmanoma, per 72 valandas nuo sužinojimo, nebent mažai tikėtina rizika žmonių teisėms ir laisvėms. Vėluojant paaiškinamos priežastys; visi asmens duomenų saugumo pažeidimai dokumentuojami. Didelė rizika reikalauja atskiro 34 straipsnio vertinimo dėl žmonių informavimo.
Lietuvos subjektui aktuali VDAI kompetencija, tačiau tarpvalstybinėje situacijoje reikia įvertinti kompetentingos duomenų apsaugos institucijos taisykles. Pranešimo per 72 valandas eiga ir duomenų pažeidimų valdymo procedūra papildo DORA incidento chronologiją. Bendri faktai gali būti naudojami keliems vertinimams, bet kiekvieno teisinio sprendimo pagrindas turi likti aiškus.
Jeigu tiekėjas tvarko asmens duomenis finansų subjekto vardu, papildomai vertinamas BDAR 28 straipsnio susitarimas. DORA sutarties sąlygos jo automatiškai nepakeičia. Taip pat duomenų tvarkymo veiklos įrašai aprašo kitą objektą negu DORA IRT registras: asmens duomenų tvarkymo veiklą, o ne vien IRT sutartinius santykius.
Kaip palaikyti atitiktį po pirmojo pateikimo
Užbaigtas projektas neturėtų reikšti užrakinto dokumentų katalogo. Naujas tiekėjas, papildoma finansinė paslauga, įsigijimas ar pasikeitusi sistemos architektūra gali pakeisti registro informaciją, riziką ir incidentų poveikį. Praktiškai verta susieti pirkimo ir pokyčių patvirtinimą su pareiga atnaujinti atitinkamus įrašus. Taip informacija atnaujinama tada, kai priimamas sprendimas, o ne tik prieš institucijos užklausą.
Renkantis DORA dokumentavimo programinę įrangą, verta tikrinti versijų istoriją, prieigos ribojimą, ryšius tarp tiekėjų ir funkcijų bei eksportą pagal reikiamą formatą. Priemonė gali palengvinti darbą, tačiau pati nenustato teisinės kategorijos, neįvertina visų rizikų ir negarantuoja atitikties. Platesnis duomenų apsaugos Lietuvoje kontekstas padeda išlaikyti sąsajas su kitomis pareigomis, jų nesuplakant.
Ar pakanka BDAR saugumo dokumentų?
Ne. Jie gali pagrįsti dalį bendrų priemonių, tačiau DORA atskirai reglamentuoja finansinių paslaugų atsparumą, IRT sutartis, registrą, incidentų klasifikavimą ir testavimą. Reikia nustatyti likusias spragas ir jų savininkus.
Ar maža įmonė gali pasirinkti supaprastintą režimą?
Vien mažumo nepakanka. Reikia patikrinti 2 straipsnio taikymo ribas, 16 straipsnio kategorijas ir konkrečių nuostatų išimtis labai mažoms įmonėms. Proporcingumas taikomas pagal faktinę riziką ir paslaugų sudėtingumą.
Ar Lietuvos bankui pateiktas pranešimas pakeičia BDAR pranešimą?
Ne. Asmens duomenų pažeidimo pobūdis, rizika ir kompetentinga institucija vertinami atskirai. Bendra incidento byla gali padėti pateikti nuoseklius faktus, bet nepanaikina skirtingų pareigų ir terminų.