MISP implementation plan and cost

What a MISP implementation involves

The MISP software is free to use and licensed under the GNU AGPL version 3, so the cost of an implementation comes from the work around the software. Three areas drive it: designing the sharing model (organizations, roles, distribution levels and sharing groups), building and hardening the instance on infrastructure you control, and connecting it to the tools that produce and consume indicators. Each area needs decisions that are hard to reverse once data is shared.

Teams usually start a MISP project for one of three reasons: they are starting a threat intelligence program, they need to exchange indicators with partners or an ISAC, or they are moving indicators out of spreadsheets and scattered feeds. Each trigger changes the design. A single team that wants a private store has fewer decisions to make than a program that will synchronize with external communities, where the hard question is who may see which attributes.

A small deployment serving one team with no outbound sync can often be run in-house, provided someone owns patching, backups and user administration. Multi-organization sharing usually benefits from an outside design review before the first sync goes live, because distribution mistakes are difficult to undo after data has left the instance. Ask any partner to show the sharing design as a written document you can keep and reuse.

Build new instances on MISP 2.5, which the project recommends for new deployments. Do not install new MISP 2.4 instances, since that line is end of life and receives security fixes only. Confirm the current 2.5 release on the MISP download page when scoping the work, and name the target version in the written quote. Upgrading an existing 2.4 instance is covered in a separate section.

What the work includes

A fixed-scope MISP engagement usually groups the work into the packages below. Each package ends with a deliverable your team keeps and can check against the written scope.

Requirements and sharing model design

Scope starts with the sharing model: which teams publish, which consume, which partners and ISACs receive events, and which data must never leave the organization. The deliverable is a written design covering distribution levels, sharing groups, sync direction and retention. Check that the design names each data class and the reviewer who approves it.

Installation on the chosen platform

MISP 2.5 is the version the project recommends for new deployments, and its download page lists the Ubuntu 24.04 installer, Docker images, Ansible roles, Puppet and RPM packages as options. The choice drives patching, rebuild effort and how your configuration management fits. Deliverable: a running instance in each agreed environment with the installation method documented. Confirm which method your platform team supports before scoping.

Organizations, roles and sharing groups

Each organization, role and sharing group is created from the approved sharing model, with role permissions limited to what each team actually does. If single sign-on is in scope, the identity provider role mapping is configured here as well. Deliverable: an account and role matrix, sharing group definitions and a test log showing each role can and cannot see the intended events.

Feeds, taxonomies and tool integrations

Feed selection decides which default and third-party feeds are enabled, since each adds data that needs a review owner and a licence check. Taxonomies and galaxies are licensed separately from the AGPL software, so their terms are recorded alongside the feed list. Named integrations, such as a SIEM or IDS export path, are scoped by system and version. Deliverable: an approved feed list, enabled taxonomies and a tested export or API path for each named tool.

Hardening, backup and documentation

Baseline hardening covers the web server and TLS, API key handling, logging and the patch cadence for security releases. Backups are verified by a test restore in the agreed environment, which shows the archive is usable before go-live. Deliverable: a hardening record, a tested backup and restore procedure and an operations runbook for administrators.

Handover and quote scope

Handover transfers administration, runbooks and open issues to your team, with a named sign-off for each acceptance criterion. A written quote should list included and excluded items, environments, named integrations, acceptance criteria and who signs off. Check that exclusions state whether feed subscriptions, analyst training and work with sync partners are included, since teams often assume they are.

What drives cost and duration

This table lists the factors that move MISP implementation effort and cost, why each one matters, how to keep it manageable, and what to ask a partner to price as a separate line.

