Lisa 3 - turvanõuded tarnijale

1

RAAMLEPING nr 1-18/2026/19

Riigimetsa Majandamise Keskus, registrikood 70004459, aadress Mõisa/3, Sagadi küla,

Haljala vald, 45403 Lääne-Viru maakond (edaspidi RMK või tellija), keda esindab Vabariigi

Valitsuse 09.01.2007 määrusega nr 4 kinnitatud “Riigimetsa Majandamise Keskuse

põhimääruse” § 18 lõike 1 alusel juhatuse liige Agne Aija, ühelt poolt

ja

AKTSIASELTS HELMES, registrikood 10364097, aadress Tallinn, Lasnamäe linnaosa,

Lõõtsa tn 6, 11415 Harju maakond (edaspidi täitja), keda esindab põhikirja alusel juhatuse liige

Andres Kaljo, teiselt poolt,

keda edaspidi nimetatakse ka eraldi pool või koos pooled, on sõlminud raamlepingu (edaspidi

leping) alljärgnevas:

1. Üldsätted

1.1. Käesolev leping sõlmitakse riigihanke „Kliendiportaali ja puidumüügi keskkond“

(edaspidi nimetatud riigihange, viitenumber 301632, DHS 1-47.3531) tulemusena.

1.2. Lepingu juurde kuuluvateks lahutamatuteks osadeks loetakse riigihanke alusdokumendid

(RHAD), täitja riigihankes esitatud pakkumus ja riigihankes tellija antud selgitused ning

pooltevahelised kirjalikud teated, mida lepingu lisadena eraldi ei allkirjastata.

1.3. Lepingul on sõlmimisel järgmised lisad, mis on lepingu lahutamatuteks osadeks:

1.3.1. Lisa 1 – tehniline kirjeldus;

1.3.2. Lisa 2 – arendusnõuded;

1.3.3. Lisa 3 - isikuandmete töötlemise nõuded volitatud töötlejale.

1.4. Vastuolu korral lepingu ja lisa vahel, kohaldatakse lepingu lisas sätestatut, kui

konkreetsest lepingu sättest ei tulene teisiti.

1.5. Leping ei kohusta tellijat täitjalt teenust tellima. Tellija tellib teenust vastavalt reaalsele

vajadusele ja olemasolevatele võimalustele, kooskõlas tehnilise kirjeldusega.

2. Lepingu ese

2.1. Lepingu esemeks on RMK-le kliendiportaali ja puidumüügi enampakkumiste keskkonna

rakenduse arendus- ja hooldustööd (edaspidi „teenus“ või „töö“), mida täitja kohustub

läbi viima vastavalt RHAD-le, sõlmitud lepingule ja selle lisadele.

2.2. Pooled täpsustavad teenuse osutamise käigus teenuse sisu, ulatust ja ajakava lähtuvalt

kiiruse, kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest. Pooltel on õigus teha

nimetatud küsimustes omapoolseid ettepanekuid ja pakkumisi, mis tagaks teenuse parima

teostuse.

2.3. Täitja teostab töö kooskõlas tehnilise kirjeldusega ja parimate praktikatega

tarkvaraarenduses.

2.4. Lepingu täitmise keel on eesti keel, muuhulgas on see ka lepingu sõlmimise,

töökoosolekute jm suhtluse ning tööde dokumenteerimise keel.

2.5. 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. Tööde teostamisel tuleb lähtuda tõhususe,

kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest ning arvestades vastavas

tegevusvaldkonnas kehtivaid õigusakte, standardeid ja head tava.

2

3. Lepingu täitmine, tööde teostamine

3.1. Töid teostatakse üldjuhul täitja valitud asukohas tellija ja täitja poolt nimetatud

arendusmetoodikaid kasutades. Täitja teostab kogumaksumuse eest 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

3.2. Täitja alustab lepingu täitmist esimesel võimalusel pärast selle sõlmimist. Tellija annab

täitjale teada lepingu täitmise algustähtaja e-kirja teel. Tellijal on õigus ühepoolselt

nimetatud tähtaega edasi lükata vajaliku perioodi võrra põhjendatud vajaduse esinemisel.

Tellija teavitab täitjat lepingu täitmise hilisemast algustähtajast ja täitmisega viibimise

põhjusest e-kirja teel.

3.3. Täitja kohustub rakendama tööde teostamisel meeskonnaliikmeid, kelle ta on esitanud

lepingu sõlmimise aluseks olevas hankemenetluses.

3.4. Lisaks meeskonnaliikmetele, kelle CV-d on lisatud pakkumusele, võib täitja vajadusel

kaasata lepingu täitmisesse meeskonnaliikmeid, kes ei pea vastama hankemenetluses

vastavatele spetsialistidele tellija poolt kehtestatud nõuetele. Nimetatud spetsialistid

osalevad lepingu täitmisel ainult koos hankemenetluses kehtestatud nõuetele vastavate

spetsialistidega, ilma lisatasu küsimata. Täitja peab tellijat piisav aeg ette kirjalikult

informeerima planeeritavast meeskonnaliikme lisamisest ning spetsialisti lisamine võib

toimuda ainult tellija kirjalikku taasesitamist võimaldavas vormis antud nõusolekul ja

kooskõlas RHAD-ga. Tellijal on õigus täitja poolt pakutavast lisa meeskonnaliikmest

keelduda.

3.5. Täitja tagab lepingu täitmise eesti keeles. Lepingu täitmisesse kaasatud

meeskonnaliikme(te) eesti keele oskus kõnes ja kirjas peab olema vähemalt tasemel, mis

võimaldab meeskonnaliikme(te)l vahetult osaleda nii meeskonnatöös (koosolekud jmt)

kui teostada lepingu esemeks olevaid arendustöid ja saada iseseisvalt, ilma täiendava

tellija poolse juhendamiseta, aru tööülesannete ja tehniliste juhiste sisust ja tellijal

kasutusel olevate töökeskkondade juhistest. Juhul, kui meeskonnaliikme(te) eesti keele

oskus ei ole piisaval tasemel, tagab täitja meeskonnaliikme(te)le omal kulul tõlgi, sh juba

sõlmitud lepingu täitmise olukorras, kui ilmnevad probleemid eespoolviidatud

kompetentsidega. Taolisel kujul lepingu täitmine ei tohi kahjustada lepingu täitmise

kvaliteeti ega kiirust, vastasel juhul on tegu lepingu olulise rikkumisega.

3.6. Töid vahetult teostavate spetsialistide asendamine/lisamine võib toimuda tellija kirjalikku

taasesitamist võimaldavas vormis antud nõusolekul. Täitja on kohustatud teavitama

tellijat meeskonnaliikme asendamisest/lisamisest kirjalikku taasesitamist võimaldavas

vormis vähemalt 14 päeva enne meeskonnaliikme asendamist/lisamist, kusjuures täitja on

kohustatud tagama, et uue meeskonnaliikme kompetents on vähemalt võrdne lepingu

sõlmimise aluseks olevas hankes vastavale meeskonnaliikmele esitatud nõuetega. Tellijal

on õigus keelduda täitja poolt lepingu täitmiseks esitatud meeskonnaliikme

asendamiseks/lisamiseks pakutavast meeskonnaliikmest, kui pakutav spetsialist ei vasta

eelnimetatud nõuetele või kui pakutava isiku kompetentside hindamisel ei oleks täitja

pakkumus olnud hankemenetluses edukas (so kohtleks teisi pakkujaid ebavõrdselt).

3.7. Lisaks punktis 3.6 sätestatule kohustub täitja tellijat vähemalt 14 päevaette teavitama

kirjalikku taasesitamist võimaldavas vormis meeskonnaliikmete planeeritud puhkustest

ja lähetustest juhul, kui puhkuse või lähetuse kestus on 4 või rohkem kalendripäeva.

3.8. Täitja annab kogu lepingu täitmise perioodi vältel jooksvalt tagasisidet tellija küsimustele

ja arupärimistele ning annab tellija nõudmisel jooksvalt ülevaate ja esitleb juba teostatud

või teostamisel olevaid töid.

3.9. Pretensioonid töö tulemi plaanipärase edenemise, teostamise efektiivsuse ja kvaliteedi

kohta annab tellija teada lisaks meeskonnaliikmele ka täitja lepingulisele kontaktisikule.

3

Olulises ulatuses või korduvaid kõrvalekaldeid tellija juhiste järgimata jätmisel loetakse

lepingu rikkumiseks.

3.10. Tellijal on õigus igal ajal lepingu täitmise käigus kolme kalendripäevase etteteatamisega

kokku kutsuda koosolekuid, kus täpsustatakse töökorraldust, tellija ja täitja ootuseid vmt.

3.11. Tellija on kohustatud kõikidele täitja lepingu täitmisega seotud põhjendatud küsimustele

vastama hiljemalt kolme tööpäeva jooksul. Juhul, kui küsimusele vastamine nõuab

tellijalt pikemat analüüsi, on tellija kohustatud andma eeltoodud kolme tööpäeva jooksul

täitjale täpse kuupäeva, millal tagasisidet antakse, sellisel juhul on täitjal õigus nõuda

tarne tähtaja proportsionaalset pikendamist.

3.12. Täitja tagab ja vastutab tööks vajalike töövahendite, litsentside ja autoriõiguste eest

iseseisvalt.

4. Analüüsi-, hooldus- ja arendustööde teostamine

4.1. Tööde teostamiseks esitab tellija täitjale tellimuse. Eraldiseisvaid kirjalikke

hankelepinguid ei sõlmita.

4.2. Töid teostatakse agiilselt tunnipõhise arvestusega, akteeritakse ja arveldatakse 1 (üks)

kord kuus eelmise kuu töötundide ja lepingus sätestatud tunnitasu alusel. Seejuures tellija

kontrollib täitja esitatud akti tundide vastavust tehtud tööle ning kinnitab või esitab

küsimusi/tagasisidet hiljemalt 14 päeva jooksul peale akti esitamist.

4.3. Täitja koostöös tellija kontaktisikuga valmistavad ette (analüüsib ja kirjeldab)

tööülesanded tellija tööülesannete projektirühmas. Täidetavad ülesanded (tulemid)

lepitakse kokku kohtumistel (ehk projektirühma koosolekul). Sellele eelnevalt hinnatakse

ja täiendatakse tulevaste tööde/tulemite sisu ja töömahtu selleks ettenähtud kohtumisel.

Täitja peab lepingu täitmisel juhinduma tellija poolt edastatud juhistest ja ülesannetest.

4.4. Konkreetse töö teostamisel lepitakse projektirühmas kokku rakendatava meeskonna

suurus ja rakendatavad rollid vastavalt pakkumusele, tellija vajadustele ja prioriteetidele

tulenevalt tellitava teenuse konkreetsest sisust.

4.5. Loodavad tulemid antakse üle tellija koodirepositooriumi kaudu vastavalt tellija juhistele.

Arendustööde raames tehtud lähtekoodi paneb täitja tellija koodirepositooriumisse ja

paigaldab tellija arenduskeskkonda vähemalt 1 (üks) kord nädalas. Täitja

meeskonnaliikmetele luuakse tellija poolt ligipääs koodirepositooriumile lähtekoodide,

andmebaasimuudatuste ning muude tulemite või nende muudatuste üleandmiseks.

4.6. Enne lähtekoodi repositooriumisse lisamist peab kood/teostatud töö/tulem olema:

4.6.1. iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga

vastuolus funktsionaalsust);

4.6.2. üldharu/muu haru tulemiga kooskõlas;

4.6.3. edaspidi mugavalt kasutatav ja mõistetav, ehk sellel on olemas oma enda

sisseehitatud testid, mis peale järgnevaid võimalikke arendusi/tegevusi näitaks, kas see

konkreetne funktsionaalsuse osa on endiselt korras, või läks katki ja tuleb korrastada.

4.7. Äriliselt võtmetähtis funktsionaalsus peab olema loodavas koodis varustatud

kommentaaridega (klasside ja meetodite kommentaarid).

4.8. Tarnitav lepingu ese peab ühilduma tellija poolt nõutud tehnilise lahendusega (erisused

on lubatud tellija kontaktisiku kirjalikku taasesitamist võimaldavas vormis esitatud

nõusolekuga), sealhulgas:

4.8.1. järgima tellija poolt nõutud tehnilise lahenduse ideoloogiat süsteemsete

protseduuride osas ja infosüsteemi arhitektuurset lahendust ja kasutusloogikat;

4.8.2. taaste- ja varundusprotseduurid peavad olema ühilduvad tellija poolt soovitud

tehnilise lahendusega;

4.8.3. lepingu ese ei tohi põhjustada süsteemi töö terviklikkuse või muid toimimise

häireid ega jõudluse langust;

4

4.8.4. lepingu ese peab olema tellija poolt nõutud infosüsteemiga ühetaoline ning

sobituma olemasolevatesse ekraanivormidesse ja töövoogu;

4.8.5. lepingu ese peab vastama hankes esitatud arendusnõuetele, välja arvatud

nendele, millele loodav infosüsteem ei kohaldu või on täitja poolt kirjalikult välja toodud

ja põhjendatud ning tellija poolt kirjalikult kinnitatud erand;

4.9. Tööde teostamise käigus tuleb täitjal vajadusel uuendada ka lepingu eseme

dokumentatsiooni (kirjeldused, juhised, protsessianalüüs jmt) ja dokumentatsioon

tellijale üle anda. Dokumentatsiooni üleandmisel eelistatakse elektroonilist vormi.

4.10. Tööde üldisteks vastuvõtukriteeriumiteks on:

4.10.1. vastavus lähteülesandes toodud ja projektirühmas kokkulepitud ärilisele- ja

tehnilisele kirjeldusele;

4.10.2. vigade ja kõrvalmõjude puudumine.

4.11. Tellijal on 14 tööpäeva aega kontrollida vastuvõtmiseks esitatud tööde

lepingutingimustele vastavust. Tellija kontaktisik võib nimetatud tähtaega pikendada, kui

pikendamine on põhjendatud.

4.12. Üleandmis-vastuvõtmisakti valmistab ette täitja vastavalt tellija poolt etteantud vormile

ning see allkirjastatakse poolte kontaktisikute poolt digitaalselt. Täitja esitab tellijale

punktis 4.2 nimetatud ja akteeritud tööde teostamise järel üleandmis-vastuvõtmisakti,

milles on sätestatud täitja poolt teostatud tööde tulemi kirjeldus, ning vastava töö

maksumus. Vajadusel täpsustatakse aktis üle antud tulemit. Üleandmise-vastuvõtmise

akti on õigus allkirjastada lepingu kontaktisikutel.

4.13. Peale üleandmise-vastuvõtmise akti allkirjastamist esitab täitja tellijale arve teostatud

