Grįžti į sąrašą

KVIETIMAS Į RINKOS DALYVIŲ KONSULTACIJĄ DĖL LABBIS 4.PRO SISTEMOS FINANSŲ VALDYMO MODULIO TECHNINIO PALAIKYMO PASLAUGŲ VIEŠOJO PIRKIMO

Išanalizuota

Akcinė bendrovė Regitra

Rinkos konsultacijaCPV: 72253200 - Sistemų palaikymo paslaugos
ID: 69850892026-03-18 10:50
Atidaryti CVP IS

Aprašymas

Šis viešasis pirkimas skirtas įsigyti LABBIS 4.PRO verslo valdymo ir apskaitos sistemos finansų valdymo modulio techninio palaikymo paslaugas. Paslaugos apima nepertraukiamo sistemos veikimo užtikrinimą, klaidų taisymą, naujų versijų diegimą bei naudotojų konsultavimą. Paslaugos teikiamos 24 mėnesių laikotarpiui, siekiant užtikrinti kritiškai svarbios finansų apskaitos sistemos stabilumą ir atnaujinimą.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas turi būti Sistemos gamintojas arba gamintojo įgaliotas atstovas teikti Sistemos techninės priežiūros ar palaikymo paslaugas. Kartu su pasiūlymu turi būti pateiktas Sistemos gamintojo raštas ar įgaliojimas, ar kitas lygiavertis dokumentas, patvirtinantis, kad Tiekėjas turi teisę teikti perkamas Paslaugas.
  • 2Perkamos paslaugos ir Tiekėjas turi atitikti Kibernetinio saugumo reikalavimų apraše, patvirtintame Lietuvos Respublikos Vyriausybės 2024 m. lapkričio 6 d. nutarimu Nr. 945 „Dėl Lietuvos Respublikos Vyriausybės 2018 m. rugpjūčio 13 d. nutarimo Nr. 818 „Dėl Lietuvos Respublikos kibernetinio saugumo įstatymo įgyvendinimo“ pakeitimo”, nustatytus reikalavimus.
  • 3turėtų teisę verstis ta veikla, kuri yra reikalinga Sutarčiai įvykdyti. Pirkėjui pareikalavus, Tiekėjas turi pateikti dokumentus, įrodančius, kad Sutartį vykdo tik tokią teisę turintys asmenys.
  • 4atitiktų nacionalinio saugumo interesus bei nebūtų registruotas (nuolat gyvenantis ar turintis pilietybę) nepatikimomis laikomose valstybėse ar teritorijose, jei tokie reikalavimai buvo numatyti pirkimo dokumentuose.

Techniniai reikalavimai

Incidentų valdymas

  • 1Tiekėjas pirkimo sutarties vykdymo metu turi turėti IT paslaugų valdymo sistemą (angl. Service Desk), skirtą Perkančiosios organizacijos incidentams registruoti.
  • 2Tiekėjas turės ne vėliau kaip per 5 (penkias) darbo dienas nuo sutarties įsigaliojimo dienos pateikti Perkančiajai organizacijai prisijungimo duomenis prie incidentų registravimo sistemos, kurioje būtų galimybė klasifikuoti incidentus pagal jų įtaką Perkančiosios organizacijos veiklai (Aukšto lygio incidentas, Vidutinio lygio incidentas, Žemo lygio incidentus).
  • 3Incidentus klasifikuoja Perkančioji organizacija incidento registracijos metu.
  • 4Incidentai gali būti registruojami ir elektroniniu paštu bei telefonu, jei nėra galimybės užregistruoti IT paslaugų valdymo sistemoje.
  • 5Tiekėjas ne vėliau kaip per 5 (penkias) darbo dienas nuo sutarties įsigaliojimo dienos turi pateikti incidentams registruoti skirtą el. pašto adresą ir telefono numerį.
  • 6Jeigu incidentas bus registruojamas telefonu, Perkančioji organizacija telefonu informuos Tiekėją, kaip jis turi būti klasifikuojamas.
  • 7Siųsdama pranešimą apie incidentą el. paštu Perkančioji organizacija laiške pateiks informaciją, kaip jis turi būti klasifikuojamas.
  • 8Incidentus, pateiktus el. paštu ir / ar telefonu, Tiekėjas turi pats užregistruoti IT paslaugų valdymo sistemoje.
  • 9Tiekėjas visais atvejais turi informuoti Perkančiosios organizacijos atstovą (arba perkančiosios organizacijos IT pagalbos tarnybą el. paštu: pagalba@regitra.lt (angl. Service Desk), kai perkančiosios organizacijos atstovas atostogauja ar pan.) el. paštu ir/ ar telefonu ar Tiekėjo IT paslaugų valdymo sistemoje (angl. Service Desk) apie visus daromus pakeitimus Sistemoje ar jos komponentuose, nurodant pakeitimų apimtį ir tikslą.
  • 10Planinių darbų atveju informuojama – ne vėliau kaip prieš 3 (tris) darbo dienas iki atliekant pakeitimą; incidentų ar problemų sprendimo atveju – prieš atliekant pakeitimus.
  • 11Aukšto lygio incidentams: Reakcijos į incidentus laikas – ne ilgiau kaip 1 (viena) darbo valanda; Incidentų išsprendimo laikas – ne ilgiau kaip 8 (aštuonios) darbo valandos.
  • 12Vidutinio lygio incidentams: Reakcijos į incidentus laikas – ne ilgiau 8 (aštuonios) darbo valandos; Incidentų išsprendimo laikas – ne ilgiau kaip 20 (dvidešimt) darbo valandų;
  • 13Žemo lygio incidentams: Reakcijos į incidentus laikas – ne ilgiau kaip 10 (dešimt) darbo valandų; Incidentų išsprendimo laikas – ne ilgiau kaip 80 (aštuoniasdešimt) darbo valandų.
  • 14Esant pagrįstoms aplinkybėms, jei incidento per nurodytą laiką išspręsti neįmanoma, su Perkančiąja organizacija privalo būti suderintas atskiras incidento sprendimo terminas.
  • 15Tokiu atveju Tiekėjas turi raštu (už sutarties koordinavimą atsakingam asmeniui) arba IT paslaugų valdymo sistemoje (angl. Service Desk) nurodyti pagrįstas priežastis ir atitinkamai siūlyti pakoreguoti terminus.

