Cybersecurity in Public ICT Procurement: From Contract Clauses to Verifiable Outcomes

Cybersecurity requirements can look technically similar while serving different procurement-law functions.

Latvian public procurement law already provides several distinct mechanisms.1

Collapsing these categories creates avoidable problems.

A supplier-level organisational property may be placed incorrectly as a product specification. A mandatory minimum may be converted into a vague points-based quality criterion. A lifecycle obligation may appear in a technical description but never become an enforceable contract condition.

A “Security Annex” in this article is therefore only an organising concept.

It is not a separate legal instrument defined by Latvian or EU procurement law.

Latvia's Public Procurement Law allows technical specifications to include functional or performance requirements, security provisions, testing rules and conformity-assessment methods.1

That gives public-sector cybersecurity a useful starting point.

A weak requirement might say:

“The solution shall be developed in accordance with secure-development best practice.”

A more verifiable requirement might say:

“Before acceptance, the supplier shall provide the agreed security-assessment result for the version proposed for acceptance, including material findings, their status and retest evidence for findings whose remediation was an acceptance condition.”

The second sentence is not automatically appropriate for every procurement.

It still needs scope, proportionality and precise definitions.

But the contracting authority can at least see what needs to be checked.

A common procurement shortcut is to choose the evidence first.

For example:

“The supplier must hold certificate X.”

A named certification may be a valid and proportionate form of evidence in some contracts.

In others, it may be too broad, too narrow or unnecessarily restrictive.

Latvia's Public Procurement Law provides mechanisms for testing reports, certificates and other evidence in defined circumstances, together with rules on equivalent evidence.1

The safer design sequence is therefore:

risk → requirement → outcome → proportionate evidence

rather than:

certificate → search for a reason to require it.

This matters for competition as much as for security.

The goal is not to weaken cybersecurity for smaller suppliers. It is to avoid making suppliers pay for evidence that does not materially improve assurance for the specific contract.

Secure by Design is a useful principle.

Procurement needs to turn it into deliverables.

For a higher-risk development contract, proportionate evidence might include:

• documented trust boundaries;
• authentication and authorisation design;
• material data flows;
• dependency-management approach;
• secret-management model;
• defined security-testing scope;
• status of material findings;
• identity of the release proposed for acceptance;
• retest results where remediation was required.

Not every item belongs in every contract.

They do not need to be packaged into one giant document either.

The important property is this:

before the contract is signed, the authority knows what an acceptable security result will look like.

A functionally complete system is not automatically a security-acceptable system.

That does not mean the contract should require “zero vulnerabilities”. Such a requirement is usually unrealistic and can create bad incentives.

A more mature acceptance model distinguishes:

a remediable nonconformity;

known residual risk;

an acceptance blocker;

a temporary compensating measure;

the authority authorised to accept the residual risk.

For example, a particular high-risk procurement may define in advance that a specified class of unresolved finding blocks acceptance unless a named role approves a documented temporary mitigation and remediation date.

That is not a universal legal threshold.

It is an example of turning security risk into a predefined contract decision instead of a last-day dispute between the project manager and supplier.

For a material requirement, one sentence is often not enough.

This does not require a new document bureaucracy.

It simply prevents the procurement from reaching acceptance with everybody interpreting the same requirement differently.

Consider a requirement for privileged administrative access.

Weak version:

“The supplier shall ensure secure administrator authentication.”

More testable version:

“Production administrative access shall use the contracting authority's approved multi-factor authentication control. Before acceptance, the authority shall verify that production administrative accounts do not retain an active alternative authentication path that bypasses the required MFA control, except for a separately governed emergency-access mechanism.”

Now the procurement can define:

verification — configuration review plus a controlled authentication test;

evidence — configuration record and test result;

failure — acceptance remains open or a predefined exception process is used;

lifecycle trigger — a material identity-platform change requires reassessment.

The words “MFA required” have now become something the authority can actually accept and later verify.

For organisations within the scope of Latvia's Cabinet Regulation No. 397, the outsourcing and supply-chain provisions already contain detailed requirements.2

Paragraphs 87–90 require, among other things:

• defined outsourcing scope and quality requirements;
• monitoring rights and access to necessary information, including logs;
• supplier incident-notification and response duties;
• information about subcontractors and flow-down of applicable requirements;
• defined system/security testing;
• return or deletion of data at contract end;
• maintenance, support and security-defect-remediation periods for relevant development/change contracts;
• assessment of outsourcing and supply-chain risks;
• an outsourcing exit strategy.2

This changes the policy question.

The problem should not be framed as though Latvia has no cybersecurity requirements for relevant public-sector outsourcing.

The practical question is:

how are applicable legal duties translated early enough into the actual procurement documents, contract obligations, delivery evidence and acceptance process?

On 21 August 2026, IUB replied to my procurement submission. It said the proposals would be considered within its methodological work, while stressing that individual requirements must always be assessed against the particular procurement object, objective, risks and facts. IUB also said that, in its view, difficulty in structuring procurement requirements was not a generally widespread problem but could arise in particular cases.4

The reply also stated that IUB was then developing guidance on the application of cybersecurity requirements in public procurement and would take the submitted suggestions into account.4

On 22 September, IUB publicly announced the new guidance.3 It addresses the application of Cabinet Regulation No. 397 from a procurement perspective, including practical questions about Security Intelligence Service (SAB) opinions, negative opinions, information to include in procurement documentation and the acquisition of technical resources for Class A information systems.3

The chronology is documented.

It does not establish that my submission caused the guidance or determined its content. IUB had already stated that the material was under development.

The more useful conclusion is that the translation of cybersecurity regulation into procurement practice is now concrete enough in Latvia to have dedicated methodological guidance.

