Vai valsts spēj pierādīt, kas tika saskaņots, pieņemts un faktiski nodots ekspluatācijā?

Latvijas valsts IKT pārvaldībā jau ir vairāki izsekojamības elementi. Ministru kabineta noteikumi Nr. 368 paredz attīstības aktivitātes reģistrēšanu, tās aprakstu, izmaiņu pieprasījumus un noslēguma paziņojumu. Noslēguma paziņojumā cita starpā norāda attīstītos VIRSIS objektus, informāciju par kiberdrošības prasību izpildi un atsauci uz attīstības aktivitātes aktuālo aprakstu. Noteikumi paredz arī faktiskās īstenošanas atbilstības pārbaudes mehānismu.4

Savukārt VIRSIS regulējums nosaka valsts informācijas resursu, sistēmu, digitālo tehnoloģiju un IKT pakalpojumu reģistrācijas un pārvaldības ietvaru.5 Atsevišķi Ministru kabineta noteikumi Nr. 367 nosaka vispārējās tehniskās prasības informācijas sistēmām.6 2026. gada aprīlī VARAM publicēja arī valsts IKT risinājumu izdarbes jeb DevOps vadlīnijas, kuru mērķis ir vienotāka, drošāka, automatizētāka un auditējamāka programmatūras izstrāde un darbināšana.7

Tāpēc būtu neprecīzi apgalvot, ka Latvijas valsts IKT pārvaldībā vispār nav izsekojamības vai dzīves cikla kontroles. Jautājums ir cits: vai šie ieraksti ir pietiekami sasaistīti, lai vajadzīgajā brīdī bez nesamērīga manuāla darba varētu pierādīt pāreju no pārvaldības lēmuma līdz konkrētajam tehniskajam rezultātam?

IKT projektā vismaz četras lietas var būt patiesas vienlaikus, bet tās nav viens un tas pats.

Dažreiz visi četri stāvokļi sakrīt vienā labi pārvaldītā laidienā. Citreiz starp tiem ir papildu labojums, konfigurācijas maiņa, ārkārtas izmaiņa, piegādātāja veikts SaaS atjauninājums vai cits starpposms. Tāpēc “projekts ir pabeigts” pats par sevi nav tehniska identitāte.

Laba izsekojamība nav obligāti sarežģīta. Praktiskā pārbaudē es sāktu ar pieciem jautājumiem.

1. Kurš saskaņotais attīstības darbs ir šā tehniskā rezultāta pamatā?
2. Kas tieši tika pieņemts?
3. Kas tieši tika izvietots vai aktivizēts ekspluatācijā?
4. Ar kādu esošu ierakstu var pierādīt saiti starp pieņemto un faktiski ekspluatācijā esošo rezultātu?
5. Vai šo ķēdi pēc gada var rekonstruēt cita kompetenta persona, nepaļaujoties uz viena piegādātāja vai administratora atmiņu?

Ja uz visiem pieciem jautājumiem jau var droši atbildēt, papildu horizontāls mehānisms, iespējams, nav vajadzīgs.

Tieši tāpēc 2026. gada priekšlikumā VARAM netika apgalvots, ka valstī noteikti ir normatīva nepilnība. Tika piedāvāts vispirms kartēt faktisko procesu un tikai tad, ja saite praksē nav pietiekami atjaunojama, pilotēt minimālu papildinājumu.3

Priekšlikumā lietoju darba jēdzienu “tehniskās izsekojamības saite”. Tas nav normatīvs termins un nav jauna dokumenta veida nosaukums.

Ar to domāta strukturēta saite starp pārvaldības ierakstu un jau esošu tehniskā rezultāta ierakstu. Piemēram:

attīstības aktivitāte → VIRSIS objekts → pieņemtais rezultāts → izmaiņas vai laidiena identifikators → izvietošanas/pakalpojuma versija → kontrolēta atsauce uz pierādījumu

Svarīgākais ir nevis tas, vai katrā posmā izmantots viens konkrēts tehnoloģisks rīks, bet gan tas, vai pāreju var rekonstruēt. Šeit ir būtisks princips: atsauces, nevis pierādījumu kopēšana.

Centrālajam pārvaldības slānim nav jākļūst par pirmkoda, konfigurāciju, drošības testu, ievainojamību informācijas, piekļuves datu vai programmatūras sastāva sarakstu noliktavu. Daļa no šīs informācijas var būt sensitīva, daļa pieder izstrādes vai drošības sistēmām, un daļa mainās daudz ātrāk nekā pārvaldības reģistrs.

Bieži pietiek ar kontrolētu identifikatoru un atsauci uz vietu, kur pierādījums tiek uzturēts.

Ir vilinoši meklēt vienu “manifestu”, kas atrisinātu visu. Praktiski dažādi jautājumi prasa dažādus pierādījumus.

