Kiberdrošība publiskajos IKT iepirkumos: no līguma klauzulām līdz pārbaudāmam rezultātam

Kiberdrošības prasības publiskajā iepirkumā var izskatīties līdzīgas, bet tām var būt pavisam atšķirīga juridiskā funkcija.

Publisko iepirkumu likums jau dod vairākus instrumentus.1

Šīs kategorijas nevajag sajaukt.

Ja piegādātāja organizatoriska īpašība tiek formulēta kā produkta tehniskā prasība, rodas viena veida problēma. Ja minimāls pass/fail drošības nosacījums tiek pārvērsts par neskaidru punktu piešķiršanas kritēriju, rodas cita. Ja līguma dzīves cikla pienākums paliek tikai tehniskās specifikācijas aprakstā bez skaidras līgumiskas sekas, prasība var kļūt grūti izpildāma praksē.

Tāpēc “Security Annex” šajā rakstā ir tikai strukturēšanas darba jēdziens, ne Publisko iepirkumu likumā definēts patstāvīgs dokumenta veids.

Publisko iepirkumu likuma 20. pants ļauj tehniskās specifikācijas formulēt kā funkcionālas vai darbības rezultāta prasības un tajās ietvert arī drošības noteikumus, pārbaudes noteikumus un atbilstības noteikšanas metodes.1

Tas ir ļoti piemērots pamats kiberdrošībai.

Piemēram, vāja prasība būtu:

“Risinājumam jābūt izstrādātam atbilstoši drošas izstrādes labajai praksei.”

Daudz pārbaudāmāka prasība būtu:

“Pirms pieņemšanas piegādātājs iesniedz saskaņotā tvēruma drošības testēšanas rezultātu par pieņemšanai paredzēto versiju, norādot būtiskos konstatējumus, to statusu un atkārtotas pārbaudes rezultātu tiem konstatējumiem, kuru novēršana bija pieņemšanas priekšnoteikums.”

Otrais formulējums vēl nav automātiski labs jebkuram iepirkumam. Tam joprojām jābūt samērīgam un precīzi definētam.

Taču vismaz ir iespējams saprast, ko pārbaudīt.

Vēl viena bieža kļūda ir vispirms izvēlēties pierādījumu un tikai tad izdomāt prasību.

Piemēram:

“Piegādātājam jābūt sertifikātam X.”

Dažos iepirkumos konkrēta sertifikācija var būt atbilstošs un samērīgs pierādījums.

Citā iepirkumā tas var būt pārāk plašs, pārāk šaurs vai nepamatoti ierobežot konkurenci.

Publisko iepirkumu likuma 22. pants paredz iespēju noteiktos gadījumos prasīt akreditētu atbilstības novērtēšanas institūciju testēšanas pārskatus, protokolus vai sertifikātus kā pierādījumu atbilstībai, vienlaikus jāņem vērā likumā paredzētie līdzvērtības mehānismi.1

Tāpēc labāka secība ir:

risks → prasība → nepieciešamais rezultāts → samērīgs pierādījums

nevis:

sertifikāts → mēģinām tam atrast pamatojumu.

Šī atšķirība ir svarīga arī mazākiem piegādātājiem. Valstij nevajag vājināt drošību, lai “palīdzētu SME”. Tai vajag izvairīties no prasībām, kuru izmaksas un administratīvais slogs nav saistīti ar reālo risku.

Secure by Design ir labs princips.

Iepirkumā tas kļūst daudz vērtīgāks, ja no tā izriet konkrēti piegādes rezultāti.

Augstāka riska izstrādes iepirkumā tie var būt, piemēram:

• dokumentētas uzticamības robežas;
• autentifikācijas un autorizācijas modelis;
• būtisko datu plūsmu apraksts;
• atkarību un komponentu pārvaldības pieeja;
• noslēpumu pārvaldības modelis;
• testēšanas tvērums;
• zināmo drošības findingu statuss;
• piegādes versijas identifikators;
• atkārtotas pārbaudes rezultāts, ja tas bija nepieciešams.

