Why an open source threat intelligence platform for financial services must be built around sharing trust
A bank, payment provider or fintech security lead needs two things from threat intelligence at once: credible indicators from trusted financial communities, and a way to contribute their own findings without exposing customer or transaction data to anyone outside their control. Self-hosting MISP or OpenCTI answers both, but the reason to start with sharing is that DORA changes the obligation. DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to 20 types of financial entity, from credit and payment institutions to insurers and crypto-asset service providers, and it is directly applicable without national transposition. Its Article 45 allows financial entities to exchange cyber threat information within trusted communities, and the membership decision carries notification duties toward the competent authority. Confirm with your supervisor which notification form and timing apply to your entity type before the first community onboarding.
MISP usually fits sharing-community work because its distribution levels, custom sharing groups and synchronization are built for exchanging indicators between organizations. Its sharing groups can be set down to individual attributes, so a payment indicator can reach a peer bank without the surrounding incident narrative. OpenCTI fits analyst modeling better, because its STIX 2 based knowledge schema and GraphQL API suit teams that map threat actors, campaigns and fraud infrastructure into relationships. Many financial teams run both, with MISP for exchange and OpenCTI for analysis. The choice depends on two facts you must confirm: which platform your target community already runs, since a shared instance is only useful if the peers can synchronize with it, and your licensing position, because OpenCTI Enterprise Edition features sit under a separate proprietary license from the Apache 2.0 Community Edition.
Which financial regulations shape the threat intelligence build
This table maps each financial regulation or standard to what it means for where the MISP or OpenCTI platform is hosted, how its providers are contracted, who can access it and what the platform must log. Read each row as a design input to settle before deployment, and confirm the applicability of each regime with your compliance and legal teams, since the obligations depend on your entity type and jurisdiction.
| Regulation or standard | Hosting location and contracts | Access control and logging of the platform |
|---|---|---|
| DORA Article 45 sharing arrangements | Sharing communities must be reached from a platform you control. Confirm with your competent authority which notification it expects and whether the community operator is an ICT provider covered by your register. | Use distribution levels and sharing groups to limit who sees each indicator. Log membership changes and sharing decisions so you can show what was shared, with whom and under which terms. |
| DORA Article 28(3) and 28(8) register and exit planning | List every hosting, cloud, feed and connector provider for the platform in your register of information. Document a tested exit plan for the platform if it supports a critical or important function. | Keep an inventory of accounts with admin rights to the platform and its database, storage and message queue, and review it on a set cycle. |
| DORA Article 30(2) contract terms | Contracts with any managed service or support partner must state where data is processed, require advance notice of location changes and cover data return on termination or insolvency. | Require the provider to supply audit logs of its own administrative access to your environment, and confirm how those logs are retained and delivered to you. |
| PCI DSS v4.0.1 (cardholder data in scope) | Keep the platform outside the cardholder data environment unless it touches card data. Indicators derived from card data may still need careful handling, so confirm scoping with your QSA or assessor. | Requirements on unique IDs, MFA for remote and admin access and log review apply where the platform is in scope. Confirm which of these apply to the intelligence system and document the decision. |
| Swift Customer Security Controls Framework v2026 | If the Swift environment connects to the intelligence platform, confirm the platform sits within the Swift scope and that its hosting supports the controls you attest to annually. | Swift controls cover access to the Swift environment and monitoring of it. Confirm whether the intelligence platform feeds Swift-related detection and how its logs reach the monitoring system. |
| FTC Safeguards Rule (16 CFR 314.4) | Applies to non-bank lenders and other covered institutions under FTC jurisdiction. Encrypt customer information in transit and at rest wherever the platform stores it, including indicators that reference customers. | Require multi-factor authentication for every user of the platform unless your Qualified Individual approves an equivalent control in writing. Monitor and log the activity of authorized users. |
| SEC Release 33-8810 (listed firms) | Relevant to SOX Section 404 internal control assessments. Document the platform as an IT general control area, covering change management, computer operations and hosting. | Evidence access control over program changes and data access, including who can alter feeds, connectors and sharing rules, and keep change records for each. |
How the build differs for banks, payment firms and fintechs
Banks, insurers and other financial entities in scope of DORA, Regulation (EU) 2022/2554, have applied the regulation since 17 January 2025. For these entities, the threat intelligence platform sits inside the ICT risk management and third-party oversight program. Information sharing under Article 45 is voluntary, but a self-hosted MISP or OpenCTI instance is usually the technical base for joining trusted communities and for documenting what was shared and why.
- Sharing arrangements: Article 45 allows trusted communities of financial entities, and the platform must record membership terms, distribution rules and what is exchanged.
- Authority notification: Joining such an arrangement must be notified to the competent authority, so keep a dated record of membership and the terms agreed.
- Register of information: Any hosted threat intelligence service or feed provider is an ICT contract that belongs in the Article 28(3) register, with the location of data processing stated under Article 30(2).
- Exit planning: Article 28(8) expects a tested exit strategy for ICT services supporting critical or important functions, which covers the intelligence store.
- Testing evidence: Threat-led testing under Article 26 is tied to TIBER-EU in the ECB's view, so keep the test scope and results connected to the platform.
Confirm with the supervisor and legal counsel whether the entity is in scope and which arrangement it is permitted to join.
PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, and also to entities that could affect the security of the cardholder data environment. That includes merchants, processors, acquirers, issuers and service providers. PCI DSS v4.0.1 is the only active version, and the future-dated v4.0 requirements took effect on 31 March 2025. The PCI SSC does not enforce compliance, so the payment brands decide who must validate.
- Scope of the platform: If the threat intelligence instance holds card data, indicators derived from payment logs, or access paths into the cardholder data environment, it may be in scope and must be segmented or controlled as such.
- Fraud and payment indicators: Card-testing, mule account and merchant compromise indicators are typically shared through payment-sector and fraud communities and pushed to detection tools.
- Assessment type: Validation is documented as a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance, so confirm which applies.
- Access control: Restrict who can view sharing groups that contain payment-related details.
- Acquirer and brand requirements: Confirm with the acquirer or payment brand whether they require particular sharing or reporting practices.
Confirm applicability and validation type with the acquirer, the payment brands and the entity's QSA.
Non-bank financial institutions under FTC jurisdiction are covered by the FTC Safeguards Rule, 16 CFR Part 314. The rule requires a written information security program led by a Qualified Individual. For the threat intelligence platform, the most direct requirements are multi-factor authentication for anyone accessing an information system, encryption of customer information in transit and at rest, and logging and monitoring of authorized user activity under 16 CFR 314.4(c). Exceptions to MFA require a written approval of an equivalent control.
- Access to the platform: Every analyst and administrator account needs MFA, unless the Qualified Individual approves an equivalent control in writing.
- Customer data in indicators: If intelligence records contain customer information, such as account identifiers in fraud cases, encrypt the store and limit what is exchanged.
- Activity logs: Record who searched, exported, changed or shared events, and keep those logs reviewable.
- Sharing communities: Lenders typically join fraud and sector groups that accept smaller members, so check the membership terms and data handling in each.
- Program documentation: Show how the platform fits the written information security program and who approves its changes.
Confirm with legal counsel whether the lender falls under the FTC Safeguards Rule or another regime, such as state requirements or a prudential supervisor.
Listed financial firms in the US carry two reporting angles. SEC guidance in Release 33-8810 names program development, program changes, computer operations and access to programs and data as example IT general control areas relevant to SOX Section 404 assessments. Separately, Regulation S-K Item 106 requires disclosure of cybersecurity risk management and governance, and the SEC adopted those rules in 2023. A threat intelligence platform matters to both because its controls and its governance records become evidence.
- ITGC evidence: Change control, access reviews and job logs for the platform may be tested as part of internal control over financial reporting.
- Governance records: Item 106 disclosures describe how management oversees cybersecurity risk, so keep minutes or reports showing platform review by the right committee.
- Sharing participation: Document which communities the firm joins and the purpose, so statements about information sharing are accurate.
- Vendor and source controls: Track feed and connector providers as third parties, with their terms and any data they receive.
- Change records: Show that connector and rule changes go through approval, since those changes affect detection.
Confirm with the external auditor and securities counsel how the platform falls within the ICFR scope and disclosure review.
Which open source platform fits financial sharing: MISP, OpenCTI or both
Financial entities usually start from one of two platforms, and the choice depends on who they share with and how they will feed detection tools. The cards below cover what MISP and OpenCTI each do well, what each needs to run, where licensing matters, and how the sharing community's own platform shapes the decision.
MISP for community sharing
MISP is the default choice for exchanging indicators with peers because its sharing model is built around distribution levels and sharing groups that can be set down to individual attributes. Its correlation engine matches exact values and patterns such as fuzzy hashes and CIDR overlaps, and it exports to Suricata, Snort, Zeek and RPZ formats that detection tools can load directly. Check that your sharing community's synchronization and taxonomy conventions match your instance before you commit.
MISP 2.5 for new deployments
MISP 2.5 is the version the project recommends for new deployments, and MISP 2.4 is end of life with security fixes only, so a new instance should not start on 2.4. Ask your implementation partner how upgrades will be scheduled, tested and documented, because a financial entity needs a tested rollback path for its sharing instance. Confirm which installation method your team will support, whether the installer, Docker images, Ansible roles or packages, and who owns each one.
OpenCTI for structured knowledge
OpenCTI organizes intelligence with a knowledge schema based on the STIX2 standards and exposes it through a web application and GraphQL API. It can use the MITRE ATT&CK framework through a dedicated connector and integrates with MISP, which lets a team keep sharing in MISP while modeling campaigns, threat actors and fraud infrastructure in OpenCTI. Its Community Edition is licensed under Apache License 2.0, and you should confirm which connectors your use case needs before you size the deployment.
OpenCTI operating components
OpenCTI has more moving parts than MISP, so plan its runtime before choosing it. A deployment needs Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, plus Python workers and connectors. Each of these needs patching, backup, monitoring and capacity planning inside your own infrastructure. Ask for the sizing your partner will use, the worker-to-platform ratio and the recovery procedure for each dependency.
OpenCTI Enterprise licensing
OpenCTI Enterprise Edition is licensed separately under a proprietary license, so it is a procurement decision that sits apart from the platform choice itself. Before you budget for it, list the features your analysts need and confirm which of them sit in the Enterprise Edition rather than the Community Edition. Also confirm the license terms for your sharing partners, since a community that only exchanges MISP data may not need Enterprise features at all.
The community platform decides
The platform your sharing community runs often matters more than your internal preference, because indicators only flow where both sides can read them. If the financial sharing group runs a MISP hub, your instance should speak its synchronization and sharing group model, and an OpenCTI instance can connect to it through a MISP connector. Ask the community operator which platform and version it runs, which sharing groups it uses and how onboarding is governed before you pick your own stack.
Integration points into fraud, payment and SOC tooling
A self-hosted MISP or OpenCTI instance is only useful when its indicators reach the tools that act on them. The cards below cover the detection consumers, rule exports, enrichment playbooks, analyst identity and connector credentials that connect the platform to the rest of the security estate, along with the separation between production sharing and analyst sandboxes.
Wazuh and Security Onion as detection consumers
Indicators exported from MISP or OpenCTI are typically matched in the SIEM or NSM platform, so the question is which one holds the detection logic for your payment and transaction logs. Confirm which platform ingests the feed and whether matches land as alerts with enough context for a fraud analyst. Check how IOC lists are refreshed, how stale entries are removed, and whether the SIEM retains the matched events under your own retention rules.
Suricata and Zeek rule exports
MISP can export indicators as Suricata, Snort, Zeek and RPZ formats, which lets network sensors block or flag traffic to known command-and-control and payment-skimming infrastructure. Sensor placement matters: a sensor that sees only north-south traffic will miss lateral movement inside the cardholder data environment. Ask who approves rule pushes into production, how rule versions are tested before deployment, and how exported rules are rolled back if they cause false positives on payment traffic.
Shuffle enrichment and triage playbooks
Shuffle can run enrichment and triage playbooks that take a MISP attribute, query internal sources such as account history or device reputation, and attach the result to a case before an analyst sees it. Playbook design should record every automated decision so that auditors can reconstruct why an alert was escalated or closed. Confirm who owns each playbook, how credentials are scoped for each connected system, and how the playbook behaves when an upstream service is unavailable.
Keycloak or authentik for analyst access
Analysts who curate indicators, approve sharing and read community data should sign in through the institution's workforce identity provider, not through local accounts. MISP supports OpenID Connect through the OidcAuth plugin, and OpenCTI documents its own authentication options. Decide which group maps to which sharing role, how leavers lose access to sharing groups, and whether privileged curation requires multi-factor authentication. Keycloak and authentik both support these patterns, but confirm the exact claim mapping against your version.
OpenBao for connector credentials
MISP feed keys, OpenCTI connector tokens, SIEM API accounts and sharing synchronization credentials are high-value secrets that should not sit in configuration files. OpenBao can store and issue these secrets with an audit trail, and its license is MPL-2.0. Ask who rotates each credential, how long a leaked token stays valid, and whether connector accounts are limited to the specific feeds or indexes they need. Name an owner for every secret before go-live.
Production sharing and analyst sandboxes
Keep the instance that synchronizes with trusted communities separate from the sandbox where analysts test feeds, enrichment modules and new rules. Production should only receive events that passed curation and carry the correct distribution and TLP markings. Sandbox data must never flow back into the sharing community by accident. Confirm the network boundary, which team can promote content from sandbox to production, and where the deployment runs in your own cloud account or data center so that indicator data stays under your control.
Rollout from community onboarding to first notified sharing
This sequence takes a financial entity from choosing a sharing community to a self-hosted MISP or OpenCTI instance that exchanges indicators under agreed sharing rules, feeds fraud and payment detections, and produces a regulator notification and evidence pack. Each phase closes with a named output that the next phase depends on.
Define intelligence requirements and select the community
The security lead, fraud and payments leads and the compliance owner agree which threats matter to the business, such as account takeover, card fraud and payment rail abuse, and who will consume the intelligence. They then shortlist sharing communities that cover those threats and confirm with each community what membership requires, including vetting, fees if any, and the sharing rules members must accept. The output is a written requirements statement and a chosen community with its membership terms on file. Confirm the membership conditions directly with the community, since they vary.
Review ICT contracts and the provider register
Compliance and procurement review every contract that supports the hosting, identity, storage and any managed service for the threat intelligence platform. Under DORA Article 28(3), each arrangement must appear in the register of information. Under Article 30(2), each contract must state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination. Under Article 28(8), exit strategies for services supporting critical or important functions must be documented and tested. The output is a register entry for each arrangement and a list of contract gaps to close before data flows.
Build the hosting and identity foundation
The platform engineering team deploys MISP or OpenCTI inside the entity's own infrastructure, with its supporting services, backups and logging. For OpenCTI, this includes Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage. Administrator and analyst access is tied to the workforce identity provider with multi-factor authentication, and the team restricts network paths so the instance accepts sharing traffic only from approved peers. The output is a tested build with documented configuration, restore evidence and a named list of administrators.
Set sharing groups and TLP governance
The intelligence owner and legal counsel write the distribution and handling rules before any event is created. This covers which distribution levels apply to each category of indicator, which sharing groups exist, who may publish, and how Traffic Light Protocol markings map to MISP or OpenCTI settings. Indicators that could expose customer data are reviewed before sharing. The output is an approved governance document and a configured set of sharing groups that matches it, verified by a test event that reaches only the intended recipients.
Connect feeds and synchronize with the community
The platform team enables the community's synchronization with the instance and imports the default and agreed feeds, taxonomies and galaxies, including MITRE ATT&CK content. The intelligence owner checks that inbound events arrive with the expected distribution and tags, and that outbound events go only to permitted peers. Duplicate and stale indicators are reviewed against the curation rules. The output is an active synchronization record, a documented feed inventory and a tested publishing path that the community's own administrators have confirmed.
Integrate fraud and payment indicators into detection
The security operations team exports curated indicators in formats the detection stack can consume, such as Suricata or Zeek rules for network-level signals, and sends fraud and payment indicators, such as known mule account identifiers or malicious payment endpoints, to the fraud engine and SIEM through an agreed pipeline. Each indicator carries its source and expiry so analysts can age out stale entries. The output is a working export path, a rule set reviewed by detection engineers, and a test showing that a known test indicator produces an alert in the target system.
Notify the authority and assemble the evidence pack
Compliance confirms with the competent authority what must be notified about membership in the sharing arrangement under DORA Article 45, and submits that notification in the form the authority requires. The team then compiles the evidence pack: the register entries, contract review records, governance document, sharing group configuration, synchronization logs, detection test results and the first notified sharing record. DeployOpen prepares this evidence for the entity's own assessment, but the independent auditors and the authority decide on conformity. The output is a submitted notification and an indexed evidence pack ready for review.
Evidence supervisors and assessors ask for, and what produces it
This table maps the evidence a supervisor, auditor or PCI or Swift assessor is likely to ask for against the component that produces it. Read each row as a question to answer before the first sharing event, not after. Auditors and certification bodies issue any attestation; DeployOpen prepares the systems, configuration and records those assessments examine.
| Evidence item | What it shows | Component or source that produces it |
|---|---|---|
| Register of information entry for the MISP or OpenCTI platform | The ICT service is recorded with its provider, location of processing and contractual terms under DORA Article 28(3) | Your third-party risk register, completed from the platform architecture and hosting location documented in the implementation |
| Sharing agreements and group membership records | Which trusted communities the entity has joined and under what terms indicators are exchanged | Your legal and compliance team, with membership lists exported from MISP sharing groups or OpenCTI organization records |
| Notification records for competent authority membership | Evidence that the entity informed its authority when joining an information-sharing arrangement under DORA Article 45 | Your compliance function; the platform supplies the membership and sync configuration dates needed to show when participation began |
| MISP or OpenCTI audit logs | Who created, edited, published or exported indicators, and when | The MISP audit log and OpenCTI activity records, forwarded to the SIEM and retained for the period your policy sets |
| Sharing group and distribution configuration exports | How TLP-style handling and distribution levels were set, supporting controls on who receives what | MISP sharing group and distribution settings exported through the API, or OpenCTI marking definitions and access configuration, kept under change control |
| Access reviews for platform users and API keys | Named users, roles and API keys are reviewed on a stated cycle and removed when no longer needed | The identity provider and platform user lists, reviewed by the access owner and recorded as signed review outputs |
| Exit plan and data return documentation | A tested route to move or remove intelligence data if the provider or hosting fails, as DORA Article 28(8) and Article 30(2) expect for critical functions | Runbooks and export tests written during deployment: MISP exports, OpenCTI backups, and object storage copies, with the results of a restore test |
| PCI DSS or Swift assessment inputs | Where the platform touches cardholder data or Swift connectivity, it sits within the scope of the assessor's review of controls | Network diagrams, access records and logging from the platform, supplied to your Qualified Security Assessor or Swift assessor, who decide scope and issue any report or attestation |
What financial teams ask before hiring a threat intelligence partner
What drives the cost of a self-hosted MISP or OpenCTI deployment?
The software licence is not the main cost. MISP is licensed under AGPL-3.0 and OpenCTI has a Community Edition under Apache License 2.0, so cost sits in infrastructure, integration work, feeds and people. Infrastructure for OpenCTI includes Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, and the documented minimums are 2 cores and at least 8 GB RAM for the platform and 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch. Connector and SIEM or firewall integration work is one-time, while feed subscriptions, analyst curation time, hosting and upgrades recur. If you need OpenCTI features that sit in the Enterprise Edition, add its subscription. Ask any partner for a quote that separates these items, names who pays for each, and states which costs recur each year.
How long does a threat intelligence rollout take?
The pace is set by scope, not by the software. A basic MISP instance on Ubuntu 24.04 with the provided installer is a smaller task than an OpenCTI deployment with several connectors, a clustered search backend and SIEM and firewall feeds. The pace also depends on how fast your team can approve sharing rules, complete legal review of community terms and get network changes through change control. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for a milestone plan that shows which steps wait on your teams. We do not give a duration here, because none is supplied for this scope.
What must our team supply for a threat intelligence engagement?
Three internal groups carry most of the dependencies. Your threat intelligence or SOC lead must confirm intelligence requirements, the sharing communities you will join and the TLP and distribution rules that govern them. Legal and compliance must review membership terms, data handling and any personal data in indicators, and must agree how notifications to authorities are made. Your identity and network teams must provide single sign-on integration, service accounts, firewall rules for community synchronization and the path to your SIEM and firewalls. Ask a partner to list these inputs in the written scope so that each one has an owner and a date.
Can our own team run MISP or OpenCTI without a partner?
Yes, if you have people who can operate the stack and curate indicators. MISP and OpenCTI are open source and self-hosted, so your staff can install, configure and maintain them directly. The practical question is staffing: you need skills in Linux, databases, search clusters and message queues for OpenCTI, plus a curator who can age out false positives and write sharing rules. A partner can plan, implement, integrate, harden, back up, upgrade and document the platform inside your infrastructure, or support it through a retainer. Decide which of these tasks you keep in-house before you request proposals.
Does DORA require us to use MISP or OpenCTI?
No. DORA, Regulation (EU) 2022/2554, does not name a threat intelligence platform or any product. Article 45 allows financial entities to exchange cyber threat information within trusted communities, and the platform you use to do that is your choice. Your obligations include keeping a register of information on ICT contractual arrangements under Article 28(3), and writing contracts that state where services and data are processed under Article 30(2). Whether to use MISP or OpenCTI should follow your sharing communities, your team's skills and your integration needs. Confirm the notification requirements for joining a community with your competent authority and legal team.
How do we handle upgrades when MISP 2.4 has reached end of life?
Any MISP 2.4 instance should move to the 2.5 line, which the project recommends for new deployments. MISP 2.4 is end of life with security fixes only, and the project strongly advises against installing new 2.4 instances; it provides an upgrade script for Ubuntu. Version 2.5.47, released on 17 September 2026, introduced a new database migration system with PostgreSQL support, so check your database plan before you move. The current release is 2.5.50, published on 9 October 2026. Plan a test instance, back up the database and configuration, and rehearse the upgrade. For OpenCTI, plan for date-based releases and for LTS licence keys if you use the LTS line.
Which OpenCTI release line should a financial institution choose?
Choose between regular releases and the LTS line based on how much change your team can absorb. Regular OpenCTI releases ship from daily to weekly and follow the x.YYMMDD.z pattern, with 7.261016.0 published on 16 October 2026 as an example. LTS releases come every 6 months, each supported for 1 year, and need a specific LTS license key. After a one-month stabilization, they receive only critical bug and security fixes. The 7.260309.0 LTS line had reached hotfix lts.8 by October 2026. Confirm with the vendor which features you need and whether they sit in the Community Edition or the Enterprise Edition before you commit to a line.
What support should we expect after go-live?
Expect ongoing work for feed curation, connector updates, upgrades, backups and monitoring of the platform itself. Support is available as a retainer for ongoing operations, upgrades and continuous testing, and most implementation work is fixed-scope with written deliverables. Ask any partner how it handles connector maintenance, which versions it will support, how it tests upgrades before they reach production, and how it documents the platform for auditors. Also ask who answers when a community synchronization fails at 2 a.m. and what escalation path applies.
Questions to put to an implementation partner for a financial entity
Start with the regulatory paperwork, because it decides what the partner must build before any feed is connected. Ask how they will populate your DORA Article 28(3) register of information for the threat intelligence platform, including the sharing community operator, any hosting provider and any subcontracted connector developer, and how each entry is kept current. Then ask how contract terms will meet Article 30(2): where the platform and its data are hosted, how advance notice of hosting changes will reach your team, and how data is returned on insolvency or termination. Ask for the exit plan required by Article 28(8) and whether they will test it. A partner that cannot show a draft of these inputs in the first scoping conversation is not ready for a regulated engagement.
Next, press on how sharing controls are enforced rather than described. Ask which distribution levels, TLP markings and sharing groups they will configure in MISP, and whether they will test that an event tagged for one community cannot reach an instance outside it. For OpenCTI, ask how marking definitions and access groups are set up and which of those controls depend on the Enterprise Edition. Ask them to put the Enterprise Edition question in writing: which features you need (for example, role or group controls your analysts require), which the Community Edition covers, and what the Enterprise license costs, who buys it and whose name it sits under. Confirm that LTS releases require a specific license key before you plan around them.
Finally, cover credentials, false positives and evidence. Ask where connector and feed API keys are stored, who can read them, how they rotate, and whether the platform's own secrets sit in a self-hosted vault rather than configuration files. Ask how indicators are aged out or demoted before a fraud or payment rule can block a transaction, who approves that step and how a wrong block is reversed. On upgrades, ask which MISP 2.5 and OpenCTI LTS line they will track, how they will move off any end-of-life version, and how long security fixes are guaranteed for each line. Last, ask what evidence pack they deliver to the competent authority: configuration baselines, sharing agreements, membership records, the notification file and test results, and who keeps them current.