Driver	Why it moves effort	How to keep it down	Ask the partner to price separately
Organizations and users	Each organization needs its own role model, sharing defaults and onboarding. Analyst and admin accounts multiply the access reviews and training needed.	Start with a small set of organizations and a role catalog of a few standard roles. Add organizations in phases after the first sharing rules are proven.	Per-organization onboarding, role design workshops and user training sessions, quoted by count.
Sharing partners and sync topology	Every sync partner needs connection testing, filtering rules, distribution checks and a trust review. Hub-and-spoke or multi-hop designs add more testing paths than a single peer.	Begin with one or two trusted partners and a documented sync policy. Use a single hub design where the community allows it.	Sync partner setup, filter rule design, connection testing and ongoing partner onboarding, priced per partner or per topology.
Event and attribute volume	Expected volume sets database growth, worker load and storage. Higher volume increases tuning, pruning policy work and performance testing.	Measure expected daily event and attribute counts from current feeds and sources before design. Set retention and pruning rules early.	Load testing against your expected volume and database tuning, quoted separately from the base install.
Feeds and enrichment sources	Each feed needs configuration, caching decisions, licence checks and failure handling. Enrichment modules add API keys, rate limits and testing against each external service.	Enable only the default feeds your team will use. Confirm the licence terms of each third-party feed before enabling it.	Feed configuration, enrichment module integration and validation, plus any custom feed connector work.
Taxonomy and galaxy customization	Custom taxonomies, galaxies and object templates change data models that analysts, sync partners and integrations depend on. Changes must be tested across upgrades.	Use the shipped taxonomies and galaxies where they meet the need. Record every custom element in a change log with an owner.	Custom object design, taxonomy or galaxy authoring, and upgrade regression testing of those changes.
Integrations with SIEM, IDS and SOAR	Each tool needs its own export format, authentication, field mapping and sighting feedback path. Suricata, Snort and Zeek rule outputs and SOAR playbooks each require separate test cases.	Pick one priority integration for the first release. Confirm the export formats your tools accept before design.	Connector build, field mapping, PyMISP scripts and integration testing, quoted per tool.
OpenID Connect single sign-on	The OidcAuth plugin needs identity provider configuration, role mapping to MISP roles and organizations, and tests for account linking. Errors here can grant wrong access.	Confirm your identity provider's claims and group model first. Keep the number of mapped roles small.	OidcAuth configuration, role mapping rules, and login and access testing against each identity provider.
Server and database sizing	CPU, memory, disk, database and Redis capacity depend on expected volume, number of users and background worker load. Sizing assumed rather than measured leads to rework after go-live. Confirm sizing against expected volume and the vendor's current requirements for the release you install, not assumed figures.	Gather volume estimates and the current MISP and database requirements before choosing hosts. Plan a staging instance to measure load before production.	Sizing review, capacity test and any changes to hosts or database layout, quoted as a separate line.
Environments: test, production and air-gapped	Each environment needs its own installation, configuration, data handling and upgrade path. Air-gapped deployments add offline package handling and manual feed updates.	Build the test environment from the same automation as production. Decide early whether an air-gapped instance will receive updates through a controlled transfer process.	Environment build, configuration parity checks, offline update procedure and separate test cycles per environment.
Compliance and evidence requirements	Assessors often ask for access records, change history, sharing controls and backup evidence. Producing this evidence means logging, retention settings and documented procedures. DeployOpen prepares evidence for assessments but does not issue audit reports or certifications.	Agree the evidence list with your assessor before design. Configure logging and retention once, not per request.	Control mapping, evidence collection procedures and documentation, priced against the agreed evidence list.

Project phases and outputs

The sequence moves from agreed sharing rules to a tested, documented MISP instance that your team can operate after handover.

