Üldkäskkiri

RAAMLEPING (edaspidi leping) nr 3-1/75

Poolte andmed

Tellija (Hankija) Siseministeeriumi infotehnoloogia- ja arenduskeskus

Registrikood 70008440

Aadress Mäealuse 2/2, 12618 Tallinn

Tellija esindaja

Esinduse alus Põhimäärus/volikiri

Kontaktisikud 1. Nimi, ametinimetus, e-post, telefon. 2.

Täitja (Pakkuja)

Registrikood

Aadress

Täitja esindaja

Esinduse alus Põhikiri/volikiri

Kontaktisikud 1. Nimi, ametinimetus, e-post, telefon. 2. …

Maksja

Registrikood

Aadress

Täitja esindaja

Esinduse alus Põhimäärus/volikiri

Kontaktisikud 1. Nimi, ametinimetus, e-post, telefon. 2. …

1. Üldised tingimused

1.1 Lepingu

sõlmimise alus

Riigihangete seaduse § 49 lg 1 p 2 ja § 72 alusel läbi viidud riigihanke „Piirikontrolli iseteeninduskioski raamhange“ (viitenumber 248377)

alusdokumendid ja täitja … pakkumus

1.2 Lepingu ese Iseteeninduslike piirikontrollikioskite hankimine

1.3 Rahastamisallikas Riigieelarve ja/või välisvahendid (täpne finantseerimisall ikas

täpsustatakse igakordses tellimuses ja/või hankelepingus), sh. Euroopa Liidu Sisejulgeolekufondi ja Eesti Vabariigi Siseministeeriumi projekti

ISFB-31 „Automaatse piirikontrollisüsteemi rajamine“ vahendid

1.4 Lepingu

maksimaalne

maksumus

1 000 000 eurot (km-ta)

1.5 Lepingu kehtivus Leping kehtib 4 aastat alates lepingu sõlmimisest või kuni maksimaa lse

maksumuse täitumiseni (kohaldub esimene täituv tingimus)

1.6 Lepingu sõlmimise

hetkel olemasolevad

lisad

Lisa 1 - Hankelepingu projekt; Lisa 1.1 - SMIT müügilepingute üldtingimused;

Lisa 1.2 - SMIT käsunduslepingute üldtingimused; Lisa 2 - Tellija tehniline kirjeldus;

Lisa 3 - Pakkuja pakkumus; Lisa 4 - Üleandmise-vastuvõtmise akti vorm; Lisa 5 – ISF märgistamise juhis

…

2(8)

2 Lepingu ese ja tellimine

2.1 Lepingu ja selle alusel sõlmitavate hankelepingute kohaselt täitja müüb ja tarnib ning tellija ostab

ja võtab vastu lepingu lisas 2 kirjeldatud lepingu esemeks olevad piirikontro lli iseteeninduskioskeid ja nendega kaasas käivaid tooteid ja teenuseid. Piirikontro lli

iseteeninduskioskite ostmine sisaldab endas: 2.1.1 piirikontrolli iseteeninduskioskite ostu; 2.1.2 piirikontrolli iseteeninduskioskite ülesepanekut;

2.1.3 tabletite ostu; 2.1.4 piirikontrolli iseteeninduskioski haldustarkvara tableti(te) jaoks;

2.1.5 piirikontrolli iseteeninduskioski haldustarkvara tööjaama(de) jaoks; 2.1.6 ABC väravate haldussüsteemi uuendamist (piirikontrolli iseteeninduskioskite tugi); 2.1.7 ABC väravate monitoorimissüsteemi uuendamise (piirikontrolli iseteeninduskiosk ite

tugi); 2.1.8 piirikontrolli iseteeninduskioski tootetuge;

2.1.9 tarkvara arendust. 2.2 Lepingu eseme ostmisel (punktid 2.1.1 ja 2.1.3) kehtivad SMIT müügilepingute üldtingimused

(lisa 1.1) ja punktides 2.1.2 ja 2.1.4 - 2.1.9 SMIT käsunduslepingute üldtingimused (lisa 1.2).

2.3 Lepingu punktis 2.1.1 ja 2.1.3 toodud esemed tarnitakse Tallinn, Mäealuse 2/2, kui hankelepingus ei ole toodud teisiti.

2.4 Täitja on kohustatud lepingu alusel ja selles sätestatud maksumuse eest teostama ka nn sidustöid, mis ei ole lepingus sõnaselgelt sätestatud, kuid mille teostamine on headest tavadest ja täitja ametialasest professionaalsusest lähtudes nõutavad ja/või vajalikud lepingust tuleneva eesmärgi

saavutamiseks. 2.5 Lepingu täitmine toimub vastavalt tellija vajadusele kogu lepingu kehtivuse jooksul tellija

esitatud tellimuste ja nende tulemusel sõlmitud hankelepingute alusel. Hankelepingud sõlmitakse poolte kokkuleppel lepingu kehtivusaja jooksul riigihangete seaduses ja käesolevas lepingus sätestatud korras. Lepingu kehtivusajal selle alusel sõlmitud hankelepingute tähtaeg

võib olla lepingu tähtajast lühem või pikem. Juhul, kui lepingu alusel sõlmitud hankeleping kehtib pärast lepingu lõppemist, kohaldatakse hankelepingule lepingu tingimusi kuni

hankelepingu täitmiseni. 2.6 Hankelepingud, mille käibemaksuta maksumused on 20 000 eurot või enam, sõlmitakse

kirjalikult. Eelnimetatust väiksemas rahalises mahus sõlmitava hankelepingu moodustavad

esitatud tellimuse alusdokumendid, pakkumus ja tellija aktsept, eraldi kirjalikku hankelepingut ei pea sõlmima, v.a kui selline tingimus on tellija poolt tellimuses sätestatud.

2.7 Lepingu eseme tellimiseks, mille eeldatav maksumus on 30 000,00 eurot või enam, esitab tellija pakkumuse esitamise ettepaneku koos hankelepingu eseme tehnilise kirjelduse ja hankelepingu projektiga.

2.8 Lepingu eseme tellimiseks, mille eeldatav maksumus on madalam kui 30 000,00 eurot, esitab tellija täitjatele kas e-riigihangete keskkonnas või e-posti teel tellimuse koos hankelepingu

eseme tehnilise kirjelduse ja vajadusel hankelepingu projektiga. Tellija tellimus peab sisaldama piisavat informatsiooni täitjale lepingukohase pakkumuse tegemiseks. Tellijal on õigus igal ajal enne tellimuse tegemist arutada tellimuse kõiki aspekte.

2.9 Lepingu eseme tarne üleandmise-vastuvõtmise osas kohaldatakse vastavalt lepingu punktile 2.2 kas SMIT müügilepingute üldtingimustes (lisa 1.1) või SMIT-i käsunduslepingute

üldtingimustes (lisa 1.2) sätestatut. 2.10 Pakkumuse esitamise täpne tähtaeg sätestatakse igakordselt pakkumuse esitamise ettepanekus.

Täitja esitab pakkumuse, mis on kooskõlas vastava tellimuse nõuetega.

2.11 Tellijal on õigus kaasata hankelepingute täitmisel tellija poolele maksja rollis kolmanda id osapooli, kelleks võivad olla eelkõige Siseministeerium ja selle valitsemisala asutused

(Häirekeskus, Politsei- ja piirivalveamet, Päästeamet, jt). Sellisel juhul sõlmitakse hankeleping kolmepoolsena.

3(8)

3 Lepingu täitmise üldised põhimõtted

3.1 Lepingu ese antakse täitja poolt tellijale üle vastavalt igakordse tellimuse ja hankelepingu

tingimustes sätestatule. Täitja kohustub tarne üle andma ühes osas ja vahetarneid ei teostata, välja arvatud, kui hankelepingus on sätestatud teisiti.

3.2 Juhul kui tarne üleandmist ei ole võimalik tähtaegselt teostada tellijast tingitud põhjustel, on täitjal õigus nõuda tarneaja proportsionaalselt hilisemaks lükkamist. Kõik taolised viivitused ja tähtaja nihutamised lepitakse kokku kirjalikku taasesitamist võimaldavas vormis (e-post).

3.3 Tellijal on õigus viie tööpäeva jooksul kontrollida tarne vastavust lepingutingimustele. 3.4 Juhul kui tellija avastab lepingu esemes vigu, puudusi või muu lepingutingimuste le

mittevastavuse, on tellijal õigus teavitada täitjat lepingu eseme lepingutingimuste le mittevastavusest ning määrata täitjale täiendav tähtaeg kestusega mitte rohkem kui 5 tööpäeva lepingu eseme lepingutingimustega vastavusse viimiseks.

3.5 Juhul kui täitja ei tarni lepingu punktis 3.4 sätestatud täiendava tähtaja jooksul tellijale lepingu eset ning kui tellija avastab lepingu esemes jätkuvalt vigu, puudusi või muu lepingutingimuste le

mittevastavuse, on tellijal õigus leping täitjapoolse lepingu olulise rikkumise tõttu üles öelda. 3.6 Kui täitja ei teosta tarnet lepingus kokkulepitud tähtajal, on tellijal õigus kohaldada täitja suhtes

leppetrahvi vastavalt lepingu punktile 6.2. Leppetrahvi tasumise kohustus algab kokkulepitud

tarne teostamise päevale järgnevast päevast, lepingu punkti 3.4 alusel täiendava tähtaja andmise korral alates täiendava tähtaja päevale järgnevast päevast, ning kestab kuni tarne vastuvõtmiseni

tellija poolt. 3.7 Kui täitja on tarninud lepingu esemeks oleva tarkvara lepingus sätestatud tähtaja sees, kuid

tellija on keeldunud lepingu eseme vastuvõtmisest lepingutingimustele mittevastavuse tõttu

ning andnud täitjale punkti 3.4 kohaselt täiendava tähtaja puuduste likvideerimiseks, hakkab leppetrahvi tasumise kohustus kulgema tegeliku tarnetähtaja päevale järgnevast päevast ning

kestab kuni lepingutingimustele vastava lepingu eseme üleandmiseni. 3.8 Täitja on kohustatud tagama lepingu eseme tarnimise ja teenuse osutamise vastavalt lepingule

ning kooskõlas täitjale kui ametialasele professionaalile esitatud asjakohaste nõuete ja hea

tavaga ning vastutama lepingu täitmise eest moel, mis ei riiva kolmandate osapoolte õigusi, sh intellektuaalomandi õigusi.

3.9 Tellijal on õigus igal ajal kontrollida lepingu eseme vastavust lepingule ning täitja kinnituste le ning nõuda täitjalt informatsiooni lepingu täitmise kohta, sh esindusõigust tõendavate dokumentide esitamist.

3.10 Tootetugi peab vastama vähemalt alljärgnevale: 3.10.1 teenindusaeg Eesti aja järgi tööpäeviti (E-R 8:00-18:00);

3.10.2 suhtluskeel: inglise; 3.10.3 Tellija teenindussoovidele reageerimine ja konsulteerimine e-posti või kokkuleppel

mõne muu vahendi teel.

4 Välisvahendite kasutamisest tulenevad nõuded

4.1 Välisvahendite kasutamise lõpptähtpäev on 31.12.2022.a. 4.2 Lähtuvalt rahastusallikast (välisvahendid) ning sellele kohalduvatest kohustuslikest nõuetest,

kohustub täitja tagama alljärgnevat:

4.2.1 kõigile projekti tegevusega seotud dokumentidele peab olema trükitud Euroopa Liidu ja Siseministeeriumi logo ning tunnuslause „Projekti kaasrahastavad Euroopa Liit

Sisejulgeolekufondi kaudu ja EV Siseministeerium“; 4.2.2 Euroopa Liidu ja Siseministeeriumi logo peab olema paigaldatud kõigile füüsilis te le

esemetele, mis on projekti läbiviimiseks ostetud;

4.2.3 toetuse ja kaasfinantseeringu nähtavuse tagamiseks esitatav Euroopa Liidu embleem ja Siseministeeriumi logo peavad vastama lisas 3, „ISF märgistamise juhis“, kirjeldatud

juhistele; 4.2.4 täitja võimaldab välisvahenditest finantseeritud lepingu korral järelevalve teostamiseks

volitatud isikutel viibida lepingu täitmises osalevate isikute ruumides ja territooriumil,

4(8)

mis on rajatud välisvahendite abil või mis on seotud toetuse kasutamisega ning teostada paikvaatlust.

5 Lepingu maksumus, arveldamise kord

5.1 Lepingu maksimaalne maksumus on 1 000 000 eurot, millele lisandub käibemaks. 5.1.1 ühe piirikontrolli iseteeninduskioski hind on … eurot; 5.1.2 ühe piirikontrolli iseteeninduskioski ülespaneku hind on … eurot;

5.1.3 ühe tableti hind on … eurot; 5.1.4 piirikontrolli iseteeninduskioski haldustarkvara ühe tableti versiooni hind on … eurot;

5.1.5 piirikontrolli iseteeninduskioski haldustarkvara ühe tööjaama versiooni hind on … eurot; 5.1.6 Ühe ABC väravate haldussüsteemi uuendamise (piirikontrolli iseteeninduskioskite tugi)

hind on … eurot;

5.1.7 Ühe ABC väravate monitoorimissüsteemi uuendamise (piirikontrolli iseteeninduskiosk ite tugi) hind on … eurot;

5.1.8 Ühe piirikontrolli iseteeninduskioski tootetoe hind ühes aastas on … eurot; 5.1.9 Tarkvara arenduse tunni hind on … eurot.

5.2 Punktides 5.1.1 kuni 5.1.9 sätestatud hinnad on tellija jaoks lõplikud ning sisaldavad kõiki

lepingu tingimuste täitmiseks vajalikke kulusid. Lepingus sätestatud hinnad kehtivad vastavas määras kogu raamlepingu perioodi.

5.3 Tellijal ei ole kohustust osta lepingu eset raamlepingu maksimaalses mahus. 5.4 Arveldamine toimub hankelepingute alusel. Hankelepingus sätestatud hind on lõplik hind, mis

kuulub tellija poolt vastava lepingu eseme eest tasumisele, sisaldades muuhulgas

intellektuaalomandi õiguste tasusid. Hankelepingus sätestatud hinda on õigus muuta üksnes lepingus või riigihangete seaduses sätestatud alustel.

5.5 Arveldamine toimub kooskõlas hankelepinguga peale tarne vastuvõtmist tellija poolt ja täitja esitatud arve alusel.

5.6 Täitja saadab tellijale Eesti e-arve standardile vastavad e-arved või välismaise täitja puhul pdf

formaadis e-posti aadressil [email protected]. E-arves peab lisaks standardis nimetatud andmetele olema toodud tellija kontaktisiku perekonnanimi, riigihanke viitenumber ja raamlepingu

number ja tellimuse viitenumber ning hankelepingu number, vajadusel ka välisvahend ite projekti number. E-arve tuleb saata e-arvete operaatori lahenduse kaudu ning loetakse laekunuks arve saaja e-arvete süsteemi laekumise kuupäevast.

5.7 Arve maksetähtaeg on 21 kalendripäeva, kui tellimuses ja hankelepingu tingimustes ei ole sätestatud teistsugust (pikemat või lühemat) tähtaega.

6 Vastutus

6.1 Täitja vastutab lepinguliste kohustuste rikkumisel vastavalt SMIT-i lepingute üldtingimustes

(lisa 1.1 ja 1.2) sätestatule. 6.2 Lisaks mujal lepingudokumentides sätestatule, on tellijal õigus nõuda ja täitjal on kohustus

maksta leppetrahvi lepingu eseme üleandmisega viivitamisel vastavalt punktis 3.4 kokkulepitule 0,5% konkreetse hankelepingu kogumaksumusest iga viivitatud kalendripäeva eest iga vastava juhtumi korral.

7 Lepingu kehtivus

7.1 Leping jõustub alates hetkest, mil pooled on lepingu allkirjastanud. 7.2 Käesoleva riigihanke tulemusel sõlmitav leping kehtib neli (4) aastat alates lepingu sõlmimises t

või kuni maksimaalse maksumuse täitumiseni sõltuvalt kumb asjaolu saabub varem. Lepingu kehtivusajal nende alusel sõlmitud hankelepingute tähtaeg võib olla lepingu tähtajast pikem.

7.3 Tellijal on õigus leping erakorraliselt üles öelda, kui täitja rikub lepingu või selle alusel

sõlmitava hankelepingu tingimusi.

8 Täitja kinnitused

5(8)

8.1 Täitja avaldab ja kinnitab, et: 8.1.1 ta on lepinguga ja riigihanke alusdokumentidega tutvunud ning mõistab täielikult

enesele võetavate kohustuste sisu ja tagajärgi ning on nõus nendes toodud tingimustega; 8.1.2 lepingu täitmisega ei kahjustata kolmandate isikute õigusi ja huve ning puuduvad

mistahes asjaolud, mis välistaksid tema õigusi sõlmida leping ja seda nõuetekohaselt täita;

8.1.3 ta on tutvunud lepingu lahutamatuks osaks olevate SMIT-i müügi- ja käsunduslepingute

üldtingimustega (lisad 1.1 ja 1.2).

Leping on allkirjastatud paberkandjal.

Lisa 1

HANKELEPINGU projekt

Hankelepingu punktid võivad muutuda sõltuvalt konkreetsest hankelepingu esemest

Poolte andmed

Tellija Siseministeeriumi infotehnoloogia- ja arenduskeskus

Registrikood 70008440

Aadress Mäealuse 2/2, 12618 Tallinn, Eesti Vabariik

Tellija esindaja

Esinduse alus Põhimäärus/volikiri

Kontaktisikud 1. Nimi, ametinimetus, e-post, telefon.

2. …

Täitja

Registrikood

Aadress

Täitja esindaja

Esinduse alus Põhikiri/volikiri

Kontaktisikud 1. Nimi, ametinimetus, e-post, telefon.

2. …

/vajadusel lisatakse maksja andmed/

1. Lepingu sõlmimise

alus

raamleping nr ..., tellija … tellimus , täitja … pakkumus

2. Lepingu ese …

3. Rahastamisallikas …

4. Lepingu eseme täitmine

4.1. Lepingu esemeks on ...

4.2. ….. 4.3. Hankelepingus kokku leppimata küsimustes lähtutakse raamlepingus sätestatust.

5 Hankelepingu maksumus ja arveldamise kord

5.1. Lepingu eseme kogumaksumus on ... eurot, lisandub käibemaks.

/vajadusel tuuakse välja tellitavate esemete ja teenuste mahud ning hinnakomponendid/ 5.2. Hankelepingus sätestatud hind on lõplik hind, mis kuulub tellija poolt vastava

lepingu eseme eest tasumisele. 5.3. Arve kuulub tasumisele ... 5.4. Arve maksetähtaeg on 21 kalendripäeva.

5.5. Täitja saadab tellijale Eesti e-arve standardile vastavad e-arved või välismaise täitja puhul pdf formaadis e-posti aadressil [email protected]. E-arves peab lisaks

standardis nimetatud andmetele olema toodud tellija ja maksja kontaktisiku perekonnanimi, riigihanke viitenumber ja lepingu number. E-arve tuleb saata e- arvete operaatori lahenduse kaudu ning loetakse laekunuks arve saaja e-arvete

süsteemi laekumise kuupäevast.

6. Hankelepingu kehtivus

7(8)

6.1. Hankeleping jõustub alates hetkest, kui pooled on hankelepingu allkirjastanud.

6.2. Hankeleping kehtib lepinguliste kohustuste täitmiseni.

7. Lepingu lisad

7.1. Lisa 1 – Tellija tellimus;

7.2. Lisa 2 – Täitja pakkumus;

7.3……...

Leping on koostatud ja allkirjastatud paberkandjal.

Lisa 4 Üleandmise-vastuvõtmise akti vorm

Alus (täida need read, mis kohalduvad):

Riigihanke viitenumber:

Raamleping nr…, sõlmitud ... a.,

Minikonkursi/tellimuse viitenumber:

Hankeleping nr …, sõlmitud … a.,

Välisvahenditest rahastatud projekti nr ja nimetus: … ja …..

Käesolevaga annab ………….. (täitja ettevõtte nimi) üle ning ……. (tellija ja maksja asutuse nimed)

võtavad vastu (edaspidi lepingu ese):

1. …….. (täida lepingu esemest tulenev võimalikult detailne sisu: tulemi maksumus; arendus- või

hooldusteenuste teostamise periood; arendus- või hooldustööde töötundide maht ja maksumus;

tootekood, selle kirjeldus, kogus, seerianumber, ühik- ja kogumaksumus);

2. …………..…(dokumentide loetelu).

Üleantava lepingu eseme maksumus on ………………. eurot (lisandub käibemaks).

………………. (täitja lepingujärgse kontaktisiku nimi) kinnitab, et lepingu ese on üleantud tähtaegselt,

vastavalt lepingus sätestatud tingimustele.

………………. (maksja lepingujärgse kontaktisiku nimi) kinnitab, et vastuvõetud lepingu ese vastab

lepingus sätestatud tingimustele ning lepingu ese on üleantud ja vastuvõetud vastavalt lepingus

sätestatud tähtajale ja tingimustele.

…………….. (tellija lepingujärgse kontaktisiku nimi) kinnitab, et vastuvõetud lepingu ese vastab

lepingus sätestatud tingimustele ning lepingu ese on üleantud ja vastuvõetud vastavalt lepingus

sätestatud tähtajale ja tingimustele.

Käesolev üleandmise-vastuvõtmise akt on allkirjastatud digitaalselt.

Täitja: Maksja: Tellija:

………………… ………………….. ………………….

/asutuse nimi/ /asutuse nimi/ /asutuse nimi/

………………….. ………………….. ………………….

/allkirjastaja nimi/ /allkirjastaja nimi/ /allkirjastaja nimi/

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

Siseministeeriumi infotehnoloogia- ja arenduskeskuse

MÜÜGILEPINGUTE ÜLDTINGIMUSED

1. Üldsätted

1.1. Leping koosneb käesolevatest üldtingimustest (edaspidi üldtingimused) ja eritingimustest

(edaspidi eritingimused) ning nende lisadest. 1.2. Lepingu eesmärgiks on reguleerida ostja (tellija) ja müüja (täitja) vahel lepingu alusel

tekkivaid õigussuhteid. 1.3. Lepingu täitmise keel on eesti keel, kui lepingus pole sätestatud teisiti.

1.4. Pooled on oma tegevuses iseseisvad ja kumbki pool ei vastuta teise poole poolt endale

kolmandate isikute ees võetud kohustuste täitmise eest.

1.5. Poolte õiguste ja kohustuste aluseks on Eesti Vabariigis kehtivad õigusaktid ja leping koos

selle juurde kuuluvate dokumentidega.

1.6. Pooled tagavad ja avaldavad, et lepingu sõlmimisega ei ole nad rikkunud ühegi enda suhtes

kehtiva seaduse, põhikirja või muu õigusakti sätet ega ühtki endale varem sõlmitud

lepingute ja kokkulepetega võetud kohustust.

1.7. Pooled kinnitavad ja tõendavad, et:

1.7.1. neil on seaduses ettenähtud piisav õigus- ja teovõime (füüsilisest isikust poole puhul)

lepingu sõlmimiseks ning lepingust tulenevate kohustuste täitmiseks ja õiguste

realiseerimiseks;

1.7.2. nende poolt lepingule ja selle lisadele allakirjutanud isikutele on antud piisavad

volitused selle lepingu sõlmimiseks kooskõlas põhikirjade, õigusaktide ja muude

asjakohaste dokumentidega.

1.8. Lepingu sõlmimisega kaotavad kehtivuse kõik pooltevahelised varasemad lepingud ja

muud kokkulepped niivõrd, kuivõrd need on vastuolus lepinguga.

2. Lepingu ese

2.1 Lepingu esemeks olevad kaubad ja nende kirjeldus on täpsemalt määratletud eritingimustes.

2.2 Müüja kinnitab, et lepingu järgi üleantavale kaubale ei ole kolmandatel isikutel mingeid

õigusi ning kolmandatel isikutel ei ole ka alust selliste õiguste taotlemiseks.

2.3 Kauba kvaliteet peab vastama lepingus kokkulepitud nõuetele ning kauba tootja

spetsifikatsioonis nimetatud tehnilistele ja kvaliteeditingimustele ning seda liiki kaubale

tavapäraselt esitatavatele kvaliteeditingimustele (sh kauba välimuse osas) jms.

3 Kauba üleandmine ja omandiõiguse üleminek

3.1 Kauba üleandmine müüjalt ostjale toimub lepingus märgitud tähtpäeval või tähtaja jooksul

ning selles märgitud kohas. Müüja informeerib ostjat eelnevalt täpsest kauba üleandmise

ajast veendudes, et ostja saab vastava teate kätte ning et ostjale sobib väljapakutud aeg.

Koos kaubaga annab müüja ostjale üle ka kauba juurde kuuluva dokumentatsiooni. 3.2 Kauba üleandmise-vastuvõtmise kohta vormistatakse üleandmise-vastuvõtmise akt. 3.3 Kauba omandiõigus ja juhusliku hävimise ning kahjustumise riisiko läheb müüjalt ostjale

üle kauba üleandmise-vastuvõtmise akti allkirjastamisega.

4 Kauba hind ja maksetingimused

4.1 Ostja tasub kauba eest vastavalt lepingus sätestatud tingimustele ja korrale kas peale poolte

poolt üleandmise-vastuvõtmise akti allkirjastamist ja selle alusel esitatud arve saamist või

