MISP or OpenCTI: which fits your threat intelligence team
If your team needs to exchange indicators with other organizations, choose MISP first. If your analysts need to model threat actors, campaigns and their relationships as a STIX knowledge graph and produce reports from it, choose OpenCTI first. Many teams end up with a question that is really two questions: they need a sharing hub, a knowledge platform, or both, and the answer depends on who they must share with and how analysts will work the data day to day. MISP suits sharing communities, where events move between instances under distribution levels and sharing groups, and where indicators are correlated across those events, including fuzzy hashes and CIDR overlaps. It is licensed under AGPL-3.0, and the repository notes that interlocked copyright among contributors prevents any single entity from changing that license model.
OpenCTI suits teams whose center of gravity is analysis. It structures intelligence as STIX 2.1 entities and relationships, imports data through connectors (including MISP, MITRE and CVE connectors), and publishes under Apache-2.0 for the Community Edition. The Enterprise Edition is proprietary and paid, and it is where audit logs, playbooks and automation, organization segregation and SSO through OpenID, LDAP or SAML are gated. If you need SSO on day one, confirm which of those features your chosen edition includes before you commit to a design, and ask the vendor for the current license terms in writing. Also budget for the infrastructure: OpenCTI depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, while MISP runs on PHP, MySQL or MariaDB and Redis.
The decision turns on four questions: who you must share indicators with, how analysts will model and report on what they collect, whether you need SSO and audit controls that sit in a paid tier, and how much operating capacity your team can staff for a multi-service stack. If the answer to the first question is a trusted community, start with MISP. If the answer is analyst reporting and a shared knowledge base, start with OpenCTI. If you need both, the MISP and OpenCTI data model comparison and the integration guide cover how the two are usually paired.
Which platform fits which scenario
This table maps common MISP and OpenCTI scenarios to the platform that usually fits better, along with the condition that decides it. Read each condition as the test to apply in your own environment before you choose. Both platforms have open-source Community editions, so the deciding factors are usually the sharing model, SSO and audit needs, and how many services your team can operate.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Sharing indicators with partners or an ISAC | MISP | Choose MISP when you need distribution levels, sharing groups and event synchronization between instances and communities. |
| Building a STIX knowledge base for analysts | OpenCTI | Choose OpenCTI when analysts need STIX 2.1 entities and relationships to browse, enrich and report on intelligence as a graph. |
| Ingesting MISP data into a graph | OpenCTI | OpenCTI's MISP connector imports events into the graph, provided MISP remains the sharing hub and the duplicated data is acceptable to operate. |
| Needing SSO through OpenID, LDAP or SAML | Confirm before choosing | OpenCTI gates OpenID, LDAP and SAML SSO behind Enterprise Edition. Confirm MISP's OIDC and other authentication options in its OidcAuth plugin README. |
| Needing audit logs and organization segregation | Confirm before choosing | OpenCTI gates audit logs and organization segregation behind Enterprise Edition. Ask MISP maintainers which audit and tenant controls your version provides. |
| Small team with limited ops capacity | MISP | MISP's core stack is PHP with MySQL or MariaDB and Redis. OpenCTI adds Elasticsearch or OpenSearch, RabbitMQ, S3-compatible storage and workers, so choose it only if you can run them. |
| Organization that must keep license terms simple | OpenCTI for permissive terms | OpenCTI Community is Apache-2.0. MISP is AGPL-3.0, so confirm with counsel what network use and modification mean for your deployment. |
How MISP and OpenCTI are built and what that means for operations
MISP is a single PHP application with a small set of supporting services, while OpenCTI is split into a platform, workers, connectors and several data stores. The number of moving parts sets how much patching, sizing and monitoring your team takes on, so compare the component count against the people you have to run it.
MISP application stack
MISP is built on PHP with CakePHP and uses MySQL or MariaDB for storage and Redis as a supporting service. For a sharing hub, that is a short list of components to patch and back up. Confirm which database engine your team already runs well, since the database is where most of the operational work lands.
Recommended MISP line
MISP 2.5 is the recommended line for new deployments, and the 2.4 line is end of life with security fixes only. Starting on 2.4 creates an upgrade project on day one. Ask whether your own environment can follow the 2.5 release cadence, including the database migration changes introduced in 2.5.47.
MISP install options
The project supports an Ubuntu 24.04 installer, Docker images, Ansible roles, Puppet and RPM packages. Native installs are simpler to reason about on one host, while container images suit teams that already run container platforms. Pick the path your team can patch on schedule, and confirm how each is upgraded before committing.
OpenCTI as a stateless platform
OpenCTI's platform exposes a UI and GraphQL API and keeps no session state of its own, so it can be scaled horizontally. Writes go through RabbitMQ to Python workers. This design helps throughput but means the platform itself is only one part of what you run. Ask your team how they will scale and restart each tier independently.
OpenCTI data services
OpenCTI depends on Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage such as MinIO. That is five data services beyond the platform. Each one needs its own backup, upgrade path and monitoring, so count them when you estimate what your operations team absorbs.
Sizing and worker ratios
OpenCTI's documented sizing starts the platform at 2 cores and at least 8 GB RAM, with Elasticsearch or OpenSearch at 2 cores, 8 GB RAM and 16 GB SSD, and at least one platform node for every 3 workers. Connector volume, not user count, drives this growth. Ask for a sizing estimate based on the feeds and connectors you plan to run.
Feature comparison: correlation, sharing, data model and identity
This table compares how MISP and OpenCTI handle correlation, sharing, data modeling, exports and identity, using only documented capabilities. Read each row with the condition that makes it matter for your team, and confirm edition-specific details in each vendor's current documentation before you decide.
| Capability | MISP | OpenCTI |
|---|---|---|
| Correlation method | Exact matches plus advanced patterns including fuzzy hashes and CIDR overlaps, with granular controls | Relationships modeled as STIX entities and relationships; confirm how analysts query and link them in the current docs |
| Sharing control | Distribution levels and sharing groups applied down to individual attributes, with automatic sync between instances and trusted communities | Organization segregation is an Enterprise Edition feature; confirm sharing and access model in the current docs |
| Core data model | Events, attributes and objects, enriched with taxonomies and galaxies (MITRE ATT&CK, threat actors, malware) | STIX 2-based knowledge schema with entities and relationships, using a GraphQL API |
| Standards export | MISP JSON, STIX 1 and 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ through the REST API | Data organized as STIX 2 objects; confirm which export formats and connectors are available in your release |
| Data import | Feeds, warning lists and sync from other MISP instances | Connector-based import, including MISP, MITRE and CVE connectors; ATT&CK via a dedicated connector |
| Detection rule output | Suricata, Snort and Zeek rule formats exported directly from events | Confirm whether detection rule export is available in your edition and connector set |
| SSO and identity | OidcAuth plugin for OpenID Connect; confirm supported providers and setup in the plugin README | OpenID, LDAP and SAML SSO require Enterprise Edition; confirm current gating in the authentication docs |
| Automation and audit | Confirm automation and audit logging options for your release in the MISP documentation | Audit logs, playbooks and automation require Enterprise Edition |
What the AGPL-3.0 and Apache-2.0 licenses mean for each platform
MISP is licensed under the GNU Affero General Public License version 3 (AGPL-3.0). The license applies to the software itself, so a team that runs MISP unmodified inside its own network has the same freedoms as any other user: it can run, study and change the code, and it does not pay the project a license fee for the software. The AGPL matters most when a team changes the code and makes that modified version available to users over a network, for example as a shared service for a partner group or a hosted portal. In that case, the AGPL requires the modified source to be offered to those users under the same terms. The MISP repository also notes that interlocked copyright among contributors prevents any single entity from changing the license model, which gives teams more confidence about the license's stability.
- Internal use: Running unmodified MISP for your own staff carries no source disclosure duty under the AGPL.
- Modified and networked use: Changes exposed to remote users, such as a customized sharing portal, can trigger the requirement to offer the modified source.
- Contributor copyright: Because contributors hold interlocking copyright, no single company can relicense the project unilaterally.
- Support is separate: The license is free, but installation, hardening and upgrades still cost time, whether done by your staff or a services provider.
- Plugins and forks: Confirm the license of each plugin or custom module you add, since it may differ from the core.
Ask legal counsel to confirm how the AGPL applies to your specific deployment and any modifications before you expose MISP to external users.
Taxonomies, galaxies and related sharing content are not covered by the AGPL software license. The MISP download page states that taxonomy and galaxy data are licensed under CC0 1.0 Universal or the 2-clause BSD license. This split matters because a team that imports, edits or redistributes this content is working under different terms than the one that governs the MISP code. A common review question is whether the content can be copied into internal tools, exported to partners or combined with proprietary feeds, and the answer depends on which license applies to each dataset.
- CC0 1.0 Universal: Places the content in the public domain to the extent the law allows, with no attribution requirement.
- BSD 2-clause: Permits redistribution in source and binary form with the copyright notice and disclaimer retained.
- Per-dataset check: Taxonomies and galaxies may carry different licenses, so verify the license for each one you use.
- Third-party feeds: Default intelligence feeds are subject to their own terms, which can restrict commercial use or redistribution.
- Exports: Exported STIX, CSV or rule files inherit the terms of the data they contain, not the MISP software license.
Ask the MISP project or your counsel which license each taxonomy, galaxy and feed you plan to use carries, and record the answers in your data governance register.
The OpenCTI Community Edition is licensed under the Apache License 2.0, a permissive license that allows commercial use, modification and redistribution with a notice requirement and a patent grant. Filigran designs and develops OpenCTI, and the repository's LICENSE file governs the files not marked as Enterprise Edition. For many teams, the Apache-2.0 terms are simpler to review than the AGPL because modifications used internally or offered as a network service do not, by themselves, require publishing the modified source. The Community Edition is the starting point for a self-hosted deployment, but several governance and identity features sit outside it.
- Permissive terms: Apache-2.0 permits internal modification and commercial use with attribution and license notices retained.
- Community scope: The Community Edition covers the core platform, connectors and the STIX knowledge model.
- Enterprise files: Files marked as Enterprise Edition fall under a separate license, not Apache-2.0.
- Connector licenses: Confirm the license of each connector you deploy, since connectors are separate components.
- Notices: Keep the Apache-2.0 notices and any NOTICE file content in your distribution of the software.
Confirm with Filigran which files and features fall under the Enterprise Edition before you plan a deployment that depends on them.
Files marked as Enterprise Edition are governed by the proprietary OpenCTI Enterprise Edition License, which requires a paid subscription. The OpenCTI documentation places several capabilities in that edition: audit logs, playbooks and automation, organization segregation, and SSO configuration through OpenID, LDAP or SAML. LTS builds add another condition. OpenCTI LTS releases are distributed as container images but require a specific LTS license key to use, and after a one-month stabilization they receive only critical bug and security fixes. A team that picks an LTS line therefore has to plan for the key as part of its operating model.
- Paid subscription: Enterprise features need a subscription, and the price is set by Filigran through its commercial process, not published on this page.
- Gated features: Audit logs, playbooks, organization segregation and SSO through OpenID, LDAP or SAML are listed as Enterprise Edition features.
- LTS key: An LTS release needs its own license key, so key management belongs in the runbook.
- Fix scope: After stabilization, LTS builds receive critical bug and security fixes only, which affects how you plan feature upgrades.
- Contract terms: Ask Filigran for the subscription terms, renewal conditions and what happens to the deployment if the key lapses.
Have procurement and counsel review the Enterprise Edition License and the subscription order form before you rely on any gated feature for compliance or access control.
What drives the running cost of MISP and OpenCTI
Both platforms are free to download under open licenses, so the running cost sits in what you operate around them: infrastructure, upgrade skills, paid editions and the people who keep data flowing. The cards below separate one-time setup from recurring spend and list what to request in a written scope before comparing quotes.
MISP database and cache footprint
MISP runs on PHP with CakePHP, MySQL or MariaDB and Redis, so its recurring infrastructure is a database host, a cache and the application server. Event volume and sync frequency drive database growth more than user count does. Ask the implementation partner to size storage for your expected attribute volume and to state whether backups and replicas are included in the infrastructure estimate.
OpenCTI search, queue and storage stack
OpenCTI's dependencies are heavier: Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage. Each is a separate service to host, patch and back up. The documented sizing starts at 2 cores and 8 GB RAM for the platform and 2 cores, 8 GB RAM and 16 GB SSD for the search cluster, so plan for these as recurring capacity rather than a one-off purchase.
Worker count and connector hosting
OpenCTI's Python workers and connectors scale with import, enrichment and export volume. The documented guidance recommends at least one platform node for every 3 workers, so each added worker adds capacity you must pay to host. Every connector you enable, including the MISP connector, is another running process to monitor. Ask for the planned worker and connector count in the quote, along with who restarts failed connectors.
Upgrade and maintenance skills
Both platforms ship updates on their own cadence, and the recurring labor is usually the skilled engineer who tests and applies them. MISP 2.4 is end of life with security fixes only, so existing 2.4 installs need a planned migration to 2.5. OpenCTI's non-LTS releases ship from daily to weekly. Ask who owns upgrade testing, rollback and dependency changes, and whether that work is in the fixed scope or a retainer.
Enterprise and LTS license costs
OpenCTI's audit logs, playbooks, organization segregation and OpenID, LDAP or SAML single sign-on sit behind the Enterprise Edition, which requires a paid subscription. Production users who want LTS builds also need a specific LTS license key. MISP's software is AGPL-3.0 with no paid tier. Ask the vendor for the subscription price, its renewal terms and which features it covers before comparing totals.
Sharing management and analyst time
MISP's recurring people cost often lies in managing sync partners, distribution levels, sharing groups and correlation tuning across trusted communities. OpenCTI's cost lies in mapping and maintaining connector output into its STIX model. Neither is free to run. Ask how many sharing partners or connectors you expect, who approves new sync links, and what analyst hours are reserved for false-positive review.
Moving intelligence from MISP to OpenCTI or the reverse
This sequence shows how a team moves indicators, events and sharing relationships between MISP and OpenCTI without losing track of what was shared, with whom and under which distribution rules. It ends with consumers and sync partners cut over to one hub that the team can operate.
Inventory events, attributes and sharing groups
The platform owner exports a full list of events, attributes, tags, taxonomies, galaxies and feeds from the current system, and records the distribution level and sharing group on each event. Sync connections, the partners on each one, and any custom taxonomies or warning lists are listed separately. The step is complete when every sharing relationship has an owner and a written record of what it covers, because this inventory is the baseline for every later check.
Decide which system remains the sharing hub
The team, with its sharing partners in mind, chooses which platform stays the place where external partners publish and receive intelligence. MISP's sync model with distribution levels and sharing groups is designed for that role, while OpenCTI is typically the analysis and knowledge layer that a team feeds through connectors. Many teams keep the hub unchanged and move only internal analysis. The decision is recorded in writing, naming the owner of each sync link, before any data moves.
Map MISP objects and galaxies to STIX entities
An analyst maps each MISP object type, attribute type, galaxy cluster and taxonomy tag to the STIX 2.1 entity or relationship that OpenCTI will hold, and flags anything without a clean equivalent. Custom taxonomies and local galaxies usually need a decision about whether to keep them as labels, convert them to entities, or retire them. The output is a reviewed mapping document that a second analyst has checked, and every unmapped field is listed with a stated handling rule.
Run the connector on a test instance
The engineering team deploys OpenCTI on a non-production environment with its required dependencies, then configures the MISP connector against a copy or a limited scope of the MISP data. Export formats such as MISP JSON or STIX can be used for a one-time load, while the connector handles ongoing import. The check is that the test instance starts cleanly, the connector completes a bounded import, and errors are logged for each record that fails to map. Confirm connector version compatibility with the OpenCTI and MISP releases in use before starting.
Validate imports against the inventory
The team compares counts, timestamps, tags, distribution markings and relationships in the target system against the inventory from the first step. A sample of events is reviewed by an analyst who checks that indicators, context and attribution survived the mapping. Records that changed meaning, such as sharing restrictions that did not carry over, are listed as defects. The step closes when discrepancies are either fixed or accepted in writing by the data owner.
Rebuild feeds, workflows and sharing agreements
Items that do not transfer through an export are rebuilt in the target platform: sharing agreements with partners, feed subscriptions, custom taxonomies, enrichment rules and analyst playbooks. Access roles and SSO settings are configured against the target's authentication model, and any SSO feature that the chosen edition gates is confirmed before rollout. The output is a rebuild checklist with an owner and a sign-off for each item, so no partner relationship depends on an undocumented setting.
Cut over consumers and sync partners
Internal consumers, detection pipelines and partner sync links are switched to the chosen hub in a planned window, with the previous system kept read-only for a documented fallback period. Each partner confirms receipt of the new sync configuration and a test event. The team checks that consumers still receive intelligence and that no event is published twice or dropped. Switching is costly once partners depend on one hub, because every sharing agreement, sync link and downstream rule must be re-approved, so this step is best done only after the earlier checks pass.
Where MISP and OpenCTI implementations usually run long
The most common overrun in a MISP deployment is not the install. It is agreeing on who may see what before the first sync. Sharing agreements and distribution policy need to be written down with each partner: which distribution levels are allowed by default, which sharing groups exist, whether attributes can be restricted below the event level, and who approves a new community connection. Teams that start synchronizing before these decisions are made usually spend weeks later removing events, re-tagging attributes and renegotiating trust with partners. Budget time for synchronization testing against a non-production peer, and confirm the current installer and supported platform for your version in the MISP download page before scheduling the build.
OpenCTI overruns tend to come from the platform's dependencies and connectors rather than from the core application. The documented stack includes Elasticsearch 8.0 or later or OpenSearch 2.9 or later, Redis, RabbitMQ and S3-compatible storage, and the search cluster is where sizing is most often underestimated. Ask your vendor or partner to size the cluster against your expected object volume and connector import rates, not the minimum documented sizing. Connector tuning, such as import scope, batch behavior and deduplication, also takes iteration. Data modeling is a separate effort: deciding how STIX entities and relationships map to your analysts' workflow is a design task that needs an owner before connectors go live. Confirm with Filigran which SSO options (OpenID, LDAP or SAML) and which audit logging and playbook features your licence tier includes, because SSO setup and those controls are gated by the Enterprise Edition, and that cost should be in the scope from the start.
Questions buyers ask before choosing or hiring help
Which costs more to run, MISP or OpenCTI?
Neither software license is usually the largest line item, because MISP is AGPL-3.0 and OpenCTI Community Edition is Apache-2.0. The cost comes from infrastructure, staff time and, if you need them, OpenCTI Enterprise Edition subscription fees. OpenCTI's documented stack adds Elasticsearch or OpenSearch, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage, and its sizing guidance recommends at least one platform node for every 3 workers. MISP runs on PHP with CakePHP, MySQL or MariaDB and Redis. Recurring costs include hosting, storage growth, patching and upgrades. One-time costs include setup and integration. Ask any quote to state node counts, storage assumptions, the upgrade approach and whether Enterprise features are in scope.
Can one team run both MISP and OpenCTI?
Yes, many teams do, but running two platforms roughly doubles the operational surface. You will maintain two stacks, two upgrade cycles and two sets of access controls. OpenCTI Community releases ship from daily to weekly, while its LTS releases arrive every 6 months and are supported for one year, so the upgrade calendar needs an owner. LTS builds also require a specific license key. Most teams choose one sharing hub, usually MISP for cross-organization exchange, and use the OpenCTI MISP connector to import events into the analysis platform. Decide which system is authoritative for each object type before you deploy, so analysts do not edit the same indicator in two places.
Which SSO features need the OpenCTI Enterprise Edition?
According to OpenCTI's documentation, SSO configuration through OpenID, LDAP or SAML requires Enterprise Edition, and so do audit logs, playbooks and automation, and organization segregation. Confirm this against the current OpenCTI authentication and Enterprise Edition documentation before you commit to a design. For MISP, the project documents an OidcAuth plugin in its repository that handles OpenID Connect login. No MISP edition or paid-tier fact was supplied for this comparison, so ask the MISP project or your implementation partner which MISP authentication and audit features you need, how the plugin is supported on your MISP version, and what it requires for your identity provider.
Does AGPL-3.0 affect our internal use of MISP?
For internal use of an unmodified MISP instance, AGPL-3.0 usually creates few obligations, because its source-sharing conditions are triggered mainly by distributing MISP or by running a modified version that users interact with over a network. Those triggers are the reason to check your setup. Ask counsel to review the case if you distribute MISP to partners, host it for a subsidiary or customers, or patch it. MISP's repository notes that contributor copyright interlocks, so no single entity can change the license model. Taxonomies and galaxies are licensed separately under CC0 1.0 or the 2-clause BSD license, which matters if you redistribute them.
How much effort does migrating between MISP and OpenCTI take?
Effort depends mainly on what data moves, how it is shared, and whether analysts need the other platform's model. The main drivers are event and attribute volume, the distribution levels and sharing groups you rely on, the galaxy and taxonomy tags in use, and the enrichment or export jobs connected to each platform. MISP exports MISP JSON and STIX 1 and 2, and OpenCTI imports through connectors, so much of the work is mapping and validating objects rather than rebuilding them. Ask for a data inventory, a written mapping of distribution rules, a test import on a copy and a rollback plan, and check that each sharing rule still holds after the move.
What does the work need from our team?
Plan for named owners rather than a single generalist. You need an infrastructure owner for hosting and backups, an identity owner for SSO and access groups, a data owner who decides sharing rules, and analysts who define the workflows the platform must support. Technical skills include Linux administration, container or virtual machine operations, database administration, and for OpenCTI, operating a search cluster, a message broker and object storage. For MISP, the project recommends version 2.5 on Ubuntu 24.04 with its provided installer, and it also lists Docker images and Ansible roles. Confirm that someone will own upgrades, since MISP 2.4 is end of life.
Can we run MISP or OpenCTI ourselves without a partner?
Yes, if your team has the infrastructure skills, time and capacity to own the platform after go-live. The decision comes down to who will handle sizing, backups, upgrades, LTS license handling, SSO and evidence for audits. DeployOpen plans, implements, customizes, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen helps choose, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted platforms inside your own cloud, data center or air-gapped network. DeployOpen does not favor MISP or OpenCTI, so the cards below cover the decisions that come before either platform is chosen and the work that follows.
Platform selection workshop
Before choosing, map who consumes intelligence and who shares it. Sharing with partners and sector communities points toward MISP's distribution levels and sharing groups, while analyst-driven knowledge management points toward OpenCTI's STIX entities and relationships. DeployOpen can help document those requirements and the edition questions they raise, such as which SSO methods your organization needs. Agree the outcome in writing before any build work starts.
Identity and SSO design
Check which single sign-on methods each platform needs for your environment. OpenCTI's OpenID, LDAP and SAML configuration is gated behind the Enterprise Edition, so the license decision and the identity design are linked. MISP's OIDC support is provided through an authentication plugin, which your team should verify against its own identity provider. DeployOpen can configure and test the chosen integration with your existing identity stack.
Self-hosted infrastructure build
OpenCTI is a stateless platform that depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, with Python workers and connectors on top. MISP runs on PHP with MySQL or MariaDB and Redis, and the project recommends Ubuntu 24.04 for new 2.5 deployments. DeployOpen can plan and build either stack inside your cloud accounts or data centers, sized to your expected connector and user load, and document the result.
Connector and feed integration
Most of the value in either platform comes from the feeds and connectors you attach. OpenCTI imports data through connectors, including MISP, MITRE and CVE connectors, while MISP ships default intelligence feeds and exports to Suricata, Snort, Zeek and STIX formats. If you run both, decide which system stays the sharing hub before wiring the connector. DeployOpen can build and maintain these integrations as a fixed-scope piece of work.
Migration and data movement
Moving from an existing MISP or OpenCTI instance, or moving events between them, needs a mapping of attributes, objects, entities and relationships before data is copied. Check how each platform's export formats preserve distribution levels, sharing groups and tags, because those controls do not carry over automatically. DeployOpen can plan the migration, run it in a test environment first and verify results against an agreed checklist.
Hardening, backup and security testing
Once the platform is live, DeployOpen can harden the host and application configuration, set up backups for the databases and object storage, and test the deployment with application and infrastructure security testing. Ask any provider to confirm how backups cover each component, including MISP's database and OpenCTI's search index and object storage. Ongoing upgrades and continuous testing are available as retainers after the initial engagement.
