Sourcing external data for a public tender: a practical guide

External data increasingly sits at the centre of tenders and RFPs, from smart-meter consumption in a utilities programme to mobility data in a transport contract. Yet the data requirement is often the least defined part of the bid. This guide sets out how to move from a vague data line item to a compliant, deliverable supply model.

1. Translate the outcome into a data requirement

Buyers rarely need “data” in the abstract; they need a specific outcome: a forecast, a service, a dashboard, a model. Start by writing down the decision the data must support, then work backwards to the variables. Capture data type, geography, historical depth, volume, refresh frequency, required structure, quality thresholds and the privacy constraints that apply. A precise requirement is what makes availability assessment and pricing possible.

2. Assess availability early

The fastest way to lose time in a tender is to assume a dataset exists at the coverage and cadence you need. Before committing language to a bid, test availability across commercial providers, public sources, specialist networks and direct acquisition routes. Where a suitable dataset is already available, the project can move quickly; where it is not, you need to know that while there is still time to adjust scope.

3. Structure the supply model around the project, not the supplier

A tender response should describe how data will be delivered in operational terms: the format, the cadence, the interface and the quality criteria. The underlying supplier is an implementation detail. Keeping supplier identities confidential by default also protects competitive positioning: what the buyer needs is the licensing, provenance and compliance information, not the vendor’s name.

4. Build compliance into the response

Public procurement and regulated industries expect clear data governance. Document the legal basis for using the data, how privacy will be handled, and how delivery will be controlled. Responsible sourcing, documented delivery terms and, where required, anonymisation or pseudonymisation should be described as part of the supply model, designed to support GDPR and EU Data Act requirements, with governance practices aligned with NIS2 and ISO/IEC 27001 principles.

5. Make the commercial model transparent

Evaluators reward clarity. Separate the three cost components: the underlying third-party data cost, the sourcing and acquisition commission, and any value-added services such as transformation, anonymisation or real-time delivery. A transparent structure is easier to score and easier to defend in a procurement audit.

6. De-risk the timeline with synthetic data

When final production data requires additional sourcing or approvals, synthetic or anonymised datasets let development, integration and testing begin immediately, so the delivery team is not idle while procurement completes. This is often the difference between a credible delivery plan and an optimistic one.

What evaluators actually score

Procurement panels rarely reward the most data; they reward the clearest, most credible plan to deliver the right data. In practice that means scorers look for: a requirement that is specific and testable, evidence that the data exists and can be lawfully used, a delivery model expressed in operational terms, a transparent commercial structure, and a realistic timeline. Vague promises (“we will source suitable data”) score poorly; a concrete supply model with acceptance criteria scores well. Writing the bid with the evaluator’s scoring grid in mind, not just the narrative, is what separates winning data sections from filler.

Structuring the data section of a bid

A strong data section follows the supply lifecycle and answers the panel’s implicit questions in order: what data, at what coverage and cadence; how its availability has been assessed; how it will be licensed and its provenance evidenced; how it will be transformed, anonymised or synthesised where needed; how it will be delivered and operated; and how the commercial model breaks down. Presenting it as a clear flow, with a small diagram or table, makes it easy to score and easy to defend in an audit.

A tender data checklist

• Is the data requirement defined in measurable terms (type, geography, depth, volume, cadence, quality, privacy)?
• Has availability been tested before the bid commits to it?
• Are licensing, provenance and compliance evidenced, with suppliers confidential by default?
• Is the delivery model (format, interface, cadence, SLAs) described operationally?
• Are the three commercial components separated and auditable?
• Does the timeline use synthetic or available data to de-risk the critical path?