Cybersecurity

Threat Intelligence Platform (TIP) RFP Template (Free)

Paste-ready threat intelligence platform requirements (feeds, STIX/TAXII, enrichment, scoring, sharing, SIEM/SOAR/EDR integration), vendor questions and a weighted scoring rubric.

15 pages Microsoft Word ★ 4 of 5 13522 downloads Updated October 9, 2026
Download Template
Threat Intelligence Software RFP Template

Preview the first pages

See the structure before you download. The Word file has every section listed below, ready to fill in.

Open preview Give feedback

What's inside

The sections in the document, in order.

  1. How to run a Threat Intelligence Platform RFP
  2. Threat Intelligence Platform RFP requirements
  3. Questions to ask Threat Intelligence Platform vendors
  4. Scoring rubric
  5. Frequently asked questions
  6. Related RFP templates

Use this threat intelligence platform RFP template when you need one place to collect intelligence from commercial feeds, open sources, sharing communities and your own investigations, turn it into scored, de-duplicated intelligence, and send it to the SIEM, SOAR, EDR and network controls that act on it.

It covers both the platform (TIP) and any intelligence sources you buy with it, and it's written for the threat intelligence, security operations and procurement team running the evaluation: when to issue an RFI first, the requirements to send, the questions that separate vendors, and how to score the answers.

Many SIEM, XDR and SOAR products now include basic threat intelligence management, so the template also helps you decide whether a separate platform is worth buying.

What’s inside this template

  • A step-by-step plan for running the evaluation, starting from your intelligence requirements, with an example schedule and advice on when to issue an RFI first
  • Requirements for feed ingestion, normalization, STIX/TAXII, enrichment, scoring and expiry, analyst workflow, sharing and distribution to security tools, each marked Must-have or Nice-to-have
  • Requirements for intelligence you buy from the vendor: collection methods, validation, finished reporting and analyst access
  • Questions that test indicator quality, false-positive handling, integration depth, data leaving your tenant and roadmap-only AI features
  • A weighted scoring rubric with 1-to-5 definitions
  • An editable Word RFP with response codes, a pricing table and a timeline

Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.

How to run a Threat Intelligence Platform RFP

A threat intelligence platform is only as useful as the questions it answers and the tools it feeds, so start from your intelligence requirements and your integration list rather than a feature list. The example schedule in this template runs about 12 weeks from kickoff to contract award; allow more if you're choosing commercial intelligence sources at the same time, or if several SOC teams take part in the proof of value.

  1. Define your intelligence requirements (weeks 1-2). List the questions intelligence must answer for each team that uses it: SOC triage, incident response, threat hunting, detection engineering, vulnerability management, fraud and leadership. Note the threats that matter most to you, such as the actors and ransomware groups that target your sector and regions. Then record the numbers vendors will price against: the sources you already receive, expected indicator volume, analyst users and the tools that must receive intelligence.
  2. Assemble the buying team. Include threat intelligence analysts, SOC and incident response leads, detection engineering, the owners of the SIEM, SOAR, EDR and network controls that will consume intelligence, and vulnerability management. Bring procurement and legal in early: feed licenses often limit how intelligence may be shared with subsidiaries, managed security providers and sharing communities, and that can rule vendors in or out.
  3. Settle the scope, and decide whether you need an RFI (weeks 2-4). Decide whether you're buying a platform, intelligence sources or both, and whether the threat intelligence features already in your SIEM, XDR or SOAR are enough. If that's still open, or your long list has more than five vendors, issue a short RFI asking how each vendor ingests your current sources, which tools it sends intelligence to, how it scores and expires indicators, and how it prices. Use the answers to build a shortlist.
  4. Tailor and issue the RFP (weeks 4-7). Delete requirements that don't apply, adjust priorities, and add your sources, integrations and intelligence requirements to Section 1. If you're buying only the platform, delete requirements F15 to F17 and the vendor-intelligence lines in the pricing table. Give vendors three weeks to respond, with a written question-and-answer window in the first week.
  5. Score the responses (weeks 7-8). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. Check every 'yes' for whether it needs an add-on license, a connector maintained by someone other than the vendor, or a feature still in preview.
  6. Run a proof of value with two or three vendors (weeks 8-11). Connect the same sources to each platform, including at least one commercial feed, one open-source feed and one TAXII collection from a sharing community, and send the output to a test SIEM and one blocking control. Check how many indicators survive de-duplication and scoring, whether any known-good infrastructure gets through, how quickly expired indicators leave downstream lists, and how fast an analyst can get from an alert to the related actor, campaign and techniques. Call references with a similar team size.
  7. Negotiate and award (weeks 11-12). Use the pricing table to compare like for like, including connector charges, volume limits and intelligence add-ons. Settle sharing rights in feed licenses, renewal caps and data export before you sign, not after.