tööde eest vastavalt üleandmise-vastuvõtmise aktile ja punktile 4.11.

4.14. Kui Tellijal puuduvad lepingu eseme osas pretensioonid, allkirjastavad pooled Lepingu

eseme üleandmise-vastuvõtmise akti.

4.15. Mistahes Teenuse osa valmimisel võib Tellija anda välja vastuvõtuakti vastava osa kohta

ning aktis fikseeritakse puudused koos puuduste kõrvaldamise tähtajaga. Selline

vastuvõtmine ei mõjuta Täitja kohustust täita kõiki Lepingus ettenähtud kohustusi.

4.16. Tellija poolt Teenuse vastuvõtmine ei vabasta Täitjat vastutusest Teenuse üleandmisel-

vastuvõtmisel avastamata jäänud vigade või Teenuse mittenõuetekohasuse eest.

4.17. Tugi- ja hooldustööde tellimuses edastab Tellija Töövõtjale teenuse osutamise

alguskuupäev, maksumus ning vajadusel muud andmed.

5. Garantiitingimused

5.1. Üle antud tulemi osas kohaldub garantii alljärgnevatel põhimõtetel:

5.1.1. garantiiaeg on 12 (kaksteist) kuud alates hetkest, mil viimase etapi tulem on

tellija poolt lepingu kohaselt vastu võetud;

5.1.2. olukorras, kus töö pole akti alusel vastu võetud, on etapi tulemi osaline või täielik

toodangus kasutuselevõtt aluseks nende osade garantiiperioodi algusele;

5.1.3. täitja on kohustatud tagama garantiiajal tulemil ilmnenud puuduste tasuta

kõrvaldamise vastavalt vea prioriteetsusele järgnevalt:

5.1.3.1. kriitilised vead 2 tööpäeva jooksul peale sellekohase teate

edastamist tellija poolt täitjale. Kriitiliseks veaks loetakse tarkvara arendusega

seotud viga, mille tõttu: tarkvara tervikuna ei ole võimalik kasutada; tarkvara

põhifunktsionaalsus ei tööta või on oluliselt häiritud; tarkvara lubab/teostab

mitteautoriseeritud operatsioone; kahjustatud on süsteemis olevad andmed;

kasutajale või seotud infosüsteemidele/andmebaasidele väljastatakse ebaõigeid

andmeid/tulemusi. Kriitiliseks veaks loetakse sealhulgas ebamõistliku

sagedusega esinevad sarnased mittekriitilised vead;

5

5.1.3.2. mittekriitilised vead 5 tööpäeva jooksul peale sellekohase teate

edastamist tellija poolt täitjale. Mittekriitiliseks veaks loetakse infosüsteemi

toimehäiret, mis ei ole põhjustatud riistvarast või muust tarkvarast või muust

arendustööst ja mida ei saa käsitleda kriitilise veana.

5.2. Veateade loetakse esitatuks, kui tellija või tellija kontaktisik on veateate esitanud

kirjalikku taasesitamist võimaldavas vormis täitjale või täitja lepingujärgse kontaktisiku

e-posti aadressil.

5.3. Täitja teostab garantiiaja vältel vajalikud tööd kasutades lepingukohast meeskonda,

milles on võimalik muudatusi teha vastavalt lepingu punktile 3.6.

6. Poolte vastutus

6.1. Pooled vastutavad lepinguliste kohustuste rikkumise eest. Kohustuse rikkumisel on teisel

poolel õigus kasutada kõiki seadusest või lepingust tulenevaid õiguskaitsevahendeid

vastavalt võlaõigusseadusele.

6.2. Lisaks mujal lepingudokumentides sätestatule, on tellijal õigus nõuda ja täitjal on

kohustus maksta leppetrahvi tarne üleandmisega või garantiitööde teostamisega

viivitamisel 0,5 % vastava töö maksumusest iga viivitatud tööpäeva eest.

6.3. Poolte hankelepingust tulenev koguvastutus on piiratud hankelepingu

kogumaksumusega.

6.4. Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue 10 000

eurot iga rikkumise eest. Täitja poolse olulise hankelepingu rikkumise korral ei pea tellija

määrama täitjale lepingu täitmiseks võlaõigusseaduse §-s 114 nimetatud täiendavat

tähtaega ning tellijal on muu hulgas õigus hankeleping üles öelda või hankelepingust

taganeda.

6.5. Oluliseks rikkumiseks loevad pooled lisaks võlaõigusseaduses ja mujal lepingus

sätestatule muuhulgas:

6.5.1. mõjuva põhjuseta lepingu täitmise katkestamine või täitmisele mitte asumine;

6.5.2. valeinfo esitamine;

6.5.3. lepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid, intellektuaalse

omandi õigused) puudumine;

6.5.4. intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine;

6.5.5. korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes ei

vasta kokku lepitud nõuetele või meeskonnaliikme asendamine ilma tellija eelneva

vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta;

6.5.6. konfidentsiaalsuskohustuse rikkumine;

6.5.7. lepingujärgsete kohustuste korduvat (vähemalt kahel korral) täitmata jätmist;

6.5.8. tähtaegselt lepingu täitmata jätmist selliselt, et tehnilises kirjelduses sätestatud

eesmärgi täitmine ei ole enam tähtaegselt realistlik ja/või täitja poolse tegevuse või

tegevusetuse tõttu ei ole võimalik enam kasutada lepingu rahastamiseks ettenähtud

vahendeid;

6.5.9. lepingujärgsete kohustuste üleandmine kolmandale isikule.

6.5.10. RMK infoturbe nõuetele mittevastavus.

6.6. Kui Täitja ei paranda teenuses esinevaid probleeme garantiitingimuste punktis 5.1.3

sätestatud lahendamise aja jooksul, on Tellijal õigus nõuda leppetrahvi järgmiselt:

6.6.1. kriitiline viga - 400 (nelisada) eurot iga ületatud tunni eest;

6.6.2. mittekriitilised vead - 200 (kakssada) eurot iga ületatud tunni eest;

7. Tasu maksmine

7.1. Pooled lähtuvad teenuse eest tasumisel pakkumuses toodud tunnihindadest.

6

7.2. Lepingu maksimaalne kogumaksumus on 1 500 000 eurot, millele lisandub käibemaks

(edaspidi lepingu hind). Lepingu hind sisaldab muuhulgas ka kõiki intellektuaalomandiga

seotud tasusid, kui need kohalduvad.

7.3. Tellijal on õigus lepingu rikkumise korral arvestatud leppetrahvid ja kahju hüvitised maha

arvata lepingu alusel täitjale tasumisele kuuluvatest summadest.

7.4. Täitja esitab arve vaid elektrooniliselt. Arve esitamiseks tuleb kasutada elektrooniliste

arvete esitamiseks mõeldud raamatupidamistarkvara või raamatupidamistarkvara E-

arveldaja, mis asub ettevõtjaportaalis https://www.rik.ee/et/e-arveldaja.

7.5. Arved kuuluvad Tellija poolt tasumisele 15 (viieteistkümne) päeva jooksul arve

edastamisest Tellijale. E-arve peab sisaldama Teenuse tegelikku tellimust vormistanud

kontaktisiku nime või lepingust tulenevat tellija kontaktisiku nime ning selgelt ja üheselt

viitama lepingu numbrile ja arve perioodile.

8. Lepingu kehtivus, täiendamine, muutmine ja lõpetamine

8.1. Raamleping jõustub selle allkirjastamisest ja kehtib 48 kuud või kuni rahalise mahu

täitumiseni, olenevalt sellest kumb olukord saabub varem.

8.2. Lepingu muutmine on võimalik üksnes poolte kirjalikul kokkuleppel ja kooskõlas

riigihangete seadusega.

8.3. Pooltel on õigus leping üles öelda seaduses ja lepingus sätestatud alustel.

8.4. Tellijal on õigus leping olenemata põhjusest ilma täiendavat tasu või hüvitist maksmata

korraliselt üles öelda, teatades sellest täitjale kirjalikult üks (1) kuu ette.

8.5. Täitjal on õigus leping erakorraliselt üles öelda, kui:

8.5.1. lepingust tulenevate täitja kohustuste täitmine on muutunud võimatuks tellijast

põhjustatud tingimustel;

8.5.2. tellija on põhjendamatult viivitanud lepingujärgsete maksete tasumisega rohkem

kui 40 (nelikümmend) kalendripäeva.

8.6. Tellijal on õigus leping erakorraliselt etteteatamise tähtaega järgimata üles öelda ja nõuda

täitjalt tekkinud otsese varalise kahju kompenseerimist, kui:

8.6.1. täitja rikkus oluliselt lepingu kohustust, mille järgimine oli täitja kohustus;

8.6.2. puudus on tekkinud täitjast tingitud asjaoludel, puuduste kõrvaldamine teenuse

osutamisel ei ole võimalik ja puudus mõjutab oluliselt teenuse osutamise väärtust tellija

jaoks;

8.6.3. täitja rikub muul moel lepingut sedavõrd oluliselt, et ei saa mõistlikult eeldada

lepingu jätkamist tellija poolt;

8.6.4. kui täitja ei täida lepingus ja selle lisades kokku lepitud nõudeid või on tema

tegevus muul viisil vastuolus lepingu ja selle lisadega ning kui hoolimata tellija

nõudmisest ei ole olukord paranenud;

8.6.5. kui esinevad riigihangete seaduse §-s 124 toodud lepingu ülesütlemise alused;

8.6.6. kui täitja on teadlikult esitanud enne või peale lepingu sõlmimist või lepingu

täitmise käigus tellijale valeinformatsiooni.

8.7. Lepingu lõppemisel jäävad kehtima kõik sellised sätted, mille osas on lepingus sätestatud

nende kehtima jäämine pärast lepingu lõppemist.

8.8. Lepingu ülesütlemine, lõpetamine või lõppemine ei vabasta pooli kohustuste täitmisest,

mis neil tekkisid enne lepingu ülesütlemist, lõpetamist või lõppemist. Lepingu

ülesütlemisel, lõppemisel või lõpetamisel teostavad pooled kõik teenuse osutamise

kulude ja arvete tasaarvestused 30 päeva jooksul alates lepingu lõpetamise kuupäevast,

juhindudes sealjuures faktiliselt tehtud kulutustest ja nõuetekohaselt osutatud teenusest.

8.9. Lepingu ülesütlemisel, lõpetamisel või lõppemisel tuleb täitjal edastada tellijale

viivitamatult (ülesütlemise teate saamisest või kokkuleppe allkirjastamisest 3 tööpäeva

jooksul lepingu lõppemise tähtaja saabumisel hiljemalt 10 tööpäeva enne lepingu

7

lõppemist) kõik seni lepingu raames tehtud ja üle andmata tööd ja seonduv materjal,

informatsioon ja dokumendid (sh poolelioleva projekti või objektiga seonduv materjal).

9. Konfidentsiaalsus ja andmekaitse

9.1. Pool kohustub tähtajatult hoidma saladuses teise poole poolt lepingu täitmise raames

saadud, edastatud või muul moel teatavaks saanud teabe ja dokumendid, mis vastavalt

avaliku teabe seaduse või muu kehtiva õigusakti nõuetele ei ole avaldamiseks kohustuslik

(konfidentsiaalne informatsioon).

9.2. Konfidentsiaalse informatsiooni avaldamine kolmandatele isikutele on lubatud vaid teise

poole eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul. Lepingus

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

esindajatele, töötajatele, audiitoritele, advokaatidele, pankadele, kindlustusandjatele,

allhankijatele või teenusepakkujatele ja muudele isikutele, keda ta oma kohustuste

täitmisel kasutab (seotud isikud).

9.3. Pool kohustub tagama, et temaga seotud isikud oleksid lepingus sätestatud

konfidentsiaalsuse kohustusest teadlikud ning rakendama temaga seotud isikutele

samaväärseid nõudeid konfidentsiaalse informatsiooni töötlemisel ja kasutamisel, kui

kehtib poolele endale lepingu ja seaduse alusel.

9.4. Täitja kohustub mitte kasutama konfidentsiaalset teavet isikliku kasu saamise eesmärgil

või kolmandate isikute huvides.

9.5. Pool kohustub tagama lepingu täitmise käigus isikuandmete töötlemise õiguspärasuse

ning vastavuse isikuandmete kaitse üldmääruses (EL 2016/679) ja teistes andmekaitse

õigusaktides sätestatud nõuetele, sh 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.

10. Load ja litsentsid

10.1. Täitja vastutab ainuisikuliselt lepingu täitmiseks vajalike lubade ja litsentside saamise

eest. Tellija teeb täitjaga mõistliku koostööd, hoidmaks ära selliste lubade või litsentside

väljaandmise asjatut viivitamist või väljaandmisest keeldumist.

10.2. Tellija võib ilma ette teatamata lepingu lõpetada, kui täitja ei saa lepingu täitmiseks

vajalikku luba või litsentsi.

10.3. Tellija tagab täitjale ligipääsu tellija kontorisse ja infosüsteemidele ulatuses, milles see

on lepingu täitmiseks vajalik.

11. Intellektuaalne omand

11.1. Täitja loovutab tellijale kõik varalised õigused autoriõiguse seaduse tähenduses käesoleva

lepingu alusel üle antud tulemitele, kaasa arvatud õiguse neid reprodutseerida, levitada ja

üldsusele kättesaadavaks teha mistahes vormis ja kandjal, ilma geograafiliste

piiranguteta. Autori varalised õigused loetakse tellijale üle läinuks pärast tulemi

lepingukohast vastuvõtmist tellija poolt.

11.2. Juhul kui lepingus või tellimuses ei ole sõnaselgelt sätestatud teisiti, on tellijal muuhulgas

õigus:

11.2.1. lepingu eset kasutada mis tahes eesmärgil ja viisil;

11.2.2. originaalteost muuta;

11.2.3. lepingu eset või selle koopiaid laenutada ja rentida;

11.2.4. anda all-litsentse lepingu eseme või selle koopiate suhtes kehtivate õiguste

kohta.

8

11.3. Täitja annab tellijale vastavalt valdkonnas kehtivatele parimatele praktikatele

dokumenteeritud lähtekoodi, va punktis 11.6 sätestatud juhtudel, kui on tegemist

standardtarkvaraga.

11.4. Juhul kui lepingus või tellimuses ei ole sõnaselgelt sätestatud teisiti, kehtivad nimetatud

õigused kogu autoriõiguste kehtivuse aja ja nende kehtivuse territooriumiks on kogu

maailm.

11.5. Lepingu alusel üle antud õigused ja litsents hõlmab kõiki edasisi tulemi arendusi. Lepingu