Dokumentų valdymo funkcionalumas

  • 1Turi būti galimybė vykdyti įstaigos dokumentų, pirkimų, pardavimų, IT, sutarčių, viešųjų pirkimų ir personalo el. dokumentų rengimo procesų valdymą.
  • 2Turi būti galimybė tvarkyti visus įstaigos dokumentus: elektroninius ir popierinius (skenavimo pagalba sukuriant skaitmeninį atvaizdą) — naudojant dokumento registravimo ir rezoliuciją naudojimo funkcionalumą.
  • 3Turi būti galimybė kurti visus personalo dokumentus — prašymus ir jų pagrindu kurti įsakymus bei jų duomenis automatiškai perduoti DU, personalo ir darbo laiko apskaitai.
  • 4Sistema turi užtikrinti dokumentų valdymo (rengimo, derinimo, vizavimo, pasirašymo, tvirtinimo, paskirstymo, supažindinimo), kontrolės (darbų sekos, informavimas), paieškos ir audito operacijas.
  • 5Sistemoje turi būti galimybė tvirtinti dokumentus, procesų ar užduočių eigos elementus per mobilius įrenginius.
  • 6Sistemoje turi būti galimybė skenuoti dokumentus tiesiogiai į sistemos dokumentų saugyklą be tarpinių vartotojų veiksmų reikalaujančių saugojimų darbo vietos kompiuteryje.
  • 7Turi būti konfigūravimo būdu (be papildomo programavimo) pritaikoma Perkančiosios organizacijos poreikiams sukuriant neribotą dokumentų rūšių skaičių.
  • 8Turi būti įdiegta dokumentų siuntimo vizavimui funkcija.
  • 9Turi būti įgyvendinta paieška pagal bet kuriuos dokumentų registravimo rekvizitus bei jų derinius.

Elektroninio parašo funkcionalumas

  • 1LABBIS 4.PRO turi būti realizuota galimybė pasirašyti dokumentus elektroniniu būdu, identifikuoti parašus paremtus XAdES formatais ir juos atpažinti.
  • 2LABBIS 4.PRO turi leisti įregistruoti gautą elektroninį dokumentą ADOC formatu.
  • 3LABBIS 4.PRO turi leisti patikrinti bet kurį elektroniniame dokumente esantį elektroninį parašą.
  • 4LABBIS 4.PRO turi būti realizuota galimybė elektroninių parašų patvirtinimui naudoti visų elektroninio parašo paslaugas teikiančių Lietuvoje įregistruotų kvalifikuotus sertifikatus sudarančių sertifikavimo paslaugų tiekėjų sudarytus kvalifikuotus sertifikatus.
  • 5LABBIS 4.PRO turi būti realizuota galimybė pasirašymui naudoti elektroninio parašo paslaugas teikiančių, Lietuvoje įregistruotų kvalifikuotus sertifikatus sudarančių sertifikavimo paslaugų tiekėjų naudojamą saugią parašo formavimo įrangą: lustines korteles (valstybės tarnautojo pažymėjimas, asmens tapatybės kortelė) ir kriptografinius USB raktus.
  • 6LABBIS 4.PRO turi leisti pasirašyti elektroninius dokumentus elektroniniu parašu, naudojant: lustines SmartCard korteles; mobilųjį elektroninį parašą; USB flash atmintines.
  • 7LABBIS 4.PRO turi būti realizuota vieno elektroninio dokumento ir elektroninių dokumentų grupės pasirašymas - „paketinis pasirašymas“.