peale kauba vastuvõtmist saadud arve alusel. Arve maksetähtaeg peab olema vähemalt 21

(kakskümmend üks) kalendripäeva arvates selle kättesaamisest.

4.2 Lepingus sätestatud kauba maksumus sisaldab endas muuhulgas kõiki müüja poolt lepingu

raames tehtavaid kulutusi.

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

4.3 Juhul kui kaup ei vasta lepingus toodud nõuetele, võib ostja lepingu maksumust ühepoolselt

alandada teavitades sellest müüjat kirjalikku taasesitamist võimaldavas vormis. Samuti võib

ostja kasutada kirjeldatud juhul muid seaduses sätestatud õiguskaitsevahendeid ning

võimalusi.

4.4 Kui müüja on Eestis registreeritud ettevõte saadab müüja ostjale Eesti e-arve standardile

vastava e-arve e-arvete operaatori Fitek AS kaudu (täpsem info http://www.fitek.ee/). Kui

müüja ei ole Eestis registreeritud ettevõte saadab müüja ostjale pdf formaadis e-posti

aadressil [email protected]. E-arve loetakse laekunuks selle Fitek AS-le laekumise

kuupäevast.

4.5 Arvel peab lisaks standardis nimetatud andmetele olema toodud ostja kontaktisiku

perekonnanimi, riigihanke viitenumber (kui on asjakohane), hanke- ja raamlepingu number

(kui on asjakohane) ja tellimuse viitenumber (kui on asjakohane) ning välisvahendite

projekti tunnus (kui on tegemist välisvahenditest rahastatava lepinguga).

4.6 Müüja poolt esitatav arve peab selgelt ja üheselt viitama lepingule. Käesolevas punktis ja

punktis 4.5 esitatud tingimustele mittevastav arve ei kuulu tasumisele. Arve maksetähtaeg

on 21 (kakskümmend üks) kalendripäeva, v.a juhul, kui kohalduvate välisvahendite

tingimustest tuleneb ja on konkreetses lepingus sätestatud teisiti.

5 Poolte vastutus. Vääramatu jõud

5.1 Lepingust tulenevate kohustuste täitmata jätmise või mittekohase täitmisega teisele poolele

tekitatud otsese varalise kahju eest kannavad pooled täielikku vastutust selle kahju ulatuses.

5.2 Müüja vastutab lepingurikkumise eest eelkõige, kui kaup ei vasta lepingus sätestatud

nõuetele, kaup ei ole tähtaegselt üle antud, müüja ei esita kauba üleandmisel kauba kohta

nõuetekohast dokumentatsiooni vms.

5.3 Lepingus sätestatud tarnetähtpäevast või -ajast või punktis 6.1 nimetatud tähtajast

mittekinnipidamise korral on ostjal õigus nõuda müüjalt leppetrahvi 1% (üks protsent)

lepingu hinnast iga viivitatud päeva eest.

5.4 Lepingus sätestatud tähtaegade ületamise korral müüja poolt või müüja poolt lepingus

sätestatud teiste kohustuste mittetäitmise või mittenõuetekohase täitmise korral on ostjal

lisaks muude õiguskaitsevahendite kasutamisele õigus leping erakorraliselt ühepoolselt

lõpetada, teatades sellest müüjale vastava kirjalikus vormis avaldusega.

5.5 Kui ostja viivitab lepingus sätestatud rahaliste kohustuste täitmisega, on müüjal õigus nõuda

ostjalt viivist 0,05% (null koma null viis protsenti) tähtaegselt tasumata summalt päevas,

kuid mitte rohkem kui 5% (viis protsenti) lepingu maksumusest.

5.6 Ostjal on õigus kauba eest tasumisel vähendada lepingu maksumust leppetrahvi summa

võrra. Lepingus sätestatud leppetrahvid on kokku lepitud kohustuste täitmisele sundimiseks

ning leppetrahvi nõudmine ei mõjuta ostja õigust nõuda müüjalt täiendavalt ka kohustuste

täitmist ja kahju hüvitamist.

5.7 Lepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta

lepingu rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Vääramatu jõu asjaolude

ilmnemisel pikeneb lepingu lõpptähtaeg nimetatud asjaolude esinemise perioodi võrra. Pool

peab vääramatu jõu asjaolude äralangemisel lepingut täitma asuma. Kui vääramatu jõu

asjaolude tõttu on poole lepingust tulenevate kohustuste täitmine takistatud enam kui 60

(kuuskümmend) kalendripäeva järjest, võib kumbki pool lepingu lõpetada.

5.8 Poolte koguvastutus lepingu täitmisel on piiratud lepingu kogumaksumusega, v.a

konfidentsiaalsuskohustuse rikkumisel tahtlikult või raskest hooletusest.

6 Garantii

6.1 Müüja annab kaubale 12 kuulise garantii, mis hakkab kehtima pärast kauba omandiõiguse

ja otsese valduse üleminekut ostjale, kui lepingus või garantiikirjas või muus dokumendis

ei ole ette nähtud garantiitähtaja ostjale soodsamat algust. Kauba suhtes esinevate

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

pretensioonide osas on müüja kohustatud ostja teatele reageerima esimesel võimalusel, kuid

mitte hiljem kui 24 (kahekümne nelja) tunni jooksul arvates teate saamisest, kui

eritingimustes ei ole sätestatud muud tähtaega.

6.2 Garantiitähtaja jooksul on müüja kohustatud tasuta parandama kauba puudused või tasuta

mittekvaliteetse kauba ümber vahetama, kui müüja ei tõenda, et puudused tekkisid

ostjapoolse kauba kasutamise või säilitamise eeskirjade rikkumise tulemusena ja kui müüja

on sellised kasutamise või säilitamise eeskirjad ostjale eelnevalt vähemalt kirjalikku

taasesitamist võimaldavas vormis teatavaks teinud. Eeldatakse, et garantiiga on hõlmatud

kõik kaubal garantiitähtaja jooksul ilmnenud puudused.

6.3 Garantiitähtaja kulg peatub ajal, mil ostja ei saa kaupa kasutada lepingutingimustele

mittevastavuse tõttu, mille eest ostja ei vastuta.

6.4 Juhul kui kaup vajab garantiihooldust, siis vastutab garantiihoolduse jälgimise,

kontrollimise ning läbiviimise eest ostja ees müüja.

6.5 Garantiiajal asendatud kaubale antakse algse garantiiga sama kestusega uus garantii.

6.6 Kauba parandamise korral pikeneb garantii parandamise aja kestuse võrra.

6.7 Garantii ei välista ega piira ostja õigust kasutada muid seadusest ja lepingust tulenevaid

õiguskaitsevahendeid.

7 Teadete edastamine ja kontaktisikud

7.1 Teadete edastamine toimub üldjuhul telefoni, e-posti või posti teel. Juhul kui teate

edastamisel on olulised õiguslikud tagajärjed, peavad teisele poolele edastatavad teated

olema edastatud kirjalikus vormis, muuhulgas näiteks poolte lepingu lõpetamise avaldused,

samuti poole nõue teisele poolele, mis esitatakse tulenevalt lepingu rikkumisest jms.

7.2 Lepinguga seotud teated edastatakse teisele poolele lepingus märgitud kontaktandmetel.

Kontaktandmete muutusest on pool kohustatud koheselt informeerima teist poolt. Juhul kui

pool on lepingu kehtivuse aja jooksul muutnud oma kontaktandmeid ning ei ole sellest teist

poolt kirjalikku taasesitamist võimaldavas vormis informeerinud, loetakse teade poole poolt

kättesaaduks, kui see on saadetud kõige viimastel poole poolt teatatud kontaktandmetel.

7.3 Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja vastu või kui

teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud aadressil ja

postitamisest on möödunud 5 (viis) kalendripäeva. E-posti teel saatmise korral loetakse

teade kättesaaduks kohale jõudmise teates märgitud kellaajal või e-kirjas näidatud saatmise

kellaajal.

7.4 Poolte kontaktisikud on määratud lepingu eritingimustes. Ostja kontaktisikul on õigus

esindada ostjat kõikides lepingu täitmisega seotud küsimustes, v.a lepingu muutmine (sh

lepingu mahu suurendamine, lepingu eseme või tähtaja oluline muutmine jms), lepingu

ühepoolne erakorraline lõpetamine ning leppetrahvi, viivise või kahjude hüvitamise nõude

esitamine.

8 Konfidentsiaalsus

8.1 Müüja kohustub lepingu kehtivuse ajal ning pärast lepingu lõppemist määramata tähtaja

jooksul hoidma konfidentsiaalsena kõiki talle seoses lepingu täitmisega teatavaks saanud

andmeid. Eelkõige, kuid mitte ainult, kohustub müüja hoidma konfidentsiaalsena andmeid,

mis sisalduvad lepingus, lepingu täitmiseks üleantud dokumentides ja muudes

dokumentides, mille sisuga on müüjal olnud võimalus seoses lepingu täitmisega tutvuda,

lisaks eeltoodule mistahes muid andmeid, mille konfidentsiaalsena hoidmise vastu on ostjal

eeldatavalt õigustatud huvi.

8.2 Konfidentsiaalse informatsiooni avaldamine kolmandatele isikutele on lubatud vaid ostja

eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul. Lepingus sätestatud

konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele poolte audiitoritele,

advokaatidele, pankadele ning juhtudel, kui pool on õigusaktidest tulenevalt kohustatud

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

informatsiooni avaldama. Müüja on teadlik, et leping on avaliku teabe seaduses sätestatud

ulatuses avalik.

8.3 Müüja kohustub täitma organisatsioonilisi, füüsilisi ja infotehnoloogilisi turvameetmeid

konfidentsiaalsete andmete kaitseks juhusliku või tahtliku volitamata muutmise, juhusliku

hävimise, tahtliku hävitamise, avalikustamise jms eest.

8.4 Müüja kohustub mitte kasutama konfidentsiaalset teavet mitte ühelgi viisil isikliku kasu

saamise eesmärgil ega kolmandate isikute huvides.

8.5 Muuhulgas kohustub müüja tagama, et tema esindaja(d), töötajad, lepingupartnerid ning

muud isikud, keda ta oma kohustuste täitmisel kasutab, oleksid käesolevas lepingus

sätestatud konfidentsiaalsuse kohustusest teadlikud ning nõudma nimetatud isikutelt selle

kohustuse tingimusteta ja tähtajatut täitmist.

9 Lepingu muutmine ja ülesütlemine

9.1 Lepingut võib muuta lepingu eritingimustes ette nähtud korras ja ulatuses või vastavalt

riigihangete seaduse §-le 123.

9.2 Ostjal on õigus sõltumata põhjusest leping igal ajal üles öelda, teatades müüjale vähemalt

60 (kuuskümmend) kalendripäeva ette. Nimetatud õigus on ostjal ka juhul, kui pooled on

kokku leppinud tähtajalises lepingus. Käesoleva punkti alusel lepingu ülesütlemisel

kohustub ostja tasuma müüjale ülesütlemise hetkeks faktiliselt üle antud esemete või

osutatud teenuste eest, muud summad hüvitamisele ei kuulu.

9.3 Poolel on õigus leping ennetähtaegselt ühepoolselt üles öelda, teatades sellest ette, kui:

9.4.1 teine pool on rikkunud lepingut ning pole rikkumist kõrvaldanud poole poolt määratud

mõistliku tähtaja jooksul; või

9.4.2 tegemist on olulise lepingu rikkumisega; või

9.4.3 rikkumine on korduv.

9.4 Lepingu ülesütlemisel müüja süü tõttu, on müüjal õigus nõuda tasu vaid lepingu

lõppemisehetkeks faktiliselt üle antud esemete või osutatud teenuste eest, mida ostjal on

tegelikkuses võimalik kasutada.

9.5 Lisaks mujal sätestatule, on poolel õigus igal ajal leping üles öelda juhul, kui:

9.6.1 lepingu täitmine on takistatud vääramatu jõu tõttu ning nimetatud mõju on peatanud

lepingu täitmist kauem kui kolm kuud; või

9.6.2 teise poole suhtes on alustatud pankrotimenetlust, pankrot on välja kuulutatud või tema

varad on arestitud või tema finantsseisund on teise poole põhjendatud hinnangul

oluliselt halvenenud ja see halvenemine muudab vähetõenäoliseks lepingu

nõuetekohase täitmise.

9.7 Ostja kohustub teostama kahe kuu jooksul lepingu lõppemisest lepingu kohase

lõpparvelduse.

9.8 Õigused ja kohustused, mis oma olemusest tulenevalt ei sõltu lepingu kehtivusest, jäävad

kehtima peale lepingu lõppemist.

10 Lõppsätted

10.1 Leping jõustub allakirjutamisest poolte poolt ja kehtib kuni lepingust tulenevate õiguste

realiseerimise ja kohustuste täitmiseni. Lepingu tingimusi võib muuta ainult

pooltevahelise kirjaliku või digitaalselt allkirjastatud kokkuleppega.

10.2 Pooled võivad lepingu erakorraliselt ühepoolselt lõpetada ja kasutada muid

õiguskaitsevahendeid jms lisaks lepingus sätestatule seaduses sätestatud juhtudel ja

korras.

10.3 Lepingu lõppemine ei mõjuta selliste kohustuste täitmist, mis oma olemuse tõttu kehtivad

ka pärast lepingu lõppemist (nt konfidentsiaalsuskohustus jms).

10.4 Pooled on kokku leppinud, et pooltel on õigus loovutada lepingust tulenevaid ja sellega

seotud õigusi ja kohustusi kolmandatele isikutele ainult teise poole eelneval kirjalikku

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

taasesitamist võimaldavas vormis antud nõusolekul. Kolmandale isikule õiguste ja

kohustuste loovutamiseks käesoleva sätte tähenduses ei ole müüja poolt lepingust

tulenevate ja sellega seotud õiguste ja kohustuste loovutamine teisele riigiasutusele või

riigi äriühingule.

10.5 Lepingule kohaldatakse Eesti Vabariigi õigust. Juhul kui lepingu mõni säte osutub

vastuolus olevaks Eesti Vabariigis kehtivate õigusaktidega, ei mõjuta see ülejäänud sätete

kehtivust. Kui kirjeldatud juhul on tegemist imperatiivsete sätetega, millest erinevalt ei

saa kokku leppida, viiakse seadusega vastuolus olevad sätted esimesel võimalusel kehtiva

regulatsiooniga kooskõlla.

10.6 Juhul, kui lepingu dokumendid on omavahel vastuolus, lähtutakse järgmisest

prioriteetsuse järjekorrast: 1) leping; 2) üldtingimused; 3) muud lepingu dokumendid. Juhul

kui vastuolus on hankeleping ja raamleping, lähtutakse hankelepingus sätestatust.

10.7 Lepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada,

antakse lahendamiseks Harju maakohtule.

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

Siseministeeriumi infotehnoloogia- ja arenduskeskuse

KÄSUNDUSLEPINGUTE ÜLDTINGIMUSED

1. Üldsätted

1.1. Leping koosneb käesolevatest üldtingimustest (edaspidi üldtingimused) ja eritingimustest

(edaspidi eritingimused) ning nende lisadest.

1.2. Lepingu eesmärgiks on reguleerida käsundiandja (tellija) ja käsundisaaja (täitja) vahel

lepingu alusel tekkivaid õigussuhteid.

1.3. Lepingu täitmise keel on eesti keel, kui lepingus pole sätestatud teisiti.

1.4. Pooled on oma tegevuses iseseisvad ja kumbki pool ei vastuta teise poole poolt endale

kolmandate isikute ees võetud kohustuste täitmise eest.

1.5. Poolte õiguste ja kohustuste aluseks on Eesti Vabariigis kehtivad õigusaktid ja leping koos

selle juurde kuuluvate dokumentidega.

1.6. Pooled tagavad ja avaldavad, et lepingu sõlmimisega ei ole nad rikkunud ühegi enda suhtes

kehtiva seaduse, põhikirja või muu õigusakti sätet ega ühtki endale varem sõlmitud

lepingute ja kokkulepetega võetud kohustust.

1.7. Pooled kinnitavad ja tõendavad, et:

1.7.1. neil on seaduses ettenähtud piisav õigus- ja teovõime (füüsilisest isikust poole puhul)

lepingu sõlmimiseks ning lepingust tulenevate kohustuste täitmiseks ja õiguste

realiseerimiseks;

1.7.2. nende poolt lepingule ja selle lisadele allakirjutanud isikutele on antud piisavad

volitused selle lepingu sõlmimiseks kooskõlas põhikirjade, õigusaktide ja muude

asjakohaste dokumentidega.

1.8. Lepingu sõlmimisega kaotavad kehtivuse kõik pooltevahelised varasemad lepingud ja muud

kokkulepped niivõrd, kuivõrd need on vastuolus lepinguga.

2. Lepingu ese

Käsundisaaja poolt osutatavad teenused on määratletud lepinguga ja selle juurde kuuluvate

dokumentidega. Käsundisaajale laieneb ka nende teenuste osutamise ja toimingute

teostamise, sh kõrvalkohustuste täitmise kohustus, mis ei ole lepingus sätestatud, kuid mis

oma olemusest lähtuvalt kuuluvad lepinguga seotud teenuste hulka. Nimetatu ei kuulu

teistsuguse kokkuleppe puudumisel eraldi tasustamisele ning käsundisaaja osutab need

teenused, teostab tööd ja toimingud lepingus fikseeritud tähtaja raames ja tasu eest.

3. Käsundisaaja kohustused Käsundisaaja on kohustatud:

3.1. osutama teenuseid omal kulul ja vastutusel hoolikalt ning professionaalsel tasemel

kooskõlas lepingu, õigusaktide, oma tegevus- või kutsealal kehtivate standardite ja heade

kommetega ning osutama neid käsundiandjale või tema poolt osutatud isikutele

kokkulepitud ajal ja korras. Kui pooled ei ole kirjalikku taasesitamist võimaldavas vormis

teisiti kokku leppinud, eeldatakse, et füüsilisest isikust käsundisaaja osutab lepingus

sätestatud teenused isiklikult. Käsundisaaja võib kohustuste täitmisel kasutada kolmandate

isikute kaasabi, kuid mitte anda täitmist üle kolmandale isikule, kui pooled ei ole kokku

leppinud teisiti, kusjuures käsundisaaja vastutab sellise kolmanda isiku tegevuse ja

tegevusetuse eest. Kolmandate isikute kaasamine teenuste osutamisele toimub käsundiandja

eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul ning tingimusel, et

kaasatud isikutega sõlmitud kokkulepped ei lähe vastuollu lepingutingimustega;

3.2. täitma lepingut käsundiandja jaoks parima kasuga ning hoidma ära kahju tekkimise

käsundiandjale;

3.3. tegutsema lepingust tulenevate kohustuste täitmisel käsundiandjale lojaalselt arvestades

käsundiandja huvidega ning neid huve kaitsma;

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

3.4. andma käsundiandjale viimase poolt nõutavas vormis teenuse osutamise kohta

informatsiooni, sh lepingu täitmisega seotud tuludest ja kuludest;

3.5. arvestama Käsundiandja poolt antavate juhiste ja ettepanekutega ning tegema koostööd

käsundiandja poolt osutatavate isikutega. Kui käsundisaaja soovib käsundiandja juhistest

kõrvale kalduda, kohustub ta sellest käsundiandjale kirjalikku taasesitamist võimaldavas

vormis teatama ja käsundiandja otsuse ära ootama. Juhul kui käsundiandja juhistest

kinnipidamisega kaasneks käsundiandjale ilmselt ebasoodus tagajärg, võib käsundisaaja

järgida käsundiandja juhiseid alles pärast seda, kui ta on juhtinud käsundiandja tähelepanu

ebasoodsale tagajärjele ja käsundiandja ei muuda sellele vaatamata juhiseid. Käsundisaaja

kohustub teavitama käsundiandjat kõigist lepingus sätestatud kohustuste täitmisega seotud

asjaoludest, mis võivad ajendada Käsundiandjat oma juhist muutma;

3.6. viivitamatult, kuid mitte hiljem kui 2 (kahe) tööpäeva jooksul alates vastavate asjaolude

ilmnemisest, kirjalikku taasesitamist võimaldavas vormis teatama käsundiandjale selliste

asjaolude ilmnemisest, millised takistavad käsundisaaja kohustuste kohast täitmist,

mõjutavad kvaliteedi saavutamist, maksumust või omavad lepingu täitmisele muud

ebasoodsat mõju vms. Seejuures ei anna eelnimetatud juhtumeil informeerimiskohustuse

täitmine käsundisaajale ilma käsundiandja vastavasisulise lepinguga samas vormis antud

nõusolekuta automaatselt õigust teenuste osutamise tähtaegu ületada, mitte kinni pidada

lepinguga teenuste suhtes kehtestatud kvaliteedinõuetest vms;

3.7. tasuma omal kulul kõik Lepingu täitmisega seotud autori- ja mistahes iseloomuga muud

tasud kolmandatele isikutele;

3.8. võimaldama käsundiandjal või käsundiandja kontaktisikul teostada igal ajal kontrolli

lepingu täitmise mahu ja kvaliteedi jms üle;

3.9. andma käsundiandjale välja selle, mille ta on lepingu täitmisega seoses saanud ja loonud

(sh seotud õigused), samuti selle, mille ta lepingu täitmiseks sai, kuid mida ta lepingu

täitmisel ei kasutanud, dokumentatsiooni jms. Samuti kohustub käsundisaaja andma

käsundiandjale üle andmed kolmandate isikute intellektuaalse omandi õiguste kohta seoses

lepingu alusel üleantud materjalide (nimi, funktsioon teenuste osutamisel, õiguste maht jms)

või osutatud teenustega;

3.10. täitma muid teenuste osutamisega kaasnevaid ning lepingus ja õigusaktides sätestatud

kohustusi;

3.11. järgima käsundiandja asukoha ruumide kasutamise korda ja teisi turvalisusega seotud

nõudeid ja piiranguid, mida käsundiandja on käsundisaajale tutvustanud enne lepingu

täitmisele asumist või lepingu täitmise ajal;

3.12. tagama, et tema poolt kaasatud meeskonnaliige kasutab talle eraldatud elektroonilist

läbipääsukaarti isiklikult ning registreerib sellega oma liikumise käsundiandja ruumides,

kui käsundiandja on võimaldanud meeskonnaliikmele juurdepääsu käsundiandja

ruumidesse;

3.13. tagama, et käsundisaaja poolt kaasatud meeskonnaliige kasutab käsundiandja poolt talle

kasutamiseks antud ligipääse infosüsteemidele üksnes isiklikult ning üksnes lepinguliste

kohustuste kohaseks täitmiseks. Käsundiandja poolt kasutada antud vahendite kasutamisel

ei ole käsundisaaja poolt kaasatud meeskonnaliikmel õiguspärast ootust privaatsusele ning

käsundiandja logib nende tegevusi seadmetes ja süsteemides;

3.14. kasutama käsundiandja poolt käsundisaajale või tema meeskonnaliikmele lepingu

täitmise käigus kasutamiseks antud käsundiandja vara otstarbekohaselt ja

heaperemehelikult ning tagama vara kaitstuse ja säilimise. Käsundisaaja kannab varalist

vastutust tema meeskonnaliikme tahtliku või hooletu käitumise tõttu käsundiandjale

tekitatud kahju eest;

3.15. täitma muid teenuse osutamisega kaasnevaid ning lepingus ja õigusaktides sätestatud

kohustusi.

4. Käsundisaaja õigused Käsundisaajal on õigus:

4.1. nõuda käsundiandjalt lepingutingimustest kinnipidamist;

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

4.2. määrata teenuse osutamise aeg, koht ja viis, arvestades lepingut, käsundiandja juhiseid,

käsundiandja tegevuse spetsiifikat, vajadusi jms;

4.3. saada käsundiandjalt teenuste osutamise eest tasu lepingus sätestatud tingimustel ja korras;

4.4. teha käsundiandjale ettepanekuid teenuste osutamise osas, esitades selle kohta omapoolsed

põhjendused kirjalikku taasesitamist võimaldavas vormis, mille käsundiandja vaatab läbi ja

teatab käsundisaajale otsustusest ettepaneku arvestamise või arvestamata jätmise kohta; 4.5. nõuda käsundiandjast sõltuvate õigusvastaste takistuste kõrvaldamist teenuste osutamisel;

4.6. nõuda teenuste osutamisega seotud koosolekute korraldamist, kui see on vältimatu teenuste

normaalseks osutamiseks, tähtaegadest kinnipidamiseks ja kvaliteedi tagamiseks.

Käsundiandja korraldab käsundisaaja eelkirjeldatud nõudmisel koosoleku 2 (kahe)

tööpäeva jooksul alates käsundisaaja vastavast kirjalikku taasesitamist võimaldavas vormis

edastatud nõudmisest.

4.7. teostada muid lepingus ja õigusaktides sätestatud õigusi.

5. Käsundiandja kohustused

Käsundiandja on kohustatud:

5.1. maksma käsundisaajale teenuste osutamise eest tasu lepingus sätestatud tingimustel ja

korras;

5.2. looma käsundisaajale teenuste osutamiseks vajalikud tingimused vastavalt eritingimustes

sätestatule;

5.3. andma käsundisaajale teenuse osutamise kohta juhiseid, kui käsundisaaja neid vajab ja

vastavat soovi avaldab;