SBOM, piemēram, var būt ļoti vērtīgs piegādes ķēdes un ievainojamību pārvaldības avots. Taču SBOM viens pats nepierāda, ka tieši šis sastāvs bija tas, ko pasūtītājs pieņēma un kas konkrētā datumā atradās produkcijā.

Tāpat Git commit pats par sevi nepierāda izvietošanu. Pieņemšanas akts nepierāda runtime stāvokli. Izvietošanas žurnāls nepierāda, ka izvietotais rezultāts bija tas, ko pasūtītājs bija pieņēmis.

Tieši saites starp šiem pierādījumiem rada izsekojamību.

Individuāli izstrādātai programmatūrai var būt precīzs repozitorijs, commit, build, artefakta kontrolsumma un deployment notikums. SaaS pakalpojumā pasūtītājam šādas detaļas var nebūt pieejamas vispār. Standarta komercprogrammatūrai var būt ražotāja versija un instalācijas inventārs. Pilnībā pārvaldītā pakalpojumā piemērotākais atskaites punkts var būt pakalpojuma versija, konfigurācijas stāvoklis vai piegādātāja izmaiņu identifikators.

Tāpēc laba publiskā IKT izsekojamības prasība nav “visām sistēmām obligāti glabāt Git SHA”.

Tā drīzāk ir prasība spēt identificēt konkrētajam piegādes modelim atbilstošo tehnisko rezultātu un sasaistīt to ar pieņemšanu un ekspluatāciju.

Šāda pieeja ir tehnoloģiski neitrālāka un arī mazāk veicina formālu atbilstību bez praktiskas vērtības.

Incidentā jautājums “kas šobrīd darbojas?” nav grāmatvedisks.

Ja tiek publiskota kritiska ievainojamība vai atklāta kompromitēšana, komandai var būt jānoskaidro, vai konkrētā ievainojamā komponente bija ekspluatācijā incidenta laikā. Ja atbilde balstās tikai uz to, kas bija paredzēts projektā vai pieņemšanas aktā, var tikt analizēts nepareizs sistēmas stāvoklis.

Tieši tāpat izsekojamība palīdz pēc ārkārtas izmaiņas. Ja incidenta laikā produkcijā tika ieviests pagaidu labojums, pēc krīzes ir jāspēj noteikt, vai tas kļuva par jauno autoritatīvo stāvokli, tika aizstāts vai palika vidē nepamanīts.

Tāpēc tehniskā izsekojamība nav tikai audita funkcija. Tā ir arī incidentu izmeklēšanas, atjaunošanas un ievainojamību pārvaldības kvalitātes priekšnosacījums.

Piegādātāja maiņa ātri parāda, cik daudz sistēmas zināšanu patiesībā pieder pasūtītājam.

Ja jaunajam uzturētājam tiek nodota dokumentācija, bet nav droši identificējams faktiskais produkcijas stāvoklis, pārņemšana sākas ar reverso inženieriju. Tas palielina izmaksas un operacionālo risku un praktiski nostiprina iepriekšējā piegādātāja zināšanu monopolu.

Savukārt, ja pārvaldības ieraksts ir sasaistīts ar tehnisko rezultātu, nav nepieciešams centralizēt visas piegādātāja iekšējās sistēmas. Pasūtītājam vajag pietiekamu pierādījumu ķēdi, lai saprastu, ko tas pārņem.

Tas ir viens no iemesliem, kāpēc izsekojamību ir lietderīgi skatīt kopā ar valsts mērķi mazināt nepamatotu atkarību no viena piegādātāja.12

2026. gada 11. augustā VARAM iesniedzu priekšlikumu par valsts IKT attīstības aktivitāšu rezultātu tehniskās izsekojamības un pierādāmības izvērtēšanu saistībā ar TAP projektu 26-TA-1866.3 Tajā apzināti netika prasīts uzreiz grozīt likumu vai izveidot jaunu reģistru.

Priekšlikums paredzēja trīs soļus:

vispirms kartēt, vai esošā sistēma jau nodrošina vajadzīgo saiti;

tikai tad pilotēt, ja kartējums parāda praktisku nepilnību;

un tikai pēc pilota lemt, vai risinājums ir metodika, VIRSIS/DevOps funkcionalitāte, līgumu pieeja vai normatīva izmaiņa.

13. augustā VARAM atbildēja, ka par lietderīgiem atzinusi īpaši tos priekšlikuma aspektus, kas saistīti ar attīstības aktivitāšu rezultātu identificējamību un sasaisti ar faktiski radītajiem tehniskajiem rezultātiem. Ministrija arī norādīja, ka jaunajā valsts IKT resursu attīstības pārvaldības kārtībā paredzēts veicināt sasaisti starp attīstības aktivitāti un radīto vai attīstīto programmatūru, tostarp reģistrējot informāciju par koda repozitoriju un ekspluatācijā nodotajām programmatūras versijām.8