Ne visam jābūt vienā dokumentā.

Un ne visu vajag prasīt katram standartproduktam.

Svarīga ir cita īpašība: pasūtītājs pirms līguma slēgšanas zina, kā izskatīsies pieņemams drošības rezultāts.

Funkcionāli pabeigta sistēma nav automātiski drošības ziņā pieņemta sistēma.

Tas nenozīmē, ka pieņemšanas kritērijam jābūt “nulle ievainojamību”. Tāds kritērijs būtu nepraktisks un bieži pat maldinošs.

Drošības pieņemšanas posmā daudz noderīgāk ir nošķirt:

novēršamu neatbilstību;

zināmu atlikušā riska elementu;

pieņemšanas bloķējošu nosacījumu;

riskam atbilstošu pagaidu mazināšanas pasākumu;

lēmumu, kurš un ar kādu pamatojumu pieņem atlikušo risku.

Piemēram, konkrētā augsta riska iepirkumā pasūtītājs var iepriekš noteikt, ka noteiktas kategorijas neatrisināta ievainojamība bloķē pieņemšanu, ja vien nosaukta atbildīgā loma dokumentēti neapstiprina pagaidu mazināšanas pasākumu un termiņu.

Tas nav universāls normatīvs slieksnis.

Tas ir piemērs tam, kā drošības risks kļūst par iepriekš definētu līguma lēmumu, ne pēdējās dienas strīdu starp projektu vadītāju un piegādātāju.

Vienai būtiskai prasībai praktiski vajag vairāk nekā teikumu.

Tas ir pietiekami vienkārši, lai neizveidotu jaunu dokumentu fabriku.

Tajā pašā laikā tas ir pietiekami precīzi, lai piegādātājs jau piedāvājuma sagatavošanas laikā saprastu, ko no viņa sagaida.

Pieņemsim, ka iepirkumā ir prasība aizsargāt privileģēto administratoru piekļuvi.

Vājš formulējums:

“Piegādātājs nodrošina drošu administratoru autentifikāciju.”

Pārbaudāmāks variants varētu noteikt rezultātu:

“Produkcijas administratīvā piekļuve izmanto pasūtītāja apstiprinātu daudzfaktoru autentifikāciju; pirms pieņemšanas jāapliecina, ka produkcijas administratīvajiem kontiem nav aktīva alternatīva autentifikācijas plūsma, kas apiet noteikto MFA kontroli, izņemot atsevišķi pārvaldītu avārijas piekļuves mehānismu.”

Tad jāpievieno:

pārbaude — konfigurācijas un kontrolēta autentifikācijas scenārija pārbaude;

pierādījums — konfigurācijas izraksts un testa rezultāts;

neatbilstība — pieņemšana netiek pabeigta vai tiek piemērots iepriekš noteikts izņēmuma process;

dzīves cikls — būtiska identitātes risinājuma maiņa izraisa prasības atkārtotu pārbaudi.

Šajā brīdī frāze “MFA required” beidzot kļūst par kontroli, kuru var pieņemt un vēlāk pārbaudīt.

Tiem subjektiem, uz kuriem attiecas Ministru kabineta noteikumi Nr. 397 “Minimālās kiberdrošības prasības”, ārpakalpojumu un piegādes ķēdes prasības jau ir diezgan konkrētas.2

87.–90. punkts cita starpā paredz:

• precīzas prasības ārpakalpojuma apjomam un kvalitātei;
• tiesības uzraudzīt pakalpojuma kvalitāti un saņemt nepieciešamo informāciju, tostarp žurnālfailus;
• piegādātāja pienākumus incidenta gadījumā;
• apakšuzņēmēju informāciju un prasību pārmantojamību;
• sistēmu pārbaudes;
• datu atdošanu vai dzēšanu pēc līguma;
• izstrādes/izmaiņu līgumos noteiktu uzturēšanas, atbalsta un drošības nepilnību novēršanas periodu;
• piegādes ķēdes riska izvērtējumu;
• ārpakalpojuma izbeigšanas stratēģiju.2