5.4. mitte tegema käsundisaajale põhjendamatult takistusi teenuste osutamisel; 5.5. vastu võtma käsundisaaja poolt nõuetekohaselt osutatud lepingujärgsed teenused; 5.6. osalema teenuste osutamisega seotud korralistel koosolekutel; 5.7. täitma muid lepingus ja õigusaktides sätestatud kohustusi.

6. Käsundiandja õigused

Käsundiandjal on õigus:

6.1. nõuda käsundisaajalt lepingutingimustest kinnipidamist;

6.2. õigus anda käsundisaajale teenuste osutamiseks juhiseid;

6.3. teostada igal ajal järelevalvet teenuse osutamise mahu, kvaliteedi ja muude tingimuste üle;

6.4. põhjendatult keelduda kooskõlastamast käsundisaaja poolt kooskõlastamiseks

esitatud ettepanekuid;

6.5. kutsuda kokku poolte koosolek, sellest käsundisaajale võimalusel 2 (kaks) tööpäeva

kirjalikku taasesitamist võimaldavas vormis ette teatades;

6.6. lisaks seaduses sätestatud juhtudele pikendada lepingu täitmise tähtaega kuni kuue kuu

võrra;

6.7. lisaks seaduses sätestatud juhtudele tellida käsundisaajalt täiendavaid teenuseid kuni 30%

ulatuses lepingu algsest kogumaksumusest ühikhindade alusel ning pikendada selle võrra

lepingu täitmise tähtaega;

6.8. kaasata lepingu täitmisse käsundiandja poolele (eelkõige maksja rollis) teisi riigiasutusi.

7. Lepingu maksumus

7.1. Lepingu maksumus sisaldab endas muuhulgas käsundisaaja poolt lepingu raames tehtavaid

kõiki kulutusi ja tasu lepingus sätestatud autoriõiguste eest (autori varaliste õiguste

loovutamine ja isiklike õiguste osas kasutusõiguse ehk litsentsi andmine), samuti kõiki muid

teenuste osutamiseks tehtud kulutusi.

7.2. Käsundiandja tasub käsundisaajale nõuetekohaselt osutatud teenuste eest vastavalt

eritingimustes sätestatule, kas peale poolte poolt üleandmise-vastuvõtmise akti

allkirjastamist ning selle alusel esitatud arve saamist ja selle heakskiitmist või peale teenuste

osutamist esitatud arve saamist või füüsilisest isikust käsundisaaja korral peale poolte poolt

üleandmise- vastuvõtmise akti allkirjastamist.

7.3. Arve maksetähtaeg peab olema vähemalt 21 (kakskümmend üks) kalendripäeva arvates

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

selle kättesaamisest. Juhul kui lepingu maksumus tasutakse füüsilisest isikust

käsundisaajale, makstakse lepingu täitmise eest hiljemalt 14. (neljateistkümnendal)

kalendripäeval pärast tööde üleandmise-vastuvõtmise akti allkirjastamist.

7.4. Kui käsundisaaja on Eestis registreeritud ettevõte saadab käsundisaaja käsundiandjale Eesti

e-arve standardile vastava e-arve e-arvete operaatori Fitek AS kaudu (täpsem info

http://www.fitek.ee/). Kui käsundisaaja ei ole Eestis registreeritud ettevõte saadab

käsundisaaja käsundiandjale pdf formaadis e-posti aadressil [email protected]. E-arve

loetakse laekunuks selle Fitek AS-le laekumise kuupäevast.

7.5. Arvel peab lisaks standardis nimetatud andmetele olema toodud käsundiandja kontaktisiku

perekonnanimi, riigihanke viitenumber (kui on asjakohane), hanke- ja raamlepingu number

(kui on asjakohane) ja tellimuse viitenumber (kui on asjakohane) ning välisvahendite

projekti tunnus (kui on tegemist välisvahenditest rahastatava lepinguga).

7.6. Käsundisaaja poolt esitatav arve peab selgelt ja üheselt viitama lepingule. Käesolevas

punktis ning punktis 7.5 esitatud tingimustele mittevastav arve ei kuulu tasumisele. Arve

maksetähtaeg on kakskümmend üks kalendripäeva, v.a juhul, kui kohalduvate

välisvahendite tingimustest tuleneb ja on konkreetses lepingus sätestatud teisiti.

7.7. Juhul kui pooled on lepingus sätestanud lepingu maksimaalse maksumuse, käsitlevad

pooled nimetatud summat indikatiivsena, s.t. kui leping öeldakse kooskõlas lepingu

tingimustega üles või on käsundiandja esitanud lepingu alusel tellimusi lepingu lõppemise

hetkeks väiksemas mahus kui on lepingu maksimaalne maksumus, ei kuulu maksimaalse

maksumuse ja tegeliku maksumuse vahe käsundisaajale välja maksmisele ega muul moel

hüvitamisele.

7.8. Juhul kui käsundiandjal on alus nõuda käsundisaajalt leppetrahvi ja/või kahju hüvitamist,

on käsundiandjal õigus leppetrahv ja/või kahjutasu maha arvata lepingu alusel

käsundisaajale tasumisele kuuluvast summast.

7.9. Juhul kui lepingu täitmisel selgub käsundiandja soovidest tulenev vajadus täiendavate

teenuste osutamiseks või teenuste osutamiseks viisil, mis erineb algselt kokkulepitust ning

millega kaasneb teenuste mahu muutumine, lepitakse lepingu maksumuse muutumine

poolte vahel kokku lepinguga samas vormis.

7.10. Juhul kui teenuste osutamine ei vasta lepingus toodud nõuetele, võib käsundiandja

lepingu maksumust ühepoolselt alandada, teavitades sellest käsundisaajat kirjalikku

taasesitamist võimaldavas vormis.

8. Teenuste kvaliteet. Üleandmine ja vastuvõtt

8.1. Osutatud teenuste kvaliteet peab vastama vähemalt lepingus toodud nõuetele ja antud

teenustele tavapäraselt esitatavatele nõuetele. Nimetatud nõuetele peavad vastama ka

teenuste osutamisega seotud dokumendid jms.

8.2. Osutatud teenuse üleandmine ja vastuvõtt toimub vastavalt eritingimustes sätestatule, kas

üleandmise-vastuvõtmise akti(de) allkirjastamisega poolte poolt või arve heakskiitmisega

käsundiandja poolt. Käsundiandjal on õigus keelduda nõuetele mittevastavate teenuste

vastuvõtmisest, näidates ära keeldumise konkreetsed põhjused.

8.3. Käsundiandjal on kümme tööpäeva aega kontrollida vastuvõtmiseks esitatud teenuste

lepingutingimustele vastavust ning üleandmise-vastuvõtmise akti allkirjastamiseks.

Käsundiandja võib nimetatud tähtaega pikendada, kui pikendamine on põhjendatud.

8.4. Kui lepingu eseme vastuvõtmine toimub arve heakskiitmise teel, tuleb see sätestada lepingu

eritingimustes, tellimuses või pakkumise esitamise ettepanekus.

8.5. Juhul kui käsundiandjal ei ole punktis 8.3 nimetatud tähtaja jooksul üleandmise-

vastuvõtmise akti allkirjastanud ega teatanud tähtaja pikendamisest, loetakse lepingu ese

vastuvõetuks ning vastuvõtmise hetkeks punktis 8.3 sätestatud tähtaja möödumisele

järgnevat kalendripäeva. Käesolevas punktis sätestatu ei kuulu kohaldamisele juhul, kui

leping ei ole täielikult rahastatud riigieelarvest (välisvahendite kasutamisel).

8.6. Juhul kui käsundiandja avastab vastuvõtmiseks esitatud lepingu esemes vigu, puudusi või

muu lepingutingimustele mittevastavuse, on käsundisaaja lepingu rikkumises ning

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

rikkumise kõrvaldamine toimub käsundiandja sellekohaste juhiste alusel.

8.7. Käsundiandjal on õigus puudustega lepingu eseme vastuvõtmisest keelduda näidates ära

keeldumise põhjused või võtta puudustega lepingu ese vastu, lisades puuduste või

vaegtööde nimekirja koos puuduste kõrvaldamise tähtajaga üleandmise-vastuvõtmise akti.

Akti allkirjastamisega kinnitab käsundisaaja, et on teadlik aktis märgitud puuduste

kõrvaldamise ja vaegtööde teostamise tähtaegadest ning võtab kohustuse nendest

tähtaegadest kinni pidada. Kõrvaldatud puuduste kohta vormistatakse eraldi üleandmis-

vastuvõtmise akt.

8.8. Kui käsundiandjal puuduvad lepingu eseme osas pretensioonid, allkirjastavad pooled

lepingu eseme üleandmise-vastuvõtmise akti.

8.9. Käsundisaaja annab käsundiandjale koos üleandmise-vastuvõtmise aktiga üle lepingu

eseme juurde kuuluva tehnilise ja muu lepingu eseme kasutamiseks ja haldamiseks vajaliku

dokumentatsiooni käsundiandja soovi kohaselt kas paberil ja/või elektroonilisel

andmekandjal (CD/DVD vms) ja/või e-posti teel või paigaldab selle käsundiandja näidatud

keskkonda.

8.10. Juhul kui lepingu esemeks on arendustööd ning arendustööde üleandmiseks ei ole

üleandmise-vastuvõtmise akti allkirjastatud ja ei kohaldu punkt 8.5, loetakse arendustööde

vastuvõtmise ajaks päeva, mil käsundiandja on töö tervikuna toodangukeskkonnas (live)

kasutusele võtnud. Käesolevas punktis sätestatu ei kuulu kohaldamisele juhul, kui leping ei

ole täielikult rahastatud riigieelarvest (välisvahendite kasutamisel).

8.11. Töötundide kajastamisele ja arveldamisele kohalduvad alljärgnevad põhimõtted:

8.12.1 käsundisaaja poolt kaasatud meeskonnaliige kohustub käsundiandja tööülesannete

haldussüsteemis või kokkuleppel käsundiandjaga muus keskkonnas, käsundiandja poolt

defineeritud tööülesannete juurde märkima selle teostamisele kulunud töötundide arvu;

8.12.2 töötundide eest arveldamine toimub vastavalt haldussüsteemis fikseeritud ja

käsundiandja poolt aktsepteeritud töötundide arvule.

8.12. Käsundiandja poolt lepingu eseme vastuvõtmine ei vabasta käsundisaajat vastutusest

lepingu eseme üleandmisel-vastuvõtmisel avastamata jäänud osutatud teenuse puuduste

või teenuse mittenõuetekohasuse eest ning käsundisaaja kohustub lepingu eseme

üleandmise hetkel esinenud vastavad vead või puudused kõrvaldama omal kulul

mõistliku aja jooksul.

8.13. Kui käsundisaaja ei nõustu käsundiandja poolt lepingu eseme vastuvõtmisest

keeldumisel või puudustega või vigadega vastuvõtmisel tuvastatud vigade või puuduste

olemasoluga, on käsundiandjal õigus nõuda ekspertiisi teostamist. Sel juhul tellib

käsundisaaja käsundiandja poolt osundatud lepingu eseme puuduste või vigade

tuvastamiseks käsundiandjaga kokku lepitud isikult ekspertiisi. Kui ekspertiisi

tulemusel ilmneb, et teenuse vastuvõtmisest keeldumine on olnud põhjendamatu,

hüvitab käsundiandja käsundisaajale ekspertiisikulud, vastasel korral kannab

ekspertiisikulud käsundisaaja. Kui ekspertiisi tulemusel ilmneb, et käsundiandja

osundatud lepingu eseme puudused või vead olid osaliselt põhjendatud, hüvitab

käsundiandja käsundisaajale ekspertiisikulud proportsionaalselt üksnes nende puuduste

või vigade osas ekspertiisi kogukuludest, mille puudumist ekspertiis on tuvastanud.

9. Poolte vastutus. Vääramatu jõud 9.1. Käsundisaaja vastutus: 9.1.1. Käsundisaaja vastutab igasuguse lepingurikkumise eest, eelkõige kui teenuste

osutamine ei vasta lepingus ja selle lisades kokkulepitud nõuetele. Teenuste osutamine

loetakse muuhulgas mittevastavaks juhul, kui käsundisaaja ei esita teenuste üleandmisel

- vastuvõtmisel nõuetekohast dokumentatsiooni, ei osuta teenuseid tähtaegselt, jätab

käsundiandjale lepingu täitmise kohta informatsiooni esitamata vms.

9.1.2. Juhul kui käsundisaaja rikub lepingust tulenevat kohustust, mille heastamine ei ole

võimalik või kui käsundiandjal ei ole heastamise vastu huvi, on käsundiandjal õigus

nõuda käsundisaajalt leppetrahvi 5% (viis protsenti) lepingu maksumusest iga

rikkumise eest. Juhul kui tegemist on olulise lepingurikkumisega, on käsundiandjal

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

lisaks leppetrahvinõudele õigus ka leping erakorraliselt ühepoolselt lõpetada.

9.1.3. Juhul kui käsundisaaja rikub lepingust tulenevat kohustust, mille heastamine on

võimalik, on käsundiandjal õigus esitada käsundisaajale nõue rikkumiste

kõrvaldamiseks (edaspidi

ettekirjutus), andes käsundisaajale rikkumise kõrvaldamiseks mõistliku tähtaja

(sõltuvalt teenuste iseloomust, rikkumise asjaoludest jms, kuid üldjuhul mitte rohkem

kui 5 (viis) tööpäeva). Kirjeldatud ettekirjutuse tegemist kohaldatakse vaid selliste

kohustuste puhul, mille puhul käsundiandja seda kohustuse olemusest tulenevalt

mõistlikuks peab ning kui tal on heastamise vastu huvi. Kui käsundisaaja ei täida

ettekirjutust selleks antud tähtaja jooksul, peab käsundisaaja maksma käsundiandjale

0,5 % lepingu maksumusest päevas iga rikkumise kõrvaldamisega viivitatud päeva eest,

välja arvatud punktis 9.1.4 sätestatud juhtudel, mil kohaldatakse nimetatud punktis

sätestatud leppetrahvimäära. Samuti on käsundusandjal õigus leping erakorraliselt

ühepoolselt lõpetada, kui käsundisaaja viivitab rikkumise kõrvaldamisega vaatamata

käsundiandja poolsele ettekirjutusele. Juhul kui tegemist on olulise rikkumisega, ei pea

käsundiandja käsundisaajale rikkumise kõrvaldamiseks täiendavat tähtaega andma ning

võib lepingu olulise rikkumise esinemisel erakorraliselt ühepoolselt lõpetada.

9.1.4. Juhul kui käsundisaaja viivitab teenuste osutamise või üleandmisega üle lepingus kokku

lepitud tähtpäevade, on käsundiandjal õigus nõuda käsundisaajalt leppetrahvi, mille

suuruseks on 1% (üks protsent) osutamata teenuste maksumusest iga viivitatud päeva

eest ja leping erakorraliselt ühepoolselt lõpetada.

9.1.5. Käsundisaaja kohustub hüvitama kõik kulud ja kahjud, mis tekivad käsundiandjale

seoses käsundisaaja poolt osutatud teenuste mittenõuetekohase osutamisega.

9.1.6. Punktist 12 tulenevate kohustuste mittejärgimise korral on tegemist olulise

lepingurikkumisega ning käsundiandjal on õigus leping erakorraliselt ühepoolselt

lõpetada ja nõuda leppetrahvi 5% (viis protsenti) lepingu maksumusest iga rikkumise

eest. Antud punkti alusel lepingu lõpetamisel tasub käsundiandja käsundisaajale üksnes

faktiliselt osutatud teenuste osa eest, kui käsundiandjal on selle osa vastu huvi.

9.1.7. Lepingu erakorraline ühepoolne lõpetamine ei võta käsundiandjalt õigust nõuda

käsundisaajalt leppetrahvi ja kahju hüvitamist. Juhul kui ühe ja sama rikkumise eest

võimaldab leping nõuda leppetrahvi mitme sätte alusel, on käsundiandjal õigus

otsustada, millise sätte alusel ta leppetrahvi nõuab.

9.1.8. Käsundiandjal on õigus teenuste eest tasumisel vähendada lepingu maksumust

leppetrahvi summa võrra. Lepingus sätestatud leppetrahvid on kokku lepitud kohustuste

täitmisele sundimiseks ning leppetrahvi nõudmine ei mõjuta käsundiandja õigust nõuda

käsundisaajalt täiendavalt ka kohustuse täitmist ja kahju hüvitamist. 9.1.9. Kui käsundiandja viivitab lepingus sätestatud rahaliste kohustuste täitmisega, on

käsundisaajal õigus nõuda käsundiandjalt viivist 0,05% (null koma null viis protsenti) päevas tähtaegselt tasumata summalt, kuid mitte rohkem kui 5% (viis protsenti) lepingu maksumusest.

9.2. Lepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta

lepingu rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Kui vääramatu jõu

asjaolude tõttu on poole lepingust tulenevate kohustuste täitmine takistatud enam kui 60

(kuuskümmend) kalendripäeva järjest, võib kumbki pool lepingu lõpetada.

9.3. Poolte koguvastutus lepingu täitmisel on piiratud lepingu kogumaksumusega, v.a

konfidentsiaalsuskohustuse rikkumisel tahtlikult või raskest hooletusest.

10. Teadete edastamine ja kontaktisikud

10.1. Teadete edastamine toimub üldjuhul telefoni, e-posti või posti teel. Juhul kui teate

edastamisel on olulised õiguslikud tagajärjed, peavad teisele poolele edastatavad teated

olema edastatud kirjalikus vormis, muuhulgas näiteks poolte lepingu lõpetamise avaldused,

samuti poole nõue teisele poolele, mis esitatakse tulenevalt lepingu rikkumisest jms.

10.2. Lepinguga seotud teated edastatakse teisele poolele lepingus märgitud kontaktandmetel.

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

Kontaktandmete muutusest on pool kohustatud koheselt informeerima teist poolt. Juhul kui

pool on lepingu kehtivuse aja jooksul muutnud oma kontaktandmeid ning ei ole sellest teist

poolt kirjalikku taasesitamist võimaldavas vormis informeerinud, loetakse teade poole poolt

kättesaaduks, kui see on saadetud kõige viimastel poole poolt teatatud kontaktandmetel.

10.3. Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja vastu või

kui teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud aadressil ja

postitamisest on möödunud 5 (viis) kalendripäeva. E-posti teel, sh digitaalselt allkirjastatud

dokumentide, saatmise korral loetakse teade kättesaaduks kohale jõudmise teates märgitud

kellaajal või e-kirjas näidatud saatmise kellaajal.

10.4. Poolte kontaktisikud on määratud lepingu eritingimustes. Käsundiandja kontaktisikul

on õigus esindada käsundiandjat kõikides lepingu täitmisega seotud küsimustes, v.a lepingu

muutmine (sh lepingu mahu suurendamine, lepingu eseme või tähtaja oluline muutmine

jms), lepingu ühepoolne erakorraline lõpetamine ning leppetrahvi, viivise või kahjude

hüvitamise nõude esitamine.

11. Omandiõigus. Autoriõigused. Dokumentide ja informatsiooni säilitamine

11.1 Lepingu alusel käsundisaaja poolt loodud või tema poolt kolmandatelt isikutelt

omandatud ja lepingu alusel käsundiandja poolt vastuvõetud ning tasutud mistahes teenuste

osutamise resultaadid ja nendega seotud võõrandatavad intellektuaalse omandi õigused, sh

autori kõik varalised õigused (edaspidi „õigused“) lähevad lepingu eseme vastuvõtmisega

lepingus sätestatud tasu eest täies mahus üle käsundiandjale. Lepingu eseme suhtes

kehtivate intellektuaalse omandi õiguste osas, mis oma olemuselt üleantavad ei ole, sh

autori isiklikud õigused, annab käsundisaaja käsundiandjale arvates lepingu eseme

üleandmisest tagasivõtmatu kogu autoriõiguste kehtivuse aja kehtiva ainulitsentsi.

Käsundiandjal on pärast lepingu eseme vastuvõtmist muuhulgas õigus omal äranägemisel

otsustada lepingu eseme kasutamisega seonduvad asjaolud, sh otsustada lepingu eseme

avaldamise viis, lepingu eseme kasutamise algusaeg ja tingimused, teha muudatusi,

täiendusi ja parandusi lepingu esemes või selleks olevas teoses, nende pealkirjades või

autorinime tähistuses, lisada lepingu esemele või lepingu esemeks olevale teosele teiste

isikute teoseid ja õigus vaidlustada lepingu eseme, selle pealkirjade ja autorinime tähistuses

tehtavaid moonutusi ning nende kohta antud kahjustavaid hinnanguid, ning nõuda lepingu

eseme kasutamise lõpetamist (ainulitsents koos all- litsentseerimisõigusega). Käsundisaaja

kohustub tagama, et tal on kõik õigused eelpool nimetatud viisil varalised õigused loovutada

ja isiklike õiguste osas ainulitsents anda.

11.2 Lepingu eseme kasutamise viis ega territoorium ei ole piiratud, st neid võib kasutada

mistahes viisil (sh internetikeskkonnas) ja kogu maailmas.

11.3 Käsundisaajal ei ole ilma käsundiandja eelneva kirjaliku nõusolekuta õigust kasutada

lepingu eset või lepingu esemeks olevat teost või selle iseseisva tähendusega osasid või

õigusi.

11.4 Käsundisaaja poolt lepingu alusel kogutud informatsioon või selle töötlused loetakse

käsundiandja omandiks ja lepingu lõppemise korral või käsundiandja nõudmisel on

käsundisaaja kohustatud viivitamatult omal kulul üle andma käsundiandjale kogu tema

valduses oleva sellise informatsiooni. Samuti kuulub käsundiandjale andmekandja, mille

vahendusel lepingu ese või selle juurde kuuluvad dokumendid reprodutseeritakse,

omandiõigus.

11.5 Kõik lepingu alusel loodud mistahes vormis ja sisuga projektid, plaanid, joonised,

spetsifikatsioonid ja muud dokumendid, mis on loodud käsundisaaja poolt või sattunud

käsundisaaja valdusesse või kontrolli alla lepingu alusel teenuste osutamisel, loetakse

käsundiandja omandiks. Kui pooled ei lepi kokku teisiti, on käsundisaaja lepingu lõppemise

korral või käsundiandja nõudmisel kohustatud oma kulul viivitamatult tagastama

käsundiandjale kõik tema valduses olevad ja eespool viidatud dokumendid, muud

infokandjad ja tehnilised vahendid.

11.6 Kui kolmas isik takistab käsundiandjat tema lepingust tulenevate intellektuaalse omandi

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

õiguste kasutamisel või rikub neid õigusi, teatab käsundiandja sellest käsundisaajale, kes

peab viivitamata võtma tarvitusele kõik vajalikud abinõud, et võimaldada lepingust

tulenevate õiguste kasutamist ja lõpetada käsundiandja õiguste rikkumine. Kui käsundisaaja

võtab sellised abinõud tarvitusele, teeb käsundiandja temaga vajalikul määral koostööd.

11.7 Juhul kui käsundiandja vastu esitatakse nõue teenuste osutamisel toimunud

autoriõiguste rikkumise tõttu, vastutab käsundiandjale tekkinud kahju eest käsundisaaja.

12 Konfidentsiaalsus

12.1 Käsundisaaja kohustub lepingu kehtivuse ajal ning pärast lepingu lõppemist määramata

tähtaja jooksul hoidma konfidentsiaalsena kõiki talle seoses lepingu täitmisega teatavaks

saanud andmeid. Eelkõige, kuid mitte ainult, kohustub käsundisaaja hoidma

konfidentsiaalsena andmeid, mis sisalduvad lepingus, lepingu täitmiseks üleantud

dokumentides ja muudes dokumentides, mille sisuga on käsundisaajal olnud võimalus

seoses lepingu täitmisega tutvuda, lisaks eeltoodule mistahes muid andmeid, mille

konfidentsiaalsena hoidmise vastu on käsundiandjal eeldatavalt õigustatud huvi.

12.2 Konfidentsiaalse informatsiooni avaldamine kolmandatele isikutele on lubatud vaid

käsundiandja eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul.

Lepingus sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele poolte

audiitoritele, advokaatidele, pankadele ning juhtudel, kui pool on õigusaktidest tulenevalt

kohustatud informatsiooni avaldama. Käsundisaaja on teadlik, et leping on avaliku teabe

seaduses sätestatud ulatuses avalik.

12.3 Käsundisaaja kohustub täitma organisatsioonilisi, füüsilisi ja infotehnoloogilisi

turvameetmeid konfidentsiaalsete andmete kaitseks juhusliku või tahtliku volitamata

muutmise, juhusliku hävimise, tahtliku hävitamise, avalikustamise jms eest.

12.4 Käsundisaaja kohustub mitte kasutama konfidentsiaalset teavet mitte ühelgi viisil

isikliku kasu saamise eesmärgil ega kolmandate isikute huvides.

12.5 Muuhulgas kohustub käsundisaaja tagama, et tema esindaja(d), töötajad,

lepingupartnerid ning muud isikud, keda ta oma kohustuste täitmisel kasutab, oleksid

käesolevas lepingus sätestatud konfidentsiaalsuse kohustusest teadlikud ning nõudma

nimetatud isikutelt selle kohustuse tingimusteta ja tähtajatut täitmist.

13 Nõuete ja kohustuste üleandmine ja lepingu ülesütlemine

13.1 Käsundiandjal on õigus sõltumata põhjusest leping igal ajal üles öelda, teatades

käsundisaajale vähemalt kuuskümmend kalendripäeva ette. Nimetatud õigus on

käsundiandjal ka juhul, kui pooled on kokku leppinud tähtajalises lepingus. Käesoleva

punkti alusel lepingu ülesütlemisel kohustub käsundiandja tasuma käsundisaajale

ülesütlemise hetkeks faktiliselt üle osutatud teenuste eest, muud summad hüvitamisele ei

kuulu.

13.2 Poolel on õigus leping ennetähtaegselt ühepoolselt üles öelda, teatades sellest ette, kui:

13.2.1 teine pool on rikkunud lepingut ning pole rikkumist kõrvaldanud poole poolt määratud

mõistliku tähtaja jooksul; või

13.2.2 tegemist on olulise lepingu rikkumisega; või

13.2.3 rikkumine on korduv.

13.3 Lepingu ülesütlemisel käsundiandja süü tõttu, on käsundisaajal õigus nõuda tasu vaid

lepingu lõppemisehetkeks faktiliselt osutatud teenuste või üle antud resultaatide eest, mida

käsundiandjal on tegelikkuses võimalik kasutada.

13.4 Lisaks mujal sätestatule, on poolel õigus igal ajal leping üles öelda juhul, kui:

13.4.1 lepingu täitmine on takistatud vääramatu jõu tõttu ning nimetatud mõju on peatanud

lepingu täitmist kauem kui 60 kalendripäeva; või

13.4.2 teise poole suhtes on alustatud pankrotimenetlust, pankrot on välja kuulutatud või tema

varad on arestitud või tema finantsseisund on teise poole põhjendatud hinnangul

oluliselt halvenenud ja see halvenemine muudab vähetõenäoliseks lepingu

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

nõuetekohase täitmise.

13.5 Lepingu lõppemise kohase arvelduse kohustub käsundiandja teostama kahe kuu jooksul

lepingu lõppemise hetkest.

13.6 Õigused ja kohustused, mis oma olemusest tulenevalt ei sõltu lepingu kehtivusest, jäävad

kehtima peale lepingu lõppemist.

14 Lõppsätted

14.1 Leping jõustub allakirjutamisest poolte poolt ja kehtib kuni lepingust tulenevate õiguste

realiseerimise ja kohustuste täitmiseni. Lepingu tingimusi võib muuta ainult pooltevahelise

kirjaliku või digitaalselt allkirjastatud kokkuleppega.

14.2 Pooled võivad lepingu erakorraliselt ühepoolselt lõpetada ja kasutada muid

õiguskaitsevahendeid jms lisaks lepingus sätestatule seaduses sätestatud juhtudel ja korras.

14.3 Lepingu lõppemine ei mõjuta selliste kohustuste täitmist, mis oma olemuse tõttu

kehtivad ka pärast lepingu lõppemist (nt konfidentsiaalsuskohustus, kokkulepped lepingu

eseme suhtes kehtivate intellektuaalse omandi õiguste osas jms).

14.4 Pooled on kokku leppinud, et pooltel on õigus loovutada lepingust tulenevaid ja sellega

seotud õigusi ja kohustusi kolmandatele isikutele ainult teise poole eelneval kirjalikku

taasesitamist võimaldavas vormis antud nõusolekul. Kolmandale isikule õiguste ja

kohustuste loovutamiseks käesoleva sätte tähenduses ei ole käsundiandja poolt lepingust

tulenevate ja sellega seotud õiguste ja kohustuste loovutamine teisele riigiasutusele või riigi

äriühingule.

14.5 Lepingule kohaldatakse Eesti Vabariigis kehtivat õigust. Juhul kui lepingu mõni säte

osutub vastuolus olevaks Eesti Vabariigis kehtivate õigusaktidega, ei mõjuta see ülejäänud

sätete kehtivust. Kui kirjeldatud juhul on tegemist imperatiivsete sätetega, millest erinevalt

ei saa kokku leppida, viiakse seadusega vastuolus olevad sätted esimesel võimalusel kehtiva

regulatsiooniga kooskõlla.

14.6 Juhul, kui lepingu dokumendid on omavahel vastuolus, lähtutakse järgmisest

prioriteetsuse järjekorrast: 1) leping; 2) üldtingimused; 3) muud lepingu dokumendid. Juhul