Finansų valdymo modulio funkcionalumas

  • 1Labbis 4.PRO apskaita tvarkoma kaupimo principu. Sistemoje turi būti galimybė vesti apskaitą vadovaujantis apskaitos standartais.
  • 2Labbis 4.PRO vedama apskaita turi būti suderinta: informacija turi būti automatiškai kaupiama ir pagal nustatytas taisykles, panaudojama rengiamoms ataskaitoms formuoti ir biudžeto vykdymui sekti.
  • 3Labbis 4.PRO turi būti galimybė registruojant operacijas, aktualias apskaitai registruoti tik vieną kartą.
  • 4Sistemoje turi būti užtikrinta atitiktis VMI i.SAF-T, i.SAF ir i.VAZ numatytiems duomenų pateikimo reikalavimams.
  • 5Sistemoje turi būti galimybė aprašyti finansinius metus ir detalius laikotarpius. Detalių laikotarpių trukmės neturi būti ribojamos, bet negali būti trumpesnės nei diena.
  • 6Sistemoje turi būti galimybė taisyti klaidas (pvz., sumą, datą, sąskaitą, kt.) storno būdu ir koreguojančiu įrašu.
  • 7Sistemoje turi būti galimybė nurodyti pagrindinę valiutą (eurus).
  • 8Sistemoje turi būti galimybė automatiškai, pagal nustatytas taisykles, registruoti operacijas įvairiomis valiutomis, didžiojoje knygoje atvaizduojant pagrindine apskaitos valiuta. Registruose turi būti saugoma ir pirminė valiuta ir vietinė valiuta.
  • 9Sistemoje turi būti galimybė automatiškai pagal nustatytas taisykles importuoti oficialius valiutų kursus iš Lietuvos banko sistemos.
  • 10Sistemoje turi būti galimybė visose funkcinėse srityse, įskaitant ir didžiosios knygos sąskaitas, panaudoti iki 5 skirtingų dimensijų (detalizuojantys požymiai).
  • 11Sistemoje turi būti galimybė realizuoti hierarchinį DK sąskaitų planą su galimybe pagal nustatytas taisykles išskirti registravimo ir sumavimo sąskaitas, kur žemesnio lygio sąskaitų likučiai turi būti sumuojami į aukštesnio lygio sąskaitas.
  • 12Sistemoje turi būti galimybė įvesti/ sukurti naują IT kortelę, kurioje įvedama ir pagal poreikį keičiama arba, vykdant IT valdymo operacijas, automatiškai fiksuojama pagrindinė IT informacija.
  • 13Sistemoje turi būti galimybė automatiškai, pagal nustatytas taisykles, skaičiuoti ir registruoti IT nusidėvėjimą (amortizaciją) tiesiogiai proporcingu (tiesiniu) metodu.
  • 14Sistemoje turi būti galimybė kaupti ir tikslinti informaciją apie trumpalaiki turtą.
  • 15Sistemoje turi būti galimybė TT naudoti FIFO ir konkrečių kainų metodus.
  • 16LABBIS 4.PRO turi leisti atlikti blankų pajamavimą, išdavimą, pardavimą, nurašymą.
  • 17LABBIS 4.PRO turi būti galimybė sudaryti pirkimo planą „iš apačios į viršų” metodu.
  • 18Sistemoje turi būti saugoma informacija apie pirkimo sąskaitas.
  • 19Sistemoje turi būti galimybė įvesti ir registruoti prekių/paslaugų pardavimo dokumentus: PVM sąskaitą faktūrą.
  • 20Sistemoje turi būti galimybė pagal nustatytas taisykles automatiškai formuoti pardavimo PVM sąskaitą faktūrą pagal registruotą pardavimo pasiūlymą.
  • 21Sistemoje turi būti galimybė pagal nustatytas taisykles, registruojant su gautinomis ir mokėtinomis sumomis susijusias operacijas, priskirti dimensijas, jas perkeliant iš registruotų operacijų dokumentą (sutarčių, sąskaitų faktūrų, avansinių apyskaitų).
  • 22LABBIS 4.PRO turi būti galimybė formuoti įvairius skolininkų sąrašus (nesilaiko apmokėjimo terminų, surašyti įspėjimai, perduota teismui, teismo priteistos skolos ir kt.).
  • 23Sistemoje turi būti galimybė nurodyti atskaitingų asmenų informaciją. Atskaitingų asmenų žinynas turi būti susietas su darbuotojų žinynu.
  • 24Sistemoje turi būti galimybė aprašant prekes, darbus, paslaugas žinynuose nurodyti ar prekė / darbas / paslauga apmokestinama PVM, ar ne ir kokiu tarifu apmokestinama.
  • 25LABBIS 4.PRO turi būti saugoma informacija apie sutartis.