Šo prasību esamība būtiski maina diskusiju.

Problēmu nevajag formulēt tā, it kā Latvijas publiskajos IKT iepirkumos kiberdrošības regulējuma nebūtu.

Jautājums ir daudz praktiskāks:

kā piemērojamo normatīvo minimumu savlaicīgi pārvērst konkrētā iepirkuma dokumentācijā, līguma saistībās, piegādes pierādījumos un pieņemšanas darbībās?

2026. gada 21. augustā IUB atbildēja uz manu iesniegumu, ka tajā ietvertie priekšlikumi tiks izvērtēti metodiskā darba pilnveidošanā. IUB vienlaikus uzsvēra divas robežas: konkrētās prasības vienmēr jāvērtē konkrētā iepirkuma priekšmeta, mērķa, risku un apstākļu kontekstā, un Biroja ieskatā prasību strukturēšanas grūtības nav vispārēji izplatīta problēma.4

Atbildē IUB arī norādīja, ka tobrīd izstrādā skaidrojumu/vadlīnijas par kiberdrošības prasību piemērošanu publiskajos iepirkumos un ņems vērā vēstulē ietvertos ierosinājumus.4

2026. gada 22. septembrī IUB publiski paziņoja par jaunā skaidrojuma publicēšanu.3 Tajā MK noteikumu Nr. 397 piemērošana skatīta no publiskā iepirkuma puses, tostarp apskatot SAB atzinumu pieprasīšanu, negatīva atzinuma sekas, iepirkuma nolikumā iekļaujamo informāciju un A klases informācijas sistēmu tehnisko resursu iegādes prasības.3

Šo notikumu secība ir dokumentējama.

Taču no tās neizriet, ka mans iesniegums izraisīja vadlīniju tapšanu vai noteica to saturu. Pats IUB jau 21. augustā rakstīja, ka materiālu izstrādā.

Svarīgāks ir cits secinājums: 2026. gadā kiberdrošības prasību praktiska ievietošana iepirkuma procesā Latvijā ir kļuvusi par pietiekami konkrētu jautājumu, lai IUB tam izdotu atsevišķu metodisku skaidrojumu.

2026. gada 27. augustā Finanšu ministrija rakstiski atzinīgi novērtēja priekšlikuma ieceri stiprināt kiberdrošības prasību izsekojamību, pārbaudāmību un konsekventu iesaisti IKT iepirkumos.5

Vienlaikus ministrija norādīja, ka spēkā esošais Publisko iepirkumu likums jau ir pietiekami atvērts un elastīgs, lai šādu pieeju īstenotu, savukārt konkrēto prasību saturs jāvērtē kopā ar attiecīgo iepirkuma priekšmetu un citiem apstākļiem.5

Tas ir būtisks skeptisks pretarguments jebkurai idejai par “vēl vienu regulējumu”.

Ja esošais likums jau ļauj definēt funkcionālas prasības, kvalitātes kritērijus, pierādījumus un līguma izpildes pienākumus, tad pirmā problēma var nebūt normu trūkums.

Tā var būt prasību projektēšanas kvalitāte.

No 2026. gada 9. jūnija Publisko iepirkumu likuma 2.^1 pants paredz pasūtītāja atbildību par iepirkumu efektivitāti un iekšējās kontroles sistēmu visā iepirkuma ciklā — no sagatavošanas līdz līguma izpildei.1

Šo normu nevajag pārinterpretēt kā tiešu pienākumu izveidot atsevišķu kiberdrošības acceptance sistēmu.

Tomēr tā labi saskan ar principu, ka prasība nedrīkst pazust pēc konkursa rezultātu paziņošanas.

Ja drošības prasība bija būtiska iepirkuma sagatavošanā, iekšējai kontrolei jāspēj sekot līdzi tam, vai tā:

• pareizi nonāca dokumentācijā;
• tika vērtēta;
• tika pārnesta līgumā;
• tika pārbaudīta piegādes laikā;
• tika ņemta vērā pieņemšanā;
• turpina darboties līguma izpildē.