Confirm discovery and sharing model
DeployOpen interviews your threat intelligence, SOC and legal stakeholders to define which data is shared, with whom, and under which distribution levels and sharing groups. Your team approves a written sharing model. The step closes when that model is signed off and mapped to the organizations that will use the instance.
Complete architecture and sizing record
The team selects the deployment method, server layout, database and Redis placement, and expected event volume, then records the result as a sizing record. You review it against your hosting constraints in your own infrastructure. The step closes when the record is approved and the sizing assumptions are written down for later review.
Build on the target platform
DeployOpen installs MISP on the agreed platform, using the installation method and release line confirmed during architecture, and checks the base services are running. The build is verified by a clean install log and a working login on the administrative interface. Confirm the current recommended release with the MISP project before the build starts.
Configure organizations, roles, sharing groups and feeds
DeployOpen creates organizations, user roles, sharing groups, taxonomies, galaxies and the agreed feeds according to the sharing model. Access is checked by test accounts for each role. The step closes with a permissions matrix signed by your team and a configuration export kept under version control.
Integrate and test with real data
Integrations with your SIEM, IDS, ticketing or identity systems are connected and exercised using representative events from your environment. Results are captured in an integration test log that lists each test, expected output and observed result. The step closes when failures are resolved or accepted in writing.
Harden and verify backups
DeployOpen applies the hardening baseline agreed in scope, covering TLS, authentication, logging and access restrictions. Backups are taken and then restored to a separate environment to prove recovery works. The step closes with a tested backup restore record and a hardening checklist with any exceptions noted.
Hand over and train operators
DeployOpen delivers runbooks for upgrades, feeds, sync partners and incident response, then trains administrators and analysts on daily operation. Your team runs a supervised handover session. The step closes when runbooks are accepted, training attendance is recorded and open items are assigned owners.

In-house or with a partner

The table separates the MISP work most teams keep in-house from the work they commonly outsource, with the skills each part needs and the ones teams often lack.

Part of the work	Usually handled by	Skills required	Skills usually missing internally
Day-to-day analyst use	In-house	Threat intelligence analysis, MISP search, tagging and event handling	Consistent tagging conventions, which are often undocumented across analysts
Event curation	In-house	Threat intelligence analysis, taxonomy and galaxy use, false-positive judgment	Clear curation rules for attributes and when to publish
Sharing decisions for own organization	In-house, with legal and management sign-off	Threat intelligence analysis, distribution levels, sharing groups, TLP handling	Mapping written sharing policy to exact MISP distribution settings
Sensor feedback	In-house	Suricata, Snort or Zeek operations, PyMISP scripts, sightings reporting	PyMISP work to send sightings back from sensors
Architecture and sizing	Partner	Linux administration, MySQL or MariaDB operations, Redis, workload modeling for ingestion and sync	Database and Redis sizing for expected ingestion and sync volumes
Sharing model design across organizations	Partner, with the organization's threat intelligence lead	Threat intelligence analysis, distribution policy, identity federation for organization roles	Cross-organization agreements and role mapping are rarely written down internally
Installation and hardening	Partner	Linux administration, PHP and MySQL or MariaDB operations, Redis, TLS, identity federation	PHP application operations and TLS configuration outside routine security work
Custom integrations	Partner	Python with PyMISP, REST API use, SIEM and IDS connectors, STIX and export formats	Upgrade-safe PyMISP scripting and connector maintenance
Testing	Partner, with internal acceptance	Linux administration, PyMISP test scripts, sync and role tests, upgrade rehearsal	Test plans for sync boundaries, role permissions and upgrade regression

What usually goes wrong

Most MISP problems surface after go-live, when shared data is already in partner hands or an analyst queue is already flooded. Each card names the prevention step and the artifact that shows it was done.

Sharing rules designed after sharing starts

Sync is switched on before sharing groups, organization roles and filtering rules are agreed, so events leave the instance under default settings. Prevent this by approving a written sharing matrix before any sync partner is connected, and check the matrix against each partner's configured pull and push rules. The sharing matrix is the artifact that proves the order.

Distribution levels applied inconsistently

Analysts pick distribution levels by habit, so attributes that should stay inside the organization are tagged for community sharing and synchronized outward. Prevent this with a short labeling standard, default distribution set per organization, and a review of attributes marked for wider sharing. The labeling standard and a periodic sample review are the proof.