alusel annab täitja tellijale õiguse luua oma äranägemisel tuletatud teoseid tulemi

edasiarendamise teel.

11.6. Juhul kui riigihankes on pakutud tehnilises kirjelduses kirjeldatud samaväärset platvormi

ning pakkumus sisaldab vastavaid litsentse, annab täitja tellijale õiguse litsentsiga

määratletud tarkvara kasutada lepingus sätestatud ulatuses ja määras. Sellisel juhul täitja:

11.6.1. tagab lepingu täitmiseks vajalike litsentside ja vajadusel muude intellektuaalse

omandi õiguste olemasolu ja kehtivuse lepingu täitmise ajal;

11.6.2. kinnitab, et kasutusõiguse andmisega tellijale ei rikuta kolmandate isikute

autoriõigusi ega muid intellektuaalse omandi õigusi lepingu kehtivuse ajal;

11.6.3. hüvitab tellijale kõik täitja poolt käesoleva punkti rikkumisest tulenevad tellijale

tekkivad kulud ja kahjud juhul, kui täitja poolt pakutavad litsentsid rikuvad teiste isikute

õigusi;

11.6.4. esitab tellijale kõigi litsentside autoriõiguste ja muude intellektuaalomandi

õiguste kasutamisõigust tõendavad kinnitused hiljemalt ajaks, kui tellijal tekib vajadus

kasutada nimetatud õigusi;

11.6.5. annab tellijale üle dokumendid ja teabe, mis on vajalikud litsentsidest tulenevate

õiguse kasutamiseks lepingu alusel;

11.6.6. kannab kõik otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul

on või väidetavalt on intellektuaalsest omandist tulenevaid õigusi lepinguga seotud

intellektuaalse omandi objektile.

11.7. Täitja tagab tellijale kõik vajalikud õigused lepingu täitmise käigus loodava tulemi

kontrollimiseks, testimiseks ning süsteemi paigutamiseks ka ajaks, mil tarne on üle antud,

kuid pole veel lepingukohaselt tellija poolt vastu võetud.

12. Probleemihalduse rakendus

12.1. Täitja koostöös tellija kontaktisikuga valmistavad ette (analüüsib ja kirjeldab)

tööülesanded tellija tööülesannete haldussüsteemis JIRA. Täidetavad ülesanded (tulemid)

lepitakse kokku projektimeeskonna kohtumistel. Sellele eelnevalt hinnatakse ja

täiendatakse tulevaste tööde/tulemite sisu ja töömahtu selleks ettenähtud kohtumisel.

Täitja peab lepingu täitmisel juhinduma tellija poolt edastatud juhistest ja ülesannetest.

12.2. Kasutatav probleemihalduse rakendus on tellija Atlassian Jira, mida kasutatakse teenuse

osutamisel avastatud probleemide, küsimuste jms ülesannetena registreerimiseks ja

järelevalveülesannete täitmiseks. Tellija registreerib tuvastatud probleemid, küsimused

jms probleemihalduse rakenduses ülesannetena. Pooled võivad kokku leppida, et

kasutavad Atlassian Jira asemel muud lahendust.

12.3. Probleemihalduse rakenduse tarkvarale pääseb juurde turvaliselt ja autoriseerituna

veebiaadressi kaudu.

12.4. Tellija võib Täitjat teavitada tuvastatud probleemidest, küsimustest jms e-posti ja telefoni

teel, kuid ülesande käsitlemise eelduseks on nende registreerimine probleemihalduse

rakenduses.

12.5. Vajaduse korral lepivad Pooled kokku täpsemas kasutuskorras probleemihalduse

rakenduse puhul, milles selgitatakse ülesannete lisamise nõudeid (rubriigid, teemad,

ülesannete prioriteetsed kategooriad jne).

9

13. Dokumentatsioon

13.1. Täitja varustab tellijat piisava, adekvaatse ja ajakohase dokumentatsiooniga tarkvara

funktsioneerimise kohta, mis on vajalik, et tellija saaks tarkvara ja teenuseid efektiivselt

kasutada.

13.2. Kasutusjuhendid ja muud tehnilised dokumendid tuleb esitada eesti keeles.

13.3. Dokumentatsioon peab vastama tarkvarale, sisaldama muudatusi ja olema

terminoloogiliselt üheselt mõistetav.

13.4. Dokumentide valmistamiseks ja levitamiseks kasutatakse Atlassian Confluence

keskkonda, mille juurdepääsu täitjale tagab tellija.

14. Vääramatu jõud

14.1. Kui mistahes vääramatu jõu tingimustele vastav asjaolu toob kaasa lepingu mittetäitmise

lepingus või selle lisades ettenähtud tähtajal ning selle mõju on ajutine, on lepingust

tulenevat kohustust rikkunud poole käitumine vabandatav üksnes ajal, mil vääramatu

jõud kohustuse täitmist takistas. Vääramatu jõud on mistahes asjaolu, mida pool ei saanud

mõjutada ja mõistlikkuse põhimõttest lähtudes ei saanud temalt oodata, et ta lepingu

sõlmimise ajal selle asjaoluga arvestaks või seda väldiks (nt loodusõnnetused, sõda,

mobilisatsioon, võimu- ja valitsusorganite aktid jms).

14.2. Vääramatu jõu esinemise tõttu lükatakse lepingulise kohustuse täitmise tähtaeg edasi

vastavalt asjaolu mõjumise ajale, kuid mitte enamaks kui 90 päeva.

14.3. Pool, kes ei suuda oma kohustusi vääramatu jõu tõttu täita, peab viivitamatult teatama

teisele poolele nimetatud olukorra tekkimisest ja lõppemisest. Mitteteatamine või

mitteõigeaegne teatamine võtab poolelt õiguse viidata rikkumise vabandatavusele, s.o

vääramatu jõu esinemisele ning teavitamise kohustust rikkunud pool vastutab lepingulise

kohustuse rikkumise eest vastavalt lepingus sätestatule.

14.4. Kui vääramatu jõu mõju on alaline ning ei võimalda pooltel täita lepingulisi kohustusi

täielikult või osaliselt, on pooltel õigus leping üles öelda või taganeda, tehes teisele

poolele vastava lepingust ülesütlemis- või taganemisavalduse.

15. Tellija esindamine lepingu täitmisega seotud küsimustes

15.1. Juhul, kui leping on allkirjastatud RMK juhatuse liikme poolt, on lepingu täitmisega

seotud hankelepingute sõlmimise ja/või tellimuste esitamise õigus, sõltumata nende

maksumusest, lepingu täitmise eest vastutava RMK struktuuriüksuse või piirkonna juhil

ning piiratud ulatuses lepingu, hankelepingu või tellimuse alusel teostatavate tööde

korraldamiseks volitatud spetsialistil.

15.2. Lepingu ning selle alusel sõlmitud hankelepingute ja/või esitatud tellimuste täitmiseks

vahetult vajalike lisade (tööajagraafikud, kasutatava tehnika loetelu) jmt dokumentide

allkirjastamise ning pretensioonide esitamise õigus, samuti tööülesannete andmise ja töö

kvaliteedi kontrollimise õigus, on lepingus, hankelepingus või tellimuses sätestatud

kontaktisikul.

15.3. Kui tööde üleandmis-vastuvõtmisaktide kinnitamiseks või allkirjastamiseks volitatud isik

ei ole teisiti välja toodud, on vastav õigus töid vahetult juhendaval RMK töötajal.

16. Tellija ja Täitja esindajad

16.1. Tellija esindajad käesoleva raamlepingu täitmisel on punktide 15.1 ja 15.2. osas: Annika

Brauer, tel +372 5348 9984, e-post [email protected].

16.2. Täitja esindajad, kes omavad õigust ja kohustust jälgida lepinguga tellija ja täitja poolt

võetud kohuste täitmist, on: projektijuht Kaidi Neeme, tel nr +372 5346 0629, e-post

10

[email protected] ja juhatuse liige Ian Nelis, tel nr +372 5664 5072, e-post

[email protected].

17. Lõppsätted

17.1. Lepingust tulenevad vaidlused lahendatakse läbirääkimiste teel. Kokkuleppe

mittesaavutamisel pöördutakse lahenduse saamiseks Harju Maakohtusse.

17.2. Täitja ei või anda lepingust tulenevaid kohustusi üle kolmandale isikule ilma tellija

kirjaliku nõusolekuta.

17.3. Lepinguga seotud informatsioonilise iseloomuga teated edastatakse poolte vahel e-posti

teel, sh pretensioonid. Muud pooltele õiguslikke tagajärgi kaasatoovad teated

vormistatakse kirjalikult ning edastatakse e-posti teel. Kontaktisiku e-posti aadressile

edastatud teate ja pretensiooni loevad pooled kätte saaduks koheselt pärast teate või

pretensiooni saatmist.

17.4. Kontaktide muutumisest kohustub pool teist poolt koheselt teavitama.

17.5. Lepingu lisad kuuluvad poolte poolt allakirjutatud lepingu juurde ja kehtivad selle

lahutamatute osadena.

17.6. Leping on allkirjastatud digitaalselt.

Lisa 1

RMK ja AKTSIASELTS

HELMES vahelise lepingu

nr 1-18/2026/19 juurde

RMK kliendiportaali ja puidumüügi

enampakkumiste keskkonna tehniline

kirjeldus

Riigimetsa Majandamise Keskus

Taust

Riigimetsa Majandamise Keskus (RMK) on Eesti suurim metsamaterjali müüja, kelle poolt

puitu väärindavatele ettevõtetele müüdav maht moodustab ligikaudu kolmandiku kogu Eesti

aastasest raiemahust. Vastavalt Vabariigi Valitsuse määrusele on sätestatud riigimetsa puidu

müügiviisid ning müügi korraldamise põhimõtted. RMK puiduturustusstrateegia kirjeldab tulu

teenimise ning puiduturu stabiilsuse vaates riikliku puidu müügi strateegia. RMK-l on

kohustus teenida riigile tulu ning tagada puiduturu stabiilsus ja investeerimiskeskkonna

atraktiivsus Eesti puidutööstuses, Metsapoliitikast ja Metsanduse arengukavast aastani 2030

lähtudes nähakse selle eesmärgi saavutamisel keskset rolli pikaajalistel kestvuslepingutel,

kuid olulisel määral kasutatakse ka avalikke enampakkumisi.

Tänane kestvuslepingute ja enampakkumiste müügiprotsess ei ole automatiseeritud ja

seetõttu kasutajasõbralik – pakkumised esitatakse e-posti teel, kasutades Exceli vorme. See

tekitab ettevõtjatele täiendavat administratiivkoormust ja ei ole kooskõlas tänapäevaste

digiteenuste standarditega. Infosüsteemide puudulikkus toob kaasa killustatuse,

ebaefektiivsuse ning tõstab ka halduskoormust RMK-le kui menetlejale.

Käesoleva arendusprojekti eesmärk on luua kaasaegne infosüsteem, mis tooks RMK

puiduturustuse kestvuslepingute ja enampakkumiste protsessid nii RMK töötajate kui ka

klientide jaoks uude ühtsesse infosüsteemi.

Mõisted ja lühendid

Alljärgnev tabel annab ülevaate tehnilises kirjelduses kasutatud peamistest mõistetest ja

lühenditest.

Mõiste Selgitus

Aastane prognoositav

kogus (sort. Prognoos)

RMK hinnanguline kogus metsamaterjali, mida aastas müüakse

sortimendi lõikes.

Avalik enampakkumine Metsamaterjali müügiviis, kus pakkumised tehakse suuliselt,

kirjalikult või elektrooniliselt ja parim hind võidab.

Avalikule

enampakkumisele

jäetav osa

Prognoosikoguses sisalduv osa, mida RMK ei müü kestvuslepingu

alusel, vaid jätab enampakkumiseks.

Kestvusleping Leping, mille alusel müüakse metsamaterjali pikema aja jooksul (üle

12 kuu), tuginedes eelnevale läbirääkimiste protsessile.

Kinnine

enampakkumine

Pakkumisvoor kestvuslepingu raames. Hind ei tohi olla madalam

eelnevate edukate pakkumuste keskmisest hinnast.

Kliendiportaal Käesoleva tehnilise kirjelduse tulemusena valmiv infosüsteem

Müügiobjekt Müügiks olev kogus puitmaterjali sortimendi ja metsandike lõikes,

piirkonna põhine.

Minimaalne lubatud

müügihind/Alghind

Hind, millest madalama hinnaga pakkumised tunnistatakse mitte

vastavaks.

MOK Müügiotsuste kaalumise infosüsteem

Avalik enampakkumine Puidumüügi avalikustatud pakkumine kliendile, EPA

Infosüsteemi eesmärk ja ulatus

RMK kliendiportaali ja puidumüügi enampakkumiste keskkonna eesmärk on luua terviklik

infosüsteem, mille käigus:

- Etapp 1: Arendatakse välja kliendiportaal lõppkasutajatele, mis hakkab olema

kättesaadav www.rmk.ee veebiportaali kaudu sisselogimise teel; siin etapis on oluline,

et luuakse tehniline platvorm, mis vastaks RMK tehnilistele nõuetele ja arhitektuurile

ning tuuakse nähtavale andmed, mis on kirjeldatud käesolevas dokumendis peatükis

“Integratsioonide kirjeldused”. Etapp 1 peab valmima hiljemalt 2026. aasta juunikuu

lõpuks.

- Etapp 2: Arendatakse puidumüügi valdkonnaga seotud rakendusi, andmebaase ja

integratsioone, mis võimaldavad puidumüügi äriloogika ja pakkumiste protsessi viia

elektroonilisel kujul kliendiportaali; Ehitatakse välja enampakkumiste moodul, mis

toimib oksjonite läbiviimise põhimõttel, kuid arvestab RMK puidumüügi protsessi

võimalikest muudatustest tuleneva paindlikkusega. Etapp 2 arendused peavad

jõudma tootekeskkonda 2026a IV kvartali alguseks, vähemalt sellises mahus, mis

võimaldavad IV kvartalis esimesed elektroonilised puidumüügi enamapakkumised läbi

viia.

- Etapp 3: Analüüsitakse ja arendatakse välja täiendavad kliendiportaali

funktsionaalsused RMK erinevate äriprotsesside katmiseks, mida täna tehakse

eraldiseisvates infosüsteemides või ka infosüsteemide väliselt.

Täpsemalt:

Etapis 1 toodud kliendiportaal hakkab olema sisse-logitud lõppkasutajale suunatud

iseteeninduskeskkond, mis pakub RMK teenuseid nii eraisikule kui ka ettevõtetele. Loodav

keskkond peab pakkuma võimalust seadistada enda eelistusi, näiteks keele ja saadava