Tas ir daudz tuvāk drošības pārvaldībai nekā formāls “prasība bija nolikumā” secinājums.

Direktīva 2014/24/ES ļauj tehniskās specifikācijas formulēt funkcionālu vai darbības rezultāta prasību veidā, izmantot ar līguma priekšmetu saistītus kvalitātes kritērijus un noteikt līguma izpildes nosacījumus.8

Tajā pašā laikā šie mehānismi nedod pasūtītājam neierobežotu brīvību.

Kritērijiem jāļauj reāli pārbaudīt pretendenta sniegto informāciju, tiem jābūt saistītiem ar līguma priekšmetu, un prasības nedrīkst nepamatoti ierobežot konkurenci.8

Kiberdrošībai tas ir labs ierobežojums.

Pasūtītājam nav jākopē viss, ko viņš zina par drošību.

Viņam jāizvēlas tas, kas ir vajadzīgs šim iepirkuma rezultātam.

NIS2 21. pants piegādes ķēdes drošību iekļauj kiberdrošības riska pārvaldības pasākumos tiem subjektiem, uz kuriem direktīvas prasības attiecas.9

2026. gada NIS Cooperation Group ICT Supply Chain Security Toolbox papildus piedāvā nesaistošu, actor-agnostic pieeju piegādes ķēdes risku identificēšanai un mazināšanai publiskajā un privātajā sektorā.10

Tas ir noderīgs konteksts iepirkumam.

Tomēr supplier questionnaire nav kontrole pats par sevi.

Ja piegādātājs atbild:

“Yes, we manage subcontractor risk.”

pasūtītājam augstāka riska līgumā joprojām jāzina, ko šis apgalvojums nozīmē praksē.

Vai būtiski apakšuzņēmēji ir identificējami?

Vai par to maiņu jāziņo?

Vai drošības prasības tiek pārnestas tālāk?

Vai piegādātājs saglabā incidentu sadarbības pienākumu?

Vai līguma beigās dati, piekļuves un noslēpumi tiek pārvaldīti?

Vai ir exit modelis?

Piegādes ķēdes drošība kļūst pārbaudāma tikai tad, kad “supplier risk management” sadalās konkrētās līguma saistībās un pierādījumos.

Ne katra drošības īpašība ir pass/fail.

Publisko iepirkumu likuma 51. pants ļauj saimnieciski visizdevīgāko piedāvājumu noteikt, izmantojot ar līguma priekšmetu saistītus kvalitātes kritērijus.1

Tas paver iespēju atsevišķos augstāka riska IKT iepirkumos izvērtēt objektīvi izmērāmu drošības kvalitāti virs minimālā sliekšņa.

Tomēr šeit ir viegli kļūdīties.

Punktus nevajag dot par miglainiem solījumiem:

“mūsu uzņēmums īpaši rūpējas par kiberdrošību”.

Un arī ne par dokumentu skaitu.

Kvalitātes kritērijam jābūt iepriekš saprotamam, salīdzināmam un pārbaudāmam.

Piemēram, konkrētā iepirkumā var būt nozīme izmērāmam atbalsta modelim, drošības labojumu piegādes spējai, migrācijas/exit īpašībai vai tehniski pārbaudāmai arhitektūras priekšrocībai.

Bet tas ir projektējams konkrētajam līgumam.

Manā 2026. gada priekšlikumā modulārais modelis ietvēra vairākus iespējamos blokus.67

Tie nav jāizmanto visi.

Drošības pamatprasības

Piemērojamais regulējums, drošības mērķis, piekļuves modelis, auditējamība un bāzes konfigurācijas prasības.

Secure by Design / Secure SDLC

Tikai tur, kur tiek izstrādāts vai būtiski mainīts risinājums un šāda prasība ir pamatota ar risku.

Drošības testēšana un pieņemšana

Ko testēs, kuru versiju, kas ir būtisks findings, kā notiek remediation un retest.

Ievainojamību un incidentu sadarbība

