Can Public-Sector ICT Prove What Was Approved, Built and Actually Deployed?

Most mature public organisations already keep extensive records. They know which project was authorised, who owned it, what budget was approved, which supplier delivered it and when the contract milestone was accepted.

Technical teams keep another set of records: repositories, release tags, build artefacts, change requests, deployment events, service versions, configuration states and operational inventories.

The difficult part is not producing more records. It is being able to traverse the gap between them.

A useful traceability chain looks conceptually like this:

approved activity → governed system or service → accepted technical result → deployment/change record → operational state → controlled evidence reference

The chain does not require the same technology in every organisation. It does require the transitions to remain reconstructable.

A recurring governance error is to let administrative completion stand in for technical identity.

Sometimes all four states align cleanly. Sometimes an emergency fix is deployed after acceptance. A managed service provider may change a component. A SaaS vendor may update the service without exposing a traditional release artefact. A configuration may drift. This is why “project completed” is not a technical identifier.

The test can be kept deliberately simple:

1. Which approved activity or change does this technical result belong to?
2. What exactly was accepted?
3. What exactly was deployed or activated?
4. What existing record proves the link between the accepted result and the operational state?
5. Could another competent person reconstruct the chain a year later without relying on one supplier or one administrator?

If the organisation can already answer these questions reliably, adding another horizontal control may be unnecessary.

If it cannot, the next step should still not be “create a new registry”. The first step should be to find where the existing chain breaks.

A public governance layer does not need copies of every artefact used to prove a technical state.

Source code belongs in a repository. Detailed deployment records belong in an appropriate delivery or operations system. Vulnerability evidence may need a restricted security environment. Secrets and access material should obviously not be copied into a governance register. A supplier’s internal evidence may remain within the supplier environment while still being referenced through a controlled assurance mechanism.

The design principle I use for this is references over replication: the central layer should carry only the information needed to identify the governed object and reach the relevant evidence under the correct access controls.

In its smallest useful form, that may be little more than an activity identifier, a system identifier, an accepted-result identifier, an operational-version identifier, dates, ownership and a controlled evidence reference.

The search for a universal manifest is attractive because it promises simplicity. It also tends to confuse different forms of evidence.

An SBOM can be extremely useful. It does not, by itself, establish that the SBOM describes the same technical result that a customer accepted and that the same result was running on a particular date.

A Git commit does not prove deployment. A signed acceptance document does not prove runtime state. A deployment log does not prove that the deployed result was the contractually accepted one.

The useful property is the link between those records, not the existence of any one of them in isolation.

A rule that works for custom-developed software can be meaningless for SaaS.

For a bespoke application, an organisation may be able to identify a repository, commit, build, signed artefact and deployment event. In a managed cloud service, the customer may never see those identifiers. In commercial off-the-shelf software, a vendor version and installation inventory may be the useful anchor. In a fully managed service, the relevant point may be a service version, change ticket or configuration state.

The requirement should therefore not be “every public system must store a Git SHA”.

The requirement, where justified, should be that the organisation can identify the technical result appropriate to the delivery model and connect it to acceptance and operation.

During an incident, “what is running?” is not an accounting question.

A newly disclosed vulnerability may affect only certain versions or components. An investigation may need to establish whether a vulnerable component was present at the time of compromise. If responders can see only the version that was supposed to be deployed, they may be investigating the wrong state.

Emergency remediation creates the reverse problem. A temporary configuration or hotfix may be introduced under pressure. After the incident, someone needs to determine whether that change was reverted, formalised or quietly became part of the long-term production baseline.

Technical traceability therefore supports incident investigation, recovery and vulnerability management as well as audit.

Changing suppliers exposes weak traceability very quickly.

If the incoming team receives documentation but cannot establish the actual production state, transition starts with discovery and reverse engineering. That increases cost and operational risk. It can also leave the previous supplier with an effective monopoly over knowledge that the customer should be able to reconstruct.

The customer does not need to own every internal supplier tool. It does need enough evidence to understand what it is taking over.

That is why traceability is also part of reducing avoidable supplier dependency.

Latvia provides a useful case because the question entered an active public-sector ICT governance reform rather than being discussed only as an abstract architecture principle.

In June and July 2026, the Latvian government publicly set out a reform agenda focused on stronger lifecycle oversight, transparent project management, better public-sector ICT capability and more open competition in procurement.12

