Government Threat Intelligence Procurement: A Practical Guide

A government threat intelligence procurement should describe a service that the institution can test, operate and leave. A catalogue containing millions of indicators does not establish whether an analyst can explain a result, whether a shared SOC may redistribute it, or what happens when a source withdraws an incorrect assessment.

This guide proposes technical evaluation criteria for UK and European public institutions. It is not a set of mandatory procurement clauses. The examples are fictional, and the responsible procurement, security, information-governance and legal teams must adapt the requirements to their institution and purchasing process.

ENISA's baseline procurement guidance, published in 2017, treats security across the purchased service's lifecycle. It provides technical context, not a statement of current procurement law. The CTI specification and test cases below are our proposed implementation method.

Define the service boundary before requesting offers

Describe who consumes the intelligence and what they are authorised to do with it. A council investigating staff-reported phishing needs different evidence and delivery arrangements from a shared security service supplying blocklists to several institutions. Combining both under one undefined threat intelligence requirement hides differences in rights, latency and operational responsibility.

Use a short service statement. In our fictional example, a shared SOC enriches domain and IP alerts for three participating public bodies. Analysts review the results before any network change. The supplier receives approved indicators through an API; it does not receive complete incident records or decide which connection to block.

Name each participating organisation, its operator and the systems consuming results. An outsourced SOC, a neighbouring authority and a temporary incident-response contractor are different recipients. Their inclusion should be explicit rather than inferred from the word partnership.

Use the PIR and collection-plan workbook to resolve an unclear decision need. For this specification, retain the resulting use cases, data boundaries, operating hours and named service owner. They determine which supplier claims matter.

Write requirements that produce an acceptance decision

Replace adjectives such as actionable or comprehensive with behaviour and evidence. Ask for the meaning of a verdict, its supporting observations, relevant dates and correction mechanism. An undocumented confidence score cannot become comparable merely because two providers both express it on a hundred-point scale.

A proposed requirement record can use this structure:

Reference: CTI-07
Need: identify when a domain assessment changes
Required behaviour: expose a stable record identifier,
assessment time, current status and a correction mechanism
Supplier evidence: schema, example records, correction workflow
Acceptance test: retrieve a supplied test record before and after correction
Expected result: the consumer detects and records the change
Reviewer: SOC integration owner
Exception: documented limitation, impact, owner and review date

The example does not prescribe one API design. A replacement record, an update endpoint or a documented withdrawal event may satisfy the need if the consuming system can process it reliably. State the required outcome and let the supplier explain its mechanism.

Distinguish unavailable evidence from contradictory evidence. A missing observation date must remain visibly missing. It should not be replaced silently by the retrieval date. Our guide to evaluating threat intelligence sources explains why provenance and claim boundaries matter when interpreting results.

Map what the institution sends and what comes back

Draw the data path before agreeing that an integration is low risk. Include the client, connector, service endpoint, upstream enrichment, support tooling, logs, backups and exported reports. A query can reveal investigative interest even when its indicator appears publicly elsewhere.

Ask the supplier to explain whether submitted values are retained, forwarded, made searchable, used to improve datasets or included in other customers' results. Separate normal operation from troubleshooting: a support ticket may contain a much richer payload than the API request it discusses.

Record where each relevant category is processed and stored, which organisations can access it, and what changes require notification or approval under the agreed arrangement. A hosting-region label alone does not answer questions about support access, subcontractors, backups or secondary processing.

Test minimisation with a fictional case. If an analyst needs domain reputation, submitting an entire URL with a case reference and access token can disclose more than the task requires. Define what the connector removes, what it preserves for investigation and where the original remains. The guide to private URL scanning and analyst OPSEC develops that submission decision.

Create a separate handling route for material that cannot enter the service. The existence of a convenient API should not silently expand its approved data boundary.

Obtain written answers about use and redistribution rights

A technically accessible dataset is not automatically licensed for every intended use. Present the supplier with concrete recipient and processing scenarios, and ask for an answer linked to the applicable agreement. Keep unresolved rights questions visible during evaluation.

For the fictional shared SOC, the rights schedule should address:

• automated ingestion and local caching by the operating team;
• display of supporting evidence in each participating body's case records;
• derived alerts or blocklists delivered to those bodies;
• sharing selected findings with an authorised response contractor;
• retention of relevant evidence after the subscription ends;
• removal or separation of material when an institution leaves the arrangement.

Distinguish the supplier's own assessment from upstream material bundled with it. Ask which rights the supplier can grant, which restrictions pass through, and how a source-specific restriction is represented in exports. One broad statement about the platform may conceal several different data licences.

Request an explanation of how the supplier establishes that it can collect and supply the datasets offered. Public visibility, technical access and authority to redistribute are separate questions. Unclear upstream rights should become an explicit procurement issue with an owner, rather than an assumption made by the integration engineer.

Handling markings also need to survive export. The TLP sharing guide covers distribution boundaries; the service's contractual rights need their own record. Ask how the connector prevents those instructions from disappearing when an analyst copies a finding into a ticket.

Match supplier assurance evidence to the purchased service