Kas saņem ziņojumu, kas triage, kā tiek piegādāts fix, kā piegādātājs iesaistās incidentā.

Piegādes ķēde

Būtiskie apakšuzņēmēji, kritiskās atkarības, piekļuves, izmaiņas un aizvietojamība.

Atbalsts, patching un EOL

Cik ilgi pakalpojums tiek uzturēts, kas notiek ar drošības labojumiem un kā pasūtītājs tiek informēts par dzīves cikla beigām.

Exit un darbības nepārtrauktība

Datu un konfigurācijas nodošana, piekļuves atsaukšana, noslēpumu rotācija, nepabeigtie drošības darbi un pārejas atbalsts.

Modularitātes jēga ir tieši tajā, ka zema riska standartpirkumam šo katalogu neuzliek pilnā apjomā.

Iepirkuma drošības dizains atbild uz jautājumu:

ko mums vajadzēja saņemt un kā mēs to pieņemsim?

Tehniskā izsekojamība, ko analizēju atsevišķi rakstā par valsts IKT izsekojamību, sākas nākamajā slānī:

vai varam vēlāk pierādīt, ka pieņemtā versija, konfigurācija un drošības rezultāts ir tas pats, kas faktiski nonāca produkcijā un turpināja mainīties kontrolēti?

Šīs problēmas ir saistītas, bet nav identiskas.

Labs iepirkums nosaka sagaidāmo stāvokli.

Laba izsekojamība pierāda faktisko stāvokli.

Vienai būtiskai drošības prasībai var pietikt ar šādu ierakstu:

Šī kartīte nav normatīva veidlapa.

Tās mērķis ir nepieļaut trīs ļoti parastas situācijas:

1. prasība ir uzrakstīta, bet neviens nezina, kā to pārbaudīt;
2. pierādījums ir iesniegts, bet neviens nezina, kuru prasību tas pierāda;
3. neatbilstība ir zināma, bet nav skaidrs, kas drīkst pieņemt risku.

Labs pēdējais filtrs nav “vai mums ir pietiekami daudz drošības prasību?”.

Noderīgāki ir astoņi jautājumi.

Ja uz pēdējiem trim jautājumiem nav atbildes, drošības prasība vēl nav pabeigta.

Publiskā IKT iepirkuma kiberdrošība nav atkarīga no tā, cik reizes nolikumā parādās vārds “drošība”.

Tā ir atkarīga no tā, vai pasūtītājs spēj savienot piecas lietas:

risku, prasību, pierādījumu, pārbaudi un lēmumu.

Spēkā esošais Latvijas publisko iepirkumu regulējums jau dod instrumentus tehniskām un funkcionālām prasībām, pierādījumiem, kvalitātes kritērijiem un līguma izpildes noteikumiem. MK noteikumi Nr. 397 attiecīgajiem subjektiem jau nosaka būtisku ārpakalpojumu un piegādes ķēdes minimumu. 2026. gada IUB jaunais skaidrojums rāda, ka šo divu pasauli praktiska savienošana ir aktuāla arī metodikas līmenī.3

Tāpēc nav obligāti vajadzīgs vēl viens universāls dokuments.

Vajag kaut ko grūtāku: katrai būtiskai drošības prasībai jau iepriekš zināt, kā izskatīsies pierādāma izpilde un kas notiks, ja tā netiks sasniegta.

Juridiskais un institucionālais statuss pārbaudīts 2026. gada 25. septembrī. Rakstā lietotie termini “Security Annex”, “drošības pieņemšana”, “kiberdrošības prasību arhitektūra” un prasības kartīte ir autora metodiski jēdzieni, ne Publisko iepirkumu likumā definēti juridiski institūti. IUB 2026. gada septembra skaidrojuma publicēšana pēc autora iesnieguma netiek pasniegta kā pierādījums cēloņsakarībai.

Šis raksts ir publisko iepirkumu, kiberdrošības assurance un tehniskās pieņemšanas prakses analīze, nevis individuāla juridiska konsultācija.