kui vastuolus on hankeleping ja raamleping, lähtutakse hankelepingus sätestatust.

14.7 Lepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada,

antakse lahendamiseks Harju maakohtule.

14.8 Üldtingimused on koostatud 9 (üheksal) lehel.

1

Lisa 2 - Tehniline kirjeldus / Technical specification for the Self-service kiosk for Border

Control Point

The project is co-financed by the European Union via the Internal Security Fund and Estonian

Ministry of Interior ISFB-31 „Creation of Automatic Border Control system (Tallinna-1 ja Narva-

1)“

For the internal use

Notation made

The access restriction is valid until

Basis: clause 35 (1) 9) and 10) of the

Estonia’s Public Information Act

SMIT

2

CONTENTS

1 INTRODUCTION ........................................................................................................................ 5

1.1 SCOPE OF TENDER ............................................................................................................ 6

1.2 STRUCTURE OF THIS DOCUMENT ................................................................................ 7

1.3 TERMINOLOGY .................................................................................................................. 7

1.4 DEFINITIONS AND ABBREVIATIONS............................................................................ 8

1.4.1 DEFINITIONS................................................................................................................ 8

1.4.2 ABBREVIATIONS ........................................................................................................ 9

1.5 REFERENCES AND STANDARDS.................................................................................. 11

2 GENERAL DESCRIPTIONS..................................................................................................... 15

2.1 BACKGROUND INFORMATION .................................................................................... 15

2.1.1 Saatse BCP.................................................................................................................... 15

2.2 SAFETY .............................................................................................................................. 15

2.3 MANAGEMENT OF MASTERLISTS............................................................................... 16

2.4 REQUIREMENTS TO GATE MODULE CONSTRUCTION....................................... 16

2.5 DOCUMENT READER .................................................................................................. 17

2.6 FACIAL IMAGE CAPTURE CAMERA........................................................................ 18

2.7 FINGERPRINT READER .............................................................................................. 18

2.8 USER INTREFACES (SCREENS) ............................................................................. 18

2.9 KIOSK IDENTIFICATION ............................................................................................ 19

2.10 KIOSK OPERATING CONDITIONS .......................................................................... 20

2.11 REQUIREMENTS TO KIOSK FUNCTIONALITY ........................................................ 20

3 REQUIREMENTS TO SYSTEM DOCUMENTATION .......................................................... 20

4 REQUIREMENTS TO THE KIOSK MANAGEMENT ........................................................... 20

5 TECHNICAL REQUIREMENTS TO THE HARDWARE....................................................... 21

5.1 DOCUMENT READER ...................................................................................................... 21

5.1.1 DOCUMENT FORMATS ............................................................................................ 21

5.1.2 READING THE OPTICAL DATA.............................................................................. 21

5.1.3 RFID CHIP READER .................................................................................................. 21

5.1.4 CERTIFICATION AND COMPLIANCE OF THE DOCUMENT READER ............ 22

5.1.5 PERFORMANCE CAPABILITIES AND TEMPORAL REQUIREMENTS ............. 22

5.1.6 COMMUNICATION REQUIREMENTS FOR THE RF-READING MODULE ....... 23

5.1.7 CHIP APPLICATION SUPPORT................................................................................ 23

5.1.8 AUTOMATION REQUIREMENTS ........................................................................... 23

3

5.2 FINGERPRINT READER .................................................................................................. 23

5.3 IMAGE CAPTURE CAMERA ........................................................................................... 23

5.3 LIGHTING ...................................................................................................................... 24

5.4 TABLET .............................................................................................................................. 24

6 REQUIREMENTS TO THE PROCEDURES OF DOCUMENT READING AND

VERIFICATION PROCESS ......................................................................................................... 25

6.1 VISUALISATION OF CHECK RESULTS ........................................................................ 25

6.2 WORKFLOW.................................................................................................................. 26

6.3 CHECKS TO BE CONDUCTED IN COURSE OF THE TRANSACTION PROCESS ... 26

6.4 PROCESS SEQUENCE OF CHECKING A MRTD .......................................................... 27

6.5 OPTICAL CHECKS ............................................................................................................ 28

6.5.1 DOCUMENT MODEL................................................................................................. 28

6.5.2 REQUIREMENTS TO THE OPTICAL CHECK PROCEDURES ............................. 29

6.6 ELECTRONIC CHECKS OF MRTDS ............................................................................... 30

6.6.1 SUPPORT OF THE FOLLOWING ALGORITHMS, PROTOCOLS AND SECURITY

MECHANISMS..................................................................................................................... 30

6.6.2 FILES AND DATA GROUPS TO BE SUPPORTED ................................................. 31

6.6.3 ELECTRONIC CHECK FLOWCHARTS ................................................................... 32

6.6.4 PROCESSING SEQUENCES ...................................................................................... 35

6.6.5 CHIP ACCESS USING BAC OR PACE PROTOCOLS............................................. 35

6.6.6 CHECKING CHIP ACCESS BY TERMINAL AUTHENTICATION (TA) .............. 37

6.6.7 CHECKING THE CHIP AUTHENTICITY (AA, CA) ............................................... 37

6.6.8 CHECKING THE ELECTRONIC DATA AUTHENTICITY WITH PASSIVE

AUTHENTICATION (PA) ................................................................................................... 39

6.6.9 MASTERLIST IMPLEMENTATION ............................................................................. 39

6.6.10 VERIFICATION OF THE SECURITY OBJECTS ................................................... 39

6.6.11 CHECKING ISSUER CERTIFICATES .................................................................... 40

6.6.12 CHECKING INTEGRITY OF CHIP CONTENTS ................................................... 41

6.6.13 COMPARISON OF THE ISSUING STATE (DG1 AND DS CERTIFCATE) ......... 43

6.7 COMBINED CHECKS ....................................................................................................... 43

6.7.1 CROSS VERIFICATION OF MRZ DATA ................................................................. 43

6.7.2 VERIFICATION OF DOCUMENT VALIDITY......................................................... 44

6.8 BIOMETRIC ENROLLMENT AND CHECKS ................................................................. 44

6.8.1 REQUIREMENTS TO THE CAMERA IMAGE QUALITY ..................................... 45

6.8.2 REQUIREMENTS TO THE CAMERA IMAGE QUALITY ASSURANCE............. 45

6.8.1 REQUIREMENTS TO THE FINGERPRINT IMAGES QUALITY .......................... 46

4

6.8.2 REQUIREMENTS TO THE FINGERPRINTS IMAGE QUALITY ASSURANCE.. 46

6.8.3 REQUIREMENTS TO THE LOCAL BIOMETRIC COMPARISON AT KIOSK .... 47

6.8.4 REQUIREMENTS TO THE LOCAL BIOMETRIC COMPARISON CODING AT

KIOSK ................................................................................................................................... 47

6.9 ERROR CODES AND LOGGING ..................................................................................... 47

6.9.1 TRANSACTION LOGGING ....................................................................................... 47

7 DEFECTS ................................................................................................................................... 51

7.1 OPTICAL DEFECTS .......................................................................................................... 51

7.2 ELECTRONIC DEFECTS .................................................................................................. 52

7.3 BIOMETRIC ENROLLMENTCOMPARISON DEFECTS ............................................... 52

8 DATA/INFORMATION EXCHANGE ..................................................................................... 52

8.1 INFORMATION EXCHANGE WITH THE KIOSK OPERATOR DESKTOP

WORKSTATION UI ................................................................................................................. 52

8.2 INFORMATION EXCHANGE WITH THE KIOSK OPERATOR MOBILE UI ............. 54

8.3 INSTRUCTIONS FOR A TRAVELLER............................................................................ 55

8.4 DATA EXCHANGE WITH PIKO...................................................................................... 56

9 REQUIREMENTS TO SECURITY OF THE SOLUTION ....................................................... 56

9.1 SECURING THE COMMUNICATION ............................................................................. 56

10 REQUIREMENTS TO SERVICE LEVEL AGREEMENT .................................................... 57

10.1 KEY PERFORMANCE INDICATORS ........................................................................... 57

11 ADDITIONAL INFORMATION............................................................................................. 57

11.1 EAC AND FINGERPRINT ENROLLMENT................................................................... 57

11.2 LIST OF MESSAGES TO KIOSK OPERATOR ............................................................. 57

11.3 LIST OF MESSAGES TO A TRAVELLER .................................................................... 58

12 ANNEX 2. FUNCTIONALITY UPGRADES ......................................................................... 59

12.1 CHANGES IN ELECTRONIC CHECKS PROTOCOL SEQUENCES .......................... 59

12.2 CHANGES DUE IMPLEMENTING MASTERLISTS, DEFECTLISTS ETC. ............... 61

13 REQUIREMENTS DEFINITION AND TENDER EVALUATION ...................................... 61

13.1 REQUIREMENTS DEFINITION ..................................................................................... 61

13.1.1 MINIMUM REQUIREMENTS ................................................................................. 61

5

FIGURES

Figure 1. Kiosk location in Saatse BCP

Figure 2. Process sequence of checking MRTDs Figure 3. Temporal sequence of MRTD checking process Figure 4. Principal process sequence of optical checks.

Figure 5. Detailed process sequence of optical checks

Figure 6. Protocol Sequence 1 performing BAC

Figure 7. Protocol Sequence 2 performing PACE, CA1 or AA

Figure 8. Protocol Sequence 3, performing PACE, TA2, CA2

Figure 9: Protocol Sequence 4, support of PACE-CAM

Figure 10: Workflow-based document check with TR-03135-1-compliant logging

Figure 11: Protocol Sequence 1, performing BAC

Figure 12: Protocol Sequence 2, performing PACE, CA1 or AA

Figure 13: Protocol Sequence 3, performing PACE, TA2, CA2

Figure 14: Protocol Sequence 4, support of PACE-CAM

TABLES

Table 1: Scope of Tender

Table 2: Interpretation of keywords

Table 3: Definitions

Table 4: Abbreviations

Table 5: References

Table 6: Visualisation of check results

1 INTRODUCTION

Herewith the Contracting Authority has decided to initiate a project to introduce machine readable

electronic travel document automated check of the EU citizens subject to a ‘minimum check’ on

the Schengen Border in Estonian Republic. The aim of the project is to facilitate MRTD data

selfserviced acquisition and delivery to the IT systems of the Estonian Police and Border Guard

Board (PPGB) for quick processing of personal data and automate decision making process.

For accomplishing of the goals set the Contracting Authority intends to acquire a self-service kiosk

solution providing more advanced self-services for travellers than is in use at present. The

requirements in this Technical Specification are provided to explain the details of technical and

procedural parameters to achieve the service level required. The Solution has to be designed in a

way which allows for extension in future developments. Foreseeable aspects of future upgrade and

extension can be found in Chapter 11 of this Specification.

All the kiosk operations MUST be conformant to the requirement in this Technical Specificat ion

and relevant standards in order to guarantee trustworthiness and security of information sent for

making border crossing decisions.

The Contracting Authority will install software needed for kiosk operators to the Border Control

workstations and tablets.

The Solution is classified as providing Self Service operations according to [BSI-TR-03135-2-v2-

1].

6

The solution is classified as a one-step procedure consisting of following operations:

• Giving directions to the travellers crossing the border;

• Traveller e-MRTD check;

• Facial biometric image capture;

• Comparison of facial images from the facial image capture camera and MRTD DG2;

• Delivery of the comparison result and content of DG1 to the PIKO system of the PBGB;

• Interrupting semi-automatic border crossing procedure and guiding travellers to manual

inspection in case of errors in MRTD check or comparison of facial images.

It is recommended to treat the definitions and descriptions as described in “Machine Readable

Travel Documents” [ICAO9303] as well as in the ICAO “Technical Report on Machine Assisted

Document Security Verification” [ICAOMADSV1]. Regarding modern electronic Identity

Documents, the Technical Guidelines [TR-03110], [TR-03121], [TR03127] and [TR-03135] are

recommended.

Unless otherwise stated, the requirements in this document apply to all software and hardware

components offered by the Vendor in the framework of this Tender. All requireme nts SHALL be

considered mandatory if not clearly specified otherwise.

All components supplied by the Vendor SHALL make it possible for the Inspection System and

Inspection Application to completely implement and meet all relevant requirements of standards ,

regulations, guidelines and recommendations provided in Table 5 hereunder.

1.1 SCOPE OF TENDER

Table 1 describes the scope of the components of the tender. Refer to Chapter 2 for further

description of each component.

Solution component Scope

Self-service kiosk The Vendor SHALL set up physically and prepare to connect to CA

networks self-service kiosk in border control point to gather and deliver to PBGB PIKO system information needed for making border crossing decisions and operating kiosk according to the instruction commands from the kiosk operator software.

The hard- and software upgrade schedule SHALL be agreed with the

CA but the Vendor SHALL provide major upgrades to the kiosk and

mission and security critical updates upon their becoming available.

Tablets with protective

covers and charging

docks

Portable devices for observation and control individual kiosk areas

locally and from distance.

Kiosk management

software user interface

version for tablets

Software used for kiosk operating.

7

Kiosk management

software operators’

user interface version

for desktop

workstations

Software used for kiosk operating.

ABC gate management

server software

solution update

Software update for ABC gate management server software

to support the operating of the kiosk according to commands from the

kiosk management software.

ABC gate monitor ing

server software solution

update

Software update to support the gathering of technical status information

from the kiosk and delivering alerts to the servicing personnel.

Licenses The Vendor SHALL submit proof that he has all the licenses required to

operate the kiosk, contingent hard- and software. Licenses MUST cover

all the components purchased in course of this Tender.

Table 1: Scope of Tender

1.2 STRUCTURE OF THIS DOCUMENT

Chapter 2 contains overall requirements. Here description of premises are provided, requirements

to the kiosk and components etc. are described.

Chapter 3 contains requirements to system documentation. Documents mandatory to be provided

by the Vendor are listed here.

Chapter 4 requirements to actual kiosk management. How to get access, how to manage data, how

to react to commands and overrides are described here.

Chapter 5 contains technical requirements to the hardware. Physical and operational paramete rs

and details of various hardware components of the Solution are provided here.

Chapter 7 contains requirements to the procedures of document reading and verification process.

Overall workflow, optical, electronic, biometric and combined checks are dealt with

here.

Chapter 8 contains requirements and performing in handling of defective documents.

Chapter 9 contains requirements to data exchange between user interfaces, PIKO and kiosk.

Chapter 10 contains Security aspects of the Solution.

Chapter 11 contains additional information related to readiness to implementation of EAC and also

topics due to be agreed during execution of the Contract.

Chapter 12 contains information about the changes in electronic check workflows related to

implementation of EAC and changes due to implementation of RCC.

Chapter 13 contains requirements definition and tender evaluation example

1.3 TERMINOLOGY

Requirements as defined in this Specification can be mandatory, recommended or optional. All the

requirements in this document are mandatory if not otherwise clearly specified.

8

MUST, SHALL,

REQUIRED, NORMATIVE

The implementation is an absolute requirement of the

specification and must be used/included.

RECOMMENDED, NOT

RECOMMENDED,

SHOULD, SHOULD NOT

The requirements are recommendations, this means that there

may exist valid reasons in particular circumstances to ignore a

particular item or requirement, but the full implications must be

understood and carefully weighed before choosing a different

course.

MAY, OPTIONAL The requirements are not binding. One operator or vendor may

choose to include it, another may omit it.

MUST NOT, SHALL NOT A so-called requirement is an absolute prohibition of the

specification.

Table 2: Interpretation of keywords

1.4 DEFINITIONS AND ABBREVIATIONS

1.4.1 DEFINITIONS

Term Definition

Contracting Authority The term Contracting Authority is used to refer to (SMIT) as

responsible for the tender process and as responsible Commissioning

Party.

EAC-PKI Extended Access Control Public Key Infrastructure – the

infrastructure required to control read access to fingerprint biometric s

on Passports and Travel Documents through Extended Access

Control.

eMRTD Term used to encompass all electronic Machine Readable Travel

Documents, hereunder electronic Passports, Residence Permits, Local

Border Traffic Permits and National Identity Cards containing ICAO

Doc 9303 compatible RFID chip and acceptable by law for Schengen

Border crossing.

Kiosk Self-standing kiosk providing self-service capabilities for border

control.

Inspection Application Software supervising document reading, face enrollment, biometr ic

comparison, data delivery to the PIKO.

Inspection System In the scope of the present tender the system containing document

reading hard- and software, facial image comparison software and

user interface to display information to the person at self-service

kiosk. Inspection System gets its input data from a full-page flatbed

document reader and facial image capture camera. Hard- and software

for fingerprint enrollment and comparison will be added when

corresponding upgrade to the system will be made.

Internal Defect List The defect list used for internal purposes, in particular for border

control. It MUST contain all known defects.

9

Terminal Inspection System (IS) as defined in [BSI_TR_03110_1] p.2.2.

Travel Document An identity document compliant to [ICAO9303] and acknowledged as

such due to [ICAO9303] or international agreements.

Operator Term is used to cover all human personnel that require system access

to operate, administer or audit the kiosk.

PIKO Border Control System of the PBGB.

Vendor The term is used throughout this specification to refer to the vendor,

tenderer/bidder or contractor in all phases of the procurement and

delivery of the requested solution.

ABC Gates

Management solution

Secunet Easyserver management and monitoring solution used by

Contracting Authority for ABC gates.

Appendix F FBI interoperability standard for fingerprints. Appendix F has

stringent image quality conditions, focusing on the human fingerp r int

comparison and facilitating large-scale machine many-to-many

matching operation.

FAP 50, FAP 60 Fingerprint reader capture area dimension according to the Appendix

F

WSQ A fingerprint image compression algorithm

Table 3: Definitions

1.4.2 ABBREVIATIONS

AA Active Authentication

AB Absorbent

ABC Automated Border Control

BAC Basic Access Control

BCP Border Control Point

CA Certification Authority, Chip Authentication, CAN area

CAN Card Access Number

CRL Certificate Revocation List

CSCA Country Signing Certification Authority

10

CS-PKI Country Signing Public Key Infrastructure

CVCA Country Verifying Certification Authority

DET Detection Error Trade-Off

DGn LDS data group n

DH Diffie-Hellmann

DL Defect List

DSL Document Signer List

EAC Extended Access Control

ECC Elliptic Curve Cryptography

ECDH Elliptic Curve Diffie-Hellmann

EF.COM Header and Data Group Presence Information

EF.SOD LDS Security Object

e-ID Electronic identity document

eMRTD Electronic Machine Readable Travel Document

ePass Electronic Passport

eRP Electronic Residence Permit

FAR False Acceptance Rate

FMR False Match Rate

FNMR False Non-Match Rate

FRR False Rejection Rate

GDPR The EU General Data Protection Regulation

HA High Availability

ICAO International Civil Aviation Organisation

IR B900 spectral range infrared

IS Inspection System, Information System

LDS Logical Data Structure according to ICAO Doc 9303

ML Master List

11

MR MRZ area

MRTD Machine Readable Travel Document

MRZ Machine Readable Zone

NTWG ICAO New Technology Working Group

OK/NOK Positive or negative result of a check

PA Passive Authentication

PAD Presentation Attack Detection

PBGB Estonian Police and Border Guard Board

PKI Public Key Infrastructure

RSA Rivest Shamir Adleman

SMIT IT and Development Centre, Ministry of the Interior

SOD Document Security Object

TA Terminal Authentication

TCC Terminal Control Centre

TLS Transport Layer Security

UI User Interface

UPS Uninterruptible Power Supply

UV 365 nm range wavelength ultra violet light

SHA Secure Hash Algorithm

SLA Service Level Agreement

VI Visual (white) light

WSQ Wavelet Scalar Quantization

Table 4: Abbreviations

1.5 REFERENCES AND STANDARDS

# Standard Publisher Date

12

[ANSI_X9_62] ANSI X9.62-2005 Public Key

Cryptography for the Financia l

Services Industry: The Ellipt ic

Curve Digital Signature Algorithm

(ECDSA).

ANSI Nov. 16th,

2005

[BSI_TR_03105_5-1] Bundesamt für Sicherheit in der Informationstechnik, Technica l Guideline TR-03105 version 2.5, Conformity Tests for Officia l

Electronic ID Documents, Part 5.1, version 1.41, Test plan for ICAO compliant Inspection Systems with

EACv1

# Standard Publisher Date

[BSI_TR_03105_5-2] Bundesamt für Sicherheit in der

Informationstechnik, Technica l

Guideline TR-03105 version 2.5,

Conformity Tests for Officia l

Electronic ID Documents, Part 5.2,

version 1.2 Test plan for eID and

eSign compliant eCard reader

systems with EAC 2

BSI May 21st,

2010

[BSI_TR_03110_1] Bundesamt für Sicherheit in der Informationstechnik, Technica l

Guideline TR-03110-1 version 2.10,

Advanced Security Mechanisms for

Machine Readable Travel

Documents – Part 1 - eMRTDs with

BAC/PACEv2 and EACv1.

BSI March

20th, 2012

[BSI_TR_03110_3] Bundesamt für Sicherheit in der Informationstechnik, Technica l Guideline TR-03110-3 version 2.10,

Advanced Security Mechanisms for

Machine Readable Travel Documents – Part 3 – Common

Specifications

BSI March

20th, 2012