Šo atbildi nevajadzētu pārinterpretēt. Tā nav apliecinājums, ka viss iesniegtais modelis tiks ieviests, un tā nav pierādījums, ka gala regulējumā būs tieši tāda pati konstrukcija. Tā tomēr ir konkrēta institucionāla reakcija uz pašu problēmas kodolu: saiti starp pārvaldības aktivitāti un faktisko tehnisko rezultātu.

Iepirkums nosaka, ko pasūtītājs sagaida saņemt un pēc kādiem kritērijiem pieņems piegādi. Tehniskā izsekojamība sākas ar nākamo jautājumu: vai vēlāk var pierādīt, kurš pieņemtais artefakts, konfigurācija un pārbaudes rezultāts faktiski nonāca produkcijā?

Arī 2026. gada institucionālās atbildes neļauj katru izsekojamības trūkumu automātiski saukt par jauna regulējuma nepieciešamību: IUB uzsvēra konkrētā iepirkuma apstākļus, bet Finanšu ministrija norādīja uz jau esošo iepirkuma tiesību elastību.910

Tāpēc prasību, pierādījumu, pieņemšanas un līguma seku dizains ir atsevišķā rakstā Kiberdrošība publiskajos IKT iepirkumos. Šeit iepirkums ir sākuma robeža; centrā ir pierādījumu ķēde pēc piegādes un visā turpmākajā dzīves ciklā.

NIS2 riska pārvaldības sistēmā ir iekļauta piegādes ķēdes drošība un tīklu un informācijas sistēmu drošība iegādes, izstrādes un uzturēšanas procesos.11 Atsevišķām NIS2 aptvertajām vienībām Komisijas Īstenošanas regula (ES) 2024/2690 konkretizē prasības attiecībā uz ICT produktu un pakalpojumu iegādes drošību un piegādātāju pārvaldību.12

Savukārt Kibernoturības akts noteiktajā produktu ar digitāliem elementiem tvērumā paredz produktu un komponentu dokumentēšanas prasības, tostarp programmatūras sastāva saraksta sagatavošanu.13

No tā tomēr neizriet, ka ES tiesības prasītu vienu universālu valsts IKT laidienu reģistru vai vienu centrālu pierādījumu manifestu.

Šie instrumenti drīzāk parāda kopējo virzienu: tehniskajam dzīves ciklam, piegādes ķēdei un drošības lēmumiem jākļūst arvien pārbaudāmākiem. Konkrētais valsts pārvaldības modelis joprojām jāprojektē atbilstoši vietējām sistēmām, kompetencēm un informācijas aizsardzības režīmam.

Ja esošo procesu kartējums parāda, ka saiti nav iespējams droši atjaunot, es sāktu ar ļoti mazu datu kopu:

Dažām sistēmām vajadzēs vairāk. Citām — mazāk.

Pilota mērķis nav maksimizēt datu daudzumu. Mērķis ir pārbaudīt, vai ar minimālu, drošu un samērīgu informāciju var uzticami atbildēt uz galveno jautājumu.

Tehniskā izsekojamība ļoti viegli var pārvērsties par vēl vienu formālu slogu, ja mērķis tiek aizmirsts.

Nevajadzētu izveidot centrālu sensitīvu tehnisko pierādījumu noliktavu tikai tāpēc, ka “auditam viss jābūt vienuviet”. Nevajadzētu prasīt vienu Git, build vai SBOM identifikatoru piegādes modeļiem, kuros tam nav jēgas. Nevajadzētu arī pieņemt, ka lauku aizpildīšana pati par sevi pierāda izsekojamību.

Labs tests ir vienkāršs: vai ieraksts palīdz citai kompetentai personai rekonstruēt faktisko tehnisko stāvokli un tā saiti ar pieņemto rezultātu?

Ja nepalīdz, mums ir vairāk metadatu, nevis vairāk kontroles.

Publiskā IKT pārvaldībā viegli izmērīt to, kas ir redzams administratīvajā procesā: projekta numuru, līgumu, finansējumu, pieņemšanas datumu. Daudz grūtāk ir saglabāt pārbaudāmu saiti ar mainīgo tehnisko realitāti.

Tieši šī saite kļūst svarīga incidentā, auditā, piegādātāja maiņā, sistēmas atjaunošanā un pēc vairākiem gadiem, kad sākotnējā projekta komanda vairs nav pieejama.

Tehniskā izsekojamība tāpēc nav aicinājums radīt vēl vienu dokumentu. Pareizi izveidota, tā dara pretējo: izmanto jau esošos ierakstus un pievieno tikai tik daudz sasaistes, lai valsts varētu pierādīt ne vien ko tā bija nolēmusi izdarīt, bet arī ko tā patiesībā pieņēma un ekspluatēja.

Raksta normatīvais un publiskās politikas statuss pārbaudīts 2026. gada 25. septembrī. Institūciju individuālās atbildes ir autora korespondences primārie dokumenti; tās nav interpretētas kā vispārsaistoši tiesību skaidrojumi.

Šis raksts ir tehniskas un pārvaldības prakses analīze, nevis individuāla juridiska konsultācija.