How to write IoT procurement requirements

Most IoT tenders are decided before they are published, by the requirements document. Requirements that describe a product favour the vendor who sells that product. Requirements that describe outcomes and ownership leave control with the buyer. We write these documents for public buyers, and the same five clauses decide almost every tender.

1. Ownership of code and documentation

State that the code, the configuration, and the documentation are the buyer’s property, delivered continuously into the buyer’s repository during the work.

A requirement that vendors cannot talk their way out of looks like this:

The supplier shall deliver all source code, infrastructure definitions, and technical documentation to the buyer’s version control system at the end of each sprint. The buyer holds all rights to the delivered material.

Access to the code, or code held in escrow, does not meet this requirement. If a vendor objects to the clause, you have learned something worth knowing before the contract is signed.

2. Data ownership and readable formats

Sensor data outlives platforms. A municipality keeps readings for legal retention, for analysis, and for the next system. The requirements must state that all data is stored in documented, open formats, and that a full export is available at any time, without cost and without proprietary tooling.

The test is practical: can your own analyst query the history with standard tools? If reading the data needs the vendor’s client software and a current licence, the buyer depends on that vendor to read its own records.

3. The exit clause

Tenders rarely evaluate the exit. Add a requirement on handover: on termination, the supplier delivers a running system, complete documentation, and a defined transition period, at a price stated in the contract. A handover price fixed in the contract prevents punitive pricing at the point of exit.

4. Infrastructure portability

Require that the platform runs on infrastructure the buyer chooses, including a move to a different provider. Infrastructure as code makes this verifiable: ask for the deployment definitions as a deliverable, and ask bidders to state how long a redeployment takes and what it costs. The answer then becomes a commitment in the bid.

5. NIS2 as requirements

Under NIS2 and Sweden’s Cybersäkerhetslag, the obligations sit with the buyer. Write them into the tender as requirements on the supplier: access control, logging, incident reporting within the legal timelines, and supply-chain transparency. A general question about NIS2 compliance gets a general yes. Require the specific capabilities, and require evidence.

Write verifiable requirements

A requirement is only a requirement if it can be verified. “The platform shall be user-friendly” cannot be tested. “An operator shall be able to add a new sensor type to the data model without supplier involvement” can. For each clause, write down how you will test it during the project, and put the test in the contract.

This also keeps the tender competitive. Verifiable, vendor-neutral requirements let more suppliers bid, which holds the price down and lets smaller firms answer, including firms that build systems to order.

The short version

Write requirements on ownership, readable data, exit, portability, and NIS2 capabilities. Make every requirement testable. Keep supplier-specific feature names out of the document.

We write requirement specifications for public IoT tenders under LOU and equivalent EU frameworks, and we stay off the supplier side of any tender we help shape. See procurement requirements support, or the Swedish page on kravspecifikation för IoT-upphandling.