[BSI TR-03121-2] Bundesamt für Sicherheit in der Informationstechnik, Technica l Guideline TR-03121-2 version 4.4,

Part 2: Software Architecture

BSI 2018

13

[BSI TR-03121-3-v1-v4-4] Bundesamt für Sicherheit in der Informationstechnik, Technica l Guideline TR-03121-3 version 4.4,

Part 3: Application Profiles and Function Modules Volume 1:

Verification ePassport and Identity

Card

BSI 2013-2018

[TR-03121 Scheme v4] Schema and examples for BSI-

TR03121, Version 4.4

BSI 2013-2018

[BSI_TR_03127] Bundesamt für Sicherheit in der Informationstechnik, Technica l Guideline TR-03127 version 1.13,

Architecture electronic Identity

Card and electronic Resident Permit

BSI March

10th, 2011

# Standard Publisher Date

[BSI TR-03129-v1-1] Bundesamt für Sicherheit in der

Informationstechnik, Technica l Guideline TR-03129 version 1.1, “PKIs for Machine Readable Travel Documents” – “Protocols for the

Management of Certificates and

CRLs”

BSI 2009

[BSI TR-03129-2] Bundesamt für Sicherheit in der Informationstechnik, Technica l

Guideline TR-03129-2 ”PKIs for Machine Readable Travel

Documents. “Protocols for the

Management of Certificates and

CRLs – National Protocols for

ePassport Application. Version 1.2“

BSI March 1st,

2016

[BSI TR-03129-P2] Bundesamt für Sicherheit in der

Informationstechnik, Technica l Guideline BSI-TR-03129 “PKIs for

Machine Readable Travel

Documents. Part 2: Supplementa l

specifications for public and offic ia l

authorities. Version 1.3.0“

BSI 2017

[BSI-TR-03135-1-v2-1] Bundesamt für Sicherheit in der

Informationstechnik, Technical

Guideline TR-03135 - Machine

Authentication of MRTDs for

Public Sector Applications Part 1:

Overview and Functional

Requirements

BSI 2016

14

[BSI-TR-03135-2-v2-1] Bundesamt für Sicherheit in der Informationstechnik, Technica l Guideline TR-03135 - Machine

Authentication of MRTDs for

Public Sector Applications Part 2:

Application profiles for offic ia l

document inspection systems

BSI 2016

[BSI-TR-03135-3-v2-3] Bundesamt für Sicherheit in der Informationstechnik, Technica l Guideline TR-03135 - Machine

Authentication of MRTDs for

Public Sector Applications Part 3:

High Level Document Check

Interface Specification

BSI 2017

[EN 62368-1:2014] IEC/EN 62368-1:2014:

Audio/video, information and

communication technology

equipment. Safety requirements.

IEC/EN

# Standard Publisher Date

[ICAO9303] Doc 9303 Machine Readable Travel

Documents, Seventh Edition, Parts 1

– 12

ICAO 2015

[ICAOMADSV1] NTWG Technical Report ‘Machine

Assisted Document Security

Verification’ Version 1.0

ICAO July 26th,

2011

[ICAOSACMRTDTR] ISO/IEC JTC1 SC17 WG3/TF5 Technical Report ‘Supplementa l Access Control for Machine

Readable Travel Documents’

Version – 1.1

ICAO April 15th,

2014

[IEC 62471] IEC 62471:2006: Photobiologica l

safety of lamps and lamp systems

[ISO_1831] ISO 1831: Printing specifications for

optical character recognition

ISO

[ISO10918-1] ISO/IEC 10918-1: Information

technology - Digital compression

and coding of continuous-tone still

images: Requirements and

guidelines

[ISO 19794-5] ISO 19794-5: Information

Technology – Biometrics –

Biometric Data Interchange Formats

– Part 5: Face Image Data

15

[RFC_4122] RFC 4122: A UUID URN

Namespace

IETF July 2005

[RFC5246] The Transport Layer Security (TLS)

Protocol Version 1.2

IETF August

2008

[RFC 5639] RFC 5639: Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve

Generation

IETF March 2010

[TR_LDS_PKI] Technical Report – LDS and PKI

Maintenance Version 1.0.

ICAO May 5

2011

Table 5: References

2 GENERAL DESCRIPTIONS

2.1 BACKGROUND INFORMATION

Self-service kiosk will be installed in Saatse BCP for both entry and exit as a pilot.

2.1.1 Saatse BCP

On the Figure 1 the plan of the premises in the Saatse BCP is provided. 1-phase 230V 50Hz AC

power will be available in Saatse BCP.

Figure 1. Kiosk location in Saatse BCP

2.2 SAFETY

All equipment and fittings MUST comply with EU safety requirements and applicable standards.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 1.

Exiting ABC Gates Management solution SHALL be used

for kiosk management and monitoring.

16

REQ 2. There SHALL be connections only to the CA's data

network.

2.3 MANAGEMENT OF MASTERLISTS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 3.

Master Lists distribution to Management servers will be

accomplished according two scenarios:

• Scenario 1 – Local MasterList provided by CA; or

• Scenario 2 – DS Verification Service provided by CA

• Both scenarios MUST be supported.

2.4 REQUIREMENTS TO GATE MODULE CONSTRUCTION

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 4.

To be future-proof, an self-service MUST be designed and

configured so that it does not preclude any future

enhancements for document authentication modules or

biometric systems for the lifetime of the hardware.

REQ 5. Footprint images MUST be drawn on the floor indicat ing

the standoff distance in front of the camera.

REQ 6. Cameras MUST support range of subject heights at standard

standoff distance between 1.4 and 2.05 meters.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 7.

A kiosk MUST contain of at least:

• Facial image capture camera;

• Document reader;

• Fingerprint reader

• Touchscreen display;

REQ 8.

The kiosk ergonomics, dimensions, location and the

environmental conditions SHOULD be considered with a

special focus on the needs of travellers with disabilit ies.

NOTE: Handicapped people in wheelchairs or similar will

be directed manual border crossing control.

17

REQ 9.

A kiosk module MUST have rigid self-stand ing

construction that can be fastened to the floor by means of

gluing.

REQ 10. All fastenings MUST be covered or special tools MUST be

used to operate.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 11.

A kiosk MUST meet basic requirements regarding the physical installation and security and safety considerations. This includes protecting the kiosk which is installed in public area against tampering and vandalism:

• by using materials that are scratch proof;

• by using materials that are impact-resistant; and

• preferably stainless steel and tempered glass.

REQ 12. The physical parts of the kiosk MUST comply with the

applicable fire protection requirements.

REQ 13. The kiosk MUST contain lighting module(s) to ensure a

proper illumination of the traveller’s face area.

REQ 14. Graphics with multiple colours or harsh contrasts

SHOULD be avoided.

REQ 15. Independent switching off of every individual kiosk MUST

be supported.

REQ 16. Every individual gate MUST have internal independent

mains circuit breaker.

2.5 DOCUMENT READER

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 17. e-Passport readers SHOULD be positioned at the height of

80-90 cm

REQ 18.

MRTD MUST be placed on the document reader with the

biographical data page facing down and the MRZ side first.

REQ 19.

Document reader MUST be able to communicate with

RFID chips in both locations – either in MRTD data page

or back cover.

18

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 20. Document reader MUST be full-page type. Swipe-type

document reader MUST NOT be used.

REQ 21.

Document Reader MUST be supplied together with

document model catalogue in machine readable form

according to the defined XML schema of [BSI-TR-

031351-v2-1] which summarizes all necessary information

on the spectrally selective verification checks.

Figure 8: Graphic instruction how to place the e-Passport on the reader

2.6 FACIAL IMAGE CAPTURE CAMERA

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 22. There MUST be one facial image capture camera per one

KIOSK.

REQ 23. The default height setting of the self-adjusting camera

MUST be configurable.

REQ 24. Facial image capture camera MUST have optical

autofocus.

2.7 FINGERPRINT READER

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 25. There MUST be one fingerprint reader per one kiosk.

2.8 USER INTREFACES (SCREENS)

2.8.1 TRAVELLERS’ SCREEN INTERFACE

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 26. Screen(s) MUST be large enough to be observed by the

travellers to use the kiosk.

19

REQ 27. The screen(s) must offer guidance and live video feedback

to the traveller (digital mirror).

REQ 28. Screen(s) position MUST be selected based on ergonomics

and convenience to the travellers.

2.8.2 KIOSK OPERATOR’S DESKTOP WORKSTATION INTERFACE

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 29.

Part of the workstation screen MUST be reserved for 1 or

2 images of Milestone security surveillance solution

camera feed supplied by the PBGB and not integrated with

the kiosk monitoring application. No. of camera feeds will

depend on system configuration of the BCP.

REQ 30.

Details of the kiosk operator’s desktop workstation user

interface SHALL be agreed with the CA during the

execution of the Contract.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 31.

Upper part of the screen (Kiosk monitoring area) MUST

show at the same time:

• Kiosk status for up to the 4 kiosks; and

• Alerts from the PIKO system.

REQ 32.

Lower part of the tablet screen MUST be reserved for 1 or

2 images of Milestone security surveillance solution

camera feed supplied by the PBGB and not integrated with

the kiosk monitoring application. No. of camera feeds will

depend on system configuration of the BCP.

REQ 33.

Details of the kiosk operator’s mobile user interface

SHALL be agreed with the CA during execution of the

Contract.

2.9 KIOSK IDENTIFICATION

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 34. Each kiosk SHOULD be uniquely identified.

REQ 35. The Vendor MUST accept possibility that numbering

syntax and interval will be prescribed by the CA.

20

2.10 KIOSK OPERATING CONDITIONS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 36. The Kiosk MUST be operative at ambient temperatures 5 –

35 degrees Centigrade.

REQ 37. The Kiosk MUST be operative at ambient humidity

30 – 70 per cent.

2.11 REQUIREMENTS TO KIOSK FUNCTIONALITY

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 38. The kiosk MUST have IS client functionality for CSCA

(and CVCA) PKI operations.

3 REQUIREMENTS TO SYSTEM DOCUMENTATION

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 39.

The Vendor SHALL, for all software and equipment (hardware) offered, provide general system documentat ion

written in English covering the following items:

• Kiosk operator desktop workstation and mobile UI

operating manuals.

4 REQUIREMENTS TO THE KIOSK MANAGEMENT

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 40. The kiosk management MUST have GUI solution for

desktop computers.

REQ 41. The kiosk management MUST have GUI solution for

tablets.

REQ 42. Personal data acquired during passenger check MUST NOT

be stored in the management and monitoring system.

REQ 43.

Manual override by the kiosk operator of the status

(operational/non-operational) of an individual kiosk

MUST be supported.

21

5 TECHNICAL REQUIREMENTS TO THE HARDWARE

5.1 DOCUMENT READER

5.1.1 DOCUMENT FORMATS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 44. Document reader MUST support TD1 format of MRTDs

specified in [ICAO9303]

REQ 45. Document reader MUST support TD3 format of MRTDs

specified in [ICAO9303]

5.1.2 READING THE OPTICAL DATA

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 46. Document data page SHALL be optically recorded and

digitized under IR, VI and UV spectral range light.

REQ 47. The optical resolution SHALL be at least 385 ppi.

REQ 48. Reading of MRZ and CAN MUST be supported.

REQ 49.

Document reader sensitivity to incoming ambient light MUST be minimized by:

shielding by technical safeguarding measurements;

by compensating of external light;

or by both methods.

REQ 50. OCR of data both in MRZ and CAN MUST be supported.

REQ 51.

OCR of data for tests MUST be based on the IR B900

spectral range image. In case of failure of reading in IR

spectral range the system SHALL restrict passage and

redirect the traveller to travel document 2nd level of

inspection.

REQ 52.

Following MRZ configurations MUST be supported:

44*2 symbols; and

30*3 symbols.

5.1.3 RFID CHIP READER

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 53. Reading of chips compliant to ISO 14443 Type А and В,

ICAO LDS 1.7, PKI 1.1 MUST be supported.

REQ 54. Transmission protocol T=CL MUST be supported.

22

REQ 55. Data exchange rates 106, 212, 424 and 848 kbps MUST be

supported.

REQ 56. Chip detection in any part of the document MUST be

supported.

REQ 57. Chip MUST be readable when document is positioned on

the optical reading surface.

REQ 58. Anti-collision protocol (chip selection based on MRZ or

CAN reading results) MUST be used.

5.1.4 CERTIFICATION AND COMPLIANCE OF THE DOCUMENT READER

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 59. Document reader MUST have the following certifications -

CE, RoHS, EN 62368-1, EN62471.

REQ 60.

Document reader MUST have the following

certifications - [BSI_TR_03105_5-1] and

[BSI_TR_03105_5-2]

REQ 61. The RF-reading module of the document reader MUST be

certified according to [TR-03105-4]

REQ 62. The document reader MUST comply with the existing

regulations regarding EMC and UV-A light emission.

5.1.5 PERFORMANCE CAPABILITIES AND TEMPORAL REQUIREMENTS

No. Requirement Description VENDOR’S

RESPONSE

FULFILLED

REQ 63. On the average, optical images of the MRZ MUST be

captured within 2 seconds

REQ 64.

Content of the extracted DG1 MUST be made available in

≤ 5 seconds1 after the document2:

has been placed onto the reader; or

fixed in reading position.

REQ 65. Document verification MUST start as soon as the input data

becomes available to the system.

REQ 66. Full document verification process of an electronic MRTD3

SHALL NOT take longer than 7 seconds4.

1 Corresponds to t1 on the Figure. 2 Estonian passport of 2021 is used as the Reference electronic MRTD. 3 On a Reference electronic MRTD using an Inspection System operated on technology using the minimal system

requirements as specified by the manufacturer. 4 Corresponds to t2 on the Figure 3.

23

5.1.6 COMMUNICATION REQUIREMENTS FOR THE RF-READING MODULE

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 67.

The RF-reading module SHALL communicate with a

semi-conductor device in the electronic MRTD using radio

frequency energy that meets the requirements specified in

[ISO14443]

5.1.7 CHIP APPLICATION SUPPORT

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 68.

Applications to be supported:

• e-Passport (DG01 – DG16); and

• e-ID (DG01 – DG21)

5.1.8 AUTOMATION REQUIREMENTS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 69. Automatic detection of document placing MUST be

supported.

REQ 70. Document scanning process MUST start automatically

REQ 71. Technical solutions enhancing reading quality of the

MRTDs are RECOMMENDED.

5.2 FINGERPRINT READER

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 72. Minimal frame rate for slaps > 5 fps is REQUIRED.

REQ 73. 4-4-2 flat fingerprint enrollment MUST supported.

REQ 74. Fingerprint reader MUST NOT use total internal reflection

technology.

5.3 IMAGE CAPTURE CAMERA

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

24

REQ 75. The minimum physical resolution of the camera video

stream MUST be at least 12 megapixels.

REQ 76. The camera system SHALL adapt automatically to the

height of the person standing in front of it.

REQ 77.

The camera system SHALL cover at least a range of 140cm

to 205 cm of a person's body height (if standing in marked

position in front of the camera system).

REQ 78.

The camera SHALL be able to capture a frontal image of

the person if the person is looking straight to the image

capture camera.

REQ 79.

The camera system SHALL guarantee sharpness of the

captured facial image if the traveller is positioned within

the designated capture area.

REQ 80. The camera system SHALL minimise distortion of the

captured facial image within the whole capture area.

REQ 81. The camera system SHALL provide live stream for traveller

instruction screen and guidance for the traveller.

REQ 82.

If the person is looking straight to the traveller instruct ion

screen the viewing direction of the person SHALL be

frontal.

REQ 83. The facial images provided by the capture unit MUST have

at least 120 pixels between the centers of the eyes.

5.3 LIGHTING

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 84.

Active diffuse lighting SHALL be used to ensure uniform

illumination of the captured facial image and to be

independent of external lighting.

REQ 85. The lighting SHALL NOT cause reflections on glasses or

the skin of the face.

REQ 86.

The lighting MAY be active during the complete capture

process and brightness MAY be varied to get best contrast

and illumination.

5.4 TABLET

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 87. The screen size MUST be ≥10 to <13”.

REQ 88. The screen ratio of the tablet MUST be 9 to 16.

25

REQ 89. The screen MUST be touch sensitive.

REQ 90. The screen brightness MUST be at least 300 cd per sq. m.

REQ 91. Battery runtime MUST be at least 8 hours.

REQ 92. The tablet orientation in dock during charging MUST be

portrait.

REQ 93. The tablet MUST have NFC connectivity.

REQ 94. The tablet MUST have 4G and WiFi connectivity.

REQ 95. The tablets MUST have Windows 10 Pro operating

system.

REQ 96. The tablets MUST support at least WPA2 WiFi encryption.

6 REQUIREMENTS TO THE PROCEDURES OF DOCUMENT

READING AND VERIFICATION PROCESS

Chapter 6 describes data processing procedures that MUST be performed during a MRTD

inspection process.

All individual document checks as defined in this Technical Specification are applicable to the

document under inspection, are mandatory if not otherwise clearly marked, SHALL be performed

and SHALL be used in composing requests to PIKO. Checks to which ‘undetermined’ result would

be applicable will not be conducted.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 97.

Unique monotonously increasing identification number

MUST be attributed to every individual document check

transaction.

REQ 98. Other principle than provided in RFC 4122 MAY be used

for document check transaction numbering.

REQ 99.

All travellers whose document check aggregate result will not be ‘successful’ MUST be redirected to manual document check. Corresponding guidance SHALL be

displayed on the traveller’s screen interface

REQ 100. Full document check MUST be performed even if document

check aggregate result will not be ‘successful’.

6.1 VISUALISATION OF CHECK RESULTS

The system MUST be able to provide the results of an individual check with reduced level of detail

to the operator’s desktop workstation and mobile UI. It is RECOMMENDED to map the defined

values in the form of traffic lights as shown in table 6.

Result of the check Traffic light color

26

Successful green

Failed red

Undetermined yellow

Not supported grey

Aborted black

Table 6.

6.2 WORKFLOW

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 101. Data in VIZ SHALL NOT be used for document optical

checks.

REQ 102.

For every check the result SHALL be mapped to:

• Successful – The check terminated, the feature of the document to be checked successfully passed the check, i.e. a specific check had been able to be applied to the

document and assessed according to its specifications.

• Failed – The check terminated, the feature of the document to be checked did NOT successfully pass the check; in other words, the applied check failed on the feature. The document SHOULD be subjected to a

further (manual) check for authenticity, integrity and validity.

• Undetermined – The check terminated, it was not possible to determine if the feature to be checked is

authentic, of integrity or is valid.;

• Not supported – The check terminated, but the specific

document does not support the features to be checked

(for example, a document without a chip, a document

which does not have specific security features per

definition, a specific protocol was not supported by a

chip etc.); or Aborted.

REQ 103.

Any anomaly MUST be considered as an indicator of a

possible risk situation resulting in mapping the check to

aggregate result ‘failed’.

6.3 CHECKS TO BE CONDUCTED IN COURSE OF THE TRANSACTION PROCESS

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE FULFILLED

REQ 104. Optical checks MUST be performed.

REQ 105. Electronic checks MRZ MUST be performed.

REQ 106. Biometric checks MUST be performed.

27

REQ 107. Combined checks MUST be performed.

REQ 108. Requests into background systems MUST be performed.

Figure 3. Process sequence of checking MRTDs

6.4 PROCESS SEQUENCE OF CHECKING A MRTD

Figure 3. Temporal sequence of MRTD checking process

Document access MUST start automatically at time t0 with placing a document to the reader’s

reading surface. The first reading of the MRZ takes place while the document is slided towards the

final reading position. As the MRZ is read during sliding the document to its final reading position

the result of the reading will be available right after the successful result of OCR (time t1). Fast

MRZ allows start PIKO decision making processes as soon as possible. This allows to start

communication between the chip and the reader and thus document verification process earlier and

reduce overall time of the DG1 and DG2 extraction process for the holder this way increasing

throughput of persons.

Upon receiving the results of three checks: 1) background check from PIKO, 2) document optical

and electronic check plus 3) result of biometric verification the OK/NOK results of these three

checks will be sent to log servers.

Insertion of the document

Fast reading of MRZ

t 0 t 1

Send MRZ to PIKO Background check in PIKO

Capturing of facial image

Performing of optical checks

Performing of electronic tests

Performing of biometric verification

Document OK / NOK

Send data to log servers

Biometrics OK / NOK

t 2 t

PIKO OK / NOK

28

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 109. Compatibility to the schema on Figure 3 MUST be

followed.

REQ 110. Fast MRZ functionality MUST be supported.

REQ 111.

Fast MRZ functionality MUST enable to finish reading

MRZ within 1 second after travel document reaching its

final reading position.

6.5 OPTICAL CHECKS

Figure 4. Principal process sequence of optical checks.

6.5.1 DOCUMENT MODEL

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE

FULFILLED

REQ 112.

Manufacturer- and model-specific check routines SHALL

be classified and logged according to the schema given in

[BSI-TR-03135-1-v2-1] table 4.2.

REQ 113.

The result of the document model identification SHALL be

mapped regarding the following list:

• The result of the document model identification MUST

be set to ‘successful’ if the model was determined and a

selection was made;

• The result of the document model identification MUST be set to ‘undetermined’ if the model could not be

determined and a selection was not made;

• The result of the document model identification MUST

be set to ‘aborted’ if checking process was aborted prior to

its defined process flow. A handling, software, or other type

of error occurred.

Start of the optical checks

Spectrally selective checks End

Check MRZ consistency

Final result of optical checks

Identify document model

29

Figure 5. Detailed process sequence of optical checks

6.5.2 REQUIREMENTS TO THE OPTICAL CHECK PROCEDURES

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 114. Optical checks must be performed according to [BSI-

TR03135-1-v2-1] pp. 4.4.3.1 and 4.4.3.2.

REQ 115. MRZ contents MUST be read in IR light.

REQ 116. MRZ contents MUST be read in VI light.

REQ 117. CAN contents MUST be read in IR light.

REQ 118. CAN contents MUST be read in VI light.

REQ 119. Optical quality (i.e. printing clearness etc.) of the MRZ

MUST be checked.

REQ 120. MRZ (CAN) contents SHALL be OCRed.

REQ 121.

Positioning of the MRZ according to [ICAODOC] Part 4

p.3 Figure 3 in bounding rectangle limits MUST be

verified.

REQ 122. Consistency of MRZ MUST be checked.

REQ 123. Syntax of MRZ MUST be checked.

REQ 124. Integrity of MRZ MUST be checked.

REQ 125. MRZ consistency, syntax and integrity checks MUST be

performed on basis of the result of IR OCR.

30

REQ 126. Accuracy of MRZ filling- in MUST be verified.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 127. Set of spectrally selective checks MUST be compiled on the

basis of document model database.

REQ 128.

At least following spectrally selective checks MUST be

performed:

• presence of UV fibres;

• data page UV dullness; • presence of MRZ overprint in VI, IR;

• Static printed feature in IR.

REQ 129.

The results of optical checks MUST be mapped regarding the following list:

• The result of the check MUST be set to ‘successful’ if all

check routines gave correct results.

• The result of the check MUST be set to ‘failed’ if at least

one check routine has incorrect result.

• Otherwise the check MUST be set to ‘undetermined’.

• The check MUST be set to ‘aborted’ if due to an error

the checking process was aborted prior to its defined

process flow.

6.6 ELECTRONIC CHECKS OF MRTDS

6.6.1 SUPPORT OF THE FOLLOWING ALGORITHMS, PROTOCOLS AND SECURITY

MECHANISMS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 130. DH and ECDH key agreement algorithms MUST be

supported.

REQ 131. BAC according to [ICAO9303] Part 11 MUST be

supported.

REQ 132. PACE according to [ICAO9303] Part 11 MUST be

supported.

REQ 133. PA according to [ICAO9303] Part 11 MUST be supported.

REQ 134. AA according to [ICAO9303] Part 11 MUST be supported.

REQ 135. Terminal Authentication (TA v1, TA v2) MUST be

supported.

REQ 136. Chip Authentication (CA v1, CA v2) MUST be supported.

31

6.6.2 FILES AND DATA GROUPS TO BE SUPPORTED

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE FULFILLED

REQ 137. EF.COM

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 138. EF.SOD V1

REQ 139. EF.SOD V2

REQ 140. DG14

REQ 141. DG15

REQ 142. EE.CVCA

REQ 143. EF.CardAccess

REQ 144. EF.CardSecurity

REQ 145. EF.ChipSecurity

REQ 146. DG1

REQ 147. DG2

REQ 148. DG3

32

6.6.3 ELECTRONIC CHECK FLOWCHARTS

Figure 6. Protocol Sequence 1 performing BAC

Start of reading of the chip

Perform BAC protocol

Read EF . SO D

DG 14 present in EF . SO D ?

DG 15 present in EF . SO D ?

yes

no

Read DG 14

Parameters for CA 1 present ?

Read DG 15 and perform AA

yes

Perform CA 1

no

yes

no

Read DG 1

Read DG 2

End

Optional for documents that

support CA 1 and AA

33

Figure 7. Protocol Sequence 2 performing PACE, CA1 or AA

Start of reading of the chip

Perform PACE protocol

Read EF . SO D

DG 14 present

in EF . SO D ?

DG 15 present

in EF . SO D ?

yes

no

Read DG 14

Parameters for CA 1 present ?

Read DG 15 and perform AA

yes

Perform CA 1

no

yes

no

Read DG 1

Read DG 2

End

Optional for documents that

support CA 1 and AA