On 11 August 2026, I submitted a proposal to the Ministry of Smart Administration and Regional Development (VARAM) in connection with TAP project 26-TA-1866. The proposal did not assert that Latvian regulation lacked traceability. It asked a narrower question: can the existing governance, VIRSIS registration, acceptance and technical delivery records already reconstruct the link between an approved development activity and the result actually operating in production?3

The proposal recommended mapping the existing process first. Only if that exercise revealed a material gap would a limited pilot add a minimal, technology-neutral traceability link. It explicitly rejected the idea of creating a central repository for source code, vulnerability details, full security-test outputs or other sensitive technical evidence.

VARAM replied on 13 August. The ministry said it had found particularly useful the aspects concerning the identifiability of development results and their linkage to technical results actually produced. It also said that the new public ICT resource development governance framework was expected to include requirements supporting the link between a development activity and the software created or developed, including information on the code repository and software versions placed into operation.8

That response should not be overstated. It does not mean that the entire proposal was adopted, nor does it guarantee the final wording of a future framework. It does show that the specific gap between governance records and technical-result identity was recognised as a useful design issue in the reform process.

The case is also useful because it shows why “build a new registry” would have been the wrong starting point.

Latvian Cabinet Regulation No. 368 already provides a governance process for information-system development activities, including registration, change requests and completion reporting, as well as mechanisms for checking actual implementation against an approved activity description.4

Cabinet Regulation No. 89 governs the state information resources, systems and interoperability information system, including the registration and management of public digital resources and services.5 Regulation No. 367 provides general technical requirements for information systems.6

VARAM’s April 2026 public-sector DevOps guidelines further promote standardised, secure and auditable software development and operation, including lifecycle management, automation, quality control and security checks.7

The policy question is therefore not whether records exist. It is whether those layers can be connected efficiently enough to reconstruct the real technical outcome.

Procurement defines what the authority expects to receive and how acceptance will be decided. Technical traceability asks a later question: can the authority prove which accepted artefact, configuration and evidence actually reached production?

Latvian institutional responses in 2026 also argue against treating every traceability gap as a missing-law problem: the Procurement Monitoring Bureau emphasised the circumstances of the specific procurement, while the Ministry of Finance pointed to the flexibility already available under procurement law.910

The procurement-side design — requirements, evidence, acceptance and contract consequences — is therefore handled separately in Cybersecurity in Public ICT Procurement. Here procurement is an input boundary; the subject is the evidence chain after and across delivery.

NIS2 requires covered entities to apply appropriate and proportionate cybersecurity risk-management measures, including supply-chain security and security in network and information-systems acquisition, development and maintenance.11 For the categories of entities within its defined scope, Commission Implementing Regulation (EU) 2024/2690 adds more detailed requirements around acquisition and supplier risk management.12

The Cyber Resilience Act, within its product scope, also increases the importance of structured product and component information, including software bill of materials obligations for manufacturers.13

These instruments support a wider move toward evidence-aware lifecycle governance. They do not create a universal EU requirement for governments to operate one central release ledger or one common technical-evidence manifest.

That distinction matters. A traceability model should be designed because it solves a governance and operational problem, not because unrelated regulatory concepts can be assembled into a supposed mandate.

Where mapping shows a real gap, the smallest useful pilot could start with only a few fields.

Different systems may need more or less.

The success criterion should not be the number of populated fields. It should be whether another competent person can use the recorded links to reconstruct the actual technical state, its history and its relationship to the approved and accepted work.

Traceability can easily turn into compliance theatre.

A central system should not collect sensitive technical material merely because “audit evidence should be in one place”. One release identifier should not be imposed on delivery models where it has no meaning. An SBOM should not be treated as proof of deployment. A completed metadata field should not be treated as proof that the underlying evidence still exists or is accessible.

The useful test is more demanding:

Does the record allow another competent person to reconstruct the technical state and verify its relationship to the accepted result?

If not, the organisation has created more metadata, not more control.

Public-sector ICT is usually good at recording administrative milestones. The harder task is preserving a verifiable relationship with technical reality as systems continue to change.

That relationship matters during incidents, audits, supplier transitions, vulnerability response and recovery. It also matters years later, when the people who originally delivered the system are no longer available.

Technical traceability should therefore not begin with a new form. It should begin with a reconstruction test: can the organisation prove what was approved, what was accepted and what actually ran?

If the existing evidence already answers that question, leave it alone.

If it does not, add the smallest link that makes the chain reconstructable.

Legal and public-policy sources were re-checked on 25 September 2026. Individual institutional replies cited below are primary documents from the author’s correspondence archive; they are not presented as generally binding legal interpretations.

This article is an analysis of technical and governance practice, not individual legal advice.