informatsiooni osas, et kasutajakeskkond oleks võimalikult mugav ja arusaadav.

Etapp sisaldab endas Azure keskkondade kasutuselevõttu, kus puudub ligipääs legacy onprem

teenustele. Ligipääsud on lubatud ainult äriloogika realiseerimiseks vajalikele teenustele läbi

ACL kihi.

Uued rakendused/teenused ja nende funktsionaalsused:

• Frontend rakendus - ligipääs avalikust võrgust. Sisaldab tulevikus äriloogiliste

protsesside vaateid ja flowsid. Esimeses etapis ainult kasutaja sisselogimine ja teise

etapi jaoks vajalikud rollide ja õiguste funktsionaalsused.

• API gateway - ligipääs avalikust võrgust.

• Sisselogimise ja identiteedi funktsionaalsuste jaoks vajalikud teenused:

o jwt-service - teenus lühiajaliste jwt tokenite väljastamiseks autentimisinfo ja

valitud rollide/õiguste alusel, tokenite värskendamine;

o long-token-service - pikajaliste (ka seadme) tokenite hoidmise teenus;

o identity-service - isikute ja rollide/esindusõiguste/õiguste hoidmise teenus.

• ACL kiht olemasolevate teenuste kasutamiseks - nende teenuste loomine on

valikuline, kui olemasolevates turustuse- ja logistika rakendustes on võimalik

implementeerida sisselogimise ja identiteedi komponendi kirjeldusele ja REST

põhimõtetele vastavad API-d, muidu annab võimaluse sõltumatult kliendiportaali

arendada.

o distribution-service - legacy turustuse töölaua teenused;

o logistics-service logistika töölaua teenused.

Lisaks on vajalik tuua API’de abil kliendi- ja lepingute andmed puiduturustuse ja logistika

töölaudadelt kliendiportaali ja need lõppkliendile välja näidata. Selleks täiendatakse

rakendust vastavate vaadetega ja lisatakse distribution-service ja logistics service API-d, mis

vastavat infot väljastavad. Kasutatakse olemasolevat puiduturustuse töölaua (TTL) ja logistika

töölaua (LTL) funktsionaalust.

Etapis 2 toodud puidumüügi kestvuslepingute ja enampakkumiste süsteemi eesmärk on

automatiseerida kestvuslepingute ja enampakkumiste teel toimuvaid puidumüügi tegevusi nii

RMK puiduturustuse kui ka puidu ostjate (klientide) poolel. Klientide jaoks peaks loodav

lahendus pakkuma võimalust saada operatiivselt infot kestvuslepingute ja enampakkumiste

osas, võimaldama mugavalt sisestada andmeid pakkumise vormile ning hallata pakkumiste ja

RMK poolsete vastupakkumiste andmeid, samuti saada individuaalseid teavitusi seoses

temaga seotud pakkumistega.

Etapis 3 soovime realiseerida RMK täiendavaid ärivajadusi kliendiportaalis.

Kõik vajadused ei ole tänaseks kaardistatud, seega peab arvestama, et hakkame liikuma

arendustega agiilselt vastavalt äriprioriteetidele.

Ühe näitena toome välja makselahenduste arendamise, mis võimaldaksid nii era- kui ka

äriklientidel sooritada RMK’st erinevaid oste. Samuti peaks portaal pakkuma API võimekust,

kui välisel osapoolel on vajadus mõne tulevikuteenusega integreeruda.

Loodava lahenduse äriarhitektuur

Tänases RMK rakenduste arhitektuuris on mitmeid rakendusi, mis juba haldavad

puiduturustusega seotud andmeid. Näiteks on kasutusel Turustuse Töölaud (TTL), mis haldab

kliendiandmeid, sh tarnekohti, lepinguid, krediidilimiite jms. Samuti on olemas Logistika

Töölaua rakendus (LTL), mis haldab tarnelepingute täitmist. Puidumüügi pakkumiste

analüüsimiseks erinevate näitajate lõikes on kasutusel müügiotsuste kaalumise rakendus

MOK.

Seega on puidumüügiga seotud põhiandmed RMK teistes süsteemides suures osas olemas

ning uus kliendiportaal peab omama ulatuslikke integratsioone RMK teiste süsteemidega.

Lahendamata on aga pakkumiste haldamise protsess, sh puidumüügi voorude avaldamine,

ostuettepanekute esitamine, pakkumiste vastuvõtt ja vastupakkumiste edastamine jpm.

Andmed peavad liikuma uue loodava infosüsteemi ja mainitud olemasolevate infosüsteemide

vahel kahepidiselt.

Seejuures on oluline, et

- Loodav lahendus peab võimaldama rakendada erinevaid puidumüügi strateegiaid.

Lahenduse esmaseks eesmärgiks on läbi protsesside automatiseerimise suurendada

müügi läbiviimiseks tehtavate tegevuste efektiivsust.

- Lahendus looks alused erinevate uute müügistrateegiate kasutuselevõtuks. Näiteks

tekib läbi loodava keskkonna võimalus viia läbi pikeneva lõpuga enampakkumisi.

Pikeneva lõpuga enampakkumine on dünaamiline oksjonimeetod, mille eesmärk on

tagada õiglane ja läbipaistev pakkumisprotsess, vältides olukordi, kus kliendid

püüavad viimase hetke pakkumistega konkurente üllatada. Selle meetodi keskmes on

automaatne lõpuaja pikendamine, mis aktiveerub juhul, kui pakkumine tehakse

vahetult enne enampakkumise esialgset lõppu. Tavapäraselt määratakse

enampakkumisele kindel lõppaeg. Kui aga keegi teeb pakkumise näiteks viimase viie

minuti jooksul enne selle lõppu, pikeneb oksjoni kestus automaatselt kindla

ajavahemiku võrra – näiteks kahe või viie minuti võrra. See mehhanism kordub iga uue

pakkumise korral, mis tehakse pikendatud aja jooksul. Enampakkumine lõpeb alles

siis, kui määratud aja jooksul pärast viimast pakkumist uusi pakkumisi ei lisandu.

- Tekiks võimalus klienditaotlusel baseeruva sortimendi ja lõikusskeemi põhise müügi

rakendamise piloteerimiseks. Täna pakub RMK kliendile välja eeldefineeritud

sortimendid ja lõikusskeemid, mille alusel saab ostupakkumise teha. Seevastu võivad

klientidel olla spetsiifilisemad soovid puidu osas, mille eest on nad potentsiaalselt

valmis kõrgemat hinda pakkuma. Kliendi soovidel baseeruva sortimendi ja

lõikusskeemi põhisel müügil on võimalik kasvavast metsast sooritada raiet

maksimaalse pakutava väärtuspakkumise alusel, vähendamaks pakkumise-nõudluse

suhtest tulenevaid ebaefektiivsusi.

Enampakkumiste strateegiaid võib olla tulevikus vaja rakendada mitmeid teisigi ning loodav

kliendiportaal peab selle paindlikkusega arvestama. Lisaks võib olla alguses vajalik teostada

A/B teste, et selgitada välja teatud strateegiate sobivuse.

Integratsioonid ja andmevahetus

Loodav lahendus on otseselt sõltuvuses integratsioonidest erinevate olemasolevate RMK