Read EF . CardAccess

34

Figure 8. Protocol Sequence 3, performing PACE, TA2, CA2

Start of reading of the chip

Perform PACE protocol

Perform TA 2

EF . ChipSecurity present ?

yes

no

Read EF . ChipSecurity

Read EF . CardSecurity

Perform CA 2

Read EF . S OD

Read DG 2

End

Read EF . CardAccess

Read DG 1

35

Figure 9: Protocol Sequence 4, support of PACE-CAM

6.6.4 PROCESSING SEQUENCES

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 149. Process sequence shown in figure 3 MUST be supported.

REQ 150. Process sequence shown in figure 4 MUST be supported.

REQ 151. Process sequence shown in figure 5 MUST be supported.

REQ 152. Process sequence shown in figure 6 MUST be supported.

REQ 153. Process sequence shown in figure 7 MUST be supported.

REQ 154. Process sequence shown in figure 8 MUST be supported.

REQ 155. Process sequence shown in figure 9 MUST be supported.

6.6.5 CHIP ACCESS USING BAC OR PACE PROTOCOLS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

Start of reading of the chip

Parse PACE - Info , select PACE - CAM OID

Perform Protocol V 1

Read EF . S OD , DG 1 and DG 2

End

Read EF . CardAccess

not supported

Parse PACE - Info , select PACE - CAM OID

supported

Read EF . CardSecurity , Verify CAM - Token

36

REQ 156.

It MUST be possible to configure the system in order that

PACE will be used as the primary protocol and BAC will

be used as the fallback one in case corresponding

document model defines support of both protocols.

REQ 157. The inspection system SHALL not use both – BAC and

PACE in the same session if fallback is not required.

REQ 158.

The result of chip MUST be mapped regarding the following list:

• Successful – The result of chip access MUST be set to ‘successful’ if access protocol used as referenced in the

profiling as mandatory has been successful. Also, the result is set to ‘successful’ if the primary protocol fails but secondary protocol succeeds if fallback has been allowed in document model.

• Failed – The result of chip access MUST be set to

‘failed’ if access protocol used as referenced in the profiling as mandatory has been rated as failed.

• Unsupported - The result of chip access MUST be set to ‘unsupported’ if neither BAC nor PACE could be

performed to access the document.

• Aborted – The result of chip access MUST be set to

‘aborted’ if due to an error the access process was

aborted prior to its defined process flow.

6.6.5.1 CHIP ACCESS VIA BAC

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 159.

The result of checking of the chip access by BAC MUST be mapped regarding the following list:

• Successful – The result of the check must be set to ‘successful’ if BAC could be performed successfully.

• Failed – The result of the check must be set to ‘failed’

if CA was performed, but performing of the protocol failed, the secure messaging channel could not be established successfully.

• Not supported – The result of the check must be set to ‘not supported’ if it is not necessary to perform BAC

in order to access the document (the document might also be accessed with an unencrypted channel or using PACE).

• Aborted – The result of the check MUST be set to

‘aborted’ if due to an error the check was aborted prior

to its defined process flow.

6.6.5.2 CHIP ACCESS VIA PACE

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

37

REQ 160.

The result of checking of the chip access by PACE MUST be mapped regarding the following list:

• Successful – The result of the check must be set to ‘successful’ if PACE could be performed successfully.

• Failed – The result of the check must be set to ‘failed’

if CA was performed, but performing of the protocol failed, the secure messaging channel could not be established successfully.

• Not supported – The result of the check must be set to ‘not supported’ if it is not necessary to perform PACE

in order to access the document (the document might also be accessed with an unencrypted channel or using BAC).

• Aborted – The result of the check MUST be set to

‘aborted’ if due to an error the check was aborted prior

to its defined process flow.

6.6.6 CHECKING CHIP ACCESS BY TERMINAL AUTHENTICATION (TA)4

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 161.

The result of checking of the chip access by TA MUST be mapped regarding the following list:

• Successful – The result of the check must be set to

‘successful’ if PACE could be performed successfully.

• Failed – The result of the check must be set to ‘failed’ if CA was performed, but performing of the protocol failed, the secure messaging channel could not be established successfully.

• Not supported – The result of the check must be set to

‘not supported’ if it is not necessary to perform PACE in order to access the document (the document might also be accessed with an unencrypted channel or using BAC).

• Aborted – The result of the check MUST be set to

‘aborted’ if due to an error the check was aborted prior

to its defined process flow.

6.6.7 CHECKING THE CHIP AUTHENTICITY (AA, CA)

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 162. The system MUST support altering the chip authentic ity

checking algorithm sequence.

REQ 163. CA is RECOMMENDED to be used if both protocols (CA

and AA) are supported by the document chip.

38

REQ 164.

The result of checking of the chip authenticity MUST be mapped regarding the following list:

• Successful – The result of checking of the chip authenticity MUST be set to ‘successful’ if AA or CA

could be performed successfully.

• Failed – The result of checking of the chip authentic ity MUST be set to ‘failed’ if both protocols were performed and both failed, or both protocols were

performed and one failed and the other was not successful, or only one was performed and failed.

• Undetermined – The result of the check must be set to undetermined if, by means of both protocols, checking the authenticity of the chip could not be determined with either AA or CA (e. g. missing data/information

for the check).

• Not supported – The result of the check must be set to not supported if AA and CA were tried but could not

be executed on a particular document.

• Aborted – The result of checking of the chip

authenticity MUST be set to ‘aborted’ if due to an error

the checking process was aborted prior to its defined

process flow.

REQ 165.

If only one of the checks from pp. 7.6.7.1 and 7.6.7.2 is

‘not supported’ and the other one is ‘successful’ or ‘failed’

the final result is ‘successful’ or ‘failed’. If both results are

‘not supported’ the final result is also ‘not supported’ and

the traveller MUST be redirected to manual inspection.

6.6.7.1 CHECKING CHIP AUTHENTICITY WITH AA

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 166.

The result of checking of the chip authenticity with AA

MUST be mapped regarding the following list:

• Successful – The result of the check must be set to ‘successful’ if AA could be performed successfully.

• Failed – The result of the check must be set to ‘failed’ if AA was performed, but performing of the protocol failed, although the required data and parameters

required for AA are available.

• Undetermined – The result of the check must be set to ‘undetermined’ if the result of checking of the authenticity of the chip cannot be determined.

• Not supported – The result of the check must be set to

‘not supported’ if AA was tried but could not be executed.

• Aborted – The result of the check MUST be set to

‘aborted’ if due to an error the check was aborted prior

to its defined process flow.

39

6.6.7.2 CHECKING CHIP AUTHENTICITY WITH CA

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 167.

The result of checking of the chip authenticity with CA MUST be mapped regarding the following list:

• Successful – The result of the check must be set to

‘successful’ if CA could be performed successfully.

• Failed – The result of the check must be set to ‘failed’ if CA was performed, but performing of the protocol failed, although the required data and parameters required for CA are available.

• Undetermined – The result of the check must be set to

‘undetermined’ if the result of checking of the authenticity of the chip cannot be determined.

• Not supported – The result of the check must be set to not supported if CA was tried but could not be

executed.

• Aborted – The result of the check MUST be set to

‘aborted’ if due to an error the check was aborted prior

to its defined process flow.

6.6.8 CHECKING THE ELECTRONIC DATA AUTHENTICITY WITH PASSIVE

AUTHENTICATION (PA)

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 168.

CDS authenticity may be confirmed only either by local ML deliverable by the CA or via TCC PA service.

6.6.9 MASTERLIST IMPLEMENTATION

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 169.

The kiosk SHALL be delivered with DS Verificat ion

Service readiness.

6.6.10 VERIFICATION OF THE SECURITY OBJECTS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 170. Ability to process security objects with one, several or no

CDS MUST be supported.

REQ 171.

Verification of the hash and signature for EF.CardSecurity

and mapping to its own final check result (if existing)

MUST be performed.

40

REQ 172.

Verification of the hash and signature for EF.ChipSecur ity

and mapping to its own final check result (if existing)

MUST be performed.

REQ 173. Verification of the hash and signature for EF.SOD and

mapping to its own final check result MUST be performed.

REQ 174. Verification of the digital signature of a security object

MUST be performed.

REQ 175. Comparison of the stored and calculated on site security

object's hash values MUST be performed.

REQ 176.

If EF.COM is present in the e-Passport chip (in addition to

EF.SOD), the content of EF.COM with EF.SOD MUST be

compared to ensure that each DG listed in EF.SOD is also

contained in EF.COM and vice versa.

REQ 177.

The result of checking of the security objects MUST be mapped regarding the following list:

• Successful – The result of checking of the security objects MUST be set to ‘successful’ if all checks from this subsection referenced in the profiling as

mandatory were checked as successful.

• Failed – The result of checking of the security objects MUST be set to ‘failed’ if at least one of the checks from this subsection that were referenced in the profiling, is rated as failed.

• Undetermined – The result of the check must be set to

undetermined if information is missing to perform the verification.

• Aborted – The result of checking of the security objects

MUST be set to ‘aborted’ if due to an error the

checking process was aborted prior to its defined

process flow.

6.6.11 CHECKING ISSUER CERTIFICATES

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 178. Check of the issuer certificate for EF.SOD MUST be

performed.

REQ 179. Check of the issuer certificate for EF.CardSecurity MUST

be performed.

REQ 180. Check of the issuer certificate for EF.ChipSecurity MUST

be performed.

REQ 181. Check of CDS signature against its respective CCSCA MUST

be performed.

41

REQ 182. Check if the document inspection time is within the valid ity

period of the CDS MUST be performed.

REQ 183. Check of the revocation state of the CDS MUST be

performed.

REQ 184. Trust Status MUST be assessed to the Certificates.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 185.

The cumulative result of checking of the issuer certifica tes

MUST be mapped regarding the following list5:

• Successful – The result of checking of the issuer certificates MUST be set to ‘successful’ if all checks

from this subsection referenced in the profiling as mandatory were checked as successful.

• Failed – The result of checking of the issuer certifica tes MUST be set to ‘failed’ if at least one of the checks from this subsection that were referenced in the

profiling, is rated as failed.

• Undetermined – The result of the check must be set to undetermined if information is missing for performing the check.

• Aborted – The result of checking of the issuer

certificates MUST be set to ‘aborted’ if due to an error

the checking process was aborted prior to its defined

process flow.

REQ 186.

In case the cumulative result of checking of the issuer

certificates is not set to ‘successful’ the traveller SHALL

be redirected to manual inspection.

6.6.12 CHECKING INTEGRITY OF CHIP CONTENTS

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE FULFILLED

REQ 187. Check whether each data group listed in EF.SOD is also

included in EF.COM MUST be performed.

REQ 188. Integrity check of all data groups MUST be performed.

REQ 189. Integrity check of each individual data group MUST be

performed.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

5 Status ’trusted’ is considered equal to the status ’successful’

42

REQ 190.

The result of checking of the integrity of chip contents MUST be mapped regarding the following list:

• Successful – The result of checking of the integrity of chip contents MUST be set to ‘successful’ if all checks from this subsection referenced in the profiling as

mandatory were checked as successful.

• Failed – The result of checking of the integrity of chip contents MUST be set to ‘failed’ if at least one of the checks from this subsection that were referenced in the profiling, is rated as failed.

• Aborted – The result of checking of the integrity of

chip contents MUST be set to ‘aborted’ if due to an

error the checking process was aborted prior to its defined

process flow.

6.6.12.1 COMPARING EF.SO D WITH EF.COM

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 191. Check whether each data group listed in EF.SOD is also

included in EF.COM MUST be performed.

REQ 192.

The result of comparing EF.SOD with EF.COM MUST be mapped regarding the following list:

• Successful – The result of the check must be set to ‘successful’ if the contents of EF.COM and EF.SOD are

consistent with each other.

• Failed – The result of the check must be set to ‘failed’ if inconsistencies between EF.COM and EF.SOD were

detected.

• Not supported – The result of the check must be set to ‘not supported’ if comparing the contents of EF.SOD

and EF.COM is not possible, e. g. because one or both

files are not on the document.

• Aborted – The result of comparing EF.SOD with

EF.COM MUST be set to ‘aborted’ if comparing

EF.SOD and EF.COM was aborted due to an error.

6.6.12.2 CHECKING DATA GROUP INTEGRITY

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 193.

For each data group which was read from the chip, the hash

value SHALL be calculated and compared to the

corresponding hash value given in EF.SOD.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

43

REQ 194.

The result of checking data group integrity MUST be mapped regarding the following list:

• Successful – The result of the check must be set to ‘successful’ if the final result of the check must be set to successful if all mandatory (regarding the profiling)

data groups to be checked, were read and the calculated hash values were identical.

• Failed – The result of the check must be set to ‘failed’ if one or more data group integrity checks result in not

identical.

• Undetermined – The result of the check must be set to ‘undetermined’ if the result is neither ‘successful’ nor ‘failed’.

• Aborted – The result of comparing EF.SOD with

EF.COM MUST be set to ‘aborted’ if building the final

result or an underlying, specific check was aborted.

6.6.13 COMPARISON OF THE ISSUING STATE (DG1 AND DS CERTIFCATE)

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE FULFILLED

REQ 195. Comparison of the issuing country (country codes in DG1

and CDS) MUST be performed.

REQ 196.

The result of comparison of the issuing country MUST be mapped regarding the following list:

• Successful – The result of the check must be set to ‘successful’ if the ICAO country code and the ISO country code match each other based on the

information in the assignment table.

• Failed – The result of the check MUST be set to ‘failed’

if the ICAO country code and the ISO country code do not match each other based on the information in the assignment table.

• Undetermined – The result of the check MUST be set

to ‘undetermined’ if information is missing to perform the check.

• Aborted – The result of comparing EF.SOD with

EF.COM MUST be set to ‘aborted’ if comparison of

the issuing states was aborted.

6.7 COMBINED CHECKS

6.7.1 CROSS VERIFICATION OF MRZ DATA

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

44

REQ 197. Cross-verification of data retrieved from MRZ and DG1 of

the RFID chip MUST be performed.

REQ 198.

Cross-verification of MRZ data SHALL be performed

comparing OCR results of (IR, AB, MR), (VI, AB, MR)

and DG1.

REQ 199.

The result of MRZ cross verification check MUST be

mapped regarding the following list:

• Successful – The result of the check MUST be set to ‘successful’ if all instances of MRZ match.

• Failed – The result of the check MUST be set to ‘failed’ if at least one instance of MRZ differs from the other

two.

• Aborted – The result of the check MUST be set to

‘aborted’ if due to an error the checking process was

aborted prior to its defined process flow.

6.7.2 VERIFICATION OF DOCUMENT VALIDITY

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 200. Verification of MRTD validity based on retrieved

information from MRZ MUST be performed.

REQ 201.

The result of document validity verification check MUST

be mapped regarding the following list:

• Successful – The result of the check MUST be set to ‘successful’ if the date of verification is within valid ity period of the MRTD.

• Failed – The result of the check MUST be set to ‘failed’

if the date of verification is outside of validity period of the MRTD.

• Aborted – The result of the check MUST be set to

‘aborted’ if due to an error the checking process was

aborted prior to its defined process flow.

6.8 BIOMETRIC ENROLLMENT AND CHECKS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 202. Kiosk must be configurable for using non-EES mode or EES

mode

45

REQ 203. Reference image SHALL be acquired from the DG2 of the

travel document.

REQ 204.

Comparison of holder’s facial image in the eMRTD DG2

to the live image collected from the image capture camera

MUST be performed.

REQ 205.

PAD detection MUST be supported by the camera and

fingerprint reader solution. The kiosk operator should

ensure that the document holder does not try to illega lly

bypass the border control by using fake biometrics or other

mechanisms when a spoofing attack (PAD) is detected.

6.8.1 REQUIREMENTS TO THE CAMERA IMAGE QUALITY

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE FULFILLED

REQ

206. All face images captured by camera MUST be compliant

with COMMISSION IMPLEMENTING DECISION (EU)

2019/329

REQ 207. Captured and framed image size must be 1600x1200 px.

REQ 208. Colour depth of facial image processed MUST be 24-bit

RGB.

REQ 209. Minimal camera resolution MUST be at least 12 MPx

REQ 210. The face SHALL be fully visible in the foreground of the

provided image.

REQ 211.

The minimum distance between both eyes for capture

positions of the passenger in the preferred area of the

camera range SHALL be corresponding to EES

requirements.

6.8.2 REQUIREMENTS TO THE CAMERA IMAGE QUALITY ASSURANCE

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 212. Pre-qualification of captured live facial images from the

acquisition stream MUST be used.

REQ 213. Capturing of images other than live facial – for example on

the shirt – MUST be avoided.

REQ 214. Ranking of images according to the conducted

prequalification SHALL be used.

REQ

215.

Images SHALL be passed to the verification stage as

indicated by the rank.

46

REQ

2016.

Pre-qualification SHALL be conducted at least according to the following criteria:

• Absence of multiplicity of faces in the picture;

• pose of the head;

• illumination of the face;

position of the eyes.

REQ 217.

Quality assessment algorithm used for face images must be same as eu-Lisa proposed or mapping to eu-Lisa algorithm

thresholds must be used.

REQ 218. Face image quality threshold must be configurable.

6.8.1 REQUIREMENTS TO THE FINGERPRINT IMAGES QUALITY

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE FULFILLED

REQ 219.

All fingerprint images MUST be compliant with

COMMISSION IMPLEMENTING DECISION (EU)

2019/329

REQ 220. WSQ image format MUST supported.

REQ 221. Resolution 500ppi is REQUIRED.

REQ 222. 256 levels of grayscale dynamic range is REQUIRED.

6.8.2 REQUIREMENTS TO THE FINGERPRINTS IMAGE QUALITY ASSURANCE

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 223. NFIQ 2.0 quality assessment algorithm used for fingerpr int

images

REQ 224. Quality threshold MUST be configurable.

47

6.8.3 REQUIREMENTS TO THE LOCAL BIOMETRIC COMPARISON AT KIOSK

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE FULFILLED

REQ 225.

The face extraction algorithm security level (threshold) to

obtain different values of FTA and FTE MUST be

configurable.

REQ 226.

The vendor of the verification algorithm MUST provide

calibration data based on the actual verifica t ion

performance.

REQ 227.

The output of the algorithm SHALL be a comparison

score6 and the result of the verification (the achieved FMR

and an indication whether the threshold has been reached)

depending on the chosen security level (threshold) of the

algorithm.

REQ 228. The Vendor SHALL provide a DET curve of the algorithm

performance.

REQ 229.

Such performance SHALL be on the basis of images of

comparable characteristic (e.g. images in size and

resolution and pose variation of a typical ePassport

deployment).

REQ 230. The FRR shall be less than 4% at a FAR of 0.1%.

6.8.4 REQUIREMENTS TO THE LOCAL BIOMETRIC COMPARISON CODING

AT KIOSK

This sub-clause describes requirements for the coding used during the verification process of facial

images.

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE FULFILLED

REQ 231. All results of the verification work flow SHALL be encoded

in XML as “ph-vid-verify”7.

6.9 ERROR CODES AND LOGGING

6.9.1 TRANSACTION LOGGING

6 Typically, a vendor-specific uncalibrated raw score. 7 The XML encoding is defined by the XML schema definition in [TR-03121 Scheme v4] ‘vid4v3.xsd’. Examples can

be found in ’phvid-verify.xml’.

48

Figure 10: Workflow-based document check with TR-03135-1-compliant logging

Figure 11 shows the extension of the client side of the document check process with transaction

logging operations (highlighted in blue). The client initiates a new transaction after a MRTD was

detected and before initiating workflow execution. After the workflow execution and result

processing is finished, the client requests saving of the corresponding transaction log and then ends

the transaction. [BSI-TR-03135-3-v2-3] Section 4.2 provides a quick overview of the interface

functions.

Logging is done for the purpose of having continuous quality control, the extraction of business

statistics and improvement of the ABC gate system.

Purpose of this requirement is to preserve information that can be given to document issuing

authorities to help to solve regular problems with one or another production batch of the travel

documents issued by them. It is not very rare, when some production or personalised sets of

MRTDs have repeating problems during inspection in another country/countries and therefore it

is nearly impossible to trace the problem.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 232.

No personal, document or border crossing procedure

information is stored or logged in the kiosk. All data except

personal, document or border crossing procedure

information obtained during a document inspection

process SHALL be stored according to the monitor ing

logdata format .

REQ 233.

The following global states of an inspection process will be logged:

• Successful

• Terminated

• Aborted

MRTD detected

Fetch one feedback element

Process feedback

End

Begin a new transaction

More feedback ?

Initiate workflow execution

yes

no

Signal end of processing

End transaction

Save transaction log

49

REQ 234.

The result of an inspection process will be logged:

• Successful

• Failed

• Undetermined

• Not supported

• Aborted

REQ 235.

Processing errors of each of the checks prescribed in this

Technical Specification resulting in an aborted check

MUST be logged together with timestamp and kiosk

unique identifier.

REQ 236.

System error codes together with timestamp and unique kiosk identifier MUST be logged. These errors can be but not limited to:

• MRZ IR reading error;

• MRZ OCR error;

• document validity error;

• Chip communication error;

• Chip authenticity error;

• MRZ or CAN reading error;

• BAC or PACE accomplishment error;

• CA1/CA2 error;

• defect Document Signer Certificate Revoked (BSI TR-

03129-2, 4.2.1.1) is detected for a CDS;

• other document verification process errors.

REQ 237.

Error code message syntax MAY be specified by the Vendor, will be agreed with the Contracting Authority and SHALL contain at least following items:

• error code;

• kiosk unique identifier; and

• timestamp.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 238.

Each error code MUST be in unique numeric integer

format number. Return code consists of a confirmation of

successful operation or error code. Return code of a

successful operation is 0 (zero). Database of error

descriptions provides a short and concise error description

that facilitates a subsequent analysis regarding the error.

Database of error descriptions is kept in the management

server.

REQ 239.

Logging of all relevant check results which is provided by

the interface specified in Chapter 7 of this Technica l

Specification MUST be supported.

50

REQ 240. Individual checks MUST be stored in the ABC Gates

Management server log.

REQ 241.

At least following information shown below MUST be included in a data entry:

• Total transaction time (document authentication,

biometric verification, background checks, etc.);

• Total access time;

• issuing country;

• date of issue;

• information about the read document (document type

and issuing state)

• travel document model indicator;

• Outcome of each of the authentication checks actually performed in the document, depending on the type of

document;

• error type and messages from the particular process

steps and document reader unit;

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 242.

Processing errors of each of the checks prescribed in this

Technical Specification resulting in an aborted check

MUST be logged together with timestamp and gate unique

identifier.

REQ 243. Error codes of data communication MUST be logged

together with timestamp.

REQ 244.

Document reader SHALL be able to provide all the

document verification data in a format that is sufficient to

build [BSI-TR-03135-1-v2-1] compatible transaction log,

according to XML schemas provided in [BSI-TR-031351-

v2-1] p.5.2. Transaction log MUST contain all data

obtained in the document verification process, except

personal data of a document holder and the MRTD itself.

REQ 245. Document verification transaction log MUST be sent to log

server of the Contracting Authority.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

51

REQ 246.

Biometric verification module SHALL be able to provide

all the biometric identification data in a format that is

sufficient to build [BSI-TR-03135-1-v2-1] compatible

transaction log, according to XML schemas provided in

[BSI-TR-03135-1-v2-1] p.5.2. Transaction log MUST

contain all data obtained in the biometric identificat ion

process, except personal data of a document holder and the

MRTD itself.

REQ 247. Biometric verification transaction log MUST be sent to log

server of the Contracting Authority.

REQ 248. Archiving of logs will be agreed with CA during execution

of the Contract.

7 DEFECTS

7.1 OPTICAL DEFECTS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 249.

If the defect ‘Specimen’ applies to the checked document,

the document SHOULD be identified and marked as

specimen. Further advance through the kiosk workflow

must be restricted and the traveller SHALL be instructed

to wait for arrival of kiosk operator.

REQ 250.

If the defect ‘Country identifier’ applies to the checked

document, further advance through the kiosk workflow

SHALL be restricted and the traveller SHALL be

instructed to wait for arrival of kiosk operator.

REQ 251.

If the defect ‘MRZ format’ defect applies to the checked

document, further advance through the kiosk workflow

SHALL be restricted and the traveller SHALL be

instructed to wait for arrival of kiosk operator.

REQ 252.

If the defect ‘MRZ check digit’ defect applies to the

checked document, further advance through the kiosk

workflow SHALL be restricted and the traveller SHALL

be instructed to wait for arrival of kiosk operator.

REQ 253.

If the defect ‘MRZ non-IR-readability’ defect applies to

the checked document, further advance through the kiosk

workflow SHALL be restricted and the traveller SHALL

be instructed to wait for arrival of kiosk operator.

52

7.2 ELECTRONIC DEFECTS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 254.

In case of electronic defects further advance through the

kiosk workflow SHALL be restricted and the traveller

SHALL be instructed to wait for arrival of kiosk operator.

7.3 BIOMETRIC ENROLLMENTCOMPARISON DEFECTS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 255.

In case of biometric enrollment or verification failure

further advance through the kiosk workflow SHALL be

restricted and the traveller SHALL be instructed to wait for

arrival of kiosk operator.

8 DATA/INFORMATION EXCHANGE

8.1 INFORMATION EXCHANGE WITH THE KIOSK OPERATOR DESKTOP

WORKSTATION UI

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 256.

