MISP for government and national CSIRTs: what the instance has to do
A CSIRT team lead usually has a mandate to share indicators with constituents and peer teams, along with strict limits on who may see each one. MISP fits this work because it stores, distributes and correlates indicators, and it controls their reach through distribution levels and sharing groups that can be set on whole events or on individual attributes. For a national or government CSIRT, the build is mostly a set of governance, identity and synchronization decisions. Installing the software is the smaller task. Deciding who belongs to each sharing group, who may publish into which community and which peers receive which data takes most of the design time.
MISP is open source under the GNU Affero General Public License version 3, and the project is associated with CIRCL, the Computer Incident Response Center Luxembourg. The license lets the CSIRT run, inspect and modify the platform. Hosting is a separate matter. Running the instance, applying updates, managing backups and keeping the database and Redis services healthy becomes the CSIRT's own operational responsibility. Commercial support is available from the project and from third-party providers, but accountability for the instance, its data and its availability stays with the team that operates it.
Write the sharing model down before installation. Decide which distribution levels the community will use, which sharing groups exist, who may create or change them and which constituents or peer teams belong to each one. Link each decision to the CSIRT's mandate and to the legal or policy basis for every exchange. The aim is for the instance to enforce the policy through its configuration, so that a reviewer can trace any indicator's reach back to a documented rule.
Identity determines who can act inside those boundaries. MISP's OidcAuth plugin lets users sign in through an OpenID Connect provider and maps identity provider roles to MISP roles, assigning the first matching role by priority. Plan that mapping before go-live. Test each priority rule with accounts from every constituent group, and confirm that the identity provider can supply the attributes the mapping needs. Break-glass local accounts for administrators should also be planned, with a documented procedure for enabling and disabling them.
Synchronization determines what leaves the instance. MISP can synchronize events and attributes automatically with other MISP instances and trusted communities, so each outbound connection is a data flow the CSIRT must approve. For every peer, confirm which distribution levels and sharing groups are pushed, how pulled material is reviewed before constituents see it and how a connection is revoked quickly. Ask peers which MISP version they run. MISP 2.4 is end of life with security fixes only, and MISP 2.5 is the version the project recommends for new deployments.
What constituents, peers and auditors expect from the instance
This table lists the federal, sector and EU obligations that constituents, peer CSIRTs and auditors are likely to raise about a government MISP instance. Read each row as a question to settle before decisions on hosting location, identity, logging and sharing groups are made. The governing mandate sets the baseline, so confirm applicability before design starts.
| Requirement and source | What it asks for | What it means for the build | Confirm with legal or compliance |
|---|---|---|---|
| NIST SP 800-53 Rev. 5 control baselines | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively | Choose the baseline before design. It sets requirements for hosting, identity, audit logging and sharing group controls. | Yes, the mandating authority or agency sets the baseline |
| FISMA and Inspector General oversight | Inspectors General independently assess agency system security and report results to OMB | Expect assessors to test the instance itself. Keep control evidence, access reviews and audit logs ready for inspection. | Yes, confirm whether FISMA reaches this CSIRT and its systems |
| FedRAMP scope for cloud-hosted shared services | Cloud services that process federal information for an agency fall within scope, while single-agency use is excluded | A community instance offered to many constituents may count as a shared service. Settle the scope decision before choosing a cloud location. | Yes, confirm scope with the agency and current FedRAMP guidance |
| CUI handling under NIST SP 800-171 | Federal agencies apply NIST SP 800-171 to protect CUI on non-federal systems unless other safeguards apply | Sharing with agencies may bring the instance under 800-171 requirements. Confirm CUI categories before loading attributes or sharing with partners. | Yes, confirm CUI markings, contract terms and the required safeguards |
| NIS2 applicability and national security exclusion | Covers central government entities and public administration, but excludes national security, public security, defense and law enforcement | A civilian CSIRT may fall within NIS2, while a defense or police CSIRT may not. Scope drives incident reporting and governance duties. | Yes, confirm with the national transposition law and counsel |
Modules, sharing and sync settings that shape a CSIRT instance
A national or sector CSIRT instance is shaped less by installation than by a small set of configuration choices. The cards below cover the settings that control who sees what, which communities exchange data, how indicators are linked, how staff sign in, and how data leaves MISP. Decide each one before the first constituent is onboarded.
Distribution levels and sharing groups
Distribution levels set who can see an event, attribute or object, from the originating organization only up to all connected communities. Sharing groups let you name an explicit set of organizations and instances, down to individual attributes. In a CSIRT setting, decide which constituents may receive material from which sources, whether attribute-level distribution is needed for sensitive sources, and who may create or change sharing groups. Map these settings to your handling rules before onboarding, because a permissive default is harder to tighten once data has been synchronized outward.
Automatic synchronization with trusted communities
Synchronization pushes and pulls events and attributes between MISP instances, so your CSIRT can join peer and sector communities without manual exchange. Each connection carries a direction, a distribution filter and tag rules that decide what crosses the boundary. Before enabling it, confirm which communities your mandate allows you to join, who approves each new partner instance, what your filters exclude, and how you will revoke a partner's access. Start with a restricted filter and review the first batches of incoming and outgoing data.
Correlation engine and its controls
The correlation engine links events and attributes through exact matches and advanced patterns such as fuzzy hashes and CIDR overlaps. For a CSIRT, correlation shows when a new indicator matches older incidents, but it can also reveal that a sensitive case exists to users with broader access. Decide which attribute types are correlated, whether fuzzy and CIDR matching apply to your constituents' address space, and how links behave for viewers who lack access to the linked event. Confirm each control in the MISP version you deploy before relying on it.
OidcAuth role mapping and priority
The OidcAuth plugin lets users sign in through an OpenID Connect provider and maps identity provider roles to MISP roles. When a user holds several matching roles, MISP assigns the first match by priority, so the order of your mapping is an access control decision. Define which identity provider groups correspond to analyst, sharing approver, site administrator and read-only roles, and set the priority order so that privileged roles are not shadowed by broader ones. Plan how removing a group from the provider takes effect in MISP when staff change roles or leave the CSIRT.
Taxonomies, galaxies and MITRE ATT&CK
Taxonomies supply shared tags, warning lists and feeds add external intelligence, and galaxies cover threat actors, malware, ransomware, tools and MITRE ATT&CK. Taxonomy and galaxy data is licensed separately from the AGPL software, under CC0 1.0 Universal or the 2-clause BSD license, which matters if you redistribute tagged data. Decide which taxonomies your reporting standard expects, whether default feeds run on a community instance, and who curates local galaxy clusters so that ATT&CK mappings stay consistent across incident reports.
Exports, the API and misp-modules
Exports convert events into MISP JSON, STIX 1 and 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ, so detection and DNS controls can consume indicators without manual rework. The OpenAPI-described API, with restSearch and the bundled PyMISP library, drives the same data for automation, and misp-modules adds expansion, import, export and action modules that run beside the core platform. Decide which formats feed which sensors, who may call the API and with which keys, and which modules may make outbound requests from your network.
Choosing between a community instance and an internal instance
The first decision a national or sector CSIRT makes about MISP is where its sharing boundary sits. The CSIRT can run one community instance that constituents log into, run an internal instance that holds the CSIRT's own working data and synchronizes selected events outward, or operate both. Each choice assigns administrative rights, data ownership and analyst workflow differently, so the decision should be made before any installer is chosen. A single community instance makes the CSIRT the administrator of every organization and user on the platform. That gives the team direct control over organization onboarding, sharing group membership and role assignment, but it also makes the CSIRT responsible for the trust decisions of every constituent. An internal instance keeps administrative rights inside the CSIRT's own staff, and synchronization to peer communities is then a deliberate outbound step. Operating both splits responsibilities: the community instance serves constituents, while the internal instance serves the CSIRT's analysts, and the two must agree on what crosses between them. Sharing groups and distribution levels are where organization boundaries are drawn. MISP lets a CSIRT define custom sharing groups and set distribution down to individual attributes, so a single instance can hold data for many constituents without exposing one organization's events to another. Confirm during design which organizations may read, modify and republish each event, and test those rules with at least one account per organization. Note that a sharing group only controls what MISP shows; it does not decide what a constituent is permitted to share under its own law or contract. The CSIRT's own analysts feel the choice most directly. On an internal instance they work with full visibility of sensitive incident material and can enrich events without waiting for a community decision. On a community instance they often act as curators, reviewing constituent submissions before publication and maintaining correlation quality across tenants. Plan separate roles for these two tasks and decide who can publish to peers. The installation route (the Ubuntu 24.04 installer recommended for MISP 2.5, Docker images, Ansible roles, Puppet or RPM packages) should follow from this operating model, not drive it. Confirm the current installer guidance with the MISP project before you commit.
Compliance considerations for a government CSIRT instance
A government CSIRT instance can fall under several frameworks at once, and each one shapes how MISP is hosted, what is encrypted, and who can access the evidence. The cards below cover the frameworks that most often apply to a government or national CSIRT. For each one, DeployOpen prepares systems, controls and evidence, while independent auditors and certification bodies give the opinion.
NIST SP 800-53 baselines and OSCAL
NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B selects controls into low, moderate and high baselines of 149, 287 and 370 controls and enhancements respectively. NIST publishes these baseline profiles in OSCAL, a machine-readable format that lets the control mapping for a MISP instance be versioned and checked against each release. Choose the baseline early, because it sets the scope of logging, access control and backup. DeployOpen prepares the system boundary, control implementation statements and evidence. Auditors and assessors give the opinion on conformance.
FISMA and Inspector General reviews
Under FISMA, Inspectors General independently assess agency system security and report to OMB on a recurring cycle set by the agency. For a CSIRT that runs MISP as an agency system, the practical question is which controls the Inspector General will sample, such as account review, audit logging and vulnerability management, and where the evidence for each one is kept. Confirm the agency's assessment calendar and its system inventory entry with the information security office before the build starts. DeployOpen prepares the control evidence and system documentation. Inspectors General and auditors give the findings.
FedRAMP scope for shared cloud services
FedRAMP covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A MISP instance hosted by a cloud provider and offered to several agencies or constituents may fall within that scope. A system used only for one agency's own operations on cloud infrastructure, and not offered as a shared service, falls outside the scope set by OMB memo M-24-15. Decide who operates the hosting and whether the service is shared before selecting a cloud provider. DeployOpen prepares the service description, boundary and control evidence. FedRAMP authorizing officials and third-party assessors make the authorization decision.
CJIS Security Policy v6.1 requirements
If a CSIRT instance stores criminal justice information, CJIS Security Policy v6.1 applies. It took effect on 26 June 2026 and requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, up from 128-bit keys. It also requires vulnerability scanning at least monthly, which maps to controls SC-13, SC-28 and RA-5. Confirm early whether MISP events will contain CJI, since that decides whether these requirements apply to the whole instance. DeployOpen prepares the encryption configuration, scanning schedule and evidence. The CJIS system agency and auditors make the compliance determination.
CUI on non-federal systems
32 CFR 2002.14(h)(2) requires federal agencies to use NIST SP 800-171 when setting requirements to protect controlled unclassified information on non-federal information systems, unless the CUI category's authority prescribes other safeguards. A MISP instance that holds CUI in a partner's or contractor's environment inherits those requirements. Under 32 CFR 170.17(c)(5), a contractor seeking CMMC Level 2 may store CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. Confirm which CUI categories appear in shared events before choosing hosting. DeployOpen prepares the NIST SP 800-171 mapping, system security plan inputs and evidence. Assessors and the contracting agency decide conformance.
NIS2 scope for public administration
NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local public administration. It excludes entities working in national security, public security, defense or law enforcement, so the scope for a given CSIRT depends on its mandate and its national transposition. Confirm the transposition law and the entity's classification with the national competent authority before assuming obligations for the instance. DeployOpen prepares the risk management measures, incident reporting records and evidence. The competent national authority and auditors decide compliance.
How distribution levels and sharing groups enforce strict controls
In MISP, distribution levels and custom sharing groups decide what leaves the instance and who receives it. They can be applied to whole events and down to individual attributes, so a CSIRT can publish an event to its constituents while holding back one sensitive indicator inside it. For a government or national CSIRT, this attribute-level control is the main safeguard against over-sharing, and synchronization topology is only a second layer. Before onboarding any constituent or peer, document which distribution level and sharing group each data type uses, and who may assign them.
The following example is illustrative only. A CSIRT analyst records a phishing campaign as an event and shares it with a named constituent group in one sector. The event's command-and-control domains use the sharing group for that constituent group, but an internal sensor address in the same event is restricted to the CSIRT's own instance. A peer CSIRT that synchronizes with the instance is not a member of that sharing group, so it receives the event metadata and public indicators but never the restricted attribute. Confirm this behavior in a test before relying on it, since the outcome depends on how your organizations and sync permissions are configured.
Changes to a sharing group should follow a written review, not an ad hoc edit by whoever has access. Widening membership or distribution is the higher-risk change, because data that has already been pulled by a peer cannot be recalled from that peer. A reasonable process requires a written reason, a second reviewer from the CSIRT, approval from the data owner for the affected constituents, and a log entry that records the old and new settings. Ask your platform team to confirm which roles can edit sharing groups, whether changes are audited, and how the version you run handles attributes that have already propagated.
Test the restriction rather than assuming it. For each restricted attribute class, create a labeled test value in a non-production or dedicated test event, then confirm it is absent from the peer's synchronization pull, from API searches made with the peer's credentials, and from every export format the community uses, including STIX, CSV, and the detection formats such as Suricata or Snort where relevant. Repeat the tests after each sharing group change, sync configuration change, and upgrade, and keep the results with the change record. Check the exact sync filter options in the documentation for your MISP version.
Rollout for a national CSIRT community instance
This sequence takes a national or sector CSIRT from governance decisions to a MISP community instance that constituents can use and peer communities can sync with. Each step closes with a tested check and sign-off, so the handover rests on evidence. Hosting, identity and sharing controls are settled early because they are the hardest to change once users and sync partners depend on them.
Confirm scope and governance decisions
Before any server is built, the CSIRT's leadership and legal advisers decide which constituents the community serves, who may join, what the instance may hold, and who approves new members and sharing agreements. DeployOpen documents these decisions in a written scope with named owners for data classification, membership and escalation. The step is complete when the governance decisions are signed off and every open question in the scope document has a named owner.
Design hosting and identity
Choose where the instance runs, such as the CSIRT's own data center, a government cloud or an accredited hosting provider, and confirm that the location meets the CSIRT's classification rules for threat data. Then design identity: decide whether users sign in through the CSIRT's existing OpenID Connect provider, how identity provider groups map to MISP roles, and how administrators are kept separate from event contributors. The step is complete when the architecture, network zones and role mapping table are approved by the security team.
Install MISP 2.5 on the chosen platform
Install MISP 2.5, the version recommended for new deployments, because 2.4 is end of life with security fixes only and the project advises against new 2.4 installs. The project lists an Ubuntu 24.04 installer, Docker images, Ansible roles, Puppet and RPM packages, so choose the method your operations team can patch and back up. MISP 2.5.47 introduced a database migration system with PostgreSQL support. Evaluate PostgreSQL against the CSIRT's database standards and supportability before choosing it, and keep MySQL or MariaDB if the standard requires it. The step is complete when a clean install passes a test backup and restore.
Build the sharing group and role model
Create sharing groups for each constituent set and for each peer community, and set default distribution levels so events do not travel further than the governance decisions allow. Define roles around duties, such as publishers, reviewers, synchronization administrators and read-only analysts, giving each only the permissions that duty needs. Test a sample event at every distribution level using test accounts to confirm that sharing behaves as the scope document specifies. The step is complete when the test matrix passes and the security lead has approved the role model.
Run a pilot with a small constituent group
Invite a small group of trusted constituent teams, ideally from one sector, to publish and consume events for a trial period set in the scope document. Collect feedback on usability, false positives, distribution mistakes and whether the exported formats work with the teams' detection tools. Log each issue in a tracker with an owner and a fix. The step is complete when the pilot exit criteria in the governance document are met and the CSIRT decides whether to widen membership.
Onboard peer synchronization in stages
Start synchronization with peer CSIRT and trusted communities only after the sharing groups have held up in the pilot. Exchange connection details through the agreed channel, confirm how certificates or keys are issued and renewed, and begin with a restrictive sync filter so only expected tags and distribution levels flow in. Verify that a test event created on one side arrives on the other with its distribution and tags intact, and that out-of-scope events are rejected and logged. The step is complete when the documented test event round-trips correctly in each direction.
Hand over the instance with runbooks
Transfer the instance to the CSIRT's operations team with runbooks covering updates, backups and restores, user onboarding, sync failures, certificate renewal, platform incident response and the process for adding a constituent. Each runbook refers back to the decisions recorded in the scope document. Run a walkthrough in which the operations team performs a restore and an update in a test environment without assistance. The step is complete when both tasks succeed and the support arrangement, internal or from a commercial MISP support provider, is written down.
Keeping the instance patched, backed up and reviewed
The recurring work on a government or national CSIRT instance decides whether it stays trusted after go-live. Design, onboarding of constituents and documentation are largely one-time costs, paid once and revisited only when the design changes. Patching, access reviews, backups, scanning and peer management repeat for as long as the instance serves users, so they belong in a written operating calendar with a named owner for each task. Before hand-over, ask your team or your partner to write that calendar down, including who approves an upgrade and who can take a sync peer offline. Without it, the instance tends to drift into an older release with stale accounts and unmonitored peers.
Version currency comes first. MISP 2.5 is the recommended version for new deployments, and MISP 2.4 is end of life with security fixes only, so an instance still on 2.4 needs a planned move. The project provides an upgrade script for Ubuntu, and MISP 2.5 is recommended on Ubuntu 24.04 with the provided installer. Current 2.5 releases move quickly. MISP 2.5.47, released on 17 September 2026, introduced a new database migration system with PostgreSQL support, and MISP 2.5.50 followed on 9 October 2026. Schedule each upgrade in a staging copy first, read the release notes for migration steps, and confirm which database engine your instance uses before you choose a target. Treat every migration as a change that needs a tested rollback point.
Two reviews repeat on a schedule. The first is vulnerability scanning. The FBI CJIS Security Policy version 6.1, effective 26 June 2026, calls for vulnerability scanning at least monthly under control RA-5 where criminal justice information is in scope. Confirm with your compliance lead whether that cadence or another one applies to the MISP host, its operating system and its supporting services. The second is access and sharing group review. Check user accounts, roles, sync permissions and sharing groups against the current constituent list, remove accounts for people who have left, and confirm that each sharing group still matches an agreed community rule. Record who signed off each review, since assessors ask for the evidence.
Backups and sync monitoring protect against the failures that are hardest to see. Back up the database (MySQL or MariaDB, or PostgreSQL if you run it), the MISP configuration files and the attachment storage, and test restores on a schedule, because an untested backup is only a hope. For sync health, track whether pulls and pushes with each peer succeed, watch for peers that have stopped responding, check background worker jobs for failures, and confirm that Redis is available. Decide in advance who responds to each alert and which peer is disconnected first when a partner community misbehaves, so the response does not wait for a meeting.
Recurring effort rises with a small set of drivers: the number of constituents and organizations with accounts, the number of sync peers and communities, the number of sharing groups and distribution rules, whether single sign-on through the OidcAuth plugin or custom modules are in use, whether the instance still runs 2.4, and how often your regime requires scanning. Ask any partner for a quote that lists patch and upgrade cycles, review cadence, backup testing, sync monitoring and peer onboarding as separate lines, and state who handles emergency patches. DeployOpen offers ongoing support and upgrades as retainers, and the scope, response expectations and exclusions should be agreed in writing before the work starts.
What government and national CSIRTs ask before hiring help with MISP
What drives the cost and effort of hosting a MISP community instance?
Scope drives most of the cost. MISP is licensed under the GNU AGPL version 3, so the software itself carries no licence fee, and the spend goes to people and infrastructure. Main drivers: the number of constituent organizations you onboard, how many feeds and synchronization links run, the identity integration, the hosting model in your own cloud or data center, and how much 24/7 operational responsibility the CSIRT keeps. One-time costs usually include design, installation, integration and onboarding. Recurring costs usually include hosting, patching, upgrades, backups, monitoring and support. Ask any quote to show these lines separately so you can see what continues after launch.
How long does it take to stand up a national CSIRT MISP instance?
The build is rarely the longest phase. Timelines are set by decisions the CSIRT must make before engineering starts: governance over who may join and what each sharing group may see, the identity provider integration, peer and community agreements, and the hosting location and approvals. Installation on a supported release is the quick part. Onboarding and testing synchronization with partners take longer, because each peer connects on its own terms. DeployOpen does not publish durations in advance because they depend on the scope. Ask for a written schedule that marks which milestones wait on your governance, identity and legal inputs. A fixed-scope agreement fixes scope, deliverables and timeline in writing before work begins.
What must a CSIRT provide before hiring a partner for MISP?
Governance decisions, identity access, peer agreements and hosting come first. Governance: who may be an organization in the community, which distribution levels and sharing groups apply, and who approves publication of sensitive indicators. Identity: administrative access to your OpenID Connect provider, so the OidcAuth plugin can map provider roles to MISP roles, with the first matching role assigned by priority. Peers: signed sharing terms with each partner CSIRT or community before synchronization is enabled. Hosting: a target environment in cloud accounts or data centers you control, with network access, storage, backup location and monitoring. Confirm each item in writing early, since missing inputs delay the build.
Can our internal team run MISP without outside help?
Often yes, if the team already operates Linux servers, databases and web applications, and can own the platform for its whole life. MISP runs on PHP with CakePHP, MySQL or MariaDB and Redis. The project recommends MISP 2.5 for new deployments and lists an installer for Ubuntu 24.04, plus Docker, Ansible, Puppet and RPM options. The harder parts are repeatable upgrades, since MISP 2.4 is end of life and receives only security fixes, and sustained sharing governance. Assess the gaps honestly: who handles patching within your service targets, who reviews sharing rules, and who covers absence. Outside help makes sense when those roles cannot be staffed continuously.
Do MISP paid support or third-party providers change the picture?
They change who is accountable for which tasks, but they do not replace the decisions your CSIRT owns. The MISP project offers paid support services, and it states that a number of third-party providers offer commercial support. Ask each vendor what its contract covers: the platform version, your customizations, your modules, your hosting and your sharing governance. DeployOpen's work covers planning, customization, integration with your identity provider and incident tools, hardening, backup design and documentation inside infrastructure you control. Recurring vendor contracts and DeployOpen retainers can overlap or leave gaps, so define the boundary between them in writing.
What should a quote for a MISP hosting engagement include?
A quote should follow from a written scope, since DeployOpen does not publish a price list. Ask for the deliverables, such as architecture, installation, identity integration, sharing group design, synchronization setup, backup and restore testing, and documentation. Also ask for the assumptions about your environment and the inputs you must supply, a split of one-time and recurring costs, and the upgrade and support terms, including who performs each MISP version move. Look for responsibilities by party, change control for scope additions, stated exclusions, acceptance criteria for each milestone, and whether third-party costs such as cloud resources or adjacent tool licences are included or listed separately.
Which MISP version should a new CSIRT deployment target?
MISP 2.5 is the version the project recommends for new deployments. MISP 2.4 is end of life and receives security fixes only, so do not install new 2.4 instances. Confirm the current 2.5 point release at the time of build. For example, 2.5.50 was released on 9 October 2026. Release 2.5.47 introduced a new database migration system with PostgreSQL support, so decide early between MySQL or MariaDB and PostgreSQL based on your operations standards, and test the migration path. Plan a supported upgrade route from the start, including staging tests, backups before each move and a rollback plan.
How DeployOpen scopes and delivers a CSIRT MISP instance
DeployOpen plans, implements, hardens, documents and supports MISP inside infrastructure you control, including cloud accounts, data centers or air-gapped networks. For a national or sector CSIRT, the work starts with written decisions about community membership, distribution controls and synchronization, because those choices shape everything built afterward.
How we scope
- Written scope covers the constituent community, sharing groups, distribution levels and the peer CSIRT and NATO communities the instance will synchronize with.
- Scope records which MISP version, installation method and database option the team will run, confirmed against the current MISP download guidance.
- Scope sets identity and single sign-on requirements, including how identity provider roles map to MISP roles through the OidcAuth plugin or another agreed method.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before build work begins, with a quote following from that scope.
How we build
- Installation is done on the platform your hosting rules require, using the supported installer, container images or configuration management method your team selects.
- Sharing groups and synchronization links are configured and tested with sample events before any constituent data flows between communities.
- Export formats, feeds, taxonomies and misp-modules are enabled only where the community's workflows need them, and each is tested against the target tools.
- Security controls for the database, Redis, TLS, backups and administrative access are implemented and checked against the agreed control baseline for your jurisdiction.
How we hand over
- Handover includes runbooks for user onboarding, sharing group changes, synchronization troubleshooting and version upgrades specific to your instance.
- Documentation records the distribution model, role matrix and data flows, giving assessors and auditors the evidence they need from your own records.
- Backup and restore procedures are demonstrated in your environment, with the results written down so your operators can repeat them.
- Your team receives knowledge transfer sessions covering daily administration, so that operation does not depend on a single DeployOpen engineer.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering patching, version moves and synchronization health checks.
- Upgrade planning considers the end-of-life status of older MISP releases and any database migration steps required by newer versions.
- Periodic security testing of the instance, its API and its integrations can be scheduled alongside operational support under the same written agreement.
- Ask any partner, including DeployOpen, to confirm in writing which support hours, response commitments and escalation paths are included before you sign.
