How MISP fits NIS2 information-sharing arrangements
If you are an essential or important entity, or a supplier to one, MISP can run the sharing mechanics you would need to take part in a community: sharing groups, distribution levels and synchronization between instances. NIS2 does not make that work for you, however. Article 29 makes participation in cybersecurity information-sharing arrangements voluntary, and the Directive creates no certificate that a MISP instance or a community membership can earn. The decision to join is a governance decision for leadership and legal teams, supported by a technical check of what the platform can share and with whom. Confirm the arrangement's rules before any synchronization is configured.
Article 29(4) requires essential and important entities to notify their competent authority when they join an information-sharing arrangement and when their withdrawal takes effect. Those two dates are the minimum record the authority will expect to see, so capture them as controlled events in your governance log: the arrangement name, the sharing groups and synchronization links it maps to, the date of joining and the date withdrawal takes effect. Confirm with your authority which channel and form it uses, and whether national transposition law adds detail. DeployOpen can prepare the MISP configuration, access records and change history that support these notifications. DeployOpen does not issue attestations, and the notification itself remains your organization's obligation.
Article 29(2) places exchanges within communities of essential and important entities and, where relevant, their suppliers or service providers. The information in scope under Article 29(1) includes cyber threats, near misses, vulnerabilities, indicators of compromise, adversarial tactics, threat-actor information and detection configuration recommendations. Map each category to a sharing group and a distribution level before you enable synchronization. A useful check is to send a test event through the planned distribution and confirm that only the intended instances receive it, and that attribute-level controls hide anything the arrangement does not cover. Record the mapping, because your team will need it when the arrangement's rules change.
Keep voluntary notification under Article 30 separate from information sharing under Article 29. Article 30 lets entities notify incidents, cyber threats and near misses voluntarily, and that voluntary reporting imposes no additional obligations on the notifying entity. Mandatory incident reporting under Article 23 is a different workflow with its own deadlines, so do not let a MISP event become the only record of a reportable incident. For the technical evidence side, ENISA's June 2025 non-binding guidance on Implementing Regulation (EU) 2024/2690 gives examples of evidence and mappings to ISO/IEC 27001:2022 and NIST CSF 2.0, which can help you decide what your sharing records should show. Confirm whether that regulation applies to your entity type.
The legal basis is still moving. The Commission proposed targeted amendments to NIS2 on 20 January 2026 (COM(2026) 13), and those amendments need approval by the European Parliament and the Council before they take effect. Member States had to adopt national transposition measures by 17 October 2024, so your obligations may be set by national law that goes beyond the Directive text. Before you commit to a community, confirm the current text of the Directive, your national transposition law and any guidance from your competent authority, and record the date you checked. Build a review point into your sharing governance so that a change to Article 29 or to national rules triggers a documented reassessment of sharing groups and notifications.
Mapping NIS2 Article 29 requirements to MISP capabilities
This table maps each NIS2 Article 29 and Article 30 point to the MISP capability that supports it, the configuration it needs and the decision the entity must still make. Read each row as a support question: MISP handles distribution and exchange, while the legal duties depend on national transposition and on decisions the organization makes. The main takeaway is that no MISP feature satisfies a notification or reporting duty on its own.
| Requirement | MISP capability | Configuration it needs | Entity must still decide |
|---|---|---|---|
| Article 29(1): threat information and indicators of compromise | Events and attributes carry distribution levels, and sharing groups can scope them to named organizations | Set distribution per event and attribute, use sharing groups for named partners, enable sync only with agreed peers | Which categories of threat information are shared, and with which communities |
| Article 29(1): adversarial tactics and threat-actor information | Taxonomies, warning lists and galaxies cover threat actors, malware, tools and MITRE ATT&CK | Enable the relevant galaxies and taxonomies, and tag events so recipients can filter them | Whether attribution is shared, given the confidence and sensitivity of the assessment |
| Article 29(1): detection configuration recommendations | Exports include Suricata, Snort, Zeek and RPZ formats | Export only to consumers that run these tools, and review generated rules before deployment | Who approves detection content before it reaches production controls |
| Article 29(2): community membership, including suppliers | Sharing groups and sync can extend to organizations outside your instance, such as suppliers | Create one sharing group per community and add supplier organizations with an explicit, limited scope | Which suppliers or service providers join, and the trust terms that apply to them |
| Article 29(4): notification on joining and withdrawal | MISP records sync connections and sharing group membership in its own data | Keep a dated record of each sync connection and membership change, and remove access when withdrawal takes effect | Who notifies the competent authority, when, and through which national channel; confirm this with the authority |
| Article 30: voluntary notification | MISP does not perform voluntary incident reporting to authorities by itself | Keep the reporting workflow separate from community sharing, and restrict distribution of draft content | Whether to report, what to include and which route to use; confirm the format and channel with the authority |
Configuring MISP to join a sharing community
This sequence takes a self-hosted MISP instance from installation to a tested connection with a sharing community. Each step produces a record you can show community operators and your competent authority, including the running version, the access model, the sharing rules and the test results.
Install MISP 2.5 with your chosen method
Your platform or infrastructure team installs MISP 2.5, 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. The project offers a provided installer for Ubuntu 24.04, Docker images, Ansible roles, Puppet and RPM packages. Choose the option that matches your existing operations standards for configuration management, patching and backups. The step is done when the web interface and API respond on the intended host, the version shown matches 2.5, and the installation is recorded in your change system.
Connect authentication through OidcAuth
The identity team configures the OidcAuth plugin so users sign in through your OpenID Connect single sign-on provider. Map identity provider groups or roles to MISP roles. The plugin assigns the first matching role by priority, so confirm the priority order with the people who own the roles before you enable it. Keep a local administrator account for recovery, stored under your privileged access controls and tested before go-live. The step is done when a test user from each group receives the expected MISP role and an account without a mapped group cannot sign in.
Define roles and organization identity
The MISP administrator creates the organization record that represents your entity and the roles that define what each user may do, such as reading events, creating events, publishing and administering synchronization. Keep the number of administrators small and assign publishing rights only to people who handle sharing decisions. Confirm the organization name and identifiers with the community operator, because they appear on every event you share. The step is done when a review of the role matrix with your security lead is signed off and each role has a named owner.
Create sharing groups and distribution rules
The MISP administrator defines sharing groups for the audiences you intend to reach, such as the community, your suppliers or service providers, and internal teams only. MISP sets distribution levels on events and attributes and can apply custom sharing groups down to individual attributes. Document which distribution level applies to each category of information, and agree with the community how it will read the sharing group labels. The step is done when a test event set to each distribution level is visible only to the audiences you specified.
Decide what gets published and shared
The security operations lead, with legal and data protection input, decides which event types and attributes leave your instance. Address indicators of compromise, vulnerabilities, threat actor information and detection recommendations separately, and set rules for personal data, customer data and internal hostnames. Use the traffic light protocol markings and tags your community expects, and confirm the attribute types the community accepts. The step is done when a written publication policy exists, the tags are configured, and an export or sample event shows that restricted attributes are excluded or flagged for review.
Configure synchronization with trusted community instances
The MISP administrator adds the community's trusted instances as synchronization servers, using connection details and credentials supplied by the community operators through a secure channel. Decide for each server whether your instance pulls, pushes or both, and set filters so only the agreed sharing groups and tags move. Use a dedicated synchronization user with the minimum role needed. The step is done when a connection test succeeds on each server and a synchronization run completes with the expected events, without errors in the job log.
Test with non-sensitive events before go-live
Before any operational intelligence flows, the team creates non-sensitive test events, such as a harmless example indicator marked for the test sharing group. Confirm that the test event reaches the community instance with the correct distribution, that correlation behaves as expected, and that a withdrawal or deletion propagates. Record each result with a date and tester name. Ask the community operators to confirm receipt on their side. The step is done when every test case passes and the operators have acknowledged the results in writing.
Notify the competent authority on joining
Under NIS2 Article 29(4), essential and important entities must notify their competent authority when they join an information-sharing arrangement and when their withdrawal takes effect. Confirm with your national authority the form, channel and timing of the notification, because the Directive sets the obligation and national transposition laws set the procedure. Keep a copy of the notification, the community agreement and the test records in your compliance evidence store. The step is done when the authority has received the notification and the record is filed with the sharing configuration.
Evidence MISP produces for auditors and supervisors
Each record below is a MISP artifact a reviewer can request to test how information sharing actually happened. Together they show what was shared, with whom, under which rules and by which accounts. Confirm with the competent authority which records it expects and how long they must be kept.
Event and attribute history
MISP stores events and attributes with their distribution level, sharing group, tags and timestamps. For a NIS2 review, this history shows which indicators the entity received, shared or withdrew, and when. Check which change history your MISP version keeps, confirm that it is enabled on your instance, and agree with the authority which fields it will want to see and for how long.
Sharing group definitions
A sharing group names the organizations allowed to receive an event or attribute and lists the instances it covers. Keep a dated copy of each definition, including every membership change, so you can show who belonged to a community when a given event was shared. This record supports the notifications NIS2 Article 29(4) requires when joining or withdrawing. Confirm whether the authority expects membership lists or only group names.
Synchronization configuration
Synchronization settings record which remote MISP instances or communities your instance pulls from and pushes to, and which distribution levels each connection allows. Export these settings regularly and keep them under change control, because they document the technical route that shared information took. Confirm with the authority and your arrangement operator which connections count as part of the arrangement.
User and role assignments
Each MISP user holds a role that controls what they can read, publish and administer. When sign-in runs through the OidcAuth plugin, identity provider roles map to MISP roles, and the first matching role by priority is assigned. Export the role definitions and user assignments on a schedule so you can show who could share information on a given date. Confirm the access review cadence the authority expects.
Exports in MISP JSON and STIX
MISP exports events in MISP JSON, STIX 1 and 2, OpenIOC, CSV and other formats, and its API supports restSearch. Exports give a reviewer a portable copy of shared content outside the platform. Test that each chosen format still carries distribution and sharing group fields, and confirm with the authority which formats it accepts before you set up a regular export routine.
Keeping evidence current as communities and MISP change
Evidence that your organization joined a sharing arrangement only stays useful if it still matches the instance. Treat every edit to a sharing group or synchronization connection as a change with a record. Each record should name the sharing group or sync partner, the distribution settings affected, the person who approved the change, the date it took effect and the reason. When an edit follows a joining or withdrawal, link the change record to the notice sent to the competent authority under NIS2 Article 29(4). Without that link, an auditor cannot tell whether the instance's sharing behavior matched what was notified.
Community membership changes without anyone deciding it. Partners leave communities, sharing terms are revised and sync peers are retired. Set a review interval in your own policy and check, at each review, that every sync partner still belongs to the community you notified, that the people who can publish to each sharing group still need that access and that the connections match the arrangement's written terms. Confirm with your national transposition law and the competent authority how withdrawal must be notified and when it takes effect, then record the effective date in MISP's change log and in your own register.
Keep the joining and withdrawal notices themselves, together with proof of sending, any acknowledgement the authority or community returns and the terms you accepted. The retention period should come from your records policy and national requirements, so confirm it with your legal or compliance team instead of assuming one. Pair the notices with a dated export or configuration snapshot of your sharing groups and sync settings at each notice date. Settings change over time, and the snapshot shows what was in force when you notified.
Upgrades change the platform that produces this evidence, so plan them as controlled changes. MISP 2.4 is end of life and receives security fixes only, and the project strongly advises against installing new 2.4 instances. MISP 2.5 is the recommended version for new deployments. MISP 2.5.47, released on 17 September 2026, introduced a new database migration system with PostgreSQL support. Read the 2.5 release notes and check that migration path before writing an upgrade plan, because it affects your backup, rollback and change records. Record the version before and after each upgrade, and test sync and sharing group behavior in a staging copy first. MISP 2.5.50, released on 9 October 2026, is the latest release at the time of writing, so confirm the current version before you start.
What MISP does not cover for NIS2
MISP covers the technical side of sharing: sharing groups, synchronization, correlation and the records they produce. The items below sit outside the platform. Each is a decision, notice or obligation that a named owner in your organization holds, and DeployOpen can prepare evidence for each one while the compliance determination stays with the entity.
Essential or important classification
Whether the entity is essential or important under Article 3 depends on its sector, size and role, and on the national rules that apply to it. MISP cannot make that determination. Legal or compliance normally owns it, often with outside counsel. Confirm the classification in writing before joining a sharing arrangement, because it sets the supervision regime that follows under Articles 32 and 33. DeployOpen can document the asset and service inventory that feeds this review, but the classification itself is the entity's decision.
Risk management under Article 21
Article 21 requires risk-management measures, and Implementing Regulation (EU) 2024/2690 sets detailed technical and methodological requirements for the listed relevant provider types, including DNS, cloud, data center, managed and online platform providers. The CISO or security governance function normally owns these measures, with the board accountable for approval. MISP supplies threat intelligence that informs risk assessments, but the policies, risk analysis and control design remain the entity's responsibility. DeployOpen can prepare evidence such as configuration records and access logs for that review.
Incident reporting under Article 23
Article 23 sets the reporting duties for significant incidents, which go to the competent authority or CSIRT on defined timelines. A MISP event is not a notification. The incident response lead normally decides what counts as significant and what gets reported, and legal reviews the content of each notice. Shared indicators add context to an incident but do not replace the reporting process. Check that your reporting runbook names who sends each notice and where timelines and submissions are recorded. DeployOpen can help assemble the incident evidence trail.
Decision to join or withdraw
Joining a sharing arrangement is a legal and governance choice. Legal and an executive sponsor normally own it, and they should review community terms, data handling, liability and what the entity agrees to share. Article 29(4) requires notifying the competent authority when the entity joins and when withdrawal takes effect. MISP can enforce sharing groups and synchronization settings, but it does not hold the membership decision or send the notice. Keep a dated record of both the decision and the notification, and plan the technical steps that end sync and remove shared data on withdrawal. DeployOpen can prepare the configuration and records that support the decision.
Supervision by the competent authority
Competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines under Articles 32 to 34. NIS2 creates no certificate of compliance. Essential entities face ex ante supervision and important entities face ex post supervision. The compliance or regulatory affairs lead normally owns these interactions and the responses. A MISP instance may be examined for access controls, logs and sharing configurations, so keep those records retrievable. Ask counsel what your national authority expects. DeployOpen can prepare evidence packs for supervisory requests but does not represent the entity.
National transposition rules
NIS2 is a directive, so obligations reach entities through national laws. Member States had to adopt and publish transposition measures by 17 October 2024 and apply them from 18 October 2024, and Article 5 allows Member States to keep or adopt rules that ensure a higher level of cybersecurity. Local rules can add requirements or name a different authority. The Commission's proposal COM(2026) 13 would amend NIS2 but remains a proposal pending approval by the European Parliament and the Council. Legal or regulatory affairs should own the mapping and confirm the current text before any design decision.
Questions buyers ask before hiring help with MISP and NIS2
How much does a MISP information-sharing setup cost?
DeployOpen does not publish a price list. A quote follows from a written, fixed scope, and the main cost drivers are:
- Scope: number of MISP instances, environments and the sharing groups to design.
- Sync partners: each partner needs trust setup, testing and monitoring.
- Identity integration: single sign-on through OpenID Connect and role mapping.
- Hosting: the infrastructure you control, which you usually pay for directly.
- Testing and documentation: verification of sharing rules and records for your evidence file.
One-time work covers design, build and onboarding. Recurring costs include hosting, upgrades, feed maintenance and any support retainer. Ask each quote to list these lines separately, state its assumptions, and say what is excluded.
How long does it take to set up MISP for sharing?
No duration can be given before the scope is agreed. Timing depends on the number of partners, how many sharing agreements are already signed, identity integration, and how quickly your teams review designs and test sync. Agreement negotiation with other communities is often the slowest step, and it sits partly outside any implementation partner's control. Fixed-scope engagements are agreed in writing with deliverables and timelines before work starts, so ask for milestones tied to each partner going live. Ask your partners for their own change windows and testing availability early, because those dates often set the final schedule.
What does our organization need to provide for a MISP sharing project?
Four inputs decide whether the project moves on schedule:
- Named owners: a technical owner for the platform, a policy owner for sharing rules, and a named contact for the competent authority.
- Community agreements: signed terms with each sharing community or partner, including who may receive which data.
- Network access: outbound connectivity to sync peers, DNS, certificates, and your identity provider, with firewall changes approved in advance.
- Sample data policy: what sample events may be used in testing, how they are labeled and how personal or sensitive fields are removed.
Agree these inputs in the written scope so that delays on your side are visible and traceable.
Can our internal team set up MISP without outside help?
Often yes, if the team already runs Linux services in production. MISP is built on PHP with CakePHP, MySQL or MariaDB, and Redis, and the project recommends MISP 2.5 for new deployments, with an installer for Ubuntu 24.04. The harder parts are rarely the installation itself. They include designing sharing groups and distribution levels, setting up synchronization with partners, mapping identity provider roles to MISP roles, handling sample data safely, and keeping up with upgrades, since MISP 2.4 is end of life. Assess your team's skills against those tasks, and consider a short pilot with one partner before connecting the full community.
Does NIS2 require a MISP certificate or certification?
No. NIS2 does not create a certificate of compliance, and MISP itself is not a certification. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as described in Articles 32 to 34 of the directive. Information sharing under Article 29 is voluntary. Your obligation is to notify the competent authority when you join an arrangement and when your withdrawal takes effect, under Article 29(4). If a customer or auditor asks for evidence, independent auditors and certification bodies, not DeployOpen, issue any audit report or certification for a standard you choose.
Can DeployOpen confirm that our national authority accepts the arrangement?
No. DeployOpen cannot confirm acceptance by any authority. The notification duty under Article 29(4) belongs to your organization, and national transposition laws and authority procedures differ between Member States. Ask your competent authority in writing what it requires, which form or channel it uses, and what technical description it expects. DeployOpen can help prepare the technical description of your MISP setup, the sharing group design and the supporting records, based on the written scope. The decision on acceptance stays with the authority.
What breaks when MISP sync partners change their sharing rules?
Sync failures usually come from configuration drift rather than from MISP itself. Common causes include expired certificates or API keys, version mismatches between instances, a sharing group that a partner removed or renamed, and distribution levels that filter out events you expected to receive. Check sync logs after every partner change, test one known event end to end, and confirm version compatibility before upgrading either side. Record each change with its date and owner, so that the sharing history can be explained later to your authority or auditor.
How DeployOpen scopes and delivers MISP information-sharing work
DeployOpen plans, builds and hands over self-hosted MISP instances in infrastructure you control, so your team can join a cybersecurity information-sharing arrangement with sharing groups, synchronization and access rules set up before the first exchange. Each engagement starts with a written scope, and the record of joining and withdrawal dates is part of what we document.
How we scope
- The written scope names the sharing communities, distribution levels and partners your instance will exchange with.
- We confirm with your legal and compliance leads which arrangement you join and the notice steps your national law sets.
- Fixed-scope engagements are agreed in writing before work starts, and ongoing support is available as a retainer afterwards.
How we build
- We install MISP 2.5 on infrastructure you control, with database, Redis, backup and TLS settings documented.
- Sharing groups, distribution levels and synchronization links are configured and tested with a trusted peer before any production exchange.
- Single sign-on through OpenID Connect can map your identity provider roles to MISP roles, so access follows your existing governance.
How we hand over
- Runbooks cover synchronization health checks, sharing group changes, feed handling and how to suspend a peer connection.
- A joining and withdrawal record lists dates, partner communities and the notice sent, to support your competent authority notification.
- Test evidence, configuration exports and admin training are delivered in the handover package agreed in the written scope.
How we support
- Retainers can cover MISP upgrades, including the move from 2.4 to 2.5 where an older instance is still in service.
- Ongoing work can include monitoring sync failures, reviewing sharing group membership and updating the handling procedure when national rules change.
- Separate retainers can cover continuous security testing of the MISP instance and its integrations.