Information needed to facilitate the following tasks to be carried out by the operator MUST be supplied:

• monitoring the user interface of the kiosk application;

• display notifications in case of malfunction or

situations except successful check or necessity of

kiosk operator arrival to BCP to manage exceptions

and make decisions about them;

REQ 257. Visual feedback of the enrollment and verification process

SHALL be provided for the kiosk operator.

REQ 258. At least both facial images (live and reference) SHALL be

displayed to the kiosk operator.

REQ 259. Captured fingerprint images SHALL be not displayed to

the kiosk operator.

REQ 260.

In case of document verification mapping to any other

result than ‘successful’ images of VIZ acquired in IR, VI

and UV SHALL be displayed to the kiosk operator.

REQ 261. The result of the biometric verification process SHALL be

provided to the kiosk operator’s screen.

53

REQ 262. The result of EES enrollment SHALL be displayed to the

kiosk operator in EES scenario.

REQ 263.

Manual override command and sending instructions to

traveller to wait for arrival of kiosk operator MUST be

supported.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 264.

The overall verification and enrollment result MUST be

displayed in the summary view appearing on the kiosk

operator’s screen.

REQ 265.

The image data (VIZ image, DG2 image and live image

used for the verification) MUST be shown in the summary

view on the kiosk operator’s screen.

REQ 266.

Further details regarding the detailed checks of the

biometric verification process SHALL be displayed upon

discretion of the kiosk operator.

REQ 267.

The result of MRZ optical check and comparison

(‘OK’/’NOK’) MUST be displayed on the kiosk operator’s

screen. Upon discretion of the kiosk operator detailed

information SHALL be displayed.

REQ 268.

The result of eMRTD data verification (‘OK’/’NOK’)

MUST be displayed on the kiosk operator’s screen. Upon

discretion of the gate operator detailed information

SHALL be displayed.

REQ 269.

A button “Border crossing allowed” for overriding the

results of the document /personal identity checks MUST

be displayed on the kiosk operator’s screen. The button

MUST be deactivated in case background check ‘NOK’

decision will be sent from PIKO.

REQ 270.

The results of background requests to PIKO (‘OK’/’NOK’)

MUST be displayed on the kiosk operator’s screen. Upon

discretion of the kiosk operator detailed information

SHALL be displayed.

REQ 271. An alert in case of an attempt to use a kiosk by a minor

MUST be displayed on the kiosk operator’s screen.

REQ 272. An alert in case of a PAD attack MUST be displayed on the

kiosk operator’s screen.

REQ 273.

Alerts MUST be displayed on the kiosk operator’s screen:

• in case of technical malfunction (missing

communication with document reader, …); etc.

54

REQ 274. A notice about a traveller required manual control MUST

be displayed on the kiosk operator’s screen.

REQ 275. A notice about kiosk manual override activated MUST be

displayed on the kiosk operator’s screen.

REQ 276. The kiosk operator desktop workstation UI SHALL be

operating in Windows 10 Pro environment.

REQ 277.

The solution of authentication and authorisation of the

kiosk operator desktop workstation UI SHALL be agreed

with the Contracting Authority during execution of the

Contract.

8.2 INFORMATION EXCHANGE WITH THE KIOSK OPERATOR MOBILE UI

NO. REQUIREMENT DESCRIPTION

VENDOR’S

RESPONSE FULFILLED

REQ 278.

The overall verification result MUST be displayed in the

summary view appearing on the kiosk operator’s mobile

screen.

REQ 279.

The result of the biometric verification process (OK/not

OK) MUST be displayed to the kiosk operator’s mobile

screen. The image data (VIZ image, DG2 image and live

image used for the verification) SHALL be displayed as

pop-ups upon request by the kiosk operator.

REQ 280.

The result of MRZ optical check and comparison (OK/not

OK) MUST be displayed on the kiosk operator’s mobile

screen. Upon discretion of the kiosk operator detailed

information SHALL be displayed.

REQ 281.

The result of eMRTD data verification (OK/not OK)

MUST be displayed on the kiosk operator’s mobile screen.

Upon discretion of the kiosk operator detailed information

SHALL be displayed.

REQ 282.

A button “Border crossing allowed” for overriding the

results of the document /personal identity checks MUST

be displayed on the kiosk operator’s screen. The button

MUST be deactivated in case ‘NOK’ decision will be sent

from PIKO.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 283.

The results of background requests to PIKO (OK/not OK)

MUST be displayed on the kiosk operator’s mobile screen.

Upon discretion of the kiosk operator detailed information

and workflow SHALL be displayed.

55

REQ 284.

In case of document verification mapping to any other

result than ‘successful’ images of VIZ acquired in IR, VI

and UV SHALL be displayed on the kiosk operator’s

mobile screen.

REQ 285. An alert in case of an attempt to use a kiosk by a minor

MUST be displayed on the kiosk operator’s mobile screen.

REQ 286.

Alerts MUST be displayed on the kiosk operator’s mobile screen:

• in case of technical malfunction (missing

communication with document reader, …); etc.

REQ 287. A notice about kiosk manual override activated MUST be

displayed on the kiosk operator’s mobile screen.

REQ 288.

The result of EES enrollment/verification SHALL be

displayed to the kiosk operator in EES scenario.

REQ 289.

The solution of authentication and authorisation of the

kiosk operator mobile UI SHALL be agreed with the

Contracting Authority during execution of the Contract.

8.3 INSTRUCTIONS FOR A TRAVELLER

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 290.

Full guidance MUST be provided on the kiosk screen. The

contents of the guidance, e.g. looping video, SHALL be

coordinated with CA.

REQ 291. An indicator showing the capture status SHOULD be

displayed to the passenger.

REQ 292.

Information whether a kiosk is operational or not MUST

be displayed to the travellers in clear and understandable

form.

REQ 293.

Up to 2 (two) communication languages MUST be

specified for a country. Communication language SHALL

be derived from the correspondence table according to the

country code in the MRZ of a MRTD. The correspondence

table MUST be agreed with the Contracting Authority

during execution of the Contract.

REQ 294. Audio instructions for the traveller MAY be provided.

56

REQ 295.

The information for the traveller MUST contain following messages but not limited to:

• Information about the successful or failed verification process;

• Document removed too early – repeat document

reading from the beginning;

• Request to wait for assistance;

The contents of the list MUST be expandable. The contents

and wording SHALL be coordinated with CA.

REQ 296. Graphics on the traveller’s UI screen should avoid multip le

colours or harsh contrast.

REQ 297.

A correspondence table containing system messages and

respective messages to the traveller MUST be present in

the ABC Gates management server. The contents of this

table SHALL be agreed with the Contracting Authority

during execution of the Contract.

8.4 DATA EXCHANGE WITH PIKO

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 298.

In case of non-EES scenario the following data MUST be

delivered to PIKO:

• Contents of MRZ;

REQ 299.

In case of EES scenario the following data MUST be

delivered to PIKO:

• Contents of MRZ;

• EES compliant Face image

• EES compliant Fingerprint images

REQ 300.

In case of EES scenario PIKO delivers to kiosk

management system:

 Information about required workflow: Verification

or Identification

 Matching result(s) from EES central system for

verification or identification

9 REQUIREMENTS TO SECURITY OF THE SOLUTION

9.1 SECURING THE COMMUNICATION

57

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 301.

In order to secure the communication channel of the

transmission, the use of either TLS 1.2 or 1.3 [RFC5246]

MUST be supported.

REQ 302. No other network connection except to the CA’s network

SHALL be used.

REQ 303. Data exchange with kiosk SHALL be protected from

electronic and mechanical interception.

10 REQUIREMENTS TO SERVICE LEVEL AGREEMENT

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 304. All requirements SHALL be applicable per kiosk. Temporal

requirements can’t be consolidated.

10.1 KEY PERFORMANCE INDICATORS

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 305. Yearly uptime per kiosk MUST be 99 (ninetynine) per cent.

11 ADDITIONAL INFORMATION

11.1 EAC AND FINGERPRINT ENROLLMENT

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 306.

The service SHALL be delivered with readiness to

implement fingerprint check and EAC functionality on

short notice.

11.2 LIST OF MESSAGES TO KIOSK OPERATOR

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 307. The messages to kiosk operators will be agreed with CA

during execution of the Contract.

58

11.3 LIST OF MESSAGES TO A TRAVELLER

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 308. The messages to traveller will be agreed with CA during

execution of the Contract.

59

12 ANNEX 2. FUNCTIONALITY UPGRADES

This Clause is informative at the moment of publishing this Tender and is intended to inform the

Vendor about the scope of the future functionality upgrades to the system. These upgrades MUST

be supported during this tender and they will be activated concurrently with implementation of

EAC functionality.

12.1 CHANGES IN ELECTRONIC CHECKS PROTOCOL SEQUENCES

Figure 11: Protocol Sequence 1, performing BAC

60

Figure 12: Protocol Sequence 2, performing PACE, CA1 or AA

Figure 13: Protocol Sequence 3, performing PACE, TA2, CA2

Start of reading of the chip

Perform PACE protocol

Perform TA 2

EF . ChipSecurit y present ?

yes

no

Read EF . ChipSecurity

Read EF . CardSecurity

Perform CA 2

Read EF . S OD

Read DG 2

DG 3 present in EF . SO D ?

Read DG 3

End

yes

no

Read EF . CardAccess Read DG 1

Read other DGs and EFs that are

readable

61

Figure 14: Protocol Sequence 4, support of PACE-CAM

12.2 CHANGES DUE IMPLEMENTING MASTERLISTS, DEFECTLISTS ETC.

NO. REQUIREMENT DESCRIPTION VENDOR’S

RESPONSE

FULFILLED

REQ 309. CDS will be sent to RCC and reply will be returned to the IS.

REQ 310.

Access to RCC will be available via VPN to the specified

network address/port in the Contracting Authority’s

network.

13 REQUIREMENTS DEFINITION AND TENDER

EVALUATION

13.1 REQUIREMENTS DEFINITION

As stated here above in this document all the provided requirements are mandatory if not stated

explicitly in another way.

13.1.1 MINIMUM REQUIREMENTS

NO. REQUIREMENT DESCRIPTION VENDOR’S RESPONSE FULFILLED

Start of reading of the chip

Parse PACE -Info , select PACE -CAM

OID

Perform Protocol V 1

Read EF .S OD , DG 1 and DG 2

End

Read EF . CardAccess

Parse PACE -Info , select PACE -CAM

OID

Read EF . CardSecurity ,

Verify CAM -Token

DG 3 present in EF . SO D ? Perform TA

DG 3 present in EF . SO D ? Read other DGs

and EFs that are readable

Not supported

supported

no

yes

Read DG 3 yes no

62

REQ 1 [Requirement title]

[Customer’s Requirement Description]

[Vendor to include, or refer to, supporting

documentation that prove/support fulfilment of

the minimum requirement]

Yes/No

REQ 2 [Requirement title]

[Customer’s Requirement

Description]

Yes/No

The requirements will be stated as in the example above.

The first column labelled “No.” provides a unique number for each requirement, using the prefix

“REQ”. Requirements are numbered sequentially throughout the document.

The second column labelled “Requirement Description” contains a Requirement Title (bold text)

and the Contracting Authority’s Requirement Description. The requirements are not scored, but

evaluated as fulfilled/not fulfilled based on the documentation provided by the Vendor. The

Contracting Authority reserves the right to decide if the Vendor fulfils the requirements or not

based on the documentation provided.

The third column labelled “Vendor’s Response” shall be filled by the Vendor to include, or refer

to, supporting documentation to convince the Customer that the requirement is fulfilled. The

referenced documentation should be as short and precise as possible.

In the last column labelled “Fulfilled” the Vendor must clearly state whether the Vendor fulfils the

requirement (Yes) or not (No). Should the column “Fulfilled” not be filled in, then the Customer

will assume the column to be filled in with “No” and therefore it will constitute a confirmation that

the Vendor cannot comply with the requirements.

1 / 1

Koostatud 04.05.2022 15:06:49 https://riigihanked.riik.ee/rhr-web/#/procurement/4362488/general-info

KÕRVALDAMISE ALUSED JA KVALIFITSEERIMISTINGIMUSED Viitenumber: 248377 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Piirikontrolli iseteeninduskioski raamhange

KÕRVALDAMISE ALUSED

KÕRVALDAMISE ALUSTE PUUDUMINE

Hankija ei sõlmi hankelepingut ettevõtjaga, kellel või kelle haldus-, juhtimis- või järelevalveorgani liikmel või muul seaduslikul või asjaomase riigihankega seotud lepingulisel esindajal on hankijale teadaolevalt RHS § 95 lõikes 1 sätestatud kõrvaldamise alus. Hankija kontrollib edukal pakkujal RHS § 95 lg 1 kõrvaldamise aluseid enne lepingu sõlmimist. RHS § 95 lg 1 nimetatud kõrvaldamise aluste kontroll toimub riigihangete registri liidese või PPA veebiliidese abil. Kui andmed ei ole hankijale päringute kaudu kättesaadavad, siis nõuab hankija edukalt pakkujalt enne hankelepingu sõlmimist kõikide asjakohaste andmete või dokumentide esitamist. Kontrolli teostatakse ja kinnitused antakse ka ühispakkujate või teiste isikute, kellele on pakkuja tuginenud, suhtes.

Kehtib: Kõik osad

Küsimused ettevõtjale: 1) Kas pakkuja kinnitab, et tema suhtes puuduvad RHS § 95 lg 1 nimetatud kõrvaldamise alused? (Raadionupp valikutega "Jah/Ei") 2) Kui pakkujal esineb vähemalt üks RHS § 95 lõike 1 punktides 1–3 ja 5 nimetatud alus, peab pakkuja esitama pakkumuse koosseisus RHS § 97 kohased ja põhjendatud heastamismeetmed iga sellise esineva asjaolu kohta. Hiljem heastamismeetmeid esitada ei saa. Kas kinnitate tingimuse ülevõtmist ja olete kõrvaldamise aluse olemasolul need lisanud? (Raadionupp valikutega "Jah/Ei")

1 / 2

Koostatud 16.05.2022 13:35:13 https://riigihanked.riik.ee/rhr-web/#/procurement/4362488/general-info

VASTAVUSTINGIMUSED Viitenumber: 248377 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Piirikontrolli iseteeninduskioski raamhange

PAKKUMUSE ESITAMINE Pakkumuse esitamisega kinnitab pakkuja kõigi riigihanke alusdokumentides esitatud tingimuste ülevõtmist.

Tingimusliku pakkumuse esitamine ei ole lubatud.

Küsimused ettevõtjale: 1. Kas ettevõtja saab kinnitada, et pakkumus vastab hanke alusdokumentides sätestatud tingimustele? (Raadionupp valikutega "Jah/Ei")

2. Kas pakkuja on täitnud pakkumuse maksumuse RHRi töölehel vastavalt nõutud tingimustele ja struktuurile "Hindamiskriteeriumid ja hinnatavad näitajad"? (Raadionupp valikutega "Jah/Ei")

3. Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud. Iga viidet, mille hankija teeb riigihanke alusdokumentides mõnele RHS-i § 88 lõikes 2 nimetatud alusele (standardile, tehnilisele tunnustusele, tehnilisele kontrollisüsteemile vms) kui pakkumuse vastavuse kriteeriumile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“. Iga viidet, mille hankija teeb riigihanke alusdokumentides ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule või tootmisviisile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“ (RHS § 88 lg 6). (Raadionupp valikutega "Jah/Ei")

4. Pakkumuste jõusoleku tähtaeg on 90 päeva. Kas pakkuja kinnitab, et on pakkumus on jõus 90 päeva? (Raadionupp valikutega "Jah/Ei")

5. Andmed lepinguks, mida kasutatakse juhul kui pakkumus tunnistatakse edukaks. Pakkuja esitab andmetena: 1. Lepingu allkirjastaja nimi 2. alus lepingu allkirjastamiseks (juhatuse liige, volikiri vm) 3. lepingu allkirjastaja ametinimetus 4. pakkuja kontaktisik lepingu täitmisel (nimi, ametinimetus, telefoni number ja e-posti aadress). (Suur sisestusala (max pikkus 4000 tähemärki))

6. Pakkuja märgib pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe määramist ärisaladuseks. Kirjeldage lühidalt pakkumuses sisalduvat ärisaladust ja lisage selle määramise põhjendus või märkige, et pakkumus ei sisalda ärisaladust. (Suur sisestusala (max pikkus 4000 tähemärki))

SANKTSIOONIDEGA SEOTUD KINNITUSED

8.04.2022 võttis Euroopa Liidu Nõukogu vastu määruse 2022/576, millega muudetakse määrust (EL) nr 833/2014, mis käsitleb piiravaid meetmeid seoses Venemaa tegevusega, mis destabiliseerib olukorda Ukrainas.

Euroopa Liidu Nõukogu sanktsioon keelab riigihankelepingute sõlmimise ja täitmise Vene Föderatsiooni kodanike, residentide või seal asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidilise isiku, asutuse või muu üksusega.

Palume pakkujal esitada allolevad kinnitused seoses Euroopa Liidu Nõukogu poolt kehtestatud sanktsioonidega.

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et pakutav kaup ei ole rahvusvahelise sanktsiooni objektiks ega pärit sanktsiooni all olevatest piirkondadest rahvusvahelise sanktsiooni seaduse (RSanS) § 7 lg 1 mõttes. (Raadionupp valikutega "Jah/Ei")

2 / 2

Koostatud 16.05.2022 13:35:13 https://riigihanked.riik.ee/rhr-web/#/procurement/4362488/general-info

2. Pakkuja kinnitab, et tema omandiõigusest üle 50% ei kuulu otseselt ega kaudselt Vene Föderatsiooni kodanikele, Vene Föderatsiooni residentidele ega Vene Föderatsioonis asutatud ettevõtetele, asutustele ega muudele üksustele. Hankijal on õigus nõuda andmeid pakkuja otseste ja kaudsete omanike ja tegelike kasusaajate kohta, sh füüsiliste isikute isikut tõendavate dokumentide koopiaid, millelt nähtub isiku kodakondsus ja juriidiliste isikute kohta isiku asukohamaa äriregistri või muu pädeva asutuse tõendit või väljavõtet. (Raadionupp valikutega "Jah/Ei")

3. Pakkuja kinnitab, et ta ei ole ühegi Vene Föderatsiooni kodaniku, Vene Föderatsiooni residendi ega Vene Föderatsioonis asutatud ettevõtte, asutuse ega muu üksuse, samuti rohkem kui 50% ulatuses otseselt või kaudselt Vene Föderatsiooni kodaniku, Vene Föderatsiooni residendi, ega Vene Föderatsioonis asutatud ettevõtja, asutuse ega muu üksuse omandis oleva ettevõtte esindaja ega tegutse nende juhiste alusel. (Raadionupp valikutega "Jah/Ei")

4. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid, tarnijaid ega tugine kvalifitseerimistingimuste täitmisel selliste ettevõtjate näitajatele, kes on: 1. Vene Föderatsiooni kodanik, Vene Föderatsiooni resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. (Raadionupp valikutega "Jah/Ei")

5. Pakkuja kinnitab, et lepingu sõlmimine temaga ei riku rahvusvahelise sanktsiooni seadust, st et pakkuja ise ei ole sanktsiooni subjekt. (Raadionupp valikutega "Jah/Ei")

TÕEND AINUÕIGUSTE OLEMASOLU KOHTA

Pakkuja esitab kinnituse, mis tõendab, et pakkuja omab ainuõigust lepingu esemeks olevate litsentside rentimiseks ja tootetoe osutamiseks. Kinnitus peab juhul, kui selle digitaalne allkirjastamine ei ole võimalik, olema allkirjastatud paberkandjal ja esitatud skaneeritud dokumendina.

Küsimused ettevõtjale: 1. Kas pakkujal on ainuõigus lepingu esemeks olevate litsentside rentimiseks ja tooetoe osutamiseks (Vabas vormis dokument)

PAKKUMUSE VASTAVUS TEHNILISELE KIRJELDUSELE

Pakkuja esitab tehnilise kirjelduse Hankija esitatud vormil (Lisa 2 Tehniline kirjeldus). Pakkuja täidab tühjad lahtrid pealkirjaga „VENDOR’S RESPONSE“ vastavalt lahtritele „REQUIREMENT DESCRIPTION“. Välja tuleb tuua pakkumuse koosseisus pakutavate asjade ja teenuste andmed, vajadusel ka viited veebikeskkondadest leitavale infole, et hankija saaks üheselt mõistetavalt kontrollida nõude täitmist.

Küsimused ettevõtjale: 1. Kas pakkuja on lisanud pakkumuse koosseisus täidetud Lisa 2 Tehniline kirjeldus? (Raadionupp valikutega "Jah/Ei")

Koostatud 04.05.2022 14:53:36 1 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 4362488/general-info

HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD

Viitenumber: 248377 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Piirikontrolli iseteeninduskioski raamhange

Pakkumuse maksumust hinnatakse - Ilma maksudeta

Elektroonilist oksjoni kasutatakse: ei

Jrk nr

Nimetus Kirjeldus Tüüp / hindamismeetod

Osakaal Kogus Ühik Pakkuja täidetav

1 Ühe piirikontrolli iseteeninduskioski hind

Ühe piirikontrolli iseteeninduskioski hind vastavalt lisale 2.

Maksumus - vähim on parim

20 EUR jah

2 Ühe piirikontrolli iseteeninduskioski ülespaneku hind

Ühe piirikontrolli iseteeninduskioski ülespaneku hind vastavalt lisale 2.

Kulu - vähim on parim

10 EUR jah

3 Ühe tableti hind Ühe tableti hind vastavalt lisale 2. Kulu - vähim on parim

10 EUR jah

4 Piirikontrolli iseteeninduskioski haldustarkvara ühe tableti versiooni hind

Piirikontrolli iseteeninduskioski haldustarkvara ühe tableti versiooni hind vastavalt lisale 2.

Kulu - vähim on parim

10 EUR jah

5 Piirikontrolli iseteeninduskioski haldustarkvara ühe tööjaama versiooni hind

Piirikontrolli iseteeninduskioski haldustarkvara ühe tööjaama versiooni hind vastavalt lisale 2.

Kulu - vähim on parim

10 EUR jah

6 ABC väravate haldussüsteemi uuendamise (piirikontrolli iseteeninduskioskite tugi) hind.

Kulu - vähim on parim

10 EUR jah

7 ABC väravate monitoorimissüsteemi uuendamise (piirikontrolli iseteeninduskioskite tugi) hind

Kulu - vähim on parim

10 EUR jah

8 Piirikontrolli iseteeninduskioski tootetoe hind aastas

Kulu - vähim on parim

10 EUR jah

9 Tarkvara arenduse tunni hind Kulu - vähim on parim

10 EUR jah

Kokku: 100

Koostatud 04.05.2022 14:53:36 2 / 2 https://riigihanked.riik.ee/rhr-web/#/procurement/ 4362488/general-info

Hindamismetoodika kirjeldus 1.   Ühe piirikontrolli iseteeninduskioski hind

Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".

2.   Ühe piirikontrolli iseteeninduskioski ülespaneku hind Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".

3.   Ühe tableti hind Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".

4.   Piirikontrolli iseteeninduskioski haldustarkvara ühe tableti versiooni hind Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".

5.   Piirikontrolli iseteeninduskioski haldustarkvara ühe tööjaama versiooni hind Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".

6.   ABC väravate haldussüsteemi uuendamise (piirikontrolli iseteeninduskioskite tugi) hind. Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".

7.   ABC väravate monitoorimissüsteemi uuendamise (piirikontrolli iseteeninduskioskite tugi) hind Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".

8.   Piirikontrolli iseteeninduskioski tootetoe hind aastas Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".

9.   Tarkvara arenduse tunni hind Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal".

NON-DISCLOSURE AGREEMENT No 3-1/75

This agreement is entered into on this … day of … 2020 (hereinafter Effective date) by and between

secunet Security Networks AG, a company existing and organised under the laws of Federal

Republic of Germany, whose registered office is located at Kurfuerstenstraße 58, 45138 Essen,

Germany, registered under number HRB 13615, represented by … (hereinafter Company)

and Republic of Estonia, represented by IT and Development Centre of the Ministry of the Interior

(in Estonian: Siseministeeriumi infotehnoloogia- ja arenduskeskus), a government authority existing and organised under the laws of Estonia, whose registry code is 70008440 and office is located at

Mäealuse 2/2, 12618 Tallinn, Estonia, represented by … (hereinafter SMIT), each also referred to separately as the Party and jointly as the Parties,

Whereas,

in the course of procurement proceedings regarding the “High-speed Internet connection for border guard vessels" (hereinafter Procurement Proceedings) and/or therefrom arising fulfilment of a public contract (hereinafter Procurement Contract) (hereinafter Procurement Proceedings and Procurement

Contract jointly referred to as Project), whose terms and consequences this agreement does not contemplate, the Company and SMIT may disclose to each other technical, commercial, financial and

other information of confidential nature, the Parties concluded this non-disclosure agreement (hereinafter Agreement) to settle the terms

of the disclosure, use and protection of the confidential information as follows :

1. The purpose of this Agreement is to set forth the rules relating to the use and protection of Confidential Information (as defined below) disclosed by a Party (hereinafter Disclosing Party) to the other Party (hereinafter Receiving Party) or having become known to the Receiving Party

as well as the confidentiality obligations of the Receiving Party with respect to the Confidentia l Information. Nothing in this Agreement shall be construed as compelling the Parties to disclose

