Geriausia NIS2 programinė įranga Lietuvos organizacijai yra ta, kuri padeda atlikti jai iš tikrųjų taikomas Kibernetinio saugumo įstatymo pareigas ir kurios rezultatus galima patikrinti. Vieno visuotinai geriausio produkto ar privalomo komercinio pirkimo nėra. Programinė įranga gali fiksuoti rizikos vertinimus, priemonių savininkus, tiekėjų peržiūras ir incidentų eigą, bet ji pati nesutvarko pažeidžiamų sistemų ir nepriima vadovybės sprendimų. Šiame vadove pateikiamas pirkimo bandymas, ne tiekėjų reitingas ar nepatikrintų kainų sąrašas. Pirmiausia nustatykite taikymo sritį pagal NIS2 Lietuvoje vadovą ir oficialią NKSC informaciją apie Kibernetinio saugumo įstatymą.
1. Ar jūsų organizacija įtraukta į KSS registrą?
Lietuvoje pagrindinės TIS2 / NIS2 direktyvos nuostatos perkeltos atnaujintu Kibernetinio saugumo įstatymu, įsigaliojusiu 2024 m. spalio 18 d. Pirkimui 2026 m. tikrinkite galiojančią, vėlesniais pakeitimais atnaujintą redakciją; įsigaliojimo data nėra dabartinio teksto data. Pareigų taikymą konkrečiai organizacijai lemia Lietuvos subjektų nustatymo sistema. NKSC reikalavimų DUK aiškina, kad neįtrauktai į Kibernetinio saugumo subjektų registrą organizacijai registruotiems KSS skirti saugumo reikalavimai dar netaikomi. Vis dėlto galiojančio įstatymo 12 straipsnis numato, kad 11 straipsnio nustatytus kriterijus atitinkantis subjektas turi pateikti reikiamus duomenis per KSIS. Todėl vien negautas pranešimas nėra pagrindas nieko nedaryti: patikrinkite dabartinius kriterijus, pateikimo pareigą ir registracijos būseną. Įtraukimas vyksta nuolat; nepakanka vien sektoriaus pavadinimo ar darbuotojų skaičiaus.
Jei organizacija įtraukta, nustatykite, ar ji yra esminis, ar svarbus subjektas, kokios sistemos bei paslaugos patenka į apimtį ir nuo kada skaičiuojami pereinamieji terminai. NKSC DUK nurodo 12 mėnesių organizaciniams ir 24 mėnesius tam tikriems techniniams reikalavimams nuo įtraukimo į registrą. Tai nėra universalus visiems vienodas kalendorinis terminas; tikrinkite savo registracijos ir taikomų punktų datą. Specialiesiems subjektams, kuriems taikomas Komisijos įgyvendinimo reglamentas (ES) 2024/2690, šio KSRA pereinamojo laikotarpio automatiškai netaikykite: jų reikalavimus vertinkite nuo įtraukimo į registrą pagal jiems skirtą teisės aktą. Pirkimo dokumente užfiksuokite šį pagrindą, kad tiekėjas neįtikintų pirkti „privalomą NIS2 licenciją“ subjektui, kuriam toks statusas nenustatytas.
2. Išskaidykite darbą prieš rinkdamiesi platformos tipą
Informacinių sistemų žemėlapis gali būti pradinis turto ir duomenų srautų atskaitos taškas, nors jis nepakeičia kibernetinio saugumo inventoriaus. Prieš demonstraciją sudarykite penkių realių darbų sąrašą: sistemos ir paslaugos apimtis, rizikos vertinimas, priemonių įgyvendinimas, tiekėjų saugumo kontrolė, incidentų pranešimas. Kiekvienam darbui nurodykite, kas organizacijoje priima sprendimą, koks įrodymas turi išlikti ir kur saugomi techniniai duomenys. Jei šiuo metu nėra sistemos savininko ar veikiančios atsarginės kopijos, GRC lentelė šios spragos neištaisys. Jei dokumentai išsimėtę keliuose skyriuose, skaitmeninis darbo srautas gali padėti juos sujungti.
Skirtingi įrankiai atlieka skirtingus darbus. GRC sistema padeda valdyti sprendimus, rizikas, patvirtinimus ir įrodymus. Turto inventorius rodo sistemas bei jų savininkus. SIEM ar stebėjimo priemonė aptinka įvykius; pažeidžiamumų valdymas padeda tikrinti techninę būklę. Vienas tiekėjas gali siūlyti kelias funkcijas, bet nepriimkite žodžio „platforma“ kaip įrodymo, kad jos visos įdiegtos. Pirkimo sąraše pažymėkite esamų sistemų galimybes, o naujas licencijas vertinkite tik aiškioms spragoms.
3. Rizikos vertinimo bandymas
Paprašykite tiekėjo parodyti vieną anoniminę, bet realistišką paslaugą: pacientų registracijos portalą arba tiekimo grandinės valdymo sistemą. Įveskite priklausomybes, galimus sutrikimus, atsakingus asmenis ir pasirinktas priemones. Tada pakeiskite vieną faktą, pavyzdžiui, tiekėjas perkėlė palaikymą kitur arba paaiškėjo, kad atsarginė kopija neatkuriama. Ar įrankis aiškiai parodo, kas turi pervertinti riziką, ką jis nusprendė ir kokie įrodymai naudoti? Automatinis rizikos balas be suprantamų prielaidų gali klaidinti vadovybę.
NKSC KSRA DUK primena, kad į politikos dokumentus turi būti įrašyti taikomi reikalavimai ir jie turi būti įgyvendinti. Programos šablonas nėra įgyvendinimo įrodymas. Vertinkite, ar sistema leidžia susieti rizikos sprendimą su konkrečia priemone, jos savininku, patikros data ir rezultatu. Jei priemonė neveikia, statusas turi būti „neįvykdyta“ arba „rizika priimta atsakingu sprendimu“, o ne automatiškai „atitinka“.
4. Tiekėjų saugumas kaip pirkimo scenarijus
Lietuvos reikalavimuose ir NKSC DUK apie tiekimo grandinę akcentuojamas tiekėjų vertinimas, prieigos ribojimas ir saugus santykio užbaigimas. Demonstracijoje įveskite paslaugų teikėją, kurio darbuotojai turi ribotą administratoriaus prieigą. Patikrinkite, ar galima nurodyti paslaugos apimtį, sutartines saugumo sąlygas, prieigos suteikimo ir atšaukimo datas, vertinimo rezultatus bei grąžintus ar sunaikintus duomenis. Vien tiekėjo pavadinimo sąrašas nesudaro saugios tiekimo grandinės.
Jei tiekėjas neatitinka vieno reikalavimo, sprendimas nėra visada „atmeskite“ arba „pažymėkite žaliai“. NKSC gairės numato rizikos įvertinimą ir atitinkamas priemones; kai rinkoje tik vienas paslaugos teikėjas, gali reikėti kitokio rizikos valdymo. Įrankis turi leisti pridėti alternatyvios kontrolės įrodymą, atsakingo asmens patvirtinimą ir peržiūros datą. Saugumo sąlygos pirkimo dokumentuose ir prieigos ribojimas turi būti vykdomi realioje sistemoje, ne tik aprašyti.
5. Incidentų pranešimas: atskirkite kanalus ir slenksčius
NKSC Kibernetinio saugumo įstatymo DUK paaiškina pranešimo apie didelius kibernetinius incidentus eigą: ankstyvas įspėjimas nedelsiant, ne vėliau kaip per 24 valandas, išsamesnis pranešimas per 72 valandas ir galutinė ataskaita pagal nacionalinį planą. Kitiems incidentams gali būti kitokios taisyklės. Esamą incidentų valdymo procedūrą naudokite kaip vieną bandymo įvestį, tačiau atskirai patikrinkite kibernetinio incidento taisykles. Demonstracijoje paprašykite klasifikuoti konkretų incidentą ir parodyti, nuo kokio momento bei pagal kokį statusą skaičiuojamas terminas. Tuščias laikmatis be klasifikavimo nepadeda.
Kibernetinis incidentas gali kartu būti asmens duomenų saugumo pažeidimas. Tokiu atveju atskirai vertinamas BDAR 33 straipsnio pranešimas VDAI ir 34 straipsnio informavimas asmenims. BDAR institucijos slenkstis yra rizika žmonių teisėms; NKSC kelias remiasi kibernetinio incidento kategorija ir KSS statusu. Vienas portalo įrašas automatiškai neįvykdo visų skirtingų pareigų. Tikrinkite oficialios KSIS paskirtį ir prieigas bei savo veikiančius kontaktus; komercinės sistemos mygtukas „siųsti“ nėra įrodymas, kad NKSC pranešimas pateiktas.
6. Patikrinkite, kas yra privaloma integracija
NKSC informacinės sistemos DUK aprašo tam tikrą pareigą KSS per 12 mėnesių nuo įregistravimo pritaikyti įvykių ir incidentų valdymo sistemas automatiniam registravimui KSIS veikiančioje platformoje. Tai nėra bendras reikalavimas kiekvienai Lietuvos bendrovei pirkti konkretų komercinį įrankį. Jei ši pareiga taikoma jūsų organizacijai, išsiaiškinkite techninę sąsają, duomenų laukus, testavimo atsakomybę ir kaip tikrinama, kad įrašas tikrai gautas. Galbūt turima sistema gali būti pritaikyta, o ne pakeista. NKSC DUK aprašo galimybę vieną kartą prašyti motyvuoto šio pritaikymo termino pratęsimo iki 12 mėnesių; tai individualus sprendimas, o ne automatinis papildomas laikotarpis.
Tiekėjo paprašykite parodyti ne tik ekrano maketą, bet ir veikiančio perdavimo testą arba tikslų diegimo planą. Jei integracijos dar nėra, pasiūlyme turi būti aiškiai nurodyta, kas ją sukurs, kokie terminai ir nuo kokių NKSC specifikacijų ji priklauso. NKSC pateikia ir nemokamą atvirojo kodo RTIR priemonę su sąsaja, todėl komercinė licencija savaime nėra integracijos sąlyga. Atsarginį pateikimo kanalą suplanuokite tiems atvejams, kai dėl paties kibernetinio incidento automatinis pranešimas neįmanomas; vien vėluojanti integracija nėra pagrindas neribotai pakeisti nustatytą automatinio pateikimo pareigą rankiniu procesu. Automatinis perdavimas be nesėkmingų užklausų stebėsenos taip pat nėra patikimos pareigos vykdymo įrodymas.
7. Vadovybės atsakomybė ir įrodymų kokybė
NIS2 ir Lietuvos teisė numato vadovybės vaidmenį tvirtinant bei prižiūrint kibernetinio saugumo rizikos valdymą. Platformoje turėtų būti matoma, kokį sprendimą vadovybė iš tiesų patvirtino, kokias rizikas priėmė ir kokie darbai vėluoja. Automatiškai sugeneruota „valdybos ataskaita“ neturi prasmės, jei joje remiamasi nepilnais duomenimis. Paprašykite bandyme pakeisti pasenusios priemonės statusą ir parodyti, ar tai patenka į vadovybės peržiūrą.
NKSC DUK nurodo ir konkrečią KSIS tvarką: politikos dokumentai į sistemą paprastai nekeliami, nurodomi jų patvirtinimo duomenys; per patikrinimą dokumentų kopijos gali būti pareikalautos. Pirkimo klausimas nėra vien „ar yra eksportas“, bet ar galima gauti teisingą dokumentų versiją, patvirtinimo datą ir išsaugotą sprendimo eigą. Tokia struktūra padeda priežiūrai, bet negali pakeisti realaus saugumo patikrinimo.
8. BDAR ir DORA persidengimą vertinkite atsargiai
Kai kurioms organizacijoms aktualūs ir BDAR 32 straipsnio saugumo reikalavimai, o finansų sektoriui – DORA įrankių klausimai. Ta pati techninė priemonė, pavyzdžiui, prieigos valdymas, gali būti įrodymas keliems procesams. Tačiau incidento kategorijos, institucijos, pranešimo slenksčiai ir terminai nėra tapatūs. Integruotas produktas gali sumažinti dvigubą duomenų įvedimą, jei jis išlaiko atskiras teises, vaidmenis ir sprendimus. Jis nėra automatiškai pigesnis ar geresnis už esamų specializuotų priemonių derinį.
Sukurkite pavyzdį su vienu incidentu ir dviem vertinimais. IT komanda nustato, kad neveikė svarbi paslauga; privatumo komanda vertina, ar paveikti asmens duomenys. Jei platforma perkelia vienos komandos sprendimą kaip automatinį kitos komandos pranešimą, ji gali sukurti klaidą. Geras įrankis leidžia panaudoti bendrus faktus, bet išlaiko atskirus teisės klausimus ir sprendimų savininkus. BDAR Lietuvoje apžvalga padeda atskirti šį sluoksnį.
9. Kaina ir diegimo apimtis be išgalvoto tarifario
Viešas „nuo“ tarifas neatsako, kiek kainuos jūsų scenarijus. Visiems tiekėjams pateikite tą patį bandymo paketą: subjektų ir sistemų skaičius, naudotojų vaidmenys, tiekėjų skaičius, esamos integracijos, duomenų kiekis, palaikymo valandos, duomenų eksportas ir sutarties pabaiga. Paprašykite rašytinio pasiūlymo su įdiegimo, priežiūros ir papildomų modulių kainomis. Čia nepateikiamos nepatikrintos rinkos kainų juostos ar garantuotas sutaupymas.
Įvertinkite ir savo žmonių laiką: kas surinks inventorių, peržiūrės rizikos vertinimus, patvirtins priemones bei tikrins pranešimus? Jei pasiūlymas žada „visišką automatizavimą“, paprašykite per demonstraciją parodyti vieną klaidingą įvestį ir jos pataisymą. Kibernetinio saugumo atitikties sprendimas privalo leisti atsakingam žmogui priimti sprendimą ir jį pakeisti pagal naujus faktus. BDAR programinės įrangos kainos metodas gali padėti sudaryti palyginamą išlaidų lentelę, tačiau BDAR įrankio kaina nėra NIS2 kainos įrodymas.
10. Priėmimo bandymas prieš sutartį
Paprašykite tiekėjų to paties demonstracinio atvejo: vienas registruotas KSS, dvi sistemos, vienas aukštos rizikos tiekėjas ir vienas incidentas, kuris sutrikdo paslaugą bei gali paveikti asmens duomenis. Tegul parodo, kas kuria įrašą, kas tikrina faktus, kas patvirtina riziką, kas siunčia pranešimą ir kur lieka pateikimo įrodymas. Įvertinkite ne tik funkcijų skaičių, bet ir klaidų kelią: ką rodo įrankis, kai nėra atsakingo žmogaus arba integracija neveikia?
Sutartyje sutikrinkite, kas demonstracijoje buvo realiai veikianti funkcija, kas buvo planas ir kokios integracijos įskaičiuotos. Reikalaukite aiškaus duomenų eksporto bei prieigų nutraukimo plano. NKSC netvirtina kiekvienos komercinės techninės specifikacijos; oficialus DUK nurodo, kad centras jų nevertina. Pirkėjas turi pats apibrėžti priėmimo kriterijus ir patikrinti tiekėjo teiginius. Vien sertifikato logotipas neįrodo, kad jūsų organizacijos konkretus procesas atitinka įstatymą.
Išmatuokite, ar priemonė veikia už programos ribų
NIS2 pirkimo bandymas negali baigtis gražiu rizikos registru. Jei programa rodo „atsarginės kopijos įdiegtos“, paprašykite parodyti paskutinį atkūrimo bandymą ir jo rezultatą. Jei rodo „daugiaveiksnis prisijungimas“, patikrinkite, ar jis įjungtas kritinėms paskyroms, o ne tik aprašytas politikoje. Jei tiekėjo rizika pažymėta maža, išsiaiškinkite, kada paskutinį kartą tikrintos jo prieigos ir paslaugos tęstinumo sąlygos. Programinė įranga gali saugoti įrodymo nuorodą, tačiau negali pati paversti neveikiančios kontrolės veikiančia.
Sukurkite priėmimo kriterijų kiekvienai svarbiai kontrolei. Pavyzdžiui, incidentų aptikimo priemonė turi perduoti signalą atsakingam žmogui ir išsaugoti laiką, kada jis patvirtino gavimą. Jei demonstracijoje tiekėjas parodo tik ranka sukurtą incidento įrašą, tai neįrodo automatinės integracijos. Užrašykite skirtumą tarp funkcijos, kurią matėte, ir funkcijos, kuri žadama po diegimo. Taip sumažinate pirkimo riziką be nepagrįsto teiginio, kad viena platformos rūšis visada geriausia.
Paskirstykite sprendimus tarp vadovybės, saugos ir IT
Kibernetinio saugumo vadovas, IT administratorius, paslaugos savininkas ir organizacijos vadovybė turi skirtingus vaidmenis. NKSC reikalavimų DUK aptaria kibernetinio saugumo vadovo kompetenciją ir funkcijų atskyrimą nuo techninio administravimo tam tikrose situacijose. Pirkimo metu patikrinkite, ar įrankyje galima atskirti priemonės vykdytoją nuo jos vertintojo ir sprendimą patvirtinančio asmens. Vienam asmeniui suteikti visus leidimus vien dėl paprastesnio diegimo gali susilpninti kontrolę.
Paprašykite parodyti vieną konfliktą: IT komanda teigia, kad pataisa įdiegta, saugos funkcija nustato, jog sistema vis dar pažeidžiama, o vadovybė turi nuspręsti dėl likutinės rizikos ir paslaugos tęstinumo. Ar sistema leidžia užrašyti skirtingus faktus, jų šaltinius ir sprendimo motyvą? Jei joje yra tik vienas žalias langelis „atitinka“, reikės papildomos darbo eigos arba kito įrankio. Vertinkite žmonių sprendimų kokybę, ne vien automatinių pranešimų skaičių.
Tiekėjo duomenų apsauga ir sutarties pabaiga
Pati NIS2 valdymo platforma gali saugoti išsamią informaciją apie pažeidžiamumus, incidentus, tiekėjus ir kritinių paslaugų priklausomybes. Todėl vertinkite jos prieigos modelį, palaikymo vietą, atsargines kopijas, žurnalus ir saugaus išėjimo galimybę. Jei į ją įkeliami asmens duomenys, atskirai nustatykite BDAR vaidmenis ir tinkamą teisinį instrumentą. Net jei produktas žada vien ES talpinimą, paklauskite, kas gali prisijungti nuotoliniu būdu ir kokie subrangovai naudojami.
Prieš pasirašant sutartį paprašykite bandymo, kaip išsaugosite rizikos registrą, incidentų istoriją ir patvirtintus dokumentus pakeitę tiekėją. Jei viską galima gauti tik kaip nepaieškomas ekrano kopijas, išėjimas bus brangus ir gali susilpninti atskaitomybę. Taip pat iš anksto apibrėžkite, kaip atšaukiamos tiekėjo prieigos ir kaip patvirtinamas duomenų sunaikinimas. Šios sąlygos yra svarbios ne todėl, kad NIS2 įpareigotų naudoti vieną formatą, o todėl, kad organizacija turi išlaikyti savo saugumo valdymo tęstinumą.
Kada nepirkti naujos platformos
Jei organizacija dar nėra įtraukta į KSS registrą, jos pirmasis žingsnis yra patikrinti galiojančius identifikavimo kriterijus ir, jei jie tenkinami, įstatymo 12 straipsnio duomenų pateikimo pareigą. Greta galima stiprinti bendrą saugumo pagrindą, tačiau vien negautas registracijos pranešimas nėra pagrindas atidėti privalomą informaciją ir pirkti platformą nėra savaiminė šios pareigos sąlyga. Jei ji įtraukta, bet jau turi veikiančią turto, rizikos ir incidentų sistemą, pradėkite nuo spragų: gal pakanka papildyti vieną darbo eigą ar ataskaitą. Jei trūksta atsakingų žmonių ir patvirtintų procesų, nauja licencija gali sukurti dar vieną tuščią informacijos vietą.
Atidėjus pirkimą reikia vis tiek paskirti darbų savininkus ir terminus. Pavyzdžiui, peržiūrėkite oficialų įtraukimo pranešimą, suinventorinkite kritines paslaugas, atlikite pirmą rizikos vertinimą ir išbandykite pranešimo kontaktą. Tada pakartokite tiekėjo bandymą su tikrais poreikiais. Pirkimo atidėjimas yra pagrįstas sprendimas tik tada, kai jis nepaslepia jau taikomų pareigų ir jų vykdymo spragų.
Įrankio pasirinkimą užbaikite naudojimo taisyklėmis
Net gerai išbandytas produktas neveiks, jei po pirkimo niekas neatsakys už duomenų kokybę. Paskirkite, kas atnaujina sistemų sąrašą, kas registruoja tiekėjo pokytį, kas peržiūri priemonės neveikimą ir kas patvirtina incidento klasifikavimą. Sutarkite, kada įrašas laikomas patvirtintu ir kas gali jį grąžinti taisyti. Šios taisyklės turi būti suprantamos budinčiai komandai, o ne tik pirkimą vykdžiusiam specialistui.
Po įdiegimo atlikite vieną pakartotinį bandymą: imituokite realų pakeitimą, pavyzdžiui, tiekėjui suteiktą naują prieigą. Ar jis pasirodo turto ar priklausomybių apraše, ar pervertinama rizika ir ar laiku uždaromas leidimas? Jei ne, problema gali būti ne produkto funkcijų stoka, o neveikiantis vidaus perdavimo procesas. Paprašykite tiekėjo padėti diagnozuoti, bet savo organizacijos sprendimą ir jo įrodymą išlaikykite savo rankose.
Dažniausi klausimai
Ar visoms Lietuvos įmonėms būtina NIS2 programinė įranga?
Ne. Pirmiausia tikrinkite galiojančius identifikavimo kriterijus, galimą duomenų pateikimo pareigą per KSIS ir registracijos būseną. NKSC saugumo reikalavimų įgyvendinimo terminus sieja su įtraukimu į KSS registrą, tačiau atitinkantis kriterijus subjektas neturėtų vien laukti pranešimo. Įstatymas savaime nenurodo pirkti konkrečios komercinės platformos.
Ar viena platforma gali automatiškai užtikrinti saugumą?
Ne. Ji gali padėti valdyti sprendimus ir įrodymus, tačiau techninės priemonės, atsarginės kopijos, tiekėjų prieigos ir darbuotojų veiksmai turi veikti tikrovėje. Vertinkite produktą bandydami konkrečius scenarijus.
Ar NKSC pranešimą pakeičia VDAI pranešimas?
Ne. KSS incidento taisyklės ir BDAR asmens duomenų pažeidimo taisyklės turi skirtingą taikymo sritį bei slenksčius. Tas pats įvykis gali reikalauti abiejų vertinimų ir atskirų pateikimo įrodymų.
Ką daryti, jei tiekėjas žada KSIS integraciją?
Paprašykite techninio bandymo arba aiškaus sutartinio diegimo plano. Patikrinkite, ar ši konkreti integravimo pareiga taikoma jūsų registruotam subjektui ir esamai įvykių valdymo sistemai; neprilyginkite pažado atliktam pranešimui.
Kokia yra geriausia kaina?
Be vienodų darbų ir paslaugos apimties patikrinimo palyginimas neturi prasmės. Prašykite rašytinių pasiūlymų pagal tą patį scenarijų, įtraukdami diegimą, palaikymą, duomenų iškėlimą ir vidinį darbą. Šiame vadove nėra patikrinto tiekėjų kainoraščio.
Šaltiniai, peržiūrėti 2026 m. rugsėjo 27 d.: NKSC Kibernetinio saugumo įstatymo centras, NKSC KSRA DUK, NKSC incidentų DUK, NKSC informacinės sistemos DUK, KSIS, NIS2 direktyva.