Which threat intelligence platform RFP questions matter most before you hire
If your organization must run threat intelligence on its own infrastructure, the platform itself is rarely the hard part. MISP and OpenCTI are both open source, so the evaluation turns on the implementer's work: which feeds get configured, how sharing rules are enforced, how indicators reach detection tools, how false positives are aged out, which OpenCTI features require the Enterprise Edition, and who keeps the connectors working after handover. A partner who cannot answer those questions in writing has not yet shown you how the platform will run in your environment. These questions apply whether the partner works with MISP, OpenCTI or both.
Send the same written questions to every candidate so the answers can be compared line by line. Require each answer to refer to the scope the parties agree in writing, since fixed-scope engagements only hold together when deliverables are named. Ask for a sample configuration or runbook, not a slide. Look for specifics such as which sharing groups and distribution levels will be created, how the distribution and sharing_group_id fields are set on imported events, which export formats feed your firewall and sensors, and what the handover covers. Vague answers about how the team will handle these items are a warning sign. Ask the candidate to name the component, setting or decision behind each answer, and to say what you must provide, such as the sharing agreements or the list of consuming tools.
Questions to ask about feeds, sharing, detection and maintenance
Which feeds and connectors will you configure, and who decides which ones we keep?
The partner should configure only the feeds your intelligence requirements justify, and your team should approve each one in writing. For MISP, default feeds ship with the platform and can be enabled or disabled, but each feed adds indicators that need curation, so ask for a list of enabled feeds, their licenses and their refresh schedules. For OpenCTI, ask which connectors are installed for import, enrichment and export, and which external services they call. A good answer names each feed or connector, its purpose, the account or key it needs, and who owns its failure alerts. Ask also how paid feeds are licensed and whether the partner will hold those contracts or you will.
How will you set up sharing groups and distribution levels in MISP?
The partner should map each sharing rule to a MISP distribution level and, where needed, a custom sharing group, and document the mapping before any event is created. MISP supports distribution levels and custom sharing groups down to individual attributes, so ask how attribute-level exceptions will be governed and who may create them. Ask for the written rule set, a test showing that an event marked for one group does not sync to another, and the process for changing a sharing group later. Also confirm which Traffic Light Protocol labels your team will use and where they are stored in the event, so analysts know what they may forward.
How do indicators reach Suricata, Zeek, Wazuh and our SIEM?
Indicators should leave the platform through defined export formats and a tested transport, not through manual copying. MISP can export Suricata, Snort, Zeek and RPZ formats, and its API with restSearch and PyMISP can feed other tools. OpenCTI exposes a GraphQL API and stream connectors. Ask the partner to show each path: which format goes to which sensor, how often it refreshes, how a rule is removed when an indicator expires, and how the SIEM receives matches as alerts. Ask also for a sample of a failed export and the alert that would notify your team. Confirm the exact version of each detection tool with its vendor or your own environment before the design is fixed.
How do you age out false positives and stale indicators?
A sound process gives every indicator an expiry, a confidence level and an owner who reviews hits. In MISP, attributes can carry expiry settings and the correlation engine helps show where an indicator recurs, but tuning rules are a human decision. Ask the partner to describe the review cycle, the threshold for demoting an indicator, and how a false positive is recorded so it is not re-imported by the next feed run. Ask who approves removal from a blocking rule, and how fast a blocked legitimate service can be restored. Ask for the written criteria, not only a description of the tool.
Which OpenCTI features need the Enterprise Edition, and what does it cost us?
The Community Edition is licensed under Apache License 2.0, and the Enterprise Edition is licensed under the separate OpenCTI Enterprise Edition License, so features gated behind that license need a paid agreement with Filigran. Ask the partner to list every feature in your design, mark which edition provides it, and cite the Enterprise Edition documentation for each. Ask whether any required connector, LTS support or analytics module is Enterprise-only. Cost depends on the subscription terms set by the vendor, so request the current price from Filigran or the reseller in writing and ask the partner to show which requirements depend on that decision.
Who maintains our connectors after go-live, and how are they updated?
The partner should own the upkeep of every custom or configured connector, and the contract should say so. Ask who tracks upstream changes to each connector, how security patches are tested in a staging copy, and who approves the upgrade. Confirm whether connectors are community-maintained, vendor-maintained or built by the partner, because that changes who fixes a broken release. Ask for a connector inventory with versions, a rollback procedure and the support window. Whether support is a one-time handover or an ongoing retainer should be clear in the written scope.
How do upgrades and LTS licensing work for OpenCTI?
OpenCTI uses date-based versions, and LTS releases need a specific LTS license key to use. The docs describe LTS releases every six months, each supported for one year, with critical bug and security fixes only after a one-month stabilization. Ask the partner which release line they will deploy, who holds the LTS key, how the key is renewed and where it is stored. Ask for the upgrade plan for MISP too: MISP 2.4 is end of life with security fixes only, and MISP 2.5 is the recommended line for new deployments. Ask how the upgrade will be tested before production.
How is intelligence data protected, retained and kept within our control?
The partner should document where data is stored, who can read each sharing group, how long events and logs are kept, and how backups are encrypted. Self-hosting in your own environment keeps the platform under your control, but the partner must show the access model, the authentication path and the audit trail. Ask whether personal data can appear in indicators and how it is minimized or removed. Ask also how the data plan maps to the access and audit rules in your regulated scope, and which items your auditors will need as evidence. Confirm each control with your assessor, because DeployOpen prepares evidence but does not issue audit reports.
How the questions change between MISP and OpenCTI
MISP is built to collect, store, distribute and share indicators, so the RFP questions centre on who sees what and how data moves between instances. Ask the partner to show how distribution levels and custom sharing groups are configured down to the attribute level, and how those settings are tested before any event leaves the organization. Synchronization with partner and community instances needs its own questions, because a misconfigured sync can publish more than intended.
- Distribution and sharing groups: Ask how distribution levels are mapped to your TLP and sharing agreements, and who approves new sharing groups.
- Synchronization: Ask which instances will sync, under what filters, and how a sync failure or unexpected publication is detected and reversed.
- Export and integration: Ask which formats (such as STIX, Suricata, Snort, Zeek or RPZ) will feed detection tools, and who maintains the rules generated from them.
- Version line: MISP 2.5 is the recommended line for new deployments and 2.4 is end of life, so ask the partner to confirm the version and upgrade path.
Confirm that the partner will document sharing rules in writing and test them against sample events before go-live.
OpenCTI organizes data on a knowledge schema based on the STIX2 standards and exposes it through a web application and GraphQL API, so its RFP questions focus on modeling, connectors and the supporting services. A partner should explain how the schema will be used for your intelligence requirements and how connectors for import, enrichment and export are chosen and maintained. Because the platform depends on several services, sizing and resilience questions carry more weight than they do for a single sharing hub.
- Dependencies: Ask how Elasticsearch or OpenSearch (the documentation lists 8.0 or OpenSearch 2.9 or later), Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage will be deployed, backed up and upgraded.
- Workers and connectors: Ask how many Python workers and connectors are planned, and who monitors the RabbitMQ queues that carry asynchronous writes.
- Sizing: Ask for the sizing basis, since the documentation gives minimum figures per component and recommends at least one platform node for every 3 workers.
- Version lines: Ask whether the partner will run a regular release or an LTS line, and how LTS license keys are obtained and renewed.
- Edition: Ask which features need the Enterprise Edition and what that license costs in your case.
Confirm the connector maintenance plan in writing, since connectors often change faster than the core platform.
Day-to-day upkeep differs between the two platforms, and the RFP should ask who carries it after handover. MISP runs on a PHP application with CakePHP, MySQL or MariaDB and Redis, while OpenCTI runs a larger service set that must be kept in step. Both need patching, backups and upgrades, and the partner should show how each task is scheduled, tested and documented for your operations team.
- MISP stack: Ask how PHP, MySQL or MariaDB and Redis versions are patched, and whether the partner uses the provided installer, Docker images, Ansible roles or RPM packages.
- Database changes: Ask how database migrations are tested before upgrades, since MISP 2.5.47 introduced a new migration system with PostgreSQL support.
- OpenCTI services: Ask how Elasticsearch or OpenSearch, RabbitMQ and storage are monitored, and who responds when a worker queue backs up.
- Release cadence: Ask how often the partner reviews new releases and how security fixes reach production.
- Handover: Ask what runbooks, dashboards and access the partner hands over at the end of the project.
Confirm the upgrade and rollback procedure for each platform before comparing proposals.
The two platforms carry different licensing questions, and the RFP should not treat them as interchangeable. MISP is licensed under AGPL-3.0, with taxonomies and galaxies under separate permissive terms, and OpenCTI has a Community Edition under Apache-2.0 and an Enterprise Edition under a proprietary license. Partners should explain how each license affects your obligations, modifications and support options.
- MISP licensing: Ask how the AGPL-3.0 terms affect any modifications you or the partner make, and how taxonomies and galaxies under CC0 1.0 or BSD-2-Clause are tracked separately.
- OpenCTI editions: Ask which features are only in the Enterprise Edition and whether your use case depends on them.
- Project governance: Ask how the partner monitors upstream project decisions, since MISP's contributors hold interlocked copyright and OpenCTI is developed by Filigran.
- Support: Ask who provides vendor support for each platform and what the partner covers in its own retainer.
Confirm the license position for each component in writing before procurement signs off.
Vendor answers that should worry you
A partner's answers to the questions in this RFP reveal whether the platform will be run as a service or sold as a license. The cards below cover the answers that should slow a decision down, because each one usually shows up later as a sharing failure, a stale feed, a broken connector or an unexpected license bill.
No written sharing model
If a vendor cannot show how sharing groups, distribution levels and TLP markings are set up, the first event shared with a partner community may expose more than intended. MISP supports distribution levels and custom sharing groups down to individual attributes, so a good answer names the groups, who approves membership and how the defaults are set on each instance. Ask for the written model before any feed or sync is configured.
Unnamed proprietary connectors
Promises of a connector that the vendor will not name, or that exists only in its own tooling, make the integration impossible to review or maintain. Ask for the exact connector name, its source repository, its license and the version of MISP or OpenCTI it targets. Every feed, enrichment and export path should be listed with its owner, so the team knows what runs in production and who fixes it.
No false positive removal plan
Indicators age, and a feed that never retires them will flood detection tools with stale or wrong matches. Ask how the vendor sets expiry or decay on indicators, how analysts mark false positives, and how those markings reach the SIEM, firewall and sensor rules that consume them. A vague answer such as monitoring the feed usually means no one owns the cleanup.
Vague OpenCTI Enterprise claims
OpenCTI Community Edition is Apache-2.0 licensed, while the Enterprise Edition is governed by its own proprietary license. A partner that cannot list which features need the Enterprise Edition, or that says everything is included, has not read the license. Ask for a written feature matrix, the license terms that apply to each feature, and the cost of the subscription that is paid to the vendor.
No owner for connector updates
Connectors, the platform and its dependencies all change on their own schedule. OpenCTI's non-LTS releases ship from daily to weekly, and LTS releases get only critical and security fixes after stabilization, so an unpatched connector can break ingestion without warning. Ask who tests each upgrade, who holds the LTS license key if one is used, who is on call when a connector fails, and what the written support terms cover.
License purchase, not a run process
A vendor that prices the platform as a license and treats delivery as finished at go-live has not planned for operations. Feeds need curation, sharing groups need governance, indicators need expiry rules and dependencies such as Elasticsearch, Redis, RabbitMQ and object storage need patching and capacity reviews. Ask for the run book, the recurring tasks, who performs them and what they cost after the first year.
How to score answers and ask for evidence
Score every answer from the RFP on four criteria: specificity, named components, written ownership and evidence offered. An answer that says the partner will "integrate the feeds" scores low. An answer that names the feed sources, the connector or import method for each, the MISP or OpenCTI version it targets and the person who signs off on the configuration scores high. Use a simple scale for each criterion, record the reason next to every score, and treat any answer without a named owner as incomplete, however polished it reads.
Reward precision on versions and licenses, because errors here predict later problems. MISP 2.4 is end of life with security fixes only, and the project recommends MISP 2.5 for new deployments, so a partner proposing a new 2.4 instance has not kept up. OpenCTI Community Edition is Apache License 2.0, while sharing features such as those in the Enterprise Edition fall under the separate OpenCTI Enterprise Edition License, and an LTS release requires a specific license key. Ask the partner to state the exact release line, the license tier of each component and whether any connector is community-maintained. A vague answer about "the latest version" should lower the score, and the partner should confirm the current release on the MISP download page and the OpenCTI product life cycle before contracting.
Ask for four artifacts before shortlisting. First, a sample runbook covering how a new feed is onboarded, tested, assigned a distribution level and retired. Second, a connector inventory listing each feed and integration, its source, version, maintainer, license and update owner. Third, a sharing group matrix showing which organizations, communities and distribution levels can see which attributes. Fourth, a false positive review procedure with aging rules, reviewers and how removals reach downstream tools. Score each artifact on whether it is dated, versioned and signed off by a named role. Illustrative example: a sharing matrix with no owner column is a draft, not evidence.
How to run the evaluation from shortlist to contract
This sequence turns a shortlist of implementation partners into one written, comparable answer set and a fixed-scope proposal. Each step narrows the decision and ends with a document or check that the buying group can sign off before any contract is signed.
Define intelligence consumers and sharing communities
Before any partner sees the question set, the security lead, the SOC manager and the compliance owner agree who will consume intelligence, which tools need indicators (SIEM, firewall, network sensors, SOAR), and which sharing communities the organization expects to join. Legal or the sector compliance owner confirms the distribution and TLP rules that apply to outgoing and incoming data. The output is a one-page requirements note that every shortlisted partner receives with the same questions, so their answers can be compared directly.
Send the question set to each shortlisted partner
Send the same written question set to every shortlisted partner at the same time, covering feeds and connectors, sharing groups and distribution levels, indicator flow to detection tools, false positive aging, OpenCTI edition needs and connector maintenance. Ask each partner to name the people who will do the configuration and the people who will maintain connectors after go-live. The step is complete when every partner has acknowledged receipt in writing and a single point of contact has been named on each side.
Review written answers against the requirements note
The buying group scores each written answer against the requirements note, marking gaps, vague wording and answers that depend on a third party. Pay close attention to whether a partner states which OpenCTI features require the Enterprise Edition license, and which connectors they build versus which they only recommend. Ask follow-up questions in writing for any unclear answer. The step closes with a scored comparison sheet and a short list of partners to invite into a working session.
Run a scoped working session on sharing and detection flow
Hold a working session with the shortlisted partners using a fixed agenda: how MISP or OpenCTI will hold sharing groups and distribution levels, how an indicator moves from the platform to a detection tool, and how a false positive is found, reviewed and removed. Ask the partner to walk through a sample indicator end to end using a non-sensitive example labeled as illustrative. The output is a session note that records each open decision and who owns it.
Request a fixed-scope written proposal
Ask the remaining partners for a fixed-scope written proposal built from the requirements note and the session decisions. The proposal should list deliverables, the systems in scope, the connectors and feeds to be configured, the integrations to the SIEM and other tools, responsibilities on each side, and the handover items. Ask for the cost components to be separated into one-time work, recurring support and any third-party licenses or feeds the organization buys directly. The step is complete when each proposal can be read against the same scope without guessing.
Compare proposals on scope and recurring costs
The buying group compares the written proposals line by line against the requirements note, looking for missing connectors, unclear sharing governance, unassigned curation work and unstated license costs for OpenCTI Enterprise or paid feeds. Ask each partner to confirm in writing what happens when an upstream connector changes or breaks. The result is a decision record that explains why the preferred partner was chosen and which assumptions must be confirmed before signing.
Confirm connector ownership and handover before work starts
Before the contract is signed, agree in writing who owns each connector, feed subscription, API key and configuration file, and who receives administrator access at handover. Confirm the maintenance responsibilities after the initial rollout, including upgrades, and how the partner will document the setup for the internal team. The step is done when the ownership table is attached to the contract and both sides have signed off the handover plan.
What the cost questions should ask a partner to price
Start with the fact that shapes every quote: MISP is free software under AGPL-3.0, and OpenCTI has a free Community Edition under Apache License 2.0. The license fee is therefore zero for the core platforms, and what you pay for is the infrastructure that runs them, the connector and integration work that connects them to your tools, the feeds you subscribe to, the analyst time spent curating indicators, and any OpenCTI Enterprise subscription. Ask the partner to show each of these as a separate line item in writing, not as a single platform figure, because each one recurs differently and each one responds to different decisions in your scope.
Infrastructure is where OpenCTI quotes diverge most. A deployment needs Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO, plus the platform nodes and worker capacity that the deployment overview sizes. Ask the partner to state the node counts, the storage volume assumed for your indicator retention, whether high availability is included, and who pays for the cloud or data center capacity. For MISP, ask for the equivalent database and cache sizing and whether the installer on Ubuntu 24.04 is used or a containerized or configuration-management approach is proposed. Confirm the source of every cloud or hardware cost, since the partner should not be the party that pays for it.
Connector work, feed subscriptions and curation are the recurring cost that surprises most buyers. Ask whether the quote covers building and testing each connector to your SIEM, firewall and SOAR, who maintains connectors after each platform release, and what happens when a connector breaks during a version upgrade. Ask which paid feeds are priced in the quote and which you license directly, and whether analyst curation is a one-time setup or a monthly retainer. Finally, if OpenCTI Enterprise is in the design, ask the partner to name the features that require it and to price the subscription separately, with the license terms confirmed against the OpenCTI Enterprise Edition documentation before you sign.
Scoring criteria for vendor answers
This table lists the criteria to test in a partner's answers, with what a strong answer looks like and the evidence to request. Use it to check whether each response is specific to a self-hosted MISP or OpenCTI deployment or only describes the product in general terms. Answers that cannot produce the listed evidence should be treated as unverified until they can.
| Criterion | What good looks like | Evidence to request |
|---|---|---|
| Sharing model | Sharing groups and distribution levels are designed per community and applied down to individual attributes, with TLP handling written into the process | Sample sharing group map, distribution level policy, and a test event showing restricted attributes do not sync to unauthorized peers |
| Detection integration | Indicators reach Suricata, Zeek, SIEM and firewall tools through exports or APIs, with named owners and a tested update path | Export format list in use, integration diagram, and a recent end-to-end test from MISP or OpenCTI to a detection tool |
| False positive aging | A written rule sets how long an indicator stays active, how it is retired, and who approves removal of contested data | Aging and expiry configuration, the review cadence, and a sample change log showing retired indicators |
| Edition scope | The partner states which OpenCTI features need the Enterprise Edition and prices or plans them separately from the Community Edition | Feature-by-feature edition matrix tied to the OpenCTI Enterprise Edition documentation, and the license key ownership record |
| Connector ownership | Each feed and connector has a named maintainer, update procedure and a documented fallback when upstream code changes | Connector inventory with versions, maintainer roles, and the last update record for each connector |
| Upgrade and LTS handling | The plan follows the platform's published release model, with test environments and a rollback step for each upgrade | Current release line in use, upgrade runbook, and confirmation of OpenCTI LTS license requirements where LTS is chosen |
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted MISP or OpenCTI inside your own cloud accounts, data centers or air-gapped networks. The work starts with a written scope that answers the partner questions on this page, so feeds, sharing rules and integrations are settled before anything is connected.
How we scope
- Written scope listing feeds, sharing communities, connectors and detection targets before any build starts
- Distribution levels, TLP markings and sharing group design agreed with your data owners in writing
- Confirmation of which OpenCTI features your scope needs and whether any require the Enterprise Edition
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
How we build
- Deployment of MISP or OpenCTI with dependencies such as Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage
- Configuration of feed ingestion, sharing groups and indicator export to your SIEM, firewall and SOAR tools
- Testing of indicator flow end to end, including false positive handling and expiry rules, before go-live
- Hardening, access control and logging of the platform in your environment, with the results recorded
How we hand over
- Runbooks for feed onboarding, connector updates, sharing group changes and indicator curation
- Architecture, configuration and data flow documentation kept in your own repository
- Compliance evidence prepared for your assessors, with independent auditors deciding what satisfies them
- Knowledge transfer sessions for the analysts and engineers who will run the platform day to day
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Planned upgrades for MISP and OpenCTI releases, including OpenCTI LTS license requirements where applicable
- Connector and integration maintenance tracked against vendor release cycles
- Periodic security testing of the platform and its integrations, scoped in writing