any Confidential Information to each other, or to enter into any further contractual relationship.

2. For the purpose of this Agreement the term Confidential Information shall mean any information

disclosed by the Disclosing Party to the Receiving Party in connection with the Project, or which has become known to the Receiving Party, whether in writing, orally, visually, in the form of

samples, models or otherwise, provided that such information, (i) if written, is clearly and conspicuously marked as being proprietary or confidential and that (ii) if oral, visual and in other non-written form, including information acquired during a visit to the premises of a Party or the

place of fulfilment of any Procurement Contract, is designated as Confidential Information at the time of disclosure and is confirmed by the Disclosing Party as such in writing within thirty (30)

days of its being disclosed. All the protection and restrictions applicable to Confidentia l

FOR INTERNAL USE

Notation made

The Access restriction is valid until

Basis: Clause 35 (1), 9, 10 of the Public

Information Act

SMIT

2(5)

Information under this Agreement shall apply to the information disclosed in non-written form as from disclosure and during the said period of thirty (30) days. Confidential Information means also

all notes, analyses, compilations, studies, interpretations or other documents prepared by the Receiving Party which contain, reflect or are based upon, in whole or in part, Confidentia l

Information.

3. Confidential Information particularly includes, but is not limited to the following information,

whether marked or designated as being proprietary or confidential or not: 3.1. any terms of contract;

3.2. information about IT solutions and configuration of hardware and software; 3.3. information that would, if disclosed to the public domain, simplify attacks on or manipulat ions

of national IT systems and databases;

3.4. information that would, if disclosed to the public domain, damage national IT systems or databases or the reputation or reliability of national institutions;

3.5. information, which shows the direct or indirect effects of implementation or non- implementation of any systems;

3.6. information about individuals, national institutions or financial information;

3.7. information about the technical specification disclosed in the course of the Project; 3.8. information classified as a state secret or as classified foreign information;

3.9. information in respect of which restriction on access is established by law or to which access is restricted pursuant to the procedure established by law;

3.10. information that would, under the circumstances, appear to a reasonable person to be

confidential.

4. In consideration of and subject to the foregoing, the Receiving Party in each case undertakes in

respect of Confidential Information and for the duration of this Agreement: 4.1. to keep the Confidential Information in strict confidence;

4.2. to keep a record of all Confidential Information and of the location of such information, a copy of which record will be made available to the Disclosing Party at the latter’s request;

4.3. except with the prior written consent of the Disclosing Party, not to make or cause to be made any disclosure of such Confidential Information to any third party, and provided that such disclosure is made solely for the purpose directly related to the Project and then only on the

condition that such third party is made aware of and undertakes in writing to observe the provisions of this Agreement. Any third party means any individual or company other than

the Company and SMIT. Irrespective of the fact with which secunet-company this contract will be closed, no one of the following companies can be regarded as third party: secunet Security Networks AG, secunet International GmbH & Co. KG, secunet Internationa l

Management GmbH, secustack GmbH and stashcat GmbH. The undersigned of secunet Security Networks AG is responsible for the above companies in accordance with the

agreement; 4.4. not to use Confidential Information otherwise than for the purposes of the Project, unless such

use is specifically authorised in writing by the Disclosing Party;

4.5. to protect Confidential Information, whether in storage or in use, with the highest degree of diligence, applying all necessary security, IT and other relevant measures at its own expense;

4.6. not to disclose Confidential Information to any persons employed by it or otherwise engaged by it in the performance of its duties other than those for whom such knowledge is essential for the purposes of the Project and such disclosure to them shall be made only under conditions

of strict confidentiality; 4.7. not to copy or reproduce Confidential Information to writing except as may be strictly

necessary for the purpose of the Project;

3(5)

4.8. not to modify, reverse engineer, decompile, create other works from or dissemble any software programs contained in the Confidential Information without the Disclosing Party’s prior

written consent; 4.9. inform the Disclosing Party immediately in writing of any queries relating to Confidentia l

Information or the need to disclose Confidential Information by law before answering to any such queries of disclosing Confidential Information under applicable laws;

4.10. inform the other Party immediately of any circumstances which might arise or have

arisen that will or might constitute a breach of this Agreement or prevent the achievement of the purpose of the Agreement; and

4.11. in case of termination of this Agreement or in case either Party elects not to pursue the purpose contemplated by the Project or upon receiving a written request from the Disclosing Party, the Receiving Party shall immediately destroy all documents or files (and all copies of

any of the foregoing, including “copies” that have been converted to computerized media in the form of image, data or word processing files either manually or by image capture)

including or based on any Confidential Information, all tangible material embodying Confidential Information and all notes, summaries, memoranda, drawings, manuals, records, excerpts or derivative information deriving from Confidential Information, in whatever form

of storage or retrieval, unless the Disclosing Party requests return thereof in which case the Receiving Party shall return the information carriers to the Disclosing Party. The return or

destruction of documentation shall not be deemed to release either Party from its obligat ions arising from this Agreement.

4.11.1. This excludes:

4.11.1.1. information in need of protection and copies thereof if and for such retention period required by law and

4.11.1.2. routinely prepared backup copies of the electronic data traffic.

5. Notwithstanding the above, information disclosed or having become known to the Receiving Party

shall not be considered Confidential Information where the Receiving Party can prove that such information:

5.1. before the time of disclosure was, or thereafter became, part of the public domain otherwise than through an act of the Receiving Party, or by circumstances dependent on the Receiving Party or by an event the risk of which is borne by the Receiving Party;

5.2. becomes known to the Receipient, without restriction, from a source other than Discloser without breach of this Agreement by Recipient and otherwise not in violation of Discloser’s

rights, or 5.3. was already known to the Receiving Party at the date of receipt of Confidential Information

pursuant to this Agreement, or

5.4. was independently developed by the Receiving Party without making use of the Disclosing Party’s Confidential Information, or

5.5. has been approved for release or use (in either case without restriction) by written authorisat ion of the Disclosing Party.

6. Liability 6.1. In case of a breach of the Agreement SMIT has the right to demand from the Company a

contractual penalty up to the sum of 20 000 euros for every incident. In such a case, SMIT shall present a justified claim in writing.

6.2. In addition to the contractual penalty, SMIT has the right to demand compensation for any

damages incurred and exceeding the contractual penalty. 6.3. The Party in breach of obligation shall pay the contractual penalty within 30 calendar days.

4(5)

6.4. In case of a delay in the payment of the contractual penalty, the suffering Party may require the other Party to pay interest on delay in the amount of 0,1% of the unpaid amount per

calendar day until conforming payment.

7. Each Party designates the below identified person(s) from within its own organisation to receive and disclose all Confidential Information which is subject to this Agreement and to maintain a log and/or file thereof:

7.1. For SMIT 7.2. For Company

Any alteration in the name or address of the above individual by one Party shall be notified to the other Party in writing.

8. This Agreement shall not be construed as granting or conferring, either expressly or impliedly, any rights under patents, copyright or any other form of intellectual property rights belonging to the

Disclosing Party in respect of Confidential Information, the ownership of which shall remain vested in the Disclosing Party at all times.

9. All Confidential Information and carriers thereof, submitted by one Party to the other shall remain the property of the Disclosing Party.

10. In providing Confidential Information hereunder, the Parties make no representation, warranty,

assurance, or inducement, expressed or implied, as to its adequacy, sufficiency or freedom from

defect of any kind, including, but not limited to, freedom from patent infringement that may result from the use of such information, nor shall the Parties incur any responsibility or obligation by

reason of such information. 11. This Agreement is entered into for the duration of ten (10) year as of the Effective date.

12. Neither Party shall assign or transfer any of its rights or obligations hereunder without the prior

written consent of the other Party hereto, except to a successor in ownership of substantially all of the assets of the assigning Party if the successor in ownership expressly assumes in writing the terms and conditions of this Agreement. Any attempted assignment without written consent will

be void.

13. Each Party shall use every reasonable endeavour to ensure that its employees and other persons, when disclosure of Confidential Information has been specifically authorized by the Disclos ing Party, shall observe the obligations contained herein as if such employees and other persons were

a Party to this Agreement.

14. Any Confidential Information disclosed by the Parties under this Agreement which is classified information i.e. information classified as state secret or otherwise provided with a military or police security classification by the competent national military, police or other relevant authority, shall

be identified by the Disclosing Party as classified information at the time of disclosure and the disclosure, protection, use and handling of such information shall be in accordance with security

procedures prescribed by the respective national legislation. 15. The present Agreement shall be construed in all respects in accordance with the laws of Estonia.

Any dispute that the Parties cannot settle amicably relating to this Agreement shall be exclusive ly and finally settled by the competent courts of Estonia.

5(5)

16. This Agreement constitutes the entire agreement between the Parties with respect to the subject matter hereof and supersedes and cancels all prior representations, negotiations, commitments,

undertakings, communications, whether oral or written, understandings and agreements between the Parties, with respect to or in connection with any of the matters or things to which such

Agreement applies or refers. 17. This Agreement can only be changed by a written amendment agreed upon by the Parties hereto

and signed by authorized representatives of the Parties.

IN WITNESS whereof the Parties have caused this Agreement to be signed by their duly authorized representatives on the date first above written.

For and on behalf of For and on behalf of

____________________

___________________

Siseministeeriumi infotehnoloogia- ja arenduskeskus

Mäealuse 2/2, Tallinn 12618

Telefon 612 6200

E-post [email protected]

Reg. kood 70008440

www.smit.ee

08.07.2022 nr 3-1/75

Väljakuulutamiseta läbirääkimistega riigihanke "Piirikontrolli iseteeninduskioski

raamhange" (viitenumber 248377) läbiviimine

Siseministeeriumi infotehnoloogia- ja arenduskeskus (edaspidi SMIT või hankija) korraldab riigihangete seaduse (edaspidi RHS) § 49 lg 1 p 2 ja § 72 alusel väljakuulutamiseta

läbirääkimistega riigihanke "Piirikontrolli iseteeninduskioski raamhange" (viitenumber 248377) ning teeb ettepaneku esitada pakkumus vastavalt käesolevas pakkumuse esitamise

ettepanekus ja selle lisades (edaspidi kõik koos PEE) sisalduvatele tingimustele. 1. Lisad

1.1. Lisa 1 – Raam- ja hankelepingu projekt; 1.1.1. Lisa 1.1 - SMIT müügilepingute üldtingimused;

1.1.2. Lisa 1 - SMIT käsunduslepingute üldtingimused; 1.2. Lisa 2 - Tehniline kirjeldus (dokument esitatakse hankes ingliskeelsena, tagamaks

hanketingimuste üheselt mõistetavuse, kuna dokumentide kontrollimisel kohalduvad

standardid on ingliskeelsed ja eestikeelne üldtunnustatud terminoloogia puudub); 1.3. Lisa 3 - Kõrvaldamise aluste kinnitus (RHR);

1.4. Lisa 4 – Vastavustingimused (RHR); 1.5. Lisa 5 – Hindamiskriteeriumid (RHR). 1.6. Lisa 6 – konfidentsiaalsusleping (dokument esitatakse hankes ingliskeelsena, kuna

dokument allkirjastatakse inglise keelsena; 1.7. eRHR-is tehakse huvitatud ettevõtjatele kättesaadavaks käesolevas punktis loetletud

dokumentide tõlked inglise keelde; 1.8. Vastuolude korral eesti ja inglise keelsetes dokumentides lähtutakse eesti keelsest

versioonist.

2. Lepingu ese, riigihanke osadeks jaotamine

2.1. Raamlepingu esemeks on piirikontrolli iseteeninduskioskite hankimine. Tehniline kirjeldus ja raam- ning hankelepingutingimused on toodud PEE lisades.

2.2. Rahastamisallikas: Riigieelarve ja/või välisvahendid (täpne finantseerimisallikas

täpsustatakse igakordses tellimuses ja/või hankelepingus), sh. Euroopa Liidu Sisejulgeolekufondi ja Eesti Vabariigi Siseministeeriumi projekti ISFB-31

„Automaatse piirikontrollisüsteemi rajamine“ vahendid 2.3. Maksimaalne maksumus on 1 000 000 eur km-ta. 2.4. Hankija ei jaga riigihanget osadeks, sest eseme olemusest tulenevalt ei ole hanke

osadeks jaotamine võimalik, kuna lepingu esemeks on funktsionaalselt koos toimivad

2(4)

ja sama eesmärgi saavutamiseks vajalikud asjad ja teenused, mille osutamise õigus on

ühel pakkujal. Pakkuja on esitanud hankijale ainuõiguse tõendi.

3. Hanketingimused 3.1. Hankemenetlus viiakse läbi RHRis. 3.2. Teave hankemenetluse sisu kohta PEE-s ja selle lisades, mis moodustavad ühtse

terviku. 3.3. PEE sisu kohta saab hankijalt selgitusi küsida kirjalikul pöördumisel läbi eRHRi

keskkonna Teabevahetuse töölehe. 3.4. Hankija vastab esitatud küsimustele 3 tööpäeva jooksul selgituse saamise taotlusest

arvates, lisades vastused e-riigihangete keskkonna Teabevahetuse lehele. eRHR saadab

automaatse teavituse vastuste lisamise kohta. 3.5. Pakkuja kohustub kandma kõik pakkumuse ettevalmistamise ja esitamise ning lepingu

sõlmimisega seotud kulud. Pakkujale ei hüvitata mis tahes kahju ega kulusid seoses hankemenetluses osalemisega.

3.6. Riigihankes saavad osaleda ainult pakkujad või taotlejad, kelle elu- või asukoht on

Eestis, mõnes muus Euroopa Liidu liikmesriigis, muus Euroopa Majanduspiirkonna lepinguriigis või Maailma Kaubandusorganisatsiooni riigihankelepinguga ühinenud

riigis. 3.7. Ühispakkumuse tegemine ei ole lubatud

4. Pakkumuse vormistamine ja esitamine 4.1. Hankija avab tähtajaks esitatud pakkumus ja kontrollib selle vastavust riigihanke

alusdokumentides toodud tingimustele. 4.2. Pakkumuses esitatud andmed peavad olema tõesed, esitatud viisil ja piisava

detailsusega, mis võimaldavad hankijal kontrollida selle vastavust riigihanke

alusdokumentides toodud tingimustele. 4.3. Maksumused tuleb esitada eurodes täpsusega kaks kohta pärast koma.

4.4. Pakkumuse maksumuses kajastatud summad on hankijale lõplikud, sh sisaldavad tasusid või muid makse, v.a käibemaksu, mis kajastatakse eraldi, ning selles toodud summadele ei lisandu täiendavaid väljamakseid ega kulutusi. 0 või negatiivse

väärtusega maksumusi ei ole lubatud kasutada ja sellise pakkumuse on hankijal õigus tunnistada mittevastavaks ning tagasi lükata.

4.5. Kui esitatavate dokumentide koosseisus on kolmanda osapoole poolt kirjalikult allkirjastatud dokumente, esitada dokument skaneeritud kujul ning originaaldokument esitada ainult juhul, kui hankijal on tekkinud kahtlus dokumendi osas.

4.6. Alternatiivlahendused ei ole lubatud. 4.7. Pakkumus on konfidentsiaalne kuni nimetatud pakkumuse edukaks tunnistamise otsuse

tegemiseni. Pakkuja peab märkima pakkumuses, millised pakkumuses esitatud andmed on pakkuja ärisaladus ning põhjendama teabe ärisaladuseks määramist. Selleks ei tohi olla pakkumuse maksumus ega osamaksumus, kui neid arvestatakse pakkumuste

hindamisel, ega muu pakkumuste hindamise kriteeriumidele vastav pakkumust iseloomustav numbriline näitaja. Hankija ei avalikusta pakkumuste sisu ärisaladusega

kaetud osas. 5. Pakkujal kõrvaldamise aluste puudumise kontrollimine

5.1. Hankija ei sõlmi raamlepingut pakkujaga, kellel või kelle haldus-, juhtimis- või järelevalveorgani liikmel või muul seaduslikul või asjaomase riigihankega seotud

lepingulisel esindajal on hankijale teadaolevalt RHS § 95 lõikes 1 sätestatud kõrvaldamise alus. Hankija nõuab vajadusel edukalt pakkujalt vajalike dokumentide

3(4)

esitamist, kui need andmed ei ole hankijale andmekogus olevate andmete alusel tasuta

kättesaadavad või hankijal eelnevalt olemasolevate andmete või dokumentide alusel. 5.2. Riigihankes saavad osaleda ainult taotlejad, ühistaotlejad, pakkujad, ühispakkujad,

alltöövõtjad, kelle elu- või asukoht on riigihangete seaduse § 3 punktis 2 nimetatud riigis (Eesti, mõni muu Euroopa Liidu liikmesriik, muu Euroopa Majanduspiirkonna lepinguriik või Maailma Kaubandusorganisatsiooni riigihankelepinguga ühinenud

riik). RHS § 95 lg 4 p 12 alusel võib hankija kõrvaldada hankemenetlusest taotleja või ühistaotleja, pakkuja või ühispakkuja, kellel puudub õigus taotlust või pakkumust

esitada. Kui alltöövõtjal esineb § 95 lõikes 4 sätestatud alus, võib hankija nõuda pakkujalt sellise alltöövõtja asendamist.

6. Pakkumuse vastavaks tunnistamine, hindamine ja edukaks tunnistamine 6.1. Hankija avab tähtajaks esitatud pakkumuse ja kontrollib selle vastavust riigihanke

alusdokumentide tingimustele. 6.2. Pakkumus tunnistatakse vastavaks, kui see on kooskõlas kõikide PEEs esitatud

tingimustega või kui pakkumuses ei esine sisulisi kõrvalekaldumisi esitatud

tingimustest. 6.3. Hankija nõudel peab pakkuja pakkumuses esitatud teavet selgitama, piiritlema või

täpsustama. 6.4. Hankijal on õigus lükata pakkumus tagasi, kui see ei vasta PEEs esitatud tingimuste le. 6.5. Pakkuja, kelle pakkumus on tagasi lükatud, ei osale edasises hankemenetluses.

6.6. Vastavaks tunnistatud pakkumusi hindab hankija 100-väärtuspunkti süsteemis alusdokumentides avaldatud hindamiskriteeriumide alusel.

6.7. Edukaks tunnistatakse majanduslikult soodsaim pakkumus riigihanke alusdokumentides toodud hindamiskriteeriumide alusel.

6.8. Hankijal on õigus igal ajal enne lepingu sõlmimist arutada pakkumuse kõiki aspekte ning

vajadusel nõuda esitatud pakkumuse täpsustamist ja täiendamist.

7. Pakkumuse tagasilükkamine. Riigihanke kehtetuks tunnistamine 7.1. Hankijal on õigus igal ajal enne raamlepingu sõlmimist tagasi lükata pakkumus, kui:

7.1.1. pakkumus ei ole tunnistatud vastavaks või seda ei saa hankija teistsugus te

vajaduste tõttu tunnistada vastavaks; 7.1.2. laekunud pakkumuse maksumus on hanke eeldatavast maksumusest ja hankija

rahalistest võimalustest nii palju suurem, et raamlepingu sõlmimine ei ole sellise maksumusega vastuvõetav;

7.1.3. riigihanke läbiviimise aluseks olevad tingimused on oluliselt muutunud ja

seetõttu osutub raamlepingu sõlmimine mittevajalikuks või võimatuks; 7.1.4. riigihankes ilmnenud ebakõlasid ei ole võimalik kõrvaldada ega menetlust

seetõttu ka õiguspäraselt lõpule viia; 7.1.5. kui raamlepingutingimuste osas ei jõuta läbirääkimiste käigus kokkuleppele; 7.1.6. ettenägematutel ja hankijast mitteolenevatel objektiivsetel põhjustel, kui

riigihanke hankemenetluse toimumise ajal on hankijale saanud teatavaks uued asjaolud, mis välistavad või muudavad hankijale ebaotstarbekaks hankemenetluse

lõpuleviimise PEEs esitatud tingimustel (sh muudatused seadusandluses). 7.2. Hankija võib põhjendatud vajadusel omal algatusel hankemenetluse kehtetuks

tunnistada. Põhjendatud vajaduseks võib olla eelkõige, kuid mitte ainult:

7.2.1. vajadus raamlepingu eset olulisel määral muuta; 7.2.2. riigihanke läbiviimise aluseks olevad tingimused on oluliselt muutunud ja

seetõttu osutub raamlepingu sõlmimine mittevajalikuks või võimatuks;

4(4)

7.2.3. hankemenetluses ilmnenud ebakõlasid ei ole võimalik kõrvaldada ega

hankemenetlust seetõttu ka õiguspäraselt lõpule viia; 7.2.4. hankija iseteeninduskioski raamhankele otsustatakse Euroopa Liidu vahendite st

ja riigieelarvest rahastust mitte tagada.

8. Läbirääkimised ja lepingu sõlmimine

8.1. Hankijal ja pakkujal on vajadusel õigus pidada läbirääkimisi pakkumuse ja/või lepingu kõikide tingimuste osas, välja arvatud järgnevate punktide osas:

8.1.1. Täitja saadab tellijale Eesti e-arve standardile vastavad e-arved või välismaise täitja puhul pdf formaadis e-posti aadressil [email protected]. E-arves peab lisaks standardis nimetatud andmetele olema toodud tellija kontaktisiku perekonnanimi,

riigihanke viitenumber ja raamlepingu number ja tellimuse viitenumber ning hankelepingu number, vajadusel ka välisvahendite projekti number. E arve tuleb

saata e-arvete operaatori lahenduse kaudu ning loetakse laekunuks arve saaja e arvete süsteemi laekumise kuupäevast.

8.1.2. Arve maksetähtaeg on 21 kalendripäeva, kui tellimuses ja hankelepingu

tingimustes ei ole sätestatud teistsugust (pikemat või lühemat) tähtaega. 8.1.3.

8.2. Juhul kui hankija pärast pakkumusega tutvumist leiab, et puuduvad lahtised küsimused, siis hankija läbirääkimisi ei alusta.

8.3. Läbirääkimised võivad toimuda kas hankija asukohas või elektrooniliselt (e-post,

Skype, eRHR vms). Suulised ja elektroonilisel teel peetud läbirääkimised protokollitakse. Hankija võib paluda pakkujal pakkumust kohandada.

8.4. Raamleping ja selle alusel sõlmitavad hankelepingud sõlmitakse inglise keeles. 8.5. Hankija edastab edukaks tunnistatud pakkumuse esitanud pakkujale allkirjastamiseks

raamlepingu, mille tingimused vastavad PEE ja edukaks tunnistatud pakkumuse

tingimustele ja läbirääkimiste käigus (kui need toimusid) kokkulepitud tingimustele. 8.6. Raamleping jõustub selle sõlmimisel. Raamleping loetakse sõlmituks hilisemast

allakirjutamise kuupäevast. 8.7. Pakkuja peab talle allkirjastamiseks edastatud raamlepingu allkirjastama ja hankijale

välja saatma hiljemalt 7 tööpäeva jooksul alates päevast, mil hankija selle pakkujale

välja saatis. Hankija võib allkirjastamise tähtaega pikendada, andes pakkujale sellest kirjalikku taasesitamist võimaldavas vormis teada.

Lugupidamisega

(allkirjastatud digitaalselt)

Janek Rozov

strateegiajuht peadirektori ülesannetes

Mattias Mikli, [email protected]

KÄSKKIRI

Tallinn 08.07.2022 nr 3-1/75

Väljakuulutamiseta läbirääkimistega riigihanke "Piirikontrolli iseteeninduskioski raamhange"

(viitenumber 248377) läbiviimine

Riigihangete seaduse § 49 lõike 1 punkti 2 ja § 72 ning Siseministeeriumi infotehnoloogia- ja

arenduskeskuse riigihangete korra punkti 6.4 alusel:

1. Viia läbi väljakuulutamiseta läbirääkimistega hankemenetlusega riigihange „Piirikontro lli iseteeninduskioski raamhange“ (248377), kuna piirivalve iseteeninduskioskid saavad

toimida ainult integreerituna olemasoleva secunet Security Networks AG (HRB 13615) abc-väravate haldussüsteemiga, siis seetõttu saab piirikontrolli iseteeninduskioske id tarnida ainult secunet Security Networks AG (HRB 13615).

2. Kinnitada riigihanke alusdokumendid. Hanke eest vastutaval isikul on õigus muuta pakkumuste esitamise tähtaega ning teha alusdokumentides menetluse käigus avastatud

vajalikke mittesisulisi muudatusi ning parandusi. 3. Teha pakkumuse esitamise ettepanek pakkujale secunet Security Networks AG (HRB

13615), kuivõrd pakkuja on esitanud hankijale ainuõigust tõendava kinnistuskirja.

4. Komisjoni liikmed kohustuvad kinnitama hankemenetluse käigus tehtavates otsustes, et neil puudub huvide konflikt pakkumuse esitanud pakkuja suhtes ning huvide konflikt i

ilmnemisel on nad kohustatud teavitama asjaoludest viivitamatult riigihanke eest vastutavat isikut kirjalikku taasesitamist võimaldavas vormis.

Käskkirja on võimalik vaidlustada Tallinna Halduskohtus (Pärnu mnt 7, Tallinn) või esitada vaie Siseministeeriumi infotehnoloogia- ja arenduskeskusele 30 päeva jooksul arvates otsuse

teatavakstegemisest.

(allkirjastatud digitaalselt)

Janek Rozov

Strateegiajuht peadirektori ülesannetes