Undersized database and workers

Database, Redis and background worker capacity is chosen for an empty instance, then event volume, feed ingestion and synchronization push load past what the host handles. Prevent this by sizing against expected event and attribute counts, feed count and sync frequency, and by documenting headroom. The sizing note, with the assumptions behind it, is the artifact to request.

Feeds enabled without an owner

Default and third-party feeds are switched on, then false positives accumulate in the event list and nobody is accountable for disabling or tuning a noisy source. Prevent this by assigning a named owner to each feed, setting a review cadence, and recording who can disable it. The feed register with owners and review dates shows the control is in place.

Integrations tied to a changing API

A SIEM connector, enrichment script or PyMISP automation is written against one API response shape or export format, then breaks after an upgrade changes it. Prevent this by pinning the PyMISP version, writing contract tests against restSearch output, and running them before each MISP upgrade. The test suite and its last passing run are the evidence.

No tested restore

Backups run on schedule, but the team has never restored the database and attachments to a separate host, so recovery time and missing components are unknown. Prevent this by restoring to an isolated server on a set cadence and comparing event counts and settings afterward. The restore test record, with dates, results and gaps, proves recovery works.

SSO without a role mapping plan

The OidcAuth plugin is connected to the identity provider, but identity roles are not mapped to MISP roles and organizations, so users receive the wrong access or are linked to existing accounts by email. Prevent this by writing the role and organization mapping table, setting role priority explicitly, and disabling unsafe account linking. The approved mapping table and a login test per role are the artifacts to check.

How the work changes by starting point

A new instance for one team usually has the narrowest scope. The main decisions are the installation method, a single organization with a small set of roles, and a basic sharing policy. Drivers that stay light here are the number of sync partners and the number of integrations.

Quote adds: server build on your chosen operating system, database and Redis setup, backup configuration, and a tested restore.
Quote adds: role and organization design for a single organization, plus a starter set of taxonomies, galaxies and default feeds, each enabled deliberately.
Quote removes: sync partner onboarding, cross-organization sharing groups and federated identity, unless you request them.
Ask for: a confirmed MISP release line (2.5 is the recommended line for new deployments) and a written list of which feeds will be enabled and why.
Confirm: who will administer the instance after handover and how much analyst training the quote includes.

What the client needs to provide

Before a MISP implementation starts, the client names two accountable people: a business owner who can decide what intelligence is shared and with whom, and a technical owner who can approve server access, network changes and identity settings. Without both, scope questions sit unanswered for weeks. Unresolved decisions on sharing and roles are the most common cause of rework, because distribution levels, sharing groups and organization roles are hard to change once events and sync partners are already connected.

The client also supplies an inventory of intelligence sources, including commercial feeds, ISAC or sector communities, internal detections and any existing threat intelligence platform, along with an estimate of expected event and attribute volume. Next, they provide the list of partner organizations that will sync with the instance, each with its sharing agreement, the data classes it may receive and the contact who approves changes. Taxonomies, default feeds and retention periods also need an owner's decision, since each one affects storage and what partners can see.

For technical setup, the client prepares the network and DNS plan, server or cloud accounts in its own infrastructure, and a TLS certificate process that covers issuance and renewal. If single sign-on is in scope, the identity provider details must be ready, including the OpenID Connect client registration, the claims that carry roles and the role names to map to MISP roles. Server sizing should be confirmed by the client's own infrastructure team against its hosting standards and expected volume, since database, Redis and worker needs depend on that environment.

Frequently asked questions

What drives the cost of a MISP implementation if the software is free?

Cost comes from people, infrastructure and ongoing operation, not from the license. MISP is licensed under the GNU AGPL version 3, so there is no license fee to set the price. The main drivers are server and database sizing, the number of organizations, roles and sharing groups, the distribution policy you must enforce, the feeds and integrations you connect, identity integration, hardening and testing. Ask any quote to separate one-time build work from recurring costs such as hosting, administrator time, upgrades and support.