Threat Intelligence Platform RFP requirements

Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.

Functional

ID Requirement Priority
F1 Ingestion of intelligence from commercial feeds, open-source feeds, information sharing and analysis centers (ISACs and ISAOs) and government sharing programs, via TAXII 2.1, STIX 2.1, CSV, JSON, RSS and vendor APIs, on a schedule we set per source. List the sources with pre-built connectors, and state support for older STIX 1.x and TAXII 1.x sources. Must-have
F2 Extraction of indicators (IP addresses, domains, URLs, file hashes, email addresses) and CVE IDs from unstructured sources such as PDF reports, web pages and emails, with analyst review before extracted items are published. State whether threat actors, malware names and ATT&CK techniques are also extracted. Must-have
F3 Normalization of all sources into one data model, with de-duplication across sources that keeps the provenance of every object: which sources reported it, when it was first and last seen, and the confidence and markings each source assigned. Must-have
F4 Automatic enrichment of indicators from internal and external services, such as passive DNS, domain registration data, IP geolocation and network owner, TLS certificate data, malware sandbox results and our own sightings, with control over which external services are queried for each source or marking. Must-have
F5 Configurable scoring of indicators that combines source reliability, confidence, age, corroboration by other sources, enrichment results and sightings in our environment, with the reasons for each score visible to analysts. Must-have
F6 Expiry rules by indicator type and source (for example, IP addresses expiring sooner than file hashes), with expired, revoked or false-positive indicators removed automatically from every detection and blocking list the platform feeds. Must-have
F7 Filtering of known-good infrastructure before intelligence reaches blocking controls, including our own domains and IP ranges, shared hosting and content delivery networks, cloud provider ranges and widely used domains, with allowlists we can edit. Must-have
F8 Objects for threat actors, campaigns, malware families, tools, vulnerabilities and attack patterns, linked to indicators and mapped to MITRE ATT&CK techniques, with search and a graph view that let analysts pivot from an indicator to everything related to it. State support for the ATT&CK Enterprise, Mobile and ICS matrices. Must-have
F9 Analyst workflow: investigations or cases, notes, tasks, tags and assignments, source reliability and information credibility ratings (for example, the Admiralty Code), and a history of every analyst change to an object. Must-have
F10 Recording of our intelligence requirements, such as priority intelligence requirements (PIRs), with sources, reports and indicators linked to each one, so we can see which requirements are covered and where collection gaps remain. Nice-to-have
F11 Production of finished intelligence from templates for tactical, operational and strategic audiences, with TLP markings carried into the output, export to PDF or HTML, and distribution to named groups. Must-have
F12 Sharing of selected intelligence with ISACs, partners and subsidiaries as STIX 2.1 over TAXII 2.1, with Traffic Light Protocol (TLP 2.0) markings and per-recipient rules for which objects and fields are shared, so internal notes and sightings stay internal. Must-have
F13 Reporting on the value of each source: indicators contributed, overlap with other sources, matches with our telemetry, false-positive reports and how early the source reported compared with others, to support renewal decisions on paid feeds. Nice-to-have
F14 AI assistance, such as summaries of reports, actors or indicators and questions asked in plain language, with citations to the underlying intelligence, an administrator setting to turn it off, and a statement of where models run and whether our data is used for training. Nice-to-have
F15 If the proposal includes the vendor's own intelligence: a description of collection sources and methods, coverage by region, sector and threat type, update frequency and how indicators are validated before publication, plus finished reports (actor, campaign and vulnerability exploitation reporting) with indicators and ATT&CK techniques attached as STIX 2.1. Must-have
F16 Access to the vendor's analysts for custom questions (often called requests for information), with the number of requests included per year and the expected turnaround. Nice-to-have
F17 Monitoring of criminal forums, marketplaces, paste sites and messaging channels for our domains, brands, leaked credentials and executives. Make this Must-have if you are not buying a separate digital risk protection service. Nice-to-have