Sistemos prieinamumo reikalavimai (SLA)

  • 1Sistemos prieinamumas – palaikomos Sistemos veikimo laikas per mėnesį procentais.
  • 2Perkančiosios organizacijos Sistemos, kuriai teikiamas palaikymas, prieinamumas matuojamas darbo valandomis.
  • 3Sistemos prieinamumas skaičiuojamas pagal Tiekėjo ir Perkančiosios organizacijos užregistruotų Aukšto lygio incidentų sprendimo laiką.
  • 4Sistemos prieinamumo rodiklis per kalendorinį mėnesį turi būti ne mažesnis kaip 90%.
  • 5Visą incidentų sprendimo laiko skaičiavimą atlieka Perkančiosios organizacijos atstovas, informuodamas Tiekėją apie Sistemos pagal SLA prieinamumą.
  • 6Tiekėjui pateikiama Sistemos prieinamumo ataskaita už praėjusį mėnesį, kurioje nurodomos visos Prieinamumo skaičiavimo formulėje esančių kintamųjų reikšmės, incidentų numeriai.
  • 7Po Paslaugų teikimo kalendorinio mėnesio per 5 (penkias) darbo dienas, Perkančiosios organizacijos atstovas elektroniniu paštu pateikia Tiekėjui Sistemos prieinamumo ataskaitą.
  • 8Nepateikus ataskaitos, laikoma, kad Tiekėjas tinkamai įvykdė įsipareigojimus.
  • 9Jeigu ataskaitoje pateiktas prieinamumo rodiklis neatitinka 4.5.8 p. nurodytos normos, Tiekėjas pagal pateiktą Sistemos prieinamumo ataskaitą sumažina ataskaitinio laikotarpio mėnesinį mokestį ir Perkančiajai organizacijai pateikia sąskaitą faktūrą apmokėjimui.