Can our own team run MISP without an outside partner?

Yes, a capable team can install and operate MISP alone. The project provides an installer for Ubuntu 24.04, along with Docker images, Ansible roles, Puppet and RPM packages. The harder work is designing sharing policy, building integrations and applying security releases on schedule, so weigh those tasks against your team's available time. Paid support is available from the MISP project and from several third-party providers that offer commercial support. DeployOpen can plan and build the deployment in your infrastructure and support it under a retainer.

How long does a MISP implementation project take?

The timeline follows from the drivers of the work. The largest are the number of sharing partners and synchronization links, the number of integrations with SIEM, IDS and identity systems, and whether you are migrating from MISP 2.4 or another threat intelligence platform. The volume of existing data to clean and import, the number of approval cycles, and how quickly your team provides environment access and sharing decisions also matter. Fixed-scope engagements agree the schedule in writing before work starts, so ask for milestones and the dependencies on your side.

What must our organization provide before a MISP project starts?

Before work starts, your team typically provides access, decisions and reference details. Infrastructure: virtual machines or a cloud account in your environment, your approved operating system, DNS names, TLS certificates and network rules for sync partners. Identity: the OpenID Connect provider details if you plan single sign-on, and the mapping from identity roles to MISP roles. Policy: the organization model, sharing groups, distribution levels and rules for sensitive attributes, signed off by a named owner. Integrations: SIEM, IDS and sync partner details, plus sample data for testing.

Should a MISP implementation quote include feeds and integrations?

Yes, the quote should list each feed and integration by name, because they carry separate effort and separate costs. MISP ships with default intelligence feeds, taxonomies, warning lists and galaxies, so enabling and tuning them is configuration work. Connecting feeds from other sources, building integrations with SIEM, IDS, SOAR or ticketing tools, and configuring sync partners each take separate effort. Taxonomies and galaxy data are licensed under CC0 1.0 or the 2-clause BSD license, separate from the AGPL software license, and commercial feed subscriptions carry their own terms. Ask for an acceptance test for each item and state which subscriptions the client will hold.

Which MISP version should a new deployment plan for today?

Plan for MISP 2.5. The project recommends 2.5 for new deployments, while MISP 2.4 is end of life, receives security fixes only, and is not recommended for new installations. MISP 2.5 releases are frequent, so pin a current patch release at scoping and include an upgrade routine in the plan. MISP 2.5.47 introduced a new database migration system with PostgreSQL support, which is relevant if your database choice is still open. Confirm the current release with the project before you finalize scope.

How DeployOpen scopes and delivers MISP

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For MISP, that means the instance, its database and Redis services, and its sharing model all run where you control them, with the scope agreed in writing before work starts.

How we scope

Agree the written scope for server and database sizing, including the MISP version targeted, since 2.5 is the recommended line for new deployments.
Define organizations, roles, sharing groups and default distribution levels so sharing rules are fixed before any feeds or sync partners are connected.
List feeds, taxonomies, galaxies and integrations with security tools, and confirm which are in or out of the fixed-scope quote.

How we build

Install on the platform you choose, confirming the installer path and operating system support against the current MISP download guidance.
Configure correlation, sharing groups and sync filtering, then test that restricted attributes stay inside the intended organization.
Integrate identity, feeds and export consumers such as SIEM or IDS tooling, and test each integration against agreed sample events.

How we hand over

Deliver the written configuration record covering roles, sharing groups, sync partners, feeds, integrations and backup settings.
Provide runbooks for routine administration, upgrades, restores and onboarding a new organization or sync partner.
Walk your administrators through the running instance and confirm acceptance against the criteria written into the scope.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, with the scope of each agreed in writing.
Plan MISP upgrades and security releases around feed and sync partner maintenance windows, with tests run before production changes.
Confirm with the MISP project or a third-party provider whether commercial support is needed alongside a DeployOpen retainer.