süsteemidega ((TTL, TL, MOK, DHS, BC, jt), aga ka väliste riiklike registritega (Äriregister,

Maksukohuslaste register, Ametlikud teadaanded), et teostada kestvuslepingute ja

enampakkumiste protsessis vajalikke kontrolle, sh kvalifitseerumistingimuste kontrolle,

näidata kliendi põhiandmeid ja finantsandmeid, tarnekohti jms.

Loodava lahenduse esialgne kontekstidiagramm, mis esitab seosed teiste süsteemidega, on

esitatud alloleval joonisel (Joonis 1. Etapp 1 ja 2 all realiseeritav kestvuslepingute ja

enampakkumiste süsteemi visioon).

Infosüsteemidena on kasutusel:

► MOK (Müügiotsuste Kaalumine) rakendustarkvara - kaalutakse klientide pakkumised

ja tarnekohad, et selgitada parimad pakkujad.

► TTL (Turustuse Töölaud) – Süsteem, mis kombineerib puidutöötlejate andmed, tarne

asukohad ning tarne operatiivse info.

► MMO (Metsamajanduse Osakond) - koondab puidu vaheladude asukohad ja kogused

ning prognoosib raiemahud ja sortimendi.

► DHS (Dokumendi Haldussüsteem) - hoiustatakse RMK dokumente ja lepinguid. RMK

plaanib 2026a jooksul tänase DHSi välja vahetada ning vana süsteemiga

integratsioone teostama ei pea.

► MÕRA (Mõõtmisraportite Kogumise Andmebaas) - grupeerib Turustuse Töölauale

mõõtmisraporti andmed müügi vormistamiseks.

► LTL (Logistika Töölaud) – annab väljastatud veoselehtede info Turustuse Töölauale

ning saab vastu lepingud ja nende täitmise info.

► Raamatupidamine (MS Business Central) - RMK finantsinfosüsteem

Lähtesüsteem Sihtsüsteem Andmevood

TTL Kliendi-portaal Info kliendilepingu täituvuse kohta, mis pärineb algselt

Logistika töölaualt ja mis võimaldab kliendil näha

lepingu mahte (kogumaht, täidetud maht, täitmisele

kuuluv maht. Andmed liiguvad RMK back-end API

päringute kaudu, kirjeldatud Integratsioonide

sektsioonis.

MOK Kliendi-portaal

Müügiobjektid, mida on kavas müüa kas

kestvuslepingute või enampakkumiste teel.

GIS Kliendi-portaal

Vaheladude asukohad, kus müüdav metsamaterjal

paikneb.

GIS MOK Vaheladude asukohad, kus müüdav metsamaterjal

paikneb.

DHS TTL Lepingu nr info lepingu sõlmimiseks.

AXAPTA Kliendi-portaal

Vaheladude asukohad, kus müüdav metsamaterjal

paikneb.

Raamatu-

pidamine

Kliendi-portaal

Klientide võlgnevused, mille kohta on informatsioon

finantssüsteemis Business Central (ERP) ja mida

kontrollitakse pakkujate kvalifitseerimisel.

TTL LTL Lepingu täituvus – lepingu kogumaht, täidetud ja

täitmata mahtude info kuvamiseks Kliendiportaalis.

MMO MOK Sortimendi prognoos

Kliendiportaal MOK Kliendiportaal edastab saabunud pakkumised

hindamiseks ja kaalumiseks MOK-i.

Kliendiportaal TTL Kliendiportaal edastab kestvuslepingu või EPK

tulemuste andmed lepingu koostamiseks TTL-i, kus

koostatakse leping.

Liidesed väliste süsteemidega:

Lähtesüsteem Sihtsüsteem Andmevood

Äriregister Kliendiportaal Päring Äriregistrisse, et kontrollida pakkuja

juhatuse liikme volitusi.

MKR

(Maksukohustusla

ste register)

Kliendiportaal Päring Maksukohustuslaste registrisse, et

kontrollida pakkuja maksuvõlgade olemasolu.

Ametlikud

teadaanded

Müügiteadete avaldamine

PS.Kõik integratsioonid analüüsitakse töö käigus üle enne nende teostamist, samuti võivad

integratsioonid täpsustuda ja täieneda.

Hankedokumentatsiooniga on kaasa pandud õiguslik analüüs projekti puudutavatest

õiguslikest mõjudest (vt Õiguslikud mõjud).

Hankedokumentatsiooniga on kaasa pandud täpsemate äriprotsesside ja kasutuslugude

kirjeldused, mis puudutavad puidumüügi enampakkumiste osa kliendiportaalis (vt Protsessid

ja kasutuslood). Protsessid ja kasutuslood on töö käigus täpsustuvad ja täienevad.

Loodava lahenduse tehniline arhitektuur

Loodav infosüsteem:

- Peab kasutama SOA (teenusepõhine arhitektuur) tehnoloogilist arhitektuuri;

- Olema täiel määral pilvekõlbulik (RMK kasutab Azure pilveteenuseid);

- Olema horisontaalselt skaleeritav;

- Süsteemi osad peavad töötama olekuta (stateless) põhimõttel;

- Esitluskiht ja back-end asuvad eraldi ning suhtlevad omavahel REST/JSON

protokolliga;

- Autentimine toimub TARA kaudu, RMK sisemiselt on kasutusel Microsoft Entra ID;

- Looma peab andmete väljastamise teenuse andmete tarbijatele, sh ärianalüüsi

tarkvaras kasutamiseks;

- Logide talletamise lahendus, indeks-server tehingutega seotud otsingulahenduse

loomiseks ning ärianalüütika tööriist (nt MS Power BI) andmetöölaudade loomiseks;

- Infosüsteem peab vastama kaasaegsetele turvastandarditele (OWASP nõuetele);

- Kõik andmeedastused toimuvad krüpteeritud kanalite kaudu;

- Kasutajaliides peab olema vähemalt kahekeelne (eesti ja inglise);

- Süsteem peab olema testitud koormustestide ja turvatestidega;

- Versioonihaldus - koodi versioonihaldus ning infosüsteemi versioonimuudatuste

korral paigalduspakettide ettevalmistamine;

- WCAG 2.2 AA ligipääsetavuse nõuete täitmine.

PS.Kõik arendusnõuded on toodud lisadokumendis “Arendusnõuded”. Kui pakkuja näeb, et

mõni arendusnõue ei ole asjassepuutuv või ei kohaldu antud süsteemile, siis ta toob selle

tervikkirjelduses välja ning pakub omaltpoolt põhjendatud alternatiivi(d).

Kasutusmugavus ja kasutajaliides:

• Tarkvara peab olema kasutajasõbralik ja intuitiivne, et tagada tõhus kasutamine nii

organisatsiooni sise- kui väliskasutajate poolt;

• Kõikidele funktsioonidele peab olema võimaldatud juurdepääs töölaua kaudu;

• Lahendus peab olema skaleeruv erineva suurusega ekraanidele;

• Tarkvara kasutajaliides peab olema eesti- ja inglise keelne.

Pilvepõhisus ja turvalisus:

• Tarkvara peab olema pilvepõhine lahendus, mis tagab kõrge turvalisuse ja andmete

kättesaadavuse;

• Juurutatav tarkvara lokalisatsioon ja tema komponendid peavad olema paigaldatud

Hankija haldusalas olevasse pilveruumi. RMK kasutab Microsoft Azure pilvekeskkonda.

Arenduskeskkond on Hankija poolt.

Dokumentatsioon:

• Arenduste teostamisel peab Täitja koostama dokumendi(d), millede eesmärgiks on anda

selge ja konkreetne ülevaade süsteemi sisust ja realiseeritud arendustest.

• Eraldiseisvaid dokumente üle ei anta vaid Tellija keskkonda (Confluence) kirjutatakse

analüüsi jooksvalt projekti käigus.

• Kirjeldused peavad olema kinnitatud Tellija poolt enne arendustöö algust.

Üle antavad dokumendid peavad sisaldama:

▪ Infosüsteemi terviku kirjeldus – olemasoleva süsteemi täiendamisel

lisatud/muudetud osade kirjeldus. Tegemist on süsteemi ärisisul

põhinevate baaskomponentidega, millele toetuvad kasutaja

tegevused, ekraanivormid, kasutuslood/protsessid, teenused jms;

▪ Vormide (ekraanivormide) kirjeldused;

▪ Kasutuslugude / vormide kasutamise protsesside / tegevuste

kirjeldused.

o Infosüsteemi teenuste kirjeldused.

o Juurutuse faasis ja lõpus peab Täitja esitama arhitektuuri kirjeldus

dokumendi, mille eesmärgiks on kirjeldada loodava ja/või juurutatava

süsteemi tehnilist ülesehitust. Kirjeldatakse rakenduse loogilist struktuuri,

näidates ära selle kihtideks jagunemise.

o Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest

tehnoloogiatest ning vahenditest.

Dokumenteerimise kohta täpsemalt on kirjas Arendusnõuete all.

Testimine:

• Enne töö üleandmist viib Täitja töö nõuetelevastavuse kindlakstegemiseks läbi testid.

• Kui töö või mistahes selle osa ei läbi teste, viiakse otsekohe pärast seda, kui Täitja on

teinud vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid

samadel tingimustel. Tellija nõudmisel viib kordustestid läbi Täitja.

Tugiteenus arendustegevuse jooksul ja peale arenduste tootekeskkonda paigaldamist:

• Raamlepingu täitmise ajal tagab pakkuja tarkvara nõuetekohase toimise, sh intsidentide tekkimise korral reageerima ja probleemi lahendama vastavalt teenustasemetele;

• Pakkuma ülalhoiu teenust peale süsteemi etappide järkjärgulist tootekeskkonda paigaldamist;

• Parandama turvanõrkuseid ja uuendama tarkvara vastavalt lepingus sätestatule;

• Hoidma tehnilist ja lõppkasutaja dokumentatsiooni ajakohasena;

• Nõustama hankijat süsteemis muudatuste tegemisel ja kasutamisel.

Kliendiportaali sisselogimine ja identiteet

1. Kliendiportaal on monoliitne front-end

2. Kliendiportaalil ei ole oma back-endi, kogu vajalik funktsionaalsus lahendatakse

eraldiseisvates mikroteenustes

3. Kliendiportaali hanke esimese etapi jaoks vajalikud apid olemasolevates legacy

süsteemides tuleb peita ACL taha ja mitte neid kliendiportaalis otse kasutada

4. Süsteem ei hõlma mitte ainult kliendiportaali sisselogimist vaid ka edasist sessiooni

ja apide ligipääsu

5. Süsteem on kasutatav ka mobiilsete rakenduste jaoks

6. Sisse peavad saama logida ja autentimine peab toetama:

a. Töötaja - Entra ID

b. Isik - TARA. Isik võib piirduda iseendana tellimuse tegemisega või profiili

(mingi isikuga seotud salvestatud info) vaatamisega või võivad isikul olla

keerulisemad seosed olemasolevate andmetega või tellimustega, näiteks

erinevad rollid

c. Mitme isiku poolt jagatud kasutuses olev seade, mis peab teatud lubatud

andmetele ligi saama

Mikroteenuste arhitektuuri puhul on mõistlik kasutada jwt tokenit api päringute auth jaoks.

Jwt tokeni sisse saab kodeerida:

• Person - isik, kes tegutseb. Entra kasutaja kui tegemist on töötajaga, tara kaudu

autenditud isik. Tühi, muul juhul.

• Representative - Person, kui tegemist on tara kaudu autenditud kasutajaga. Entra

puhul vabalt valitud (kui pole määratud eraldi ärireeglite ja seostega)

• Representee - kelle õigustes tegutsetakse. Sama kui representative, kui tegutsetakse

iseendana. Muul juhul määratud esindusõigustega.

• Anonüümse kasutuse fakt

• Anonüümse seadme fakt (seadme ligipääs kliendi andmetel peab olema määratud

eraldi seostega)

Spetsiifiliste rollide kodeerimise vajadus ei ole selge aga on tõenäoline.

Mikroteenused saavad lubada või keelata ligipääsu apidele jwt tokeni alusel või saab seda

teha api gateway tasemel. Mikroteenused otsustavad jwt claimide alusel, kas päringuga

lisatavad või küsitavad andmed on lubatud.

Jwt tokenile saab kehtestada lühikese kehtivusaja (5-10min) ja värskendamist samuti piirata

ajaliselt, et saavutada sessiooni aegumine ja uue autentimise nõudmine.

Jwt tokeni väljastamine võib käia erineval moel:

• Entras autenditud kasutajal lubatakse küsida vajalike andmetega jwt token

• TARA kaudu autenditud kasutajatele väljastatakse jwt token tara autentimisinfo

põhjal

• Eelgenereeritud pikajalise tokeni (mobiilirakenduse/seadme lubamisel, profiili

loomisel loodud) alusel

Integratsioonide kirjeldused

Api on kirjeldatud OpenAPI standardi järgi. OpenAPI spertsifikatsioon on lisatud

hankematerjalidele (ttl2_openapi.json).

Järgnevalt on välja toodud esimeses etapis kasutatavad teenused ja otspunktid.

1. Lepingute nimekiri ja detailid

Endpoint: /api/ sales-contracts/by-customer-reg-code/:regCode

2. Müügipakkumiste info

Endpoint: sale-offer/?filter=[{"field":"customer.regNum","value":["regCode"]}]

3. Lepingu täitmise info / Tarnegraafik

Endpoint: delivery-graph/by-sales-contract/:id

4. Tarnegraafikute ja vedude staatuste kuvamine

Endpoint: delivery-graph/by-sales-contract/:id

5. Mõõtmistulemuste kuvamine TTL2-st (mõõdetud ja arveldatud maht)

Endpoint: timber-

load/page?filter=[{"field":"salesContract.customer.id","value":[":id"]},{"field":"divDateFrom

","value":[":periodStart"]},{"field":"divDateTo","value":[":periodEnd"]},{"field":"statuses","v

alue":[":value1, :value2"]}]

6. Arvete kuvamine

Endpoint:

invoice/page?filter=[{"field":"customer.id","value":["id"]},{"field":"salesContract.ContractId"

,"value":["id"]}]

7. Krediidilimiidi kuvamine

Endpoint: customer/detail/:id

8. Tarnekohtade kuvamine

Endpoint: customer-address/by-customer-id/:id

Lisa 2

RMK ja AKTSIASELTS

HELMES vahelise lepingu

nr 1-18/2026/19 juurde

Arendusnõuded Avalikustamine: RMK sisene teave

Teavet ei ole lubatud jagada kolmandate osapooltega, v.a juhul, kui selleks on õiguslik alus ja/või see

on vajalik tööprotsesside toimimiseks.

Avalikustamise lisainfo: “Arendusnõuded (MFN)” lisatakse tarkvara arendamise, hankimise ja

juurutamise hangete korral hankedokumentide juurde, v.a dokumendi punktis 2.1 viidatud “RMK

Töö- ja koodihaldus” ja punktis 5 viidatud “Logimise spetsifikatsioon”, mis väljastatakse hanelepingu

sõlmimise järel ning punktis 2.3 viidatud “Eelistatud tehnoloogiate nimekiri”, mis väljastatakse

konfidentsiaalsusleppe (NDA) või hankelepingu sõlmimise järel. Riigihangete portaali

hankedokumentide juurde koos “Arendusnõuded (MFN)” dokumendiga neid vaikimisi ei lisata.

Sisukord Arendusnõuded ...................................................................................................................................... 1

1. Ülevaade ja skoop ........................................................................................................................... 2

2. Üldnõuded ...................................................................................................................................... 2

2.1 Töö- ja koodihaldus ................................................................................................................... 2

2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release ............................................................ 2

2.3 Platvorm .................................................................................................................................... 3

2.4 Koodi kvaliteet ja arendusprotsess ........................................................................................... 3

2.5 Dokumenteerimine ................................................................................................................... 4

2.6 Haldus ....................................................................................................................................... 5

2.7 Välised sõltuvused .................................................................................................................... 5

2.8 Muud üldised nõuded ............................................................................................................... 5

3. Frontend nõuded (UX/UI) ............................................................................................................... 5

3.1 Tehnilised .................................................................................................................................. 5

3.2 Kasutuskogemus ....................................................................................................................... 6

4. Backend nõuded (API/teenused) .................................................................................................... 7

4.1 Konfiguratsioon ja deploy ....................................................................................................... 7

4.2 API disain ja dokumentatsioon ................................................................................................. 7

4.3 Töökindlus ja monitooring ........................................................................................................ 7

4.4 Koodistruktuur ja arendus ........................................................................................................ 8

4.5 Integratsioon ............................................................................................................................. 8

5. Logimine .......................................................................................................................................... 8

6. Andmebaasi ja andmetöötluse nõuded .......................................................................................... 8

6.1 Üldpõhimõtted .......................................................................................................................... 8

6.2 Identifikaatorid ja audit ............................................................................................................. 9

6.3 Platvorm ja tööriistad................................................................................................................ 9

6.4 Turvalisus ja juurdepääs ............................................................................................................ 9

7. Turvanõuded ................................................................................................................................... 9

7.1 Üldised põhimõtted .................................................................................................................. 9

7.2 Sessioonid ............................................................................................................................... 10

7.3 Lähtekood ja arendusvahendid ............................................................................................... 10

8. Hooldatavus ja toetatavus ............................................................................................................ 10

1. Ülevaade ja skoop

Käesolev dokument kirjeldab kuidas RMK-s arendatakse, hangitakse ja juurutatakse tarkvara. See

hõlmab nii tarkvara arendust kui ka karbitoodete ja SaaS (Software as a Service) teenuste kasutusele

võttu. Nõuded ei kirjelda ärifunktsionaalsust.

Dokumendis viidatakse ka teistele välistele dokumentidele, mis moodustavad käesoleva

dokumendiga ühtse terviku.

2. Üldnõuded

2.1 Töö- ja koodihaldus

• Kõik tööd peavad olema kirjeldatud piletina RMK JIRA-s. Täpsemad JIRA ja versioonihalduse

kasutamise nõuded on kirjeldatud dokumendis „RMK Töö- ja koodihaldus“(välisele

arenduspartnerile väljastatakse dokument peale hankelepingu sõlmimist).

• Git repod: RMK kood asub Azure DevOps repodes.

2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release

• Lokaalne käivitus: Rakendused peavad olema lokaalselt käivitatavad ilma väliste

sõltuvusteta. Vajalikud sõltuvused peaksid olema lokaalselt käivitatavad Docker Compose-i

konteineriga. Välised sõltuvused(API-d) võivad olla mockitud. Rakenduse käivitamiseks ja

testimiseks vajalikud andmed peavad olema rakenduses seadistatud. Peale käivitamist peab

olema rakendus kasutatav. Rakenduse

Vajalikud käsud ja sammud rakenduse lokaalseks käivitamiseks peavad olema välja toodud

koodi repos README.md failis.

• Koodi formaadi kontroll: koodi formaadi kontroll peab olema build protsessi osa. Kood peab

vastama RMK-s kokku lepitud formaadile.

• Staatiline analüüs: staatiline analüüs(nt Sonar) peab olema build protsessi osa selliselt, et

kui kvaliteedi lävendit ei ületata, siis build ei õnnestu. Uus kood ei tohi tekitada juurde Sonari

vigu. Lokaalselt seda sammu ei ole (võimalusel kasutada Sonarit IDE pluginana, või minna

eraldi Sonari liidesesse ja kontrollida vigasid).

• Testide käivitamine: Unit ja integratsioonitestide käivitamine igal ehitusel.

• Release strateegiad: kasutusel võivad olla erinevad väljalaskmise mustrid (nt blue-green,

canary). Tähtis on, et uue versiooni kasutuselevõtt oleks kontrollitud ja võimaldaks vajadusel

kiiret tagasipööramist.

• Production ressursivajadus: arendusmeeskonna ülesanne on testida rakenduse jõudlust ja

selle põhjal teha ettepanek rakenduse ressursivajaduse kohta production keskkonnas, mis on

sisendiks haldusosakonnale.

2.3 Platvorm

• Versioon: Ükskõik mis programmeerimiskeelte, raamistike või teekidega infosüsteeme

realiseeritakse, kehtib sama põhimõte: alati kasutatakse kas viimast LTS (Long Term Support)

versiooni, või selle puudumisel viimast stabiilset versiooni. Kui arendustöö käigus tuleb uus

LTS versioon välja, siis see uuendatakse kohe ära, kui ei esine seda takistavaid asjaolusid.

• Eelistatud tehnoloogiate nimekiri: Nimekiri programmeerimiskeeltest, raamistikest,

teekidest ja nende versioonidest, mida võib ilma täiendava kooskõlastamiseta kasutada on

kirjeldatud dokumendis „Eelistatud tehnoloogiate nimekiri“(välisele arenduspartnerile

väljastatakse dokument riigihanke käigus NDA alusel või peale hankelepingu sõlmimist).

Juhul kui on soov kasutada midagi muud, siis tuleb see valik kooskõlastada RMK

tarkvaraarhitektiga.

• Keskkond: backend, frontend ja andmebaasid töötavad Azure pilvekeskkonnas.

• CI/CD: kasutatakse Azure CI/CD. Build protsessi osana käivitatakse koodi formaadi kontroll,

staatiline analüüs, testid.

• Sõltuvused: kasutatakse ainult toetatud ja turvauuendusi saavaid teeke.

• Skaleeruvus: rakenduste arendamisel peab arvestama võimalusega, et need jooksevad

mitme õla peal.

• Docker: rakendus peab olema tarnitav Dockeri konteineritena.

2.4 Koodi kvaliteet ja arendusprotsess

• Põhiharu kvaliteet: main haru peab alati olema testitud ja valmis production keskkonda

paigaldamiseks.

• Sisendi valideerimine: kõik kasutajalt või teistest süsteemidest tulevad sisendid

valideeritakse. Kui rakendusel on nii kliendi- kui serveripool, toimub valideerimine mõlemas

komponendis. Samuti rakendatakse valideerimist teistes integratsioonipunktides

(andmebaas, välised liidesed).

• Väljundandmete kontroll:

Rakenduse poolt kasutajale või teisele süsteemile väljastatavad andmed peavad olema

õigesti vormindatud, äriliselt korrektsed ja turvalised.

o Formaadi kontroll: kõik väljastatavad väärtused vastavad kokkulepitud skeemile või

standardile. Näiteks kuupäevad esitatakse ISO 8601 formaadis (2025-09-

02T12:00:00Z), rahasummad kahe komakohaga, ning API vastus vastab OpenAPI

kirjeldatud struktuurile.

o Äriline korrektsus: väljastatav info järgib ärireegleid ja loogikat. Näiteks ei väljastata

negatiivset saldo väärtust, kui süsteemi reeglid seda ei luba; ID viitab alati reaalselt

olemasolevale kirjetele; staatuse väljad sisaldavad ainult eeldefineeritud väärtusi.

o Turvalisus: väljund ei tohi sisaldada tundlikke või sisemisi andmeid, mida kasutaja

või partner ei pea nägema (nt paroole, võtmeid, sisemisi tehnilisi tunnuseid). Tekstid

peavad olema korrektselt escape’itud, et vältida XSS või sarnaseid ründeid.

Logidesse ei tohi sattuda täielikud isikuandmed ega salajased identifikaatorid.

• Staatiline koodianalüüs: kasutatakse staatilist koodianalüüsi (Sonar); kõrge prioriteediga

turvavead tuleb lahendada enne live keskkonda paigaldamist. Kõik Sonari vead vaadatakse

enne arenduse üleandmist üle, vead mida ei peeta otstarbekaks parandada kooskõlastatakse

RMK tarkvaraarhitektiga.

• Kompilaatori hoiatused: build-i hoiatused ja staatilise analüüsi tulemused vaadatakse üle ja

arvestatakse.

• Kiirlahenduste vältimine: ei kasutata testimata lahendusi, mis eiravad häid praktikaid või

RMK nõudeid.

2.5 Dokumenteerimine

• Dokumentatsiooni põhielemendid:

o süsteemi funktsionaalne ja tehniline kirjeldus,

o kasutatavad liidesed (API-d, integratsioonid),

o perioodilised tööd (schedulerid, batch-protsessid),

o arenduskeskkonna seadistamine

o andmebaasi struktuuri kirjeldus (tabelid, seosed, migratsioonid),

o keskkonnad ja paigaldus

o peamised hooldustegevused (nt logide ülevaatus, varunduse kontroll, sõltuvuste

uuendamise tsükkel)

• Dokumentatsiooni asukoht: RMK Confluence keskkond

• Diagrammid: süsteemi arhitektuuri ja komponente visualiseeritakse eelistatult PlantUML või

Mermaid formaadis.

• Arhitektuur: iga süsteemi kohta peab olema arhitektuuriülevaade, sealhulgas API

spetsifikatsioonid (nt OpenAPI).

2.6 Haldus

• Tehniline võlg: arenduse käigus tuleb dokumenteerida teadaolevad piirangud ja tehniline

võlg (nt TODO-d, ajutised lahendused) ning soovitused nende likvideerimiseks.

• Sõltuvuste ja platvormi uuendused: arenduse käigus tuleb kirjeldada süsteemi kaasaegsena

hoidmise strateegiat (nt milliseid raamistikke ja teeke tuleb regulaarselt uuendada, millal

tuleb planeerida üleminek LTS-versioonidele).

• Monitooringu vajadused: tarnija peab kirjeldama arendatava süsteemi monitooringu

aspektid (nt vealogid, jõudlusmõõdikud, integratsioonide toimivus, job scheduler-i töö).

• Teavitused: tarnija peab defineerima soovitatud häirete künnised (nt kui API annab vea, kui

mingi protsess ei lõpeta näiteks 15 minutiga).

• Elutsükli planeerimine: tarnija peab andma hinnangu, millised tehnoloogiad või

komponendid võivad lähiaastatel vajada moderniseerimist või väljavahetamist.

2.7 Välised sõltuvused

• Teekide kasutamine: kasutada ainult laialdaselt toetatud ja turvauuendusi saavaid teeke.

• Sõltuvuste miinimum: sõltuvusi hoitakse minimaalsena, et vähendada turvariske ja

halduskoormust.

• Litsentsid: sõltuvuste litsentsitingimusi, turvalisust ja ajalugu hinnatakse; eelistatakse

vabavaralisi komponente.

• Jätkusuutlikkus: hinnatakse teekide jätkuarenduse ja toe kättesaadavust. Vajadusel

analüüsitakse mõju RMK protsessidele, kui komponendi arendus lõpeb.

• Ühilduvus: analüüsitakse kasutatavate komponentide ühilduvust teiste süsteemidega.

2.8 Muud üldised nõuded

• Kodeering ja locale: kogu süsteemis (lähtekoodis, andmebaasis, jne) kasutatakse UTF-8

kodeeringut; vaikekeel on et-EE (laiendatav i18n); ajatsoon on UTC (UI-s kohalik aeg).

3. Frontend nõuded (UX/UI)

3.1 Tehnilised

• Tehnoloogia: kui rakenduse nõuded võimaldavad siis eelistame serveris renderdatud HTML-i

(Thymeleaf, HTMX).

• Raamistikud: kui kasutatakse mingit raamistikku, siis eelistame laialdaselt toetatud

raamistikku (nt React, Angular või Vue).

• Raamistiku versioon: projektis kasutatavad raamistikud peavad olema toetatud ja saama

turvauuendusi.

• Build: sõltuvused hallatakse paketihalduriga, arvestades kasutatavat tehnilist lahendust:

o SPA: npm / yarn / pnpm (lock fail versioonihalduses; build deterministlik).

o Java SSR (Server-Side Rendering nt Thymeleaf): Gradle (või Maven) hoiab nii

backendi kui frontendi build-i .

o PHP SSR: Composer.

o Python SSR: pip.

Build peab olema deterministlik ja versioonitav (lock failid, build-config git-s).

• Keskkonnaspetsiifilised seaded: hoitakse välises konfiguratsioonis (nt .env).

• API kasutus: kõik API-päringud käivad läbi konfiguratsiooni alusel määratud lõpp-punktide;

otselinke koodis ei kasutata.

• Turvalisus: tundlikke andmeid ei salvestata brauseri püsivasse vahemällu (LocalStorage,

SessionStorage) ilma krüpteerimiseta.

• Jõudlus: rakendus peab laadima mõistliku aja jooksul - alla 2s esmase vaate kuvamine

tavatingimustes. Pildid, skriptid ja stiilid peavad olema optimeeritud (lazy load, cache,

minify).

• Telemeetria: kriitilised kliendipoolsed vead (JavaScript errorid, katkised API päringud)

peavad jõudma tsentraalsesse monitooringusse.

3.2 Kasutuskogemus

• Reageeriv (responsive) disain: rakendus peab olema kasutatav erineva ekraanisuurusega

seadmetel (desktop, mobiil, tahvel).

• Navigatsioon: menüüd ja liikumisloogika on rakenduse eri vaadetes ühtsed. Sama

funktsionaalsus on alati leitav samast kohast.

• Nuppude paigutus ja järjestus: sama tüüpi tegevused (nt “Salvesta”, “Tühista”) paiknevad

alati samas järjekorras ja paigutusega.

• Veateated: esitatakse ühtses formaadis (struktuur, sõnastus, värvilahendus). Teated on

arusaadavad ja ei sisalda tehnilist müra. Veateated ei sulgu automaatselt, et kasutajal oleks

võimalik neid adekvaatselt edastada toe saamiseks.

• Kinnitused ja dialoogid: riskantsete tegevuste (nt kustutamine, lõplik kinnitamine) puhul

küsitakse alati kinnitust. Dialoogid järgivad sama stiili ja loogikat.

• Abitekstid ja juhendid: tooltipid, sisestusväljade placeholderid ja abitekstid on stiililt ja

positsioonilt ühtsed. Kõik väljad ja tegevused on varustatud abitekstiga, mis aitab kasutajal

mõista, mis juhtub enne kui ta midagi teeb.

• Laadimise tagasiside: pikemate tegevuste puhul (nt päring serverisse, faili üleslaadimine)

peab kasutaja nägema visuaalset indikaatorit (spinner, progress bar).

• Etteaimatavus: süsteemi käitumine peab olema selge ja ootuspärane – väldime olukorda

kus kasutaja peab mõtlema „mis siis juhtub, kui ma siia vajutan“. Tegevuste tagajärjed on

nähtavad või selgitatud enne sooritamist.

• Ikonograafia ja sümbolid: sama tegevuse tähistamiseks kasutatakse alati sama ikooni ja

tähendust.

• Stiil ja kujundus: värvipalett, kirjatüübid ja komponentide kujundus vastavad ühtsele

disainisüsteemile või stiilijuhendile.

• Klahvikombinatsioonid ja kiirtoimingud (kui rakendatud): töötavad järjepidevalt kõigis

vaadetes.

• Terminoloogia: tekstid ja nimetused (nt “kasutaja”, “konto”, “fail”) on järjepidevalt samad

kogu rakenduses.

• Andmete sisestuse valideerimine: sisestusväljade puhul kasutatakse valideerimist enne

serverisse saatmist, et ilmseid vigu kasutajale kiiremini esile tuua.

4. Backend nõuded (API/teenused)

4.1 Konfiguratsioon ja deploy

• Seadistused: keskkonnaspetsiifilised väärtused hoitakse rakendusest väljas (Azure Key

Vault, keskkonnamuutujad), aga konfiguratsioon ise on koodi juures vastavates failides.

• Konfiguratsioon: konfiguratsioon on versioneeritav ja muudatused jälgitavad.

• Ehitamine: Java proejktide ehitamisel eelistatakse Gradle-t.

4.2 API disain ja dokumentatsioon

• Versioonimine: REST/HTTP liidesed on versioonitud (nt /v1).

• Dokumentatsioon: kõik REST/HTTP liidesed peavad olema dokumenteeritud nii, et

partneritel ja RMK-l on võimalik neid kasutada ja testida. Dokumentatsiooni võib teha

erineval viisil (nt kirjalik juhend, Postman collection, README näidised). Soovitatavalt

kasutatakse masinloetavat standardit OpenAPI ja sellest genereeritud Swagger liidest.

• Asukoht: kui kasutatakse OpenAPI/AsyncAPI dokumentatsiooni, peab vastav fail asuma

samas Git repo-s koos lähtekoodiga, et see oleks alati koodiga kooskõlas.

• Koormuse juhtimine: kasutatakse mehhanisme ülekoormuse vältimiseks (nt rate limiting,

throttling).

• Veakäsitlus: veateated on standardiseeritud, inimloetavad ja ei sisalda tundlikku sisemist

infot.

• Sisend, väljund: API sisend ja väljund peab jälgima REST põhimõtteid

• Protokoll, formaat: kasutatakse HTTP protokolli ja API väljund on JSON, välja arvatud

binaarfailide puhul.

4.3 Töökindlus ja monitooring

• Health-checkid: rakendus peab pakkuma health-check ja readiness liideseid(Spring Boot

Actuator).

• API töökindlus: API peab olema kasutatav (vastab päringutele) ja enamus päringuid peab

lõppema mõistliku aja jooksul ning ilma veata. Täpsemad jõudluse või töökindluse eesmärgid

määratakse projektipõhiselt.

• Testimine: Integratsiooniteste ja end to end teste võib kirjutada. Nende puudumisel tuleb

enne release-i teha regressioonitestimist käsitsi.

4.4 Koodistruktuur ja arendus

• Struktuur: Java projektides kasutatakse kihipõhist package struktuuri, kus komponendid on

jaotatud package-tesse tehnilise rolli järgi (nt controllers, services, repositories).

• Perioodilised tööd: kõik schedulerid, batchid ja stored procedures dokumenteeritakse

README-s. Perioodiliste tööde käivitamine eraldi klassis äriloogikast.

• Teenusklassid: äriloogika peab olema realiseeritud Service kihis, mille sisendiks ja väljundiks

on domeeniobjektid. Teenuseklassi testideks on unit testid.

• Kontrollerid: Kontrollerite testid tuleb kirjutada kasutades MockMvc raamistikku, kus

teenustekihi vastused on mockitud.

• Presentatsioonikiht: presentatsioonikiht ei tohi kasutada sisendiks ja väljundiks

domeeniobjekte, vaid eraldi Request ja Response ressursse.

• Autoriseerimine: päringute autoriseerimine peab toimuma kontrolleritekihis.

• Testimine: koodi unit testide haru-kattuvus(branch coverage) peab olema 90%. Unit testid

tuleb jooksutada CI/CD süsteemis iga buildiga uuesti. Build peab katki minema, kui testid

pole edukad. Repository (ja messaging) kihi testid tuleb kirjutada integratsioonitestidena

vastu mockitud (ntx rest apid) või konteineris jooksva päris välise süsteemi vastu (näiteks

rakenduse Postgres baas TestContainers abil). Iga test hoolitseb ise oma testandmete

loomise ja esialgse seisu taastamise eest. Erinevates testides samade andmete kasutamine ei

ole lubatud.

• Koodistandard: kasutakse Google Java koodistandardit

(https://google.github.io/styleguide/javaguide.html) ja peab olema osa buildist

(https://github.com/diffplug/spotless).

4.5 Integratsioon

• Andmebaasid, välised liidesed: andmebaasi ja teiste väliste andmete küsimine peab olema

lahendatud eraldi repository kihis, mis väljastab äriloogika kihile ainult domeeniobjekte.

• Sõnumid, eventid: eventide saatmine ja vastuvõtmine peab olema realiseeritud äriloogikast

eraldi consumerites ja producerites.

5. Logimine

Logimisnõuded on kirjeldatud dokumendis „Logimise spetsifikatsioon“.

• NB! Välisele arenduspartnerile väljastatakse “Logimise spetsifikatsioon” dokument peale

hankelepingu sõlmimist.

6. Andmebaasi ja andmetöötluse nõuded

6.1 Üldpõhimõtted

• Andmete terviklikkus: kõik andmebaasi struktuurid (tabelid, seosed, indeksid) peavad

tagama andmete terviklikkuse ja vältima duplikaate või orvuks jäänud kirjeid.

• Normaliseeritus: andmemudel peab olema vähemalt 3. normaalkujus või põhjendatult

denormaliseeritud (näiteks jõudluse kaalutlustel).

• Järjepidevus: andmete formaat ja tähistus (nt kuupäevad, valuutad, staatuse väljad) peab

olema ühtne kogu süsteemis.

• Äriloogika: relatsioonilisse baasi tuleb suhtuda kui andmete hoidlasse, äriloogika peab

olema implementeeritud rakenduskihis. Stored procedure kasutamine ei ole lubatud.

6.2 Identifikaatorid ja audit

• Primaarvõtmed: numbrilised ID-d on eelistatud, mitte UUID, välja arvatud kui on tehniline

vajadus globaalseks unikaalsuseks.

• Auditväljad: igas tabelis, kus toimub andmete muutmine, peavad olema väljad created_by,

created_at, modified_by, modified_at.

• Auditlogi või event sourcing: kasutatakse sõltuvalt süsteemi iseloomust ja ärivajadusest.

6.3 Platvorm ja tööriistad

• Andmebaasi tarkvara: RMK eelistatud andmebaas on PostgreSQL. Arenduse ja testimise

eesmärgil võib kasutada ka mäluandmebaase (nt H2, SQLite3).

• Migratsioonid: kõik struktuurimuudatused hallatakse migratsioonitööriistadega ja

versioonihalduses (soovitatavalt Flyway). Käsitsi tehtud muudatused ei ole lubatud, välja

arvatud erandkorras ja RMK-ga eelnevalt kooskõlastatult. Kõik sellised muudatused tuleb

dokumenteerida ja kanda tagasi migratsiooniskriptidesse, et tagada keskkondade ühtsus.

6.4 Turvalisus ja juurdepääs

• Paroolid ja autentimisandmed: salvestatakse ainult soolatud räsi kujul (nt Argon2, bcrypt,

scrypt). Lihttekstina talletamine on keelatud.

• Õiguste haldus: andmebaasis kasutatakse eraldi kontosid rakenduse ja haldustööde jaoks

(väikseima privileegi põhimõte).

7. Turvanõuded

7.1 Üldised põhimõtted

• Autentimine ja identiteet: rakendused ja kasutajad tuvastavad end RMK autentimisnõuete

alusel (Entra ID, TARA väliskasutajatele).

• Autoriseerimine: juurdepääs rakendustes toimub rollipõhiselt. Rollide nimetusvorming: APP-

{env}-{teenus}-{roll}.

• Andmete liigitus: rakenduse planeerimisel määratakse andmete tüüp ja liigitus,

dokumenteeritakse nende käsitlemise alused.

• Turvaline arendus: rakenduse arendamisel järgitakse RMK dokumente Arenduse elutsükkel

ja Turvaline arhitektuur.

• Andmekaitse: mitteavalikud andmed kaitstakse vastavalt teabe liigitusskeemile ja

andmekaitse nõuetele. Töötlemisel järgitakse kehtivaid andmekaitse õigusakte, sh GDPR.

• Andmevahetus: kogu andmevahetus on krüpteeritud (TLS 1.2+); kasutatakse RMK

krüptograafia juhendis määratud protokolle ja vorminguid.

• Auditväljad ja -logi: rakendustes logitakse, millal ja kes kirje lõi ning viimati muutis (audit

trail).

• Saladuste haldus: kõik võtmed ja paroolid hoitakse Azure Key Vault-s, mitte lähtekoodis või

konfiguratsioonifailides.

• Keskkondade eraldatus: live keskkond peab olema rangelt eraldatud arendus- ja

testkeskkondadest. Toodanguandmeid ei tohi kasutada arendus- ega testkeskkondades.

• Vajaduspõhine ligipääs: kõik ligipääsud lähtuvad vajaduspõhimõttest (default deny).

• Vähima privileegi põhimõte: kõik protsessid töötavad vähimate vajalike õigustega.

• Autentimise integreerimine: kasutajate õiguseid arvestatakse läbivalt igal tasemel (UI,

äriloogika, andmebaas, integratsioonid).

7.2 Sessioonid

• Timeout: serveripoolne sessiooni idle timeout ≤ 30 minutit, absoluutne timeout ≤ 12 tundi.

• Sessiooni turvalisus: sessiooni ID logitakse vajadusel maskitult või räsitult.

• Sessiooni lõpetamine: sessioon suletakse automaatselt, kui kasutaja logib välja või jõuab

timeout.

7.3 Lähtekood ja arendusvahendid

• Ligipääs: lähtekood asub RMK Azure DevOps keskkonnas, kus ligipääsu hallatakse projekti

põhiselt.

o RMK arendajatele antakse ligipääs vajaduspõhiselt töölepingu kehtivuse ajal.

o RMK töötajatele antakse ligipääs ainult vajaduse korral ja vaikimisi lugemisõigus.

o Välistele arendajatele antakse projektipõhine ligipääs, mis eemaldatakse projekti

lõppedes.

• Lähtekoodi turvalisus: tuleb vältida lubamatute funktsioonide lisamist ja tagada, et

lähtekood, arendusvahendid ja teegid on kaitstud tahtmatute või pahatahtlike muudatuste

eest.

• Koodi kvaliteet: turvavigade automaatne analüüs (nt Sonar).

8. Hooldatavus ja toetatavus

• Koodistandardid: rakenduse kood peab olema ühtses stiilis, loetav ja järgitav, et ka uus

arendaja saaks töö kiiresti üle võtta.

• Juhendite praktilisus: dokumentatsioon peab olema piisavalt selge, et uuel arendajal või

administraatoril oleks võimalik süsteem kiiresti üle võtta.

• Testid: rakenduse põhitöövood peavad olema kaetud automaatsete testidega. See

võimaldab veenduda, et süsteemi põhifunktsioonid töötavad ka pärast muudatusi.

• Runbook-d (käitamis- ja taastamisjuhendid): kriitiliste töövoogude ja häireolukordade jaoks

peab olema lühike samm-sammuline juhend, mis kirjeldab, kuidas probleem lahendada või

süsteem taastada.

• Tugi ja eskaleerimine: peab olema selge, kes ja kuidas reageerib süsteemi tõrgetele ning

millised on reageerimisajad erineva tõsidusega olukordades.

Lisa 3

RMK ja AKTSIASELTS HELMES

vahelise lepingu nr 1-18/2026/19

juurde

ISIKUANDMETE TÖÖTLEMISE NÕUDED VOLITATUD TÖÖTLEJALE

1. Üldine

1.1. Riigimetsa Majandamise Keskus (RMK) (edaspidi vastutav töötleja) edastab

AKTSIASELTSile HELMES (edaspidi volitatud töötleja) punktis 2.1 nimetatud

andmed ja volitab volitatud töötlejat neid andmeid töötlema ainult juhul, kui andmete

töötlemine on lepingust tulenevalt vajalik.

1.2. Käesoleva lisa eesmärk on kokku leppida volitatud töötleja õigustes ja kohustuses

lepingu täitmise käigus saadud isikuandmete töötlemisel, millest pooled juhinduvad

lepingu täitmisel.

1.3. Vastuolude korral lepingu ja käesoleva lisa sätete vahel tuleb juhinduda käesoleva lisa

sätetest.

2. Isikuandmete töötlemise eesmärk ja kirjeldus

2.1. Vastutav töötleja kirjeldab ära isikuandmete töötlustoimingud tabelis 1, milles

sätestatakse:

2.1.1. andmete töötlemise eesmärgi/eesmärgid, milleks isikuandmeid vastutava

töötleja nimel töödeldakse;

2.1.2. andmesubjektide kategooriad, kelle isikuandmeid töödeldakse;

2.1.3. töödeldavate andmete liigid;

2.1.4. töötlemise alused;

2.1.5. andmete säilitustähtajad.

Töötlemise

eesmärk

Andmesubjektide

kategooriad Andmete liigid

Töötlemise

alused Säilitustähtajad

Kliendiportaali

kaudu

puidumüügi

protsesside

RMK töötajate

isikuandmed;

Isikut tuvastavad

andmed;

Kontaktandmed;

GDPR art6(1)(e)

ja GDPR art

6(1)(b) -

avalikes huvides

Volitatud

töötleja säilitab

andmeid ainult

lepingu

korraldamine ja

haldamine. Sh

enampakkumiste

läbiviimine,

dokumentide

haldamine,

lepingute

sõlmimine ja

täitmine.

Klientide ja

lepingupartnerite

isikuandmed

Kasutajakontode

andmed;

Volituste andmed;

Lepingute

andmed;

Enampakkumiste

andmed;

oleva ülesande

täitmine ja

lepingu täitmine

GDPR art 28 -

volitatud

töötleja töötleb

andmeid

vastutava

töötleja

dokumenteeritud

juhiste alusel.

täitmiseks

vajaliku aja

jooksul ning

seejärel andmed

kustutatakse,

välja arvatud

juhul, kui

säilitamine on

vajalik

õigusnõuete

täitmiseks või

vaidluste

lahendamiseks.

Infosüsteemi

turvalisuse ja

töökindluse

tagamine.

RMK töötajate

isikuandmed;

Klientide ja

lepingupartnerite

isikuandmed

Tehnilised ja

turbeandmed, sh

autentimisandmed,

logid, intsidentide

andmed,

varundamise ja

taastamisega

seotud andmed.

GDPR art

6(1)(c) ja GDPR

art 6(1)(f) -

juriidilise

kohustuse

täitmine ja

vastutava

töötleja

õigustatud huvi

GDPR art 28 -

volitatud

töötleja töötleb

andmeid

vastutava

töötleja

dokumenteeritud

juhiste alusel.

Volitatud

töötleja säilitab

andmeid ainult

lepingu

täitmiseks

vajaliku aja

jooksul ning

seejärel andmed

kustutatakse,

välja arvatud

juhul, kui

säilitamine on

vajalik

õigusnõuete

täitmiseks või

vaidluste

lahendamiseks.

Tabel 1. Isikuandmete töötlustoimingute tabel

3. Isikuandmete töötlemise kestus ja säilitamise nõuded

3.1. Volitatud töötleja töötleb isikuandmeid üksnes minimaalses vajalikus mahus ja lepingus

kindlaksmääratud aja jooksul, välja arvatud juhul, kui volitatud töötleja on kohustatud

teavet töötlema volitatud töötleja suhtes kohalduva seaduse alusel.

3.2. Käesoleva lisa raames tuleb andmeid säilitada vastavalt tabelis 1 sätestatud ajale. Selle

aja möödudes tuleb andmed volitatud töötleja süsteemidest kustutada.

3.3. Peale teenuslepingu lõppemist tuleb vastutava töötleja teave volitatud töötleja

hallatavatest süsteemidest turvaliselt kustutada, küsides enne selleks vastutavalt

töötlejalt kirjaliku kinnituse. Kinnituse küsimisel tuleb kirjeldada plaanitav turvalise

kustutuse meetod.

4. Nõuded volitatud töötlejale

4.1. Volitatud töötleja on kohustatud kasutama ja töötlema tabelis 1 olevaid andmeid üksnes

lepingu täitmiseks ja vastutava töötleja dokumenteeritud juhiste alusel, välja arvatud

juhul, kui volitatud töötleja on kohustatud teavet töötlema volitatud töötleja suhtes

kohalduva õiguse alusel. Viimati nimetatud juhul teavitab volitatud töötleja vastutavat

töötlejat vastava kohustuse olemasolust enne teabe töötlemist, kui selline teavitamine ei

ole olulise avaliku huvi tõttu volitatud töötleja suhtes kohalduva õigusega keelatud.

4.2. Volitatud töötleja peab täitma kõiki kehtivaid andmete töötlemisalaseid nõudeid,

andmete turvalisust puudutavaid ning andmete kaitse alaseid Euroopa Liidu ja Eesti

Vabariigi õigusakte ja muid eeskirju.

4.3. Volitatud töötleja on kohustatud aitama vastutavat töötlejat järgmiste nõuete täitmise

tagamisel, võttes arvesse andmetöötluse laadi ja volitatud töötlejale kättesaadavat

teavet:

4.3.1. kohustus hinnata kavandatavate töötlemistoimingute mõju isikuandmete kaitsele

(edaspidi „andmekaitsealane mõjuhinnang“), kui teatava töötlemisviisiga

kaasneb tõenäoliselt suur oht füüsiliste isikute õigustele ja vabadustele;

4.3.2. kohustus tagada isikuandmete õigsus ja ajakohasus, teavitades vastutavat

töötlejat viivitamata, kui volitatud töötleja saab teada, et tema töödeldavad

isikuandmed on ebaõiged või aegunud;

4.3.3. kohustus teavitada vastutavat töötlejat kohe, kui vastutava töötleja nõuded ja

juhised lähevad volitatud töötleja arvates vastuollu isikuandmete kaitse

üldmäärusega või kohaldatavate liidu või liikmesriigi andmekaitsealaste

sätetega.

5. Alamtöötleja kaasamine

5.1. Volitatud töötleja ei telli käesolevate nõuete kohaselt vastutava töötleja nimel tehtavate

töötlemistoimingute tegemist alamtöötlejalt ilma vastutava töötleja eelneva kirjaliku

eriloata. Volitatud töötleja esitab eriloa taotluse vähemalt 14 kalendripäeva enne

kõnealuse alamtöötleja kaasamist koos teabega, mis on vajalik, et vastutav töötleja saaks

loa kohta otsuse teha. Luba registreeritakse lepingu külge lisana.

5.2. Kui volitatud töötleja kaasab konkreetsete töötlemistoimingute tegemiseks (vastutava

töötleja nimel) alamtöötleja, teeb ta seda lepinguga, millega kehtestatakse alamtöötlejale

sisuliselt samad andmekaitsealased nõuded, mis on volitatud töötlejal käesolevate

nõuete kohaselt.

5.3. Volitatud töötleja tagab, et alamtöötleja täidab volitatud töötleja suhtes käesolevaid

nõudeid.

5.4. Volitatud töötleja jääb vastutava töötleja ees täielikult vastutavaks alamtöötleja nõuete

täitmise eest vastavalt volitatud töötlejaga sõlmitud lepingule. Volitatud töötleja

teavitab vastutavat töötlejat, kui alamtöötleja ei täida oma lepingulisi nõudeid.

6. Tehnilised ja korralduslikud meetmed, sealhulgas tehnilised ja korralduslikud

meetmed andmete turvalisuse tagamiseks

6.1. Volitatud töötleja kohustub tarvitusele võtma asjakohased tehnilised ja korralduslikud

meetmed lepingu alusel toimuva andmete töötlemise loata või ebaseadusliku töötlemise,

juhusliku kaotamise või hävitamise või kahjustumise vältimiseks.

6.2. Volitatud töötleja tagab organisatsioonisisese metoodilise ja süstemaatilise infoturbe

haldamise, eelistatult laialdaselt tunnustatud turvasmetoodika põhjal (nt ISO/IEC

27001, SOC2, CIS Security Controls, Eesti riiklik infoturbe standard E-ITS vms), sh

rakendades:

6.2.1. infoturbe riskihalduse;

6.2.2. varahalduse, sh arvestades RMK varadega;

6.2.3. infoturbe rollide ja vastutuse kindlaksmääramine;

6.2.4. pääsuõiguste halduse;

6.2.5. turvaintsidentide halduse;

6.2.6. jätkuvuse halduse, sh oma tarneahela ulatuses;

6.2.7. tööjaamade ja teiste IT-seadmete ja tarkvarade tugevdamise ja

konfiguratsioonihalduse;

6.2.8. kahjurvara tõrje;

6.2.9. krüptograafiliste meetmete halduse;

6.2.10. auditilogi ja turvaseire olemasolu;

6.2.11. nõrkuse ja paigahalduse;

6.2.12. füüsiliste turvameetmete halduse;

6.2.13. turvameetmete perioodilise läbivaatuse (vähemalt kord aastas).

6.3. Kõik need infoturbe protsessid peavad tagama RMK varade konfidentsiaalsuse,

tervikluse, käideldavuse ja organisatsiooni kohanemisvõime muutuvas küberohtude

keskkonnas.

7. Andmete turvalisus edastamisel ja talletamisel

7.1. Volitatud töötleja on kohustatud hoidma lepingu täitmise käigus teatavaks saanud

andmeid rangelt konfidentsiaalsena ning mitte kasutama ega avaldama andmeid, mis

tahes muul kui käesolevas lepingus sätestatud eesmärgil.

7.2. Konfidentsiaalse teabe edastamisel arvutivõrgu kaudu peab teave olema krüpteeritud

turvalise krüptomeetme abil vastavalt kokkulepitud andmeedastuse viisile, kas:

7.2.1. rakenduste vahelisel suhtlusel üle API kasutades turvalist šifrikomplektiga TLS

(HTTPS) veebiseanssi;

7.2.2. inimkasutajale andmete jagamisel üle veebiliidese kasutades turvalist

šifrikomplektiga TLS (HTTPS) veebiseanssi;

7.2.3. kaugpääsuga andmete jagamisel kasutades VPN ühendust turvalise

konfiguratsiooniga;

7.2.4. e-kirjaga andmete edastamisel kasutades krüpteeritud manuseid (.cdoc).

7.3. Konfidentsiaalse teabe talletamisel (andmed jõudeolekus) peab rakendama turvalisi

krüptomeetmeid. Näiteks kogu ketta krüpteerimine, mälupulga krüpteerimine,

krüpteeritud andmebaas või andmebaasi kirjed.

7.4. Turvaline krüptomeede on lahendus, mis rakendab turvalist krüptoalgoritmi,

võtmepikkust, krüptovõtme käsitlust, tarkvara jms. Valikul peab lähtuma uusimast RIA

avaldatud krüptograafiliste algoritmide elutsükli uuringust (https://www.ria.ee/amet-

uudised-ja-kontakt/uudised-pressikontakt/uuringud-ja-

analuusid?view_instance=2&current_page=1&sort_property=1&sort_direction=desc#

kruptouuringud).

7.5. Volitatud töötlejal pole lubatud edastada andmeid väljapoole Euroopa Liidu

liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma

vastutava töötleja sellekohase selgesõnalise kirjaliku nõusolekuta.

8. Pääsuhalduse meetmed

8.1. Volitatud töötleja on kohustatud oma töötajatele andma töödeldavatele isikuandmetele

juurdepääsu üksnes ulatuses, mis on vajalik lepingu täitmiseks, haldamiseks ja selle

täitmise üle tehtavaks järelevalveks. Volitatud töötleja tagab, et isikuandmeid töötlema

hakkavad volitatud isikud on kohustatud järgima isikuandmete töötlemise nõudeid või

nende suhtes kehtivaid asjakohaseid seadusjärgseid konfidentsiaalsuskohustusi.

8.2. Juurdepääs RMK varadele, sh teabele on lubatud:

8.2.1. VPN ja RDP/SSH kaugpääsu lahenduste kaudu;

8.2.2. läbi kokkulepitud IP aadressi;

8.2.3. Läbi külaliskontode.

8.3. Vastutava töötleja konfidentsiaalse teabega dokumentatsioon peab olema vastavalt

märgistatud, kui vastav märgistus on juba seotud alusdokumentatsioonil või kui need

juhised on vastutava töötleja poolt antud. Dokumentatsioonil saab kasutada märgistust:

asutusesiseks kasutamiseks ning vastav viide õigusaktile või “RMK siseseks

kasutamiseks”.

8.4. Vastutava töötleja süsteemides talletatud ja üksnes seal töötlemiseks mõeldud teavet ei

tohi kopeerida volitatud töötleja süsteemidesse, kui ei ole kirjalikult kokku lepitud

teisiti.

8.5. Vastutava töötleja konfidentsiaalsele teabele juurdepääsu jagamisel tuleb arvestada

konkreetsete töötajate teadmisvajadusega ning rakendada minimaalõiguste printsiipi.

8.6. Juurdepääsu võimaldavat teavet (nt paroolid, PIN-koodid, salajased või privaatvõtmed,

tookenid jne) tohib talletada ainult krüpteeritud kujul (nt tarkvaraline paroolihoidla,

vault) või füüsiliselt kaitstud hoidlas (nt seifis).

8.7. Juurdepääsul peab kõikidele kasutajatele jõustama mitmetasemelised autentimisviisid

ja keelama üksnes ühetasemelised autentimisviisid.

8.8. Vastutava töötleja süsteemides loodud kasutajakontosid võib kasutada ainult volitatud

töötleja töötaja, kellele nimeline konto on loodud ja kellele on pääsuõigused üle antud.

Konto jagamine on keelatud.

8.9. Volitatud töötleja peab vastutavat töötlejat viivitamata teavitama kasutajakonto

sulgemisese vajadusest, kui mõni volitatud töötleja töötajatest on töölt lahkunud, ei ole

enam seotud lepingu täitmisega või pääsuandmed on sattunud ohtu (nt lekkinud).

9. Töötluskoha füüsilise turbe meetmed

9.1. Vastutava töötleja konfidentsiaalset teavet tohib töödelda ainult nendes ruumides, kus

on tagatud piisav kaitse füüsiliste turvaohtude eest, näiteks seadme vargus või

volitamata juurdepääs, ekraani või klaviatuuri jälgimine jms.

10. Andmete kvaliteedi tagamise meetmed

10.1. Volitatud töötleja peab vastutava töötleja konfidentsiaalset teavet töötlema viisil, et

andmete õigsus, täielikkus ja ajakohasus oleks tagatud. Võimalusel peab rakendama

sisendandmete valideerimist, töödeldud andmete testimist ja kindlustama volitatud

töötleja poolt kasutatava tarkvara korrektne toimimine.

11. Sündmuste logimine ja seire

11.1. Volitatud töötleja tagab konfidentsiaalse teabe töötlemisega seotud revisjonlogi (audit

logi) olemasolu ja pideva turvaseire.

11.2. Logisid peab säilitama 2 aastat.

12. Jätkuvuse ja muudatuse meetmed

12.1. Volitatud töötleja teavitab vastutavat töötlejat kirjalikult kõigist muudatustest, mis

võivad mõjutada volitatud töötleja võimet või väljavaateid pidada kinni käesolevast

lisast ja vastutava töötleja kirjalikest juhistest. Pooled lepivad kõigis käesolevat lisa

puudutavates täiendustes ja muudatustes kokku kirjalikult.

12.2. Volitatud töötleja tagab oma teenuste kättesaadavuse, arvestades võimalike

probleemidega enda tarneahelas.

12.3. Vastutava töötleja poolsel pärimisel annab volitatud töötleja teavet oma toodetes

kasutatavatest süsteemi-komponentidest ja turvafunktsioonidest.

12.4. Teenuseid mõjutavatest muudatustest ja võimalikest plaanilistest katkestustest antakse

vastutavale töötlejale teada enne muudatust või katkestust.

13. Turvameetmete teavitus ja kontroll

13.1. Vastutav- ja volitatud töötleja peavad suutma tõendada käesolevate nõuete täitmist.

13.2. Volitatud töötleja peab võimaldama vastutaval töötlejal või tema poolt volitatud

audiitoril teha auditeid ja kontrolle ning panustama nendesse.

13.3. Vastutav- ja volitatud töötleja teevad auditi käigus saadud teabe ja auditite tulemused

taotluse korral kättesaadavaks pädevale järelevalveasutusele.

13.4. Volitatud töötleja tagab oma töötajate teavitamise käesolevatest turvameetmetest.

13.5. Volitatud töötleja tagab iseseisvalt enda ja alltöövõtjate organisatsioonis pideva

turvameetmete rakendatuse kontrolli.

13.6. Volitatud töötleja organisatsioonisisest infoturbehaldust peab auditeerima sõltumatu

osapool vähemalt üks kord aastas. Selle korraldab volitatud töötleja.

13.7. Tunnustatud turvasertifikaadi (nt ISO/IEC 27001, SOC2) või auditiaruande (E-ITS

auditi aruanne) korral ei pea eraldiseisvat sõltumatud auditit lisaks läbi viima, kui

sertifikaat või auditi aruanne:

13.7.1. on kehtiv;

13.7.2. käsitlusala katab ära RMK varadega seotud teenused või tooted;

13.7.3. tehakse vastutavale töötlejale kättesaadavaks.

13.8. Võimalikud erandid ja kõrvalekalded nimetatud meetmetest tuleb kirjalikult

kooskõlastada vastutava töötlejaga enne erandi rakendamist.

13.9. RMK võib igal ajahetkel kontrollida ja auditeerida nimetatud turvameetmete

rakendatust ja volitatud töötleja peab seda toetama.

14. Andmetega seotud rikkumisest teavitamine

14.1. Volitatud töötleja teavitab vastutavat töötlejat andmetega seotud rikkumistest või kui on

alust kahtlustada, et selline rikkumine on aset leidnud, ilma põhjendamatu viivituseta

alates hetkest, kui volitatud töötleja või tema poolt kasutatav alamtöötleja saab teada

andmetega seotud rikkumisest või on alust kahelda, et selline rikkumine on aset leidnud,

kuid mitte hiljem kui kakskümmend (20) tundi pärast sellest teada saamist.

14.2. Volitatud töötleja teeb vastutava töötlejaga igakülgset koostööd turvaintsidentide

käsitlemisel, sh analüüsimisel, isoleerimisel ja normaalse olukorra taastamisel.

14.3. Volitatud töötleja peab oma sisemised lahendused ja protsessid korraldama selliselt, et

intsidendi korral vastutava töötlejaga seotud äriprotsessid ja -teenused toimiksid

võimalikult vähese häiringuga.

14.4. Vastutava töötleja nõudmisel peab volitatud töötleja ilma põhjendamatu viivituseta

edastama vastutavale töötlejale kogu andmetega seotud rikkumist puudutava asjakohase

informatsiooni.

14.5. Teates tuleb kirjeldada vähemalt järgmist:

14.5.1. toimunud andmetega seotud rikkumise laad, andmesubjekti kategooriad ja

ligikaudne arv ning isikuandmete liigid ja ligikaudne arv;

14.5.2. eeldatav kuupäev ja kellaaeg;

14.5.3. isikuandmetega seotud rikkumise tõenäolised tagajärjed;

14.5.4. volitatud töötleja asjakohase kontaktisiku nimi ja kontaktandmed, kellelt saab

täiendavat informatsiooni;

14.5.5. meetmeid, mida volitatud töötleja rikkumise lahendamiseks on tarvitusele

võtnud või võtab, et vältida andmetega seotud rikkumisi tulevikus, ja vajaduse

korral ka meetmeid, mille abil leevendada rikkumise võimalikke negatiivseid

mõjusid;

14.5.6. esitama muud teavet, mis on mõistlikult nõutav, et vastutav töötleja saaks täita

kohaldatavaid andmekaitsealaseid nõudeid, sealhulgas riigiasutustega seotud

teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav

andmesubjekti tuvastamiseks;

14.5.7. Juhul kui kogu teavet ei ole võimalik esitada korraga, peab esialgne teade

sisaldama sel ajal kättesaadavat teavet ning täiendav teave esitatakse viivituseta

pärast selle saamist.

14.6. Teavet andmetega seotud rikkumistest ja turvaintsidentide kohta loetakse

konfidentsiaalseks ja see tuleb edastada krüpteeritult.

14.7. Teavitus tuleb edastada:

14.7.1. E-posti aadress: [email protected];

14.7.2. telefon: +372 676 7000.

14.8. Vastutav töötleja teavitab vajadusel kolmandaid osapooli, avalikkust ja

järelevalveasutusi, sh Andmekaitse Inspektsiooni, Riigi Infosüsteemi Ametit ja Politsei-

ja Piirivalveametit. Volitatud töötleja ei teosta avalikku suhtlust osas, mis võimaldab

tuvastada vastutavat töötlejat ja tema kliente.

15. Lõppsätted

15.1. Kui volitatud töötleja ei täida käesolevatest nõuetest tulenevaid kohustusi, võib vastutav

töötleja anda volitatud töötlejale korralduse peatada isikuandmete töötlemine seniks,

kuni volitatud töötleja järgib käesolevaid nõudeid või leping lõpetatakse. Volitatud

töötleja teavitab vastutavat töötlejat viivitamata, kui ta ei suuda käesolevaid nõudeid mis

tahes põhjusel täita.

15.2. Vastutaval töötlejal on õigus lõpetada leping , kui:

15.2.1. vastutav töötleja on volitatud töötleja poolse isikuandmete töötlemise punkti

15.1 kohaselt peatanud ja kui käesolevaid nõudeid ei hakata järgima mõistliku

aja jooksul või hiljemalt ühe kuu jooksul pärast peatamist;

15.2.2. volitatud töötleja rikub oluliselt või jätkuvalt käesolevaid nõudeid või

isikuandmete kaitse üldmäärusest tulenevaid nõudeid.

15.3. Volitatud töötlejal on õigus lõpetada leping isikuandmete töötlemise osas pärast seda,

kui ta on vastutavat töötlejat punkti 4.3.3 kohaselt teavitatud, et tema juhised lähevad

vastuollu kohaldatavate õigusnõuetega, kuid vastutav töötleja nõuab nende juhiste

järgimist.

15.4. Pärast lepingu lõpetamist kustutab volitatud töötleja vastutava töötleja valikul kõik

vastutava töötleja nimel töödeldud isikuandmed ja kinnitab vastutavale töötlejale, et ta

on seda teinud, või tagastab kõik isikuandmed vastutavale töötlejale ja kustutab

olemasolevad koopiad, välja arvatud juhul, kui seaduses kohaselt nõutakse

isikuandmete säilitamist. Volitatud töötleja jätkab nendele nõuetele vastavuse tagamist

seni, kuni andmed kustutatakse või tagastatakse.