The Latvian Ministry of Finance replied on 27 August 2026 and positively assessed the intention to improve traceability, verifiability and consistent inclusion of cybersecurity requirements in ICT procurement.5

It also made an important qualification: the existing Public Procurement Law is already sufficiently open and flexible to support the proposed type of approach, while the content of specific cybersecurity requirements must be assessed in relation to the procurement object and other material circumstances.5

That is an important skeptical counterweight.

If existing procurement law already supports functional requirements, evidence, quality criteria and contract-performance obligations, the first problem may not be missing legislation.

It may be requirement engineering.

Since 9 June 2026, Section 2.^1 of Latvia's Public Procurement Law requires contracting authorities to take responsibility for procurement effectiveness and maintain internal controls across the procurement lifecycle, from preparation through contract performance.1

That provision should not be overread as a direct statutory requirement for a cybersecurity acceptance framework.

It does, however, fit an important governance principle.

A material security requirement should not disappear once the award decision is made.

Internal control should be able to follow whether the requirement:

• entered the correct procurement document;
• was evaluated where relevant;
• became a contract obligation;
• was verified during delivery;
• informed acceptance;
• continues to operate during contract performance.

That is a stronger security model than proving only that the requirement existed in the tender.

Directive 2014/24/EU permits technical specifications based on functional or performance requirements, award criteria linked to the subject matter of the contract and contract-performance conditions.8

The Directive also limits that flexibility.

Award criteria must permit effective competition and be accompanied by specifications that allow the information supplied by tenderers to be effectively verified. Contract conditions must remain linked to the subject matter of the contract.8

That is a useful constraint for cybersecurity.

The authority should not copy everything it knows about security into the tender.

It should select what matters for the actual contract outcome.

NIS2 includes supply-chain security and relations with direct suppliers and service providers among the cybersecurity risk-management measures for entities within its scope.9

The 2026 EU ICT Supply Chain Security Toolbox adds a common, non-binding and actor-agnostic method for identifying and mitigating ICT supply-chain risks across public and private sectors.10

This is useful procurement context.

A supplier questionnaire is still not a control by itself.

If a supplier says:

“Yes, we manage subcontractor risk.”

a higher-risk contract may still need to define what that means.

Are material subcontractors identifiable?

Must changes be notified?

Do security requirements flow down?

Who retains incident-cooperation duties?

What happens to data and access at termination?

Is there an exit path?

Supply-chain assurance becomes real when a general governance claim is converted into contract obligations and evidence.

Not every security characteristic is pass/fail.

Latvia's Public Procurement Law permits quality criteria linked to the subject matter when identifying the most economically advantageous tender.1

That creates room, in suitable higher-risk ICT procurements, to evaluate objectively measurable security quality above a mandatory baseline.

This is also easy to misuse.

Points should not be awarded for vague statements such as:

“Our company takes cybersecurity very seriously.”

Nor should document volume itself earn points.

A quality criterion needs to be defined, comparable and verifiable.

Depending on the contract, that might concern a measurable support model, security-update capability, exit characteristic or technically verifiable architecture feature.

The specific criterion still has to be designed for the procurement at hand.

My 2026 submissions proposed a modular architecture rather than one universal template.67

Possible modules included:

Security baseline

Applicable obligations, security objective, access model, auditability and baseline configuration.

Secure by Design / Secure SDLC

Used where development or material modification justifies evidence about architecture, trust boundaries, dependencies and testing.

Security testing and acceptance

What will be tested, which version, how material findings are handled, and when retesting is required.

Vulnerability and incident cooperation

Reporting channels, triage, fixes, escalation and supplier support during incidents.

Supply chain

Material subcontractors, critical dependencies, access, material changes and replaceability.

Support, patching and EOL

Support period, security updates, end-of-life notification and unsupported-component risk.

Exit and continuity

Data/configuration handover, access revocation, secret rotation, outstanding security work and transition support.

The purpose of modularity is to avoid imposing the full catalogue on a low-risk commodity purchase.

Procurement security answers:

What were we supposed to receive, and how would we accept it?

Technical traceability — addressed separately in Public ICT Traceability: From Approval to Production — asks a later question:

Can we prove that the accepted version, configuration and security result are the same state that actually reached production and continued to change under control?

The problems are related but not identical.

Good procurement defines the expected state.

Good traceability proves the actual state.

A material security requirement can be expressed in a compact record:

This is not a statutory form.

It is designed to prevent three ordinary failures:

1. the requirement exists but nobody knows how to test it;
2. evidence is delivered but nobody knows which requirement it proves;
3. a nonconformity is known but nobody knows who may accept the risk.

A useful final review is not “Do we have enough cybersecurity requirements?”

Ask instead:

If the last three questions have no answer, the security requirement is probably unfinished.

Cybersecurity in public ICT procurement is not measured by how often the tender uses the word security.

It depends on whether the authority can connect five things:

risk, requirement, evidence, verification and decision.

Latvian public procurement law already provides mechanisms for technical and functional requirements, evidence, quality criteria and contract-performance conditions. Cabinet Regulation No. 397 already creates substantial outsourcing and supply-chain obligations for entities within its scope. IUB's new 2026 guidance shows that translating those duties into procurement practice is an active methodological issue.3

A new universal document is therefore not necessarily the answer.

The harder and more useful discipline is this:

for every material security requirement, know in advance what verifiable performance looks like and what happens when the supplier does not achieve it.

Legal and institutional status was checked on 25 September 2026. “Security Annex”, “security acceptance”, “cybersecurity requirement architecture” and the requirement record are the author's methodological concepts, not independent legal institutions created by Latvian procurement law. The later publication of IUB guidance is not presented as evidence that the author's submission caused or determined that guidance.

This article analyses public procurement, cybersecurity assurance and technical acceptance practice. It is not individual legal advice.