Geriausia DORA programinė įranga konkrečiam Lietuvos finansų subjektui yra ta, kuri padeda įvykdyti jam taikomas pareigas ir pateikia patikrinamus darbo rezultatus. Vienas įrankis gali būti skirtas IRT sutarčių registrui, kitas incidentams ar rizikos valdymui. Užrašas „DORA atitiktis“ savaime neįrodo, kad pasiūlymas apima visus šiuos procesus arba Lietuvos bankui tinkamą ataskaitą.
Šis pirkėjo vadovas padeda parengti reikalavimus, demonstracijos scenarijų ir priėmimo kriterijus. Lietuvos pateikimo sąlygos patikrintos 2026 m. rugsėjo 27 d. Nurodytas 2026 m. registro teikimo laikotarpis jau pasibaigęs: jis naudojamas kaip konkretaus ataskaitos ciklo pavyzdys, o ne būsimo termino pažadas. Kito ciklo reikalavimus reikia tikrinti pagal naują oficialią informaciją.
Pirmiausia nustatykite subjekto ir pirkimo apimtį
DORA reglamentas (ES) 2022/2554 taikomas nuo 2025 m. sausio 17 d. Jis apima konkrečias finansų subjektų kategorijas, tačiau numato ir išimtis. Bankas, mokėjimo įstaiga, draudikas ir draudimo tarpininkas neturėtų būti vertinami pagal vieną nepatikrintą klausimyną. Pirkimo reikalavimai turi remtis tikruoju licenciniu statusu ir veikla.
DORA 2 straipsnyje, be kitų išimčių, numatyti labai maži, maži ir vidutiniai draudimo, perdraudimo ir papildomos draudimo veiklos tarpininkai. Atskirai reglamentuojama supaprastinta IRT rizikos valdymo sistema konkrečioms subjektų kategorijoms. Supaprastinimas nėra visoms mažoms įmonėms pasirenkamas planas, o išimtis iš DORA neleidžia automatiškai daryti išvados, kad nelieka kitų nacionalinių pareigų.
Dokumentuokite taikymo išvadą, nagrinėtas normas ir atsakingą asmenį. Jei įmonė priklauso grupei, atskirai nustatykite kiekvieno juridinio asmens poreikius. Grupės naudojama platforma gali būti tinkama bendram valdymui, bet vietinės ataskaitos ribos turi sutapti su Lietuvos reikalavimais. Platesnį teisinį kontekstą padeda įvertinti DORA Lietuvoje vadovas.
Lietuvos banko įstatymo pakeitimas Nr. XV-293 numato Lietuvos bankui DORA kompetentingos institucijos funkcijas. Todėl nereikia laukti būsimo reglamento perkėlimo kaip direktyvos. Vis dėlto atskiri nacionaliniai priežiūros ir pateikimo klausimai svarbūs, o kompetencijos ribos vertinamos kartu su reglamento 46 straipsniu ir atitinkama Europos priežiūros sistema.
Atskirkite finansų subjektą nuo IRT tiekėjo
Paprastas programinės įrangos tiekėjas vien dėl darbo bankui netampa DORA finansų subjektu. Jam gali būti nustatytos kliento sutartinės informavimo, pagalbos ar audito pareigos. Tai skiriasi nuo paties finansų subjekto valdymo organo atsakomybės ir pareigos priimti sprendimus dėl IRT rizikos. Sutartyje šias ribas būtina suprasti abiem šalims.
DORA taip pat numato atskirą kritinės svarbos IRT trečiųjų šalių paslaugų teikėjų priežiūrą, kai jie nustatomi pagal reglamento procedūrą. Toks statusas nėra automatiškai suteikiamas kiekvienam debesijos ar atitikties įrankio pardavėjui. Pasiūlyme prašykite tiksliai paaiškinti, ką reiškia tiekėjo vartojama atitikties formuluotė ir kokie dokumentai ją pagrindžia.
Finansų subjektas išlieka atsakingas, net jei registro parengimą arba techninį pateikimą perduoda paslaugų teikėjui. Pirkimo dokumentuose verta atskirti duomenų pateikimą, jų patikrinimą, galutinį patvirtinimą ir techninį perdavimą. Prie kiekvieno veiksmo turi būti aiškus atsakingasis ir rezultatas, kurį galima patikrinti nepriklausomai nuo tiekėjo žodinio patvirtinimo.
Jeigu lyginate platesnes atitikties platformas, naudokite dokumentuoto tiekėjų palyginimo metodą. BDAR dokumentavimo galimybės savaime neįrodo DORA registro, TLPT ar priežiūros ataskaitų palaikymo. Kiekvieną reikalingą darbo eigą vertinkite atskirai pagal demonstraciją, techninę specifikaciją ir sutartyje nurodytą apimtį.
Registro duomenų modelis turi atspindėti susitarimus
DORA 28 straipsnio informacijos registras apima sutartimi įformintus susitarimus dėl IRT paslaugų naudojimo. Tiekėjų kontaktų lentelė gali būti pradinis šaltinis, bet ne visas registras. Reikia tinkamai susieti juridinius asmenis, susitarimus, teikiamas paslaugas ir palaikomas funkcijas, atskiriant ypatingos svarbos arba svarbioms funkcijoms reikšmingus susitarimus.
Demonstracijai parenkite pavyzdį, kuriame vienas tiekėjas turi kelias sutartis, o viena sutartis apima daugiau nei vieną paslaugą. Patikrinkite, ar sistema išlaiko šias sąsajas ir nekuria klaidinančių dublikatų. Vienas laisvo teksto laukas „paslaugos aprašymas“ gali būti patogus skaitymui, bet nepakankamas struktūrizuotai ataskaitai su tarpusavio nuorodomis.
Kritiškumo vertinimą susiekite su finansų subjekto funkcija ir galimomis sutrikimo pasekmėmis. Populiarus tiekėjas nėra automatiškai vienodai kritiškas visoms jo paslaugoms. Prašykite parodyti, kas patvirtina klasifikaciją, kokiu pagrindu ir kaip sprendimas peržiūrimas pasikeitus paslaugai. Programos pasiūlyta kategorija turi likti patikrinama, o ne tapti nepaaiškinamu galutiniu atsakymu.
Duomenų šaltiniams suteikite savininkus. Pirkimų komanda gali žinoti sutarties terminą, IT komanda technines priklausomybes, o veiklos vadovas sutrikimo poveikį. Įrankis turėtų padėti surinkti šias dalis ir parodyti nesuderintas reikšmes. Automatinis importas nepakeičia sprendimo, kuri iš dviejų prieštaraujančių datų ar kategorijų teisinga.
Lietuvos 2026 m. REGATA scenarijus
Lietuvos banko DORA informacijoje nurodyta, kad 2026 m. IRT registrų informacija buvo teikiama kovo 16–balandžio 3 d. imtinai pagal 2025 m. gruodžio 31 d. duomenis. Tais metais teikimo lygmuo buvo individualus, net jei finansų subjektas priklausė grupei. Latvijos ar kitos šalies terminų negalima automatiškai perkelti Lietuvos subjektui.
Registro informacija teikiama REGATA tik xBRL-csv formatu. Lietuvos bankas nurodo finansų subjekto LEI kodą pateikti ir ataskaitoje, ir jos pavadinime. Jei ataskaitoje yra klaidų, ji teikiama iš naujo, nes šių ataskaitų negalima rankiniu būdu patikslinti pačioje REGATA. Tai konkretūs kriterijai, kuriuos tiekėjas turi gebėti pademonstruoti.
Pirkimo scenarijuje paprašykite parengti ataskaitą vienam pasirinktam juridiniam asmeniui pagal nurodytą ataskaitinę datą. Po to pakeiskite vieną klaidingą duomenį ir pakartokite eksportą. Reikia suprasti, kur atliekamas taisymas, kaip išlaikoma ankstesnė versija ir kaip išvengiama netyčinio kito grupės subjekto informacijos įtraukimo.
Prie eksporto prašykite patikrinimo rezultato ir paaiškinimo, kurią taksonomijos bei taisyklių versiją jis naudoja. Paprastas CSV failas nėra tas pats, kas reikalaujamas ataskaitos paketas. Techninis formatas ir teisingi ryšiai tarp duomenų turi būti vertinami kartu. Sėkmingas vietinis patikrinimas taip pat neturėtų būti painiojamas su faktiniu ataskaitos priėmimu priežiūros sistemoje.
Atskirkite eksportą nuo pateikimo paslaugos
Lietuvos banko REGATA puslapis aprašo priežiūros ataskaitų surinkimo sistemą. Pirkėjui svarbu išsiaiškinti, ar siūloma programa tik parengia failą, ar turi atskirą sutartą pateikimo funkciją. Jei pateikimą vykdo pats klientas, sutartyje neturėtų likti dviprasmiško pažado, kad pardavėjas „pasirūpins ataskaita“.
Nustatykite naudotojų teises ir pavaduotoją. Net tinkamai sugeneruotas paketas nebus pateiktas laiku, jei vienintelis įgaliotas žmogus neturi prieigos arba negali prisijungti. Prieš priėmimą patikrinkite organizacinę grandinę: kas patvirtina duomenis, kas pateikia, kas patikrina rezultatą ir kas ištaiso grįžtamajame pranešime nurodytas klaidas.
Bandymų aplinka leidžia įvertinti pateikimo parengtį, tačiau nereikia joje naudoti perteklinių tikrų duomenų. Pasirinkite tinkamai parengtą bandymo medžiagą ir sutarkite, kas saugo rezultatus. Bandymas nėra leidimas nepranešus pateikti tikrą ataskaitą. Galutinis veiksmas turi priklausyti įgaliotam subjektui ir jo patvirtintam procesui.
Reikalaukite aiškaus pakeitimų valdymo, kai keičiasi oficiali taksonomija ar tikrinimo taisyklės. Kas stebi naują versiją, kada ji bus įdiegta ir kaip klientas patikrins rezultatą? Bendras pažadas „visada atnaujinama“ neatsako į klausimą, ką daryti prieš artėjantį teikimą, jei pakeitimas dar neparengtas. Sutartyje numatykite informavimo ir pagalbos tvarką.
Praktiniam priėmimui naudokite dvi grupės bendroves, kurios perka paslaugą iš to paties tiekėjo. Vienos sutartyje sąmoningai palikite neteisingą identifikatorių, o kitos duomenis parenkite be šios klaidos. Paprašykite parodyti, ar patikrinimas tiksliai nurodo probleminį ryšį ir ar taisymas nepakeičia kitos bendrovės įrašo. Toks bandymas parodo duomenų atskyrimą geriau nei vienas tvarkingas pavyzdinis failas.
Tada tą patį rinkinį perduokite jūsų būsimam naudotojui. Stebėkite, ar jis supranta klaidos paaiškinimą, suranda duomenų savininką ir pakartoja eksportą be pardavėjo atliekamų nematomų veiksmų. Jei tam būtinas specialistas, tai turi atsispindėti paslaugos apimtyje ir vidiniame darbo plane. Pirkimas turi būti pagrįstas procesu, kurį organizacija galės vykdyti ir po demonstracijos.
Priėmimo įrodyme išsaugokite naudotą ataskaitinę datą, parengtą paketą, patikrinimo išvadą ir taisymo seką. Atskirai pažymėkite, ar rezultatas tik patikrintas vietoje, ar išbandytas oficialioje bandymų aplinkoje. Jeigu numatyta tikro pateikimo paslauga, jos įvykdymą patvirtina atskiras sutartas įrodymas. Šios ribos padeda išvengti situacijos, kai abi šalys mano, kad galutinį veiksmą atliks kita.
Incidentų darbo eiga turi skirti kelis laikrodžius
DORA didelio IRT incidento klasifikavimas turi remtis taikomais kriterijais. Programos prioriteto žyma „kritinis“ nėra savaime teisinė klasifikacija. Prašykite parodyti, kokie faktai ir slenksčiai naudojami, kas patvirtina rezultatą ir kaip išsaugomas ankstesnis vertinimas, jei vėliau paaiškėja nauja informacija apie klientus, trukmę ar paslaugos poveikį.
Deleguotojo reglamento (ES) 2025/301 5 straipsnis numato pradinį pranešimą kuo anksčiau, ne vėliau kaip per keturias valandas nuo priskyrimo dideliam incidentui ir ne vėliau kaip per 24 valandas nuo sužinojimo apie IRT incidentą. Jei incidentas dideliu pripažįstamas tik vėliau nei per tas 24 valandas, taikoma atskira keturių valandų taisyklė.
Tarpinis pranešimas teikiamas per 72 valandas nuo pradinio, net jei padėtis nepasikeitė. Atnaujintas tarpinis pranešimas teikiamas nepagrįstai nedelsiant, bet kuriuo atveju atkūrus įprastą veiklą; galutinis pateikiamas per mėnesį nuo tarpinio arba naujausio jo atnaujinimo. Savaitgalių taisyklės turi subjektų išimčių, todėl negalima visiems automatiškai perkelti termino į pirmadienį.
Demonstracijoje pakeiskite klasifikavimo laiką ir įtraukite vėliau paaiškėjusį didelio incidento atvejį. Atskirai patikrinkite vėlavimo informavimo ir atnaujinimo užduotis. Lietuvos banko ataskaitų kalendorius rodo elektroninių pinigų įstaigų pateikimo kanalus ir skiria savanorišką kibernetinės grėsmės ataskaitą. Vienos kategorijos lentelė nepakeičia visų subjektų teisinio vertinimo.
BDAR ir NIS2 negalima sujungti vienu pažymėjimu
Tas pats įvykis gali reikalauti kelių atskirų vertinimų. Asmens duomenų saugumo pažeidimas nėra tapatus kiekvienam IRT incidentui. Pagal BDAR apie pažeidimą kompetentingai priežiūros institucijai pranešama nepagrįstai nedelsiant ir, jei įmanoma, per 72 valandas nuo sužinojimo, nebent mažai tikėtinas pavojus žmonių teisėms ir laisvėms. Vėlavimą reikia paaiškinti.
BDAR pažeidimo pranešimo darbo eiga todėl turi savo pradžios momentą, rizikos sprendimą ir adresatą. Dokumentuojami visi asmens duomenų saugumo pažeidimai, o didelio pavojaus komunikacija žmonėms vertinama atskirai pagal 34 straipsnį. DORA ataskaitos pateikimas savaime neįrodo, kad įvykdyti šie BDAR reikalavimai.
DORA yra sektorinis Sąjungos teisės aktas NIS2 prasme atitinkamiems finansų subjektams. Tačiau šios išvados negalima automatiškai taikyti visiems grupės juridiniams asmenims ir paprastiems tiekėjams. NIS2 programinės įrangos pasirinkimą vertinkite tik nustačius konkrečią taikymo sritį. Bendra saugumo priemonė gali padėti keliuose režimuose, bet teisiniai sprendimai turi likti atskiri.
Pirkimo reikalavimuose prašykite vienos faktų chronologijos ir atskirų sprendimų pagal kiekvieną taikomą režimą. Tai leidžia mažinti pakartotinį įvedimą nepanaikinant svarbių skirtumų. Lietuvos duomenų apsaugos kontekstas padeda sujungti atsakomybes, tačiau platformos bendras atitikties procentas neturėtų slėpti nepriimto pranešimo sprendimo ar neišsiųsto dokumento.
Sutartys, tiekėjų grandinė ir pasitraukimas
DORA 30 straipsnis nustato IRT susitarimų turinio reikalavimus, o ypatingos svarbos arba svarbias funkcijas palaikančioms paslaugoms numatytos papildomos sąlygos. Vertinkite paslaugos aprašymą, vietas, duomenų apsaugą ir grąžinimą, pagalbą incidento metu, priežiūros institucijų bendradarbiavimą bei nutraukimą. Vienas bendras tiekėjo pareiškimas apie atitiktį nepakeičia konkrečių teisių sutartyje.
Įrankio demonstracijoje susiekite sutartį su paslauga ir funkcija, tada įtraukite tiekėjo pakeitimą. Ar galima rasti susijusius rizikos sprendimus ir nustatyti, kas turi juos peržiūrėti? Sutarties dokumento saugojimas dar nėra jos sąlygų kontrolė. Reikia matyti galiojimą, pakeitimus, trūkstamą informaciją ir įsipareigojimus, kurių įvykdymą būtina patikrinti.
Jei paslaugų teikėjas tvarko asmens duomenis kliento vardu, atskirai įvertinkite BDAR 28 straipsnio sutartį arba kitą pagal Sąjungos ar valstybės narės teisę privalomą teisės aktą. Leidžiama ir elektroninė rašytinė forma. DORA sutarties reikalavimai nepanaikina asmens duomenų tvarkytojo pareigų ir automatiškai neužtikrina jų įvykdymo.
Pasitraukimo scenarijuje prašykite parodyti visų reikalingų įrašų, ryšių ir įrodymų išvedimą. Nustatykite, kiek truks prieiga po sutarties pabaigos ir kas padės su duomenų paaiškinimu. Vien atsisiunčiamos ataskaitos gali nepakakti tęsti darbą kitoje sistemoje. Paslaugos pakeičiamumas turi būti vertinamas praktiškai, įskaitant žmones, žinias ir sutartines ribas.
Atsparumo bandymai ir vadovybės sprendimai
DORA numato riziką atitinkantį skaitmeninio atsparumo testavimą, o TLPT taikomas pagal atskiras nustatymo sąlygas. Nereikia manyti, kad kiekvienas mažas finansų subjektas privalo pirkti tą patį TLPT modulį. Kita vertus, paprastas užduočių kalendorius pats neatlieka techninio bandymo ir nepakeičia tinkamai parengto testavimo proceso.
Pirkimo metu paprašykite susieti bandymo rezultatą su nustatyta rizika, trūkumo savininku ir taisymo įrodymu. Jei aptikta spraga pažymėta uždaryta, turi būti aišku, kas patikrino rezultatą. Pirkėjui svarbus ne tik gražus atliktų testų sąrašas, bet ir galimybė pamatyti, kurie rizikos mažinimo darbai iš tiesų dar nebaigti.
Vadovybės informacijoje atskirkite techninius rodiklius nuo sprendimų. Pavyzdžiui, atkūrimo bandymas gali pavykti, bet užtrukti ilgiau, nei leidžia veiklos poreikis. Tada reikia sprendimo dėl papildomų priemonių arba rizikos valdymo, o ne tik teigiamos programos būsenos. Vadovai turi matyti išimtis ir nežinomus dalykus kartu su pateiktų įrodymų ribomis.
Jei atitikties platforma pati laikinai neveikia, incidento valdymas ir būtina komunikacija neturi visiškai sustoti. Iš anksto įvertinkite reikalingų kontaktų, procedūrų ir įrašų prieinamumą kitu būdu. Tai praktiškas pirkimo scenarijus: ar komanda gali tęsti darbą, kai sutrikimas paliečia būtent įrankį, kuriuo paprastai koordinuojami veiksmai?
Kainą vertinkite pagal sutartą rezultatą
Paprašykite rašytinio pasiūlymo su aiškiu juridinių asmenų, naudotojų, tiekėjų ir funkcijų skaičiumi. Atskirai įtraukite migraciją, duomenų sutvarkymą, eksportų konfiguravimą, mokymus, atnaujinimus ir išėjimo pagalbą. Faktinės kainos negalima nustatyti iš bendros programinės įrangos kategorijos ar nepatikrinto ankstesnių metų intervalo.
BDAR programinės įrangos kainos struktūros vadovas padeda susisteminti bendras sąnaudų kategorijas, bet DORA specifikacijai reikės atskirų priėmimo kriterijų. Platesnis BDAR įrankių pasirinkimas gali būti naudingas bendram pirkimui. Kelių sričių sujungimas yra vertinamas pasirinkimas, o ne savaime pigesnis ar geresnis sprendimas.
Prieš pasirašymą užfiksuokite demonstracijos aplinką, naudotą duomenų rinkinį ir parodytas funkcijas. Atskirai pažymėkite tai, kas veikia dabar, kam reikia kliento darbo ir kas tik planuojama. Ateities funkcija neturėtų gauti tokio pat įvertinimo kaip išbandytas eksportas. Jei ji būtina, sutarkite dėl patikrinamo rezultato ir neįvykdymo pasekmių.
Dažniausiai užduodami klausimai
Ar komercinė DORA platforma privaloma?
Reglamentas nustato pareigas ir rezultatus, o ne bendrą pareigą pirkti konkretų produktą. Tinkamą sprendimą lemia subjekto apimtis, rizikos ir gebėjimas palaikyti patikimus įrašus. Pirkimą pagrįskite realia darbo eiga ir patikrinamais pranašumais, išlaikydami atsakomybę už duomenų ir sprendimų turinį.
Ar grupės registras pakeičia Lietuvos individualų pateikimą?
Ne automatiškai. Lietuvos banko nurodytam 2026 m. ciklui taikytas individualus teikimo lygmuo, nepriklausomai nuo priklausymo grupei. Grupės platforma turi gebėti parengti reikiamos apimties rezultatą. Būsimo ciklo datą, lygmenį ir technines taisykles reikia tikrinti iš naujo oficialioje informacijoje.
Ar visiems subjektams reikia TLPT?
Ne. Taikomos atskiros subjektų nustatymo sąlygos, todėl TLPT poreikis negali būti sprendžiamas vien pagal bendrą etiketę „finansų įmonė“. Programos pirkimo apimtį reikia susieti su konkrečiais testavimo įsipareigojimais. Planavimo ir įrodymų saugojimo funkcija nėra pats įsiskverbimo testas.
Koks svarbiausias demonstracijos rezultatas?
Pasirinktam subjektui parengtas ir patikrintas registro paketas, aiški klaidų taisymo seka ir įrodytas atsakomybės pasidalijimas yra stiprus pradinis rezultatas. Papildomai patikrinkite incidento klasifikavimo ir terminų scenarijų, sutarties pakeitimą bei duomenų išvedimą. Kiekvienas rezultatas turi atitikti jūsų sutartą pirkimo apimtį.