Sistemos palaikymo bendrieji reikalavimai

  • 1Užtikrinti nepertraukiamą Sistemos darbą, jeigu sutrikimas nėra susijęs su Perkančiosios organizacijos veiksmais (veikimu ar neveikimu), Perkančiosios organizacijos IT infrastruktūra ar trečiosiomis šalimis (elektros, tinklų, ir pan. sutrikimais).
  • 2Vykdyti Sistemos bei jos komponentų palaikymą.
  • 3Taisyti Sistemos eksploatavimo problemas, klaidas (incidentus) ir/ar netikslumus, atsiradusius dėl neteisingo Sistemos veikimo.
  • 4Tiekėjas turi įdiegti visas naujausias Sistemos versijas, iš anksto informavęs (ne vėliau kaip prieš 3 (tris) darbo dienas iki planuojamų atlikti atnaujinimų dienos) ir suderinęs su Perkančiąja organizacija numatomus darbus ir jų atlikimo terminus.
  • 5Tiekėjas prieš naujos Sistemos versijos diegimą, šalių suderintais terminais, turi atlikti Sistemos testavimo darbus Perkančiosios organizacijos pateiktoje aplinkoje.
  • 6Tiekėjas turi įdiegti į testinės sistemos serverį naują Sistemos versiją.
  • 7Tik Perkančiajai organizacijai patvirtinus, jog testiniame serveryje nauja versija veikia tinkamai, nauja versija turi būti įdiegta į produkcinį serverį.
  • 8Tiekėjas turi atlikti naujos Sistemos versijos įdiegimo darbus, perkeliant visas ankstesnėje versijoje sukonfigūruotas savybes.
  • 9Po diegimo darbų atlikimo Tiekėjas turi įsitikinti (patikrinti), kad Sistema veikia stabiliai (įprastu greičiu ir be sutrikimų) ir veikia visos iki pakeitimo veikusios funkcijos.
  • 10Po Sistemoje atliktų pakeitimų, versijos atnaujinimų Tiekėjas turi paskelbti IT paslaugų valdymo sistemoje (angl. Service Desk) arba pateikti už sutartį atsakingam asmeniui Sistemos elektroninės dokumentacijos atnaujinimą (Administratoriaus ir naudotojo vadovą elektroniniu formatu lietuvių kalba ne vėliau kaip per 10 darbo dienų nuo versijos įdiegimo.
  • 11Sistemos techninio palaikymo paslaugas galės teikti tiek nuotoliniu būdu, tiek atvykęs į Perkančiosios organizacijos pagrindinę būstinę (Liepkalnio g. 97A, Vilnius), kur yra Sistemos serverio buvimo vieta.
  • 12Perkančioji organizacija pateiks nuotolinius prisijungimus prie Sistemos problemų, klaidų ar netikslumų taisymui ar atnaujinimų atlikimui. Prisijungimas turi būti atliekamas tik naudojant HTTPS sesijas bei VPN ar lygiavertes technologijas.
  • 13Perkančioji organizacija turi teisę stebėti, fiksuoti ir įrašinėti visus Tiekėjo atliekamus veiksmus.
  • 14Nuotoliniai prisijungimai galimi tik apibrėžtam Tiekėjo darbuotojų skaičiui, pasirašiusiems atitinkamus konfidencialumo įsipareigojimus, kontroliuojant Sistemos administratoriui ir gavus Perkančiosios organizacijos sutikimą.
  • 15Paslaugos teikiamos Perkančiosios organizacijos darbo laiku: darbo dienomis pirmadieniais–penktadieniais: 7:30 – 16:15 val.

Viešųjų pirkimų valdymo funkcionalumas

  • 1Sistemoje turi būti galimybė pagal nustatytas taisykles suformuoti pirkimo inicijavimo informacijos dokumentą, nurodant sistemoje numatomą pradėti pirkimo procesą: pirkimo objekto pavadinimą; BVPŽ kodą ar kodus; pagrindinį BVPŽ kodą, naudojamą kontrolei pagal viešųjų pirkimų planą; reikiamas dimensijas; perkamą prekių, paslaugų ar darbų kiekius (jei įmanoma); planuojamą sutarties pradžią ir trukmę; dimensijas; pirkimo būdą; ar pirkimas vykdomas CVPIS ar CPO; preliminarią pirkimo vertę be PVM (pirkimo plano kontrolei); preliminarią pirkimo vertę su PVM einamaisiais metais; kitą informaciją.
  • 2Sistemoje turi būti galimybė pagal nustatytas taisykles vykdyti pirkimo inicijavimo dokumento kontrolę pagal pirkimą planą.
  • 3Sistemoje turi būti galimybė suvesti ir saugoti informaciją apie inicijuoto pirkimo būseną (pvz., „vykdoma apklausa", „paskelbtas konkursas", „gauti pasiūlymai" ir t.t.) ir papildomą pirkimo informaciją: skelbimai viešųjų pirkimų tarnybos informacinėje sistemoje (skelbimo numeris ir data); pirkimo pradžia; vokų atplėšimas (procedūros data, voko Nr.); informacinio pranešimo data; konkurso dalyviai; pasiūlymą eilės sudarymo data: laimėjusio pasiūlymo nustatymo data; pasiūlymo kaina, įkainis(-iai); pirkimo objektas; ir kt.
  • 4Sistemoje turi būti galimybė įvesti ir registruoti sutarties informaciją.
  • 5Sistemoje turi būti galimybė įvesti ir registruoti sąskaitą faktūrą ar kitą jai prilyginamą sutartinių įsipareigojimų vykdymo dokumentą (pvz., darbų priėmimo aktai).

Kibernetinio saugumo reikalavimai tiekėjui

  • 1Tiekėjas per 2 (du) mėnesius nuo sutarties įsigaliojimo privalo pateikti taikomą informacijos ar (ir) kibernetinio saugumo politikos dokumentą ar (ar) vidines tvarkas, reglamentuojančias kibernetinio saugumo užtikrinimą, įskaitant parengtą veiksmų planą didelio poveikio kibernetinių incidentų ir veiklos sutrikdymo scenarijų atveju, užtikrinantį operatyvų paslaugų atstatymą ir alternatyvius sprendimus kritinėms paslaugoms teikti bei veiklos tęstinumui užtikrinti bei turimus (jei Tiekėjas turi) su informacijos ar kibernetinio saugumo užtikrinimu susijusius sertifikatus (pvz. ISO, SOC2 ar kitus).
  • 2Tiekėjas privalo nedelsiant informuoti AB „Regitra“ apie bet kurį AB „Regitra“ teikiamoms paslaugoms ar TIS veiklai įtaką darantį atsiradusį ar įvykusį incidentą.
  • 3Tiekėjas privalo turėti procedūrą ar tvarką kibernetiniams incidentams registruoti ir eskaluoti.
  • 4Tiekėjas privalo pranešti AB „Regitra“ apie visus pagal KSĮ klasifikavimą užfiksuotus didelius ir nedidelius incidentus, susijusius su AB „Regitra“ TIS.
  • 5Pranešimo apie kibernetinius incidentus terminai: apie didelį kibernetinį – nedelsiant, bet ne vėliau kaip per 20 valandas nuo sužinojimo apie didelį kibernetinį incidentą momento; apie nedidelį kibernetinį incidentą – nedelsdamas, bet ne vėliau kaip per 64 valandas nuo sužinojimo apie kibernetinį incidentą momento.
  • 6Tiekėjas per 1 mėn. nuo pranešimo apie įvykusį kibernetinį incidentą registravimo dienos turi pateikti AB „Regitra“ kibernetinio incidento tyrimo ataskaitą.
  • 7AB „Regitra“ gali kartą paslaugų teikimo metu iš anksto suderintu laiku, suderinta apimtimi ir būdu testuoti Tiekėjo reagavimo į incidentus procedūras, įskaitant atsarginių kopijų atkūrimo ir veiklos tęstinumo planą.
  • 8Siekiant, kad kibernetiniai incidentai būtų kuo greičiau pašalinti, Tiekėjas privalo bendradarbiauti ir dalintis būtina informacija su AB „Regitra“ ir kitomis institucijomis (pvz., Nacionaliniu kibernetinio saugumo centru prie KAM (NKSC), Policijos departamentu (PD), Valstybine duomenų apsaugos inspekcija (VDAI), kaip tą numato KSĮ ir Nacionalinis kibernetinių incidentų valdymo planas).
  • 9Tiekėjas privalo užtikrinti savo naudojamos programinės įrangos palaikymą bei vykdyti reguliarius savo įrangos saugumo atnaujinimus.
  • 10Tiekėjas privalo užtikrinti su teikiamomis paslaugomis susijusių saugumo spragų, keliančių riziką AB „Regitra“ TIS, šalinimą.
  • 11AB „Regitra“ turi teisę savo infrastruktūroje vykdyti pastovią Tiekėjo teikiamo informacinio turto ir TIS paslaugų stebėseną, įskaitant ir atliekamų veiksmų žurnalinių įrašų (angl. log) registravimą, stebėjimą ir anomalijų identifikavimą.
  • 12Tiekėjas turi AB „Regitra“ arba jos įgaliotiems paslaugų tiekėjams leisti atlikti jo atitikties šiame dokumente įvardintiems reikalavimams planinį auditą.
  • 13Tiekėjas įsipareigoja sudaryti sąlygas tokiam auditui atlikti sutarties vykdymo laikotarpiu.
  • 14Pagal AB „Regitra“ reikalavimą ir šalių suderintą terminą Tiekėjas privalo pateikti informacijos saugumo audito ataskaitas (jei informacijos saugumo auditas buvo atliktas), kiek jos susijusios su Tiekėjo teikiamomis paslaugomis.
  • 15Tiekėjo paslaugų teikimo pabaigoje yra būtina užtikrinti, kad visi AB „Regitra“ konfidencialūs, komercinę paslaptį sudarantys ir asmens duomenys ir kitas informacinis turtas būtų saugiai Tiekėjo grąžintas arba sunaikintas, pateikiant sunaikinimo įrodymus.
  • 16Informacijos sunaikinimas (ištrynimas), turės būti atliekamas dedant protingas ir komerciškai pagrįstas pastangas per protingą terminą, atsižvelgiant į technines, organizacines ir ekonomines galimybes.
  • 17Pavyzdžiui, ši pareiga nebus laikoma pažeista, jeigu informacija išliks atsarginėse kopijose, kurios bus ištrinamos pagal įprastą duomenų saugojimo ciklą.
  • 18Siekiant įsitikinti, kad nebuvo atlikta jokia įtartina veikla, AB „Regitra“ gali atlikti paskutinių Tiekėjo veiksmų audito žurnalinių įrašų, užfiksuotų AB “Regitra”, analizę ir juos saugoti ne mažiau kaip 90 kalendorinių dienų nuo įrašo padarymo dienos.
  • 19Tiekėjas privalo užtikrinti, kad kibernetinio saugumo reikalavimų, įvardintų 9, 21, 22, laikytųsi ir sutarties vykdymui pasitelkiami subtiekėjai, kurie pasitelkiami TIS projektavimo, kūrimo, diegimo, naudojimo, priežiūros ar modernizavimo paslaugos teikti (jei pasitelkiami).
  • 20Sutarties vykdymo laikotarpiu AB „Regitra“ gali reikalauti Tiekėjo užtikrinti ir kitus KSRA pateiktus kibernetinio saugumo reikalavimus, taikomus esminiam kibernetinio saugumo subjektui, jei šis reikalavimas bus įvertintas kaip keliantis riziką Tiekėjo paslaugų ar (ir) AB „Regitra“ TIS saugumui užtikrinti, Tiekėjui ir AB „Regitra“ dėl to susitarus raštu.
  • 21AB „Regitra“ gali bent kartą per metus atlikti Tiekėjo teikiamos programinės įrangos kodo saugumo analizę, naudojant statinį (angl. SAST – Static Application Security Testing) arba dinaminį (angl. DAST – Dynamic Application Security Testing) programinės įrangos saugumo testavimą.
  • 22Programinės įrangos tiekėjui ir prižiūrėtojui – vykdyti prižiūrimos programinės įrangos atnaujinimus ir (ar) privilegijuotiems vartotojams prieigos prie AB „Regitra“ TIS taikyti technines priemones (pvz. angl. Privileged Access Management ar kitas), kurių pagalba fiksuoti jų atliekamus veiksmus ir pan.).

Kibernetinio saugumo reikalavimai sistemoms ir prieigoms

  • 1Tiekėjams prieiga prie AB „Regitra“ TIS gali būti suteikiama tik, jei Tiekėjai laikosi šio dokumento reikalavimų.
  • 2Tiekėjo darbuotojams ir paslaugoms AB „Regitra“ taikys žemiausios privilegijos principą – minimali, terminuota ir tik jų darbo funkcijoms vykdyti reikalinga prieiga prie AB „Regitra“ TIS ir informacinio turto.
  • 3AB „Regitra“ užtikrins, kad AB „Regitra“ nevieša informacija bus pasiekiama tik iš vidinio AB „Regitra“ tinklo arba naudojantis VPN (angl. Virtual Private Network).
  • 4Visi atliekami prisijungimai bus registruojami audito įrašuose ir kontroliuojami.
  • 5Kiekviena prieiga prie AB „Regitra“ informacinio turto bus AB „Regitra“ autentifikuota, autorizuota ir registruojama.
  • 6Rekomenduojama Tiekėjui naudoti sudėtingus slaptažodžius ir daugiapakopę autentifikaciją (angl. MFA – Multi-factor authentication).
  • 7Kompiuterinę darbo vietą sukonfigūruoti taip, jog prisijungti prie TIS būtų galima tik naudojant VPN (angl. Virtual Private Network) arba alternatyvią, didesnį ar tą patį saugumo lygį užtikrinančią technologiją.
  • 8Įsitikinti, kad TIS, iš kurios jungiamasi nuotoliniu būdu yra saugi – atnaujinta operacinė sistema ir kita programinė įranga, įdiegta, aktyvuota ir nuolatos atnaujinama antivirusinė programinė įranga, įjungta ir sukonfigūruota ugniasienė ir pan.
  • 9Užtikrinti nuolatinę prieigos teisių kontrolę.
  • 10Vykdyti nuolatinį veiksmų stebėjimą ir kontrolę arba rinkti ir saugoti žurnalinius įrašus ne trumpiau kaip 6 mėnesius arba ilgesnį laikotarpį, jei tai būtina teisės aktų, incidentų tyrimo ar rizikos valdymo tikslais.
  • 11Užtikrinti AB „Regitra“ viešai neskelbtinos ir kitos jautrios informacijos apsaugą organizacinėmis ir techninėmis priemonėmis.
  • 12Užtikrinti, kad nuotolinio prisijungimo ryšys būtų kontroliuojamas.
  • 13Užtikrinti, kad prisijungimas per nuotolinį ryšį ir nuotolinės prieigos suteikimas vyktų vadovaujantis principu „būtina žinoti“ bei turėtų sutartą galiojimo terminą, kuris būtų nurodytas sutartyje.
  • 14Kiekvienam naudotojui turi būti sukurtas individualus prisijungimo identifikatorius.
  • 15Prisijungdama nuotoline prieiga prie TIS trečioji šalis privalo patvirtinti savo tapatybę slaptažodžiu ir papildoma kelių veiksnių tapatumo nustatymo priemone, angl. Multi-factor authentication.
  • 16Prisijungimo slaptažodis trečiajai šaliai privalo būti perduotas atskirai nuo naudotojo prisijungimo identifikatoriaus, naudojant saugius ryšio kanalus.
  • 17Bet kokia nuotolinė prieiga, neatitinkanti šiame skyriuje aprašytų reikalavimų prie TIS, yra draudžiama.
  • 18Pasibaigus sutarties terminui ar pilnai suteikus paslaugas prieš sutarties pasibaigimo terminą, trečiųjų šalių prieigos prie TIS AB „Regitra“ bus nedelsiant sustabdytos ir (ar) panaikintos.
  • 19Turi būti naudojamas TLS standartas (1.3 versija arba naujesnė), jei tai palaiko Perkančiosios organizacijos ir serverio operacinės sistemos.
  • 20Administratoriaus funkcijos turi būti atliekamos naudojant atskirą tam skirtą paskyrą, kuri negali būti naudojama kasdienėms naudotojo funkcijoms atlikti.
  • 21Naudotojams negali būti suteikiamos administratoriaus teisės.
  • 22Kiekvienas naudotojas turi būti unikaliai atpažįstamas.
  • 23Naudotojas ir administratorius turi patvirtinti savo tapatybę slaptažodžiu ir papildoma tapatumo nustatymo priemone (kelių veiksnių tapatumo nustatymo priemonės), taikoma, jei Perkančiosios organizacijos nenaudoja Windows autentifikacijos, nes tokiu atveju tapatumo nustatymas yra Perkančiosios organizacijos pusėje.
  • 24Naudotojo teisė dirbti su konkrečia tinklų ir informacine sistema turi būti sustabdoma, kai naudotojas nesinaudoja tinklų ir informacine sistema ilgiau kaip 3 mėnesius.
  • 25Slaptažodis turi būti sudarytas iš didžiųjų ir mažųjų raidžių, skaičių ir specialiųjų simbolių, taikoma, jei nenaudojama Windows autentifikacija.
  • 26Turi būti nustatytas maksimalus leistinas naudotojų mėginimų prisijungti prie tinklų ir informacinių sistemų skaičius – ne daugiau negu 5 kartai iš eilės. Po numatyto bandymų skaičiaus prisijungti prie tinklų ir informacinių sistemų paskyra turi užsiblokuoti. Atblokuoti gali tik įgalioti asmenys. Reikalavimas taikomas, jei nenaudojama Windows autentifikacija.
  • 27Slaptažodis turi būti keičiamas ne rečiau kaip kas 6 mėnesius.
  • 28Slaptažodį turi sudaryti ne mažiau kaip 10 simbolių.
  • 29Pirmąkart jungiantis prie tinklų ir informacinių sistemų, turi būti reikalaujama, kad naudotojas pakeistų slaptažodį.
  • 30Naudotojas turi turėti galimybę bet kuriuo metu pasikeisti slaptažodį.
  • 31Programiniame kode draudžiama išsaugoti duomenis (vardą, slaptažodį, aplikacijų programavimo sąsajas (angl. Application programming interface) raktus / ženklus (angl. Token) ir kt.), kuriuos atskleidus gali būti pasinaudota prieiga prie įrenginių, resursų, paskyrų ar valdiklių.

Personalo valdymo ir darbo užmokesčio apskaitos funkcionalumas

  • 1Personalo valdymo, darbo laiko apskaitos, atostogų rezervo bei darbo užmokesčio skaičiavimo moduliai turi būti vieninga tarpusavyje integruota įrašų lygyje sistema: visi informacijos pakeitimai, įvedus duomenis viename modulyje, turi atsispindėti visuose su juo susijusiuose moduliuose.
  • 2Sistemoje turi būti kaupiama darbuotojo asmeninė tiesiogiai su darbo santykiais susijusi informacija (pvz.: vardas, pavardė, asmens kodas; asmens dokumento serija, numeris, asmens dokumentą išdavusios įstaigos pavadinimas; asmens dokumento išdavimo ir galiojimo datos; socialinio draudimo pažymėjimo serija ir numeris; a/s numeris banke; darbuotojo įdarbinimo data; darbo sutarties Nr., sudarymo data, darbuotojo paskutinio įdarbinimo ir/ar perkėlimo datos; departamentas; padalinys; tabelinis numeris, pareigų kodas, pavadinimas; namų adresas; telefonas; pilietybė, šeimos narių sudėtis, nurodant vaikų gimimo datas; bandomojo laikotarpio pabaiga, pastabos; informacija apie darbuotojo išsilavinimą ir kvalifikacijos kėlimą, informacija apie teisės egzaminuoti suteikimą, sustabdymą ar panaikinimą, duomenys apie neįgalumą, darbingumo lygį ir pan.).
  • 3Sistemoje turi būti duomenų (informacijos) pasikeitimo su SODRA galimybė apie apdraustuosius, kuriems išduoti elektroniniai nedarbingumo pažymėjimai arba nėštumo ir gimdymo atostogų pažymėjimai.
  • 4Sistema turi užtikrinti apsikeitimą duomenimis su VI „Regitra“ personalo apskaitos sistema PERIS.
  • 5Sistemoje turi būti sudaryta galimybė/šablonai automatiniam įvairių rūšių įsakymų parengimui (priėmimo, perkėlimo, atleidimo, atostogų, leidimų dirbti kitą darbą, drausminių nuobaudų, priedų, priemokų, pašalpų ir premijų skyrimo, skatinimų, kvalifikacijos kėlimo kursų organizavimo ir kt.) bei jų tvirtinimui.
  • 6Sistemoje turi būti vedama atostogų apskaita: galimybė įvesti duomenis apie kasmetines atostogas tiek kalendorinėmis, tiek darbo dienomis, nurodomas laikotarpis, už kurį suteikiamos atostogos; darbuotojams suteikiamos kasmetinės atostogos, tikslinės, skatinimo, papildomos kasmetinės atostogos (už nepertraukiamą darbo stažą), nurodomas laikotarpis, už kurį suteikiamos atostogos; nurodomi atšaukimai iš atostogų; pateikiama neišnaudotų atostogų informacija bet kuriai datai, nemokamos atostogos. Turi būti numatyta kasmetinių atostogų planavimo ir grafiko (eiles) sudarymo bei keitimo galimybė. Sistemoje turi būti galimybė iš atostogų grafiko parengti atostogų įsakymą ir susisieti su atostoginių skaičiavimo moduliu. Atostogų įsakymai turi turėti ne mažiau kaip 3 tvirtinimo lygius.
  • 7Sistemoje turi būti sudaryta galimybė vesti komandiruočių ir kitų neatvykimų į darbą apskaitą.
  • 8Sistemoje turi būti galimybė priskirti darbo grafiką kiekvienam darbuotojui individualiai ar grupei darbuotojų.
  • 9Sistemoje turi būti numatyta galimybė apskaičiuoti įvairių tipų atlyginimą už darbą (mėnesinis, valandinis, autorinis).
  • 10Sistemoje turi būti numatyta galimybė apskaičiuoti nepanaudotų atostogų rezervo pokytį kiekvieną mėnesį.
  • 11LABBIS 4.PRO sistemoje turi būti Internet/Intranet priėjimo savitarnos (Self service) galimybė: darbuotojui turi būti galimybė matyti savo kortelę, tabelį, darbo grafiką, Atsiskaitymo lapelį, nepanaudotas atostogas, pažymą apie darbo užmokestį.
  • 12Sistemoje turi būti galimybė išskirti vadovo savitarnos funkcionalumą.
  • 13Sistema turi paruošti statistines ataskaitas FFDATA formatu, apibrėžtu kompiuterinei programai ABBYY eFormFiller.

Dokumentai9

  • RK 1 priedas_Techninė specifikacija_LABBIS_priežiūra.docx
  • RK 2 priedas_ADTS_LABBIS_tech_priežiūra.docx
  • RK 2 priedas_Sutarties projektas_Bendrosios sąlygos (Labbis palaikymas).docx
  • Apibendrinta rinkos konsultacijos informacija 2026 03 .docx
  • Techninės specifikacijos priedas Nr. 1.docx
  • 1289_6985089.pdf
  • Rinkos konsultacija_Kvietimas.docx
  • RK 2 priedas_Sutarties projektas_Specialiosios sąlygos (Labbis palaikymas).docx
  • RK 3 priedas_Rinkos konsultacijos klausimynas.docx
tendis.lt · Sukurta recodin.lt