The NCSC supply-chain assessment guidance addresses procurement, risk and security teams establishing supplier assurance. It supports examining the relationship through its lifetime, rather than relying on the initial questionnaire alone.

Build an evidence request around your service boundary. Relevant material can include an architecture diagram, administrative-access controls, incident procedures, assessment scope, remediation status and a demonstration of tenant separation. Identify which claim each item supports. A policy document demonstrates an intended process; a recent, scoped test can provide different evidence about its implementation. For support connections, use the third-party remote access workflow to define the person, task, scope and duration.

For any certificate or assessment, verify the organisation, service, date, scope and exclusions. If the purchased API sits outside the assessed environment, the evidence does not automatically extend to it. Ask how material findings are tracked and who accepts outstanding risk.

Identify dependencies that could interrupt or change the service: a hosting provider, an identity platform, a critical upstream feed or an outsourced support team. The purpose is to understand consequences and escalation, not to demand unlimited disclosure of every commercial relationship.

In the evaluation record, distinguish supported, partly supported and unsupported claims. A confident sales answer should not overwrite a missing artefact. Give each unresolved item a consequence: further evidence, a bounded condition before acceptance, a reduced scope or rejection according to the buyer's stated process.

Run a service acceptance exercise with failure cases

Use an isolated test consumer and approved sample data. Agree the expected outcomes before the demonstration, and keep the production service protected while testing. Supplier-provided fixtures are useful for checking mechanics; they do not establish real-world detection coverage.

Start with ordinary retrieval. Verify authentication, pagination, record identifiers and field interpretation. Interrupt a multi-page fetch and confirm whether the consumer can resume without silently losing records or multiplying the same evidence. Record the test configuration so a later reviewer can repeat it.

Next change a test assessment. Confirm that its previous status remains explainable and that the current state reaches the consumer. If a withdrawal needs a full resynchronisation, measure and document that dependency. An update visible in the supplier's portal but absent from the operational feed has not completed the required workflow.

Test an unknown indicator and a failed request separately. The local application should distinguish no result, unavailable service and an assessment of low risk. An HTTP success response is not by itself proof that the requested intelligence exists.

Exercise access boundaries with authorised test accounts. Check that a user for one institution cannot retrieve another institution's private case material, where the service stores such material. If it does not, record that boundary rather than inventing a tenant-isolation requirement for a dataset that is public to all subscribers.

Finish with a correction or outage notification. The test should reach the actual operational recipient and identify the affected function. Save the observed result, remaining defects and acceptance decision. A screenshot of the supplier dashboard cannot substitute for evidence that the consuming workflow behaved as agreed.

Make service interruption and change manageable

Specify availability, freshness and support response separately. An endpoint can answer requests while serving stale data. A supplier can acknowledge a ticket while the service remains unavailable. Define where each measurement starts and ends, and which party can observe it.

Agree what the consumer does when freshness exceeds the accepted limit. It might retain dated evidence for investigation, suspend new automated imports or require manual review. The right response depends on the use case; automatically replacing every control with an empty list can introduce a different failure.

Ask how changes to fields, authentication, quotas and upstream coverage are communicated. Include a route for urgent changes and a way to test planned ones. Identify the institution's owner for connector updates, because supplier notice alone does not implement a fix.

Cost and operational value belong in the separate threat intelligence feed ROI benchmark. Acceptance establishes that the agreed service works; it does not prove that the purchase delivers sufficient value.

Rehearse the exit while the supplier is still available

ANSSI's outsourcing guidance, published in 2010, uses a security-assurance approach to express context-specific expectations of a provider. It is methodological background, not a current procurement-law template. The following exit rehearsal is a proposed CTI-specific exercise.

Choose a representative case and export the information that the institution is entitled to retain. Check whether another analyst can still distinguish the original observation, supplier assessment, correction history, local annotation and handling restriction. A file containing only the final risk score may be readable but inadequate for explaining an earlier decision.

Record what cannot be exported or kept. Agree the treatment of caches, connector credentials, scheduled jobs, support copies and material held by subcontractors. An instruction to delete everything can conflict with an agreed need to preserve investigation evidence; resolve that question before termination with the responsible teams.

Name the migration owner, dependencies, assistance required and expected costs. Rehearse credential revocation after the replacement path works. Request the agreed evidence of closure and record any residual retention with its reason and end condition. Identify these copies before the rehearsal, while their owners can still answer questions.

Give the decision-maker a traceable purchasing record

Present the proposed service, verified requirements, unresolved exceptions and operating responsibilities together. Link each acceptance result to its requirement. Keep security suitability, commercial value and procedural approval as distinct decisions with their appropriate owners.

Use a decision-oriented CTI briefing to explain the important trade-offs without reproducing the entire technical pack. An exception should show what remains unknown, who accepts its consequence and when it will be revisited.

An IsMalicious reputation report can provide an indicator lookup to examine during an authorised evaluation. Assess it against the same evidence, handling and acceptance criteria as any other candidate. A defensible purchase leaves the institution able to explain what it bought, what it verified and how it will respond when the service changes.