Technical and architecture

ID Requirement Priority
T1 Delivery as [SaaS / self-hosted in our cloud / on premises]. State which deployment models are offered, which features differ between them, and whether an air-gapped deployment with offline updates is available. Must-have
T2 Choice of the region where intelligence, enrichment results, analyst work and logs are stored, to meet data-residency requirements. Must-have
T3 Capacity for our expected volumes [sources, indicators per day, stored objects, analyst users], with published limits on stored objects, ingestion rate, API calls and searches, and evidence of performance at that scale. Must-have
T4 A data model based on STIX 2.1 objects and relationships, or a documented mapping to it, that imports and exports intelligence, including custom properties and markings, without losing data. Must-have
T5 A documented availability design, backups and recovery objectives, and documented behavior of the lists the platform sends to our controls if the platform is unavailable (for example, whether controls keep the last list they received). Must-have
T6 Configurable retention of intelligence, sightings and analyst history, with expired intelligence archived and still searchable rather than deleted, unless we choose otherwise. Must-have
T7 Separate workspaces for business units, subsidiaries or sensitive investigations, with rules for which intelligence flows between them. Make this Must-have if you are a managed security provider or a group with separately run subsidiaries. Nice-to-have

Integration

ID Requirement Priority
I1 Single sign-on with our identity provider via SAML 2.0 or OIDC, with user and group provisioning via SCIM. Must-have
I2 Two-way integration with our SIEM [name]: curated indicators sent as watchlists or lookup tables, and sightings (matches in our data) returned to the platform so they inform scoring and investigations. Must-have
I3 Integration with our SOAR and case management tools: enrichment lookups from playbooks, and creation or update of intelligence from incident findings. Must-have
I4 Distribution of indicators to EDR/XDR, firewalls, secure web gateways, DNS security and email security, with per-destination rules on indicator types, minimum score and TLP marking, and an optional approval step before indicators are used for blocking. Must-have
I5 A documented REST API covering all objects and actions, and a TAXII 2.1 server so our tools can pull curated collections. State API rate limits. Must-have
I6 Storage and export of detection rules in open formats such as Sigma and YARA, linked to the related actors, malware and techniques. Nice-to-have
I7 Vulnerability context for our vulnerability or exposure management tool: CVEs linked to exploitation evidence, threat actors and campaigns, plus public known-exploited vulnerability catalogs and exploit prediction scores such as EPSS. Nice-to-have
I8 Notifications to our ticketing (ITSM) and team chat tools when new intelligence matches our intelligence requirements, assets or watched terms. Nice-to-have

Security and compliance

ID Requirement Priority
S1 A current SOC 2 Type II report and ISO/IEC 27001 certification covering the proposed service, available under NDA. Must-have
S2 FedRAMP authorization at the required impact level, or equivalent regional certifications for public-sector use. Make this Must-have if you are a public-sector buyer. Nice-to-have
S3 Access control by role and by data: limits on which users and integrations can see intelligence by TLP marking, source, collection or workspace, so restricted intelligence (such as TLP:AMBER+STRICT or TLP:RED) reaches only permitted people and tools. Must-have
S4 Enforcement of TLP markings and feed license restrictions on every export, share and integration, with a block or warning when restricted intelligence is included. Must-have
S5 Protection of our operational security: a list of the third-party services that receive our indicators or searches, controls to stop specific sources or markings from being sent to them, and a contractual statement of whether the vendor uses our intelligence, sightings or searches for any other purpose, with a way to opt out. Must-have
S6 Administrator and analyst access through SSO with MFA, and an audit log of configuration changes, analyst edits, exports and shares. Must-have
S7 Isolation of our tenant's data, encryption in transit and at rest, and a documented key-management approach. State whether customer-managed keys are offered. Must-have
S8 A data processing agreement, a current list of sub-processors, support for our privacy obligations (intelligence can contain personal data such as email addresses and leaked credentials), and a contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. Must-have

Implementation and support

ID Requirement Priority
M1 An onboarding plan covering connection of our current sources, migration of existing intelligence with its history and markings, integration setup, and design of scoring, expiry and distribution rules with our analysts, with named roles and the effort expected from both sides. Must-have
M2 Identification of who delivers the implementation (vendor, partner or both) and the named team's experience with deployments of similar scope. Must-have
M3 A service-level agreement for availability of the platform and its TAXII and API endpoints, with service credits. State how availability is measured. Must-have
M4 Support with response-time targets by severity, including out-of-hours support for problems that stop intelligence reaching our controls. State the hours and targets. Must-have
M5 Maintenance of feed connectors and integrations when third-party products or APIs change, with stated timelines. Identify any connectors maintained by partners or the community rather than the vendor. Must-have
M6 Advance notice of changes to the data model, scoring, API or integrations that could change what reaches our controls, with a deprecation period for API changes. Must-have
M7 Training for analysts and administrators, including how to tune scoring and distribution rules, plus a named customer success contact and periodic reviews of how sources and integrations are used. Nice-to-have

Commercial and pricing

ID Requirement Priority
C1 Pricing broken down by platform, analyst seats, connectors or integrations, intelligence sources and term, showing list price, discount and net price, plus prices for adding seats, sources or modules mid-term, co-terminated with the main agreement. Must-have
C2 A statement of which third-party feeds need a separate subscription from their provider, and which intelligence, if any, is included in the platform price. Must-have
C3 Any limits on stored objects, ingestion volume, API calls or users in the proposed edition, and the charges or actions that apply if we exceed them. Must-have
C4 A cap on price increases at renewal, covering the platform and any intelligence subscriptions. State the cap. Must-have
C5 License terms that state whether purchased intelligence may be shared with our subsidiaries, managed security providers acting for us and sharing communities, and under which markings. Must-have
C6 A proof of value at no charge, including trial access to the proposed intelligence sources. Nice-to-have
C7 Exit terms covering export of all intelligence, sightings, analyst notes, reports and history in STIX 2.1 or another documented format, and transition assistance at the end of the contract. Must-have

Questions to ask Threat Intelligence Platform vendors

These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.

  1. Connect three of our current sources [list] during the demo. How long does it take, what changes during normalization, and how do analysts see which sources reported each indicator?
  2. Show how one indicator's score was calculated. Which inputs can we change, and how does the score change when our SIEM reports a sighting or an analyst marks the indicator as a false positive?
  3. How do you keep known-good infrastructure, such as content delivery networks, cloud provider ranges and our own domains, out of the block lists you send to our controls? Show the default allowlists and how we edit them.
  4. What are your default expiry rules for IP addresses, domains, URLs and file hashes? Show an expired or revoked indicator being removed from a SIEM watchlist and a firewall block list, and tell us how long that takes.
  5. Which integrations with our SIEM, SOAR, EDR and firewalls [list] are built and maintained by you, which by partners or the community, and which would need custom work? Show sightings flowing back from our SIEM.
  6. Which third-party services see our indicators or searches during enrichment? Can we keep selected sources or markings inside our tenant, and do you use our intelligence, sightings or searches for anything other than serving us?
  7. Import a PDF threat report we provide. Show which indicators, CVEs, malware and ATT&CK techniques are extracted, how an analyst corrects mistakes, and what gets published.
  8. Share a set of objects with a sharing community over TAXII 2.1. Show how you select them, how TLP markings and feed license restrictions are enforced, and how internal notes and sightings are kept out.
  9. Starting from an alert on a single domain, show how an analyst reaches the related actor, campaign, malware and ATT&CK techniques, and what evidence supports each link.
  10. If you propose your own intelligence: how is it collected, how are indicators validated before publication, and how much of it is original rather than gathered from public sources? Provide a recent week of indicators and a recent finished report relevant to our sector.
  11. Show your reporting on source value for one of our feeds: unique contribution, overlap with other sources, matches in our telemetry and false-positive reports. Which of these measures are available today?
  12. Which AI features are in your proposal? Show a generated summary with its sources cited, and tell us where the models run, what data they see, and whether our data is used for training.
  13. We're moving from [our current platform or shared repository]. How do you migrate existing intelligence with its history, markings and analyst notes, and what can't be migrated?
  14. Which features in your proposal are generally available today, and which are in preview or on the roadmap? Give dates for the roadmap items.
  15. Provide a reference customer with a similar team size that sends intelligence from your platform to blocking controls in production. How do they catch and reverse false positives?

Scoring rubric

Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.

Criterion Weight What a strong response shows
Collection, normalization and scoring 20% Your own sources connected in the proof of value, de-duplication that keeps provenance, scores an analyst can explain, and expiry that works.
Integration and distribution to security tools 20% Maintained two-way integrations with your SIEM, SOAR, EDR and blocking controls, per-destination rules, and revoked or expired indicators removed downstream.
Analyst workflow and finished intelligence 15% Quick pivoting from an indicator to related actors, campaigns and ATT&CK techniques, accurate extraction from unstructured reports, and usable case and reporting tools.
Sharing, data handling and security 10% TAXII 2.1 sharing with TLP 2.0 markings and license restrictions enforced, clear control over what leaves your tenant, and current certifications.
Intelligence content (if purchased) 10% Original, validated intelligence relevant to your sector and regions, sample data that holds up under review, and machine-readable reports. If you're buying only the platform, move this weight to integration.
Implementation and support 10% A credible onboarding and migration plan, an experienced named team, vendor-maintained connectors and clear support targets.
Commercials and total cost 15% Transparent pricing for the platform and each source, clear volume limits, fair sharing rights, a renewal cap and a three-year view.
Total 100%

Scoring scale

  • 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
  • 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
  • 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
  • 2 Weak: misses one or more Must-haves, or the answer is vague.
  • 1 Poor: does not meet the requirement, or no answer.

Frequently asked questions

What should a threat intelligence platform RFP include?

Your intelligence requirements and the teams that use intelligence; the sources you'll connect and the tools that must receive intelligence; requirements for ingestion, normalization, enrichment, scoring and expiry, analyst workflow, sharing and integration, each marked Must-have or Nice-to-have; requirements for any intelligence you're buying from the vendor; security, data-handling and support terms; a pricing table; and the rubric you'll score with. This template includes all of them.

What is the difference between a threat intelligence platform and a threat intelligence feed?

A feed is a source: a stream of indicators, and often reports, from a commercial provider, an open-source project, a government program or a sharing community. A threat intelligence platform (TIP) is the software that collects many feeds and your own findings, de-duplicates and scores them, gives analysts context, and sends the useful part to your security tools. Many vendors sell both, so decide whether you're buying the platform, the intelligence or both, and ask for separate prices.

Do we need a threat intelligence platform if our SIEM or XDR already includes threat intelligence?

Not always. Many SIEM, XDR and SOAR products now include threat intelligence features that ingest feeds and match indicators against your data, and that can be enough if you use a few sources and have no dedicated intelligence analysts. A separate platform is worth evaluating when you combine many paid and community sources, have analysts who write finished intelligence, share with partners or sharing communities, or need to send one curated set of intelligence to several different tools. You can score your current tools against this template alongside standalone platforms.

What are STIX and TAXII?

STIX (Structured Threat Information Expression) is a standard format for describing threat intelligence: indicators, malware, threat actors, campaigns, attack patterns and the relationships between them. TAXII (Trusted Automated Exchange of Intelligence Information) is the protocol for exchanging STIX data over HTTPS. Both are OASIS standards; require version 2.1 of each so you can exchange intelligence with sharing communities and take your data with you if you change platforms.

How long does a threat intelligence platform RFP take?

The example schedule in this template runs about 12 weeks from kickoff to contract award, including three weeks for vendor responses and three to four weeks for a proof of value. Allow more time if you're selecting commercial intelligence sources at the same time, or if legal review of feed licensing and sharing rights is new to your organization.

Related RFP templates

Download Template

More cybersecurity templates