Open source threat intelligence for DORA information sharing

How open source threat intelligence supports DORA information sharing

A financial entity that wants to share threat intelligence under DORA can do so through trusted communities, and a self-hosted MISP or OpenCTI instance can serve as the technical base for that sharing. Article 45(1) permits financial entities to exchange indicators of compromise, tactics, techniques and procedures, cyber security alerts and configuration tools, provided the sharing aims to enhance digital operational resilience and runs through arrangements that protect the sensitive nature of the information. The arrangements must follow rules of conduct covering business confidentiality, the GDPR and competition policy guidelines, so the protective rules matter as much as the software.

DORA sets no certification scheme for this activity, and no product carries a DORA certificate. The Regulation has applied since 17 January 2025 and is directly applicable in all member states, so there is no national transposition to wait for. The obligations that follow are governance obligations and a notification duty: under Article 45(3), the entity notifies its competent authority of its participation once membership is validated, and again when membership ends. Buying a platform does not discharge either duty. Before choosing between MISP and OpenCTI, the entity should confirm with its competent authority which notification form and content it expects, and which communities it intends to join.

The practical work sits in governance and configuration. Define the conditions for participation, the sharing groups and distribution levels that map to each community, the handling rules for indicators that contain personal data, and who approves what leaves the instance. Ask an implementation partner to show how the chosen platform records membership, sharing decisions and changes so that the evidence for the authority can be produced on request. Confirm the platform licence terms for your use, since MISP is licensed under AGPL-3.0 and the OpenCTI Enterprise Edition uses a separate licence. Those decisions should be written down before the first event is shared.

Mapping DORA requirements to platform functions and configuration

This table maps each DORA provision on threat information sharing and intelligence gathering to what a self-hosted MISP or OpenCTI instance must do and how to configure it. Read each row as a control question: the requirement, the platform function that answers it, and the configuration evidence an assessor will ask to see.

Requirement	What the platform must do	How to configure it
Article 45(1): sharing within trusted communities	Exchange indicators of compromise, tactics, techniques and procedures, and alerts only with a defined community of financial entities	Create one sharing group per community, restrict synchronization to its member instances, and document each member and its onboarding approval
Article 45(1)(b) and (c): protection of sensitive information and governance rules	Keep shared content limited to the intended recipients and enforce the community's rules of conduct on confidentiality, GDPR and competition policy	Set distribution levels per event and attribute, apply TLP tags consistently, and disable automatic publication to wider audiences unless the community rules allow it
Article 45(2): participation conditions and operational elements	Support defined entry conditions, optional public authority or third-party involvement, and a dedicated platform for the arrangement	Record admission criteria in the sharing agreement, configure sync only after validation, and document any service provider with access to the instance
Article 45(3): notification of membership start and end	Provide dated records that show when membership was validated and when it ended, so the entity can notify its competent authority	Keep a sync-partner register with validation and termination dates, and remove sync connections and sharing group access on the end date
Article 13(1): gathering vulnerability and threat information	Collect feeds, community intelligence and internal observations, and assess their likely impact on the entity	Enable default and selected feeds, map events to MITRE ATT&CK galaxies, and assign owners who tag relevance to financial services systems
Article 13(2): inputs to post-incident reviews	Keep a timeline of indicators, related events and analyst actions that a review can test for promptness and forensic quality	Retain events with timestamps and attribution, link them to incident records, and export their history for the review file
Article 13(6): training for staff and senior management	Provide a controlled environment where analysts and managers practice using shared intelligence	Use a separate non-production instance or sample events, restrict training access to named roles, and log completion records in the training programme

MISP or OpenCTI for a DORA sharing arrangement

MISP is the platform most often used to exchange indicators inside a trusted community. It is licensed under AGPL-3.0, so the software can be self-hosted and modified under that license, and the project notes that interlocked copyright among contributors prevents any single entity from changing the license model. For a DORA Article 45 arrangement, MISP's sharing controls matter most: distribution levels and custom sharing groups can be set down to individual attributes, so you can limit what leaves your instance and to whom. Automatic synchronization with other MISP instances lets you exchange events with trusted peers.

Sharing groups: Define who receives each event or attribute, which supports the confidentiality rules Article 45 expects.
Attribute-level control: Restrict sensitive indicators without withholding the whole event.
STIX and standard exports: Share in STIX 1 and 2, and export to Suricata, Snort, Zeek and RPZ formats for detection tools.
Synchronization: Exchange events and attributes with member instances, once the community's onboarding rules are agreed.
Taxonomies and galaxies: Use shared tags for threat actors, malware and MITRE ATT&CK, with licensing separate from the AGPL software.

Confirm with the community which MISP version and sync configuration it expects, and whether its hub runs a specific release line such as MISP 2.5, the recommended version for new deployments.

Which open source platforms fit a DORA sharing setup

A DORA sharing setup is not one product. It combines a sharing platform that exchanges intelligence inside a trusted community, sensors that turn indicators into detections, an automation layer that moves notifications and enrichment, and an identity layer that controls who can reach the sharing instance. The cards below cover each role and the license or operating fact to check before you commit.

MISP as the sharing platform

MISP is the most direct fit for exchanging indicators with a trusted community, because it provides distribution levels, custom sharing groups down to individual attributes, and automatic synchronization with other instances. It is licensed under AGPL-3.0, so a self-hosted deployment carries source obligations to check with counsel if you modify it. Confirm which community instances you can synchronize with, how your sharing groups map to the trust rules of the arrangement, and whether your team can run the MISP 2.5 upgrade path, since 2.4 is end of life.

OpenCTI as the knowledge layer

OpenCTI organizes intelligence as a STIX 2 knowledge graph, which suits teams that need to relate threat actors, campaigns and ATT&CK techniques to the indicators they receive. The Community Edition is licensed under Apache License 2.0, but some features sit in the Enterprise Edition under a separate license. Confirm which connectors and capabilities your use needs are in the Community Edition, plan for Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and decide whether you will run an LTS line that requires a license key.

Suricata and Zeek for sensor-side indicators

Indicators received through sharing only reduce risk if sensors can act on them. Suricata is a network intrusion detection and prevention engine under GPL-2.0, and Zeek is a network analysis framework under a BSD-style license, so both can consume indicators exported from MISP in the formats they support. Confirm sensor placement, the traffic each sensor can see, and how rule updates are approved before shared indicators reach production blocking, since a false positive from a community feed can disrupt a business service.

Shuffle for notification and enrichment

Shuffle is a SOAR platform under AGPL-3.0 that can automate the path from a received event to a decision. In a DORA setup, it can route incoming intelligence to analysts, enrich indicators against internal records, and assemble the facts needed for a participation or membership notification. It does not decide what must be notified. Confirm with your compliance team which events trigger a notification, who approves it, and how the workflow records timestamps and evidence, so the automation does not become an undocumented step in your reporting chain.

Keycloak or authentik for access control

A sharing instance holds sensitive intelligence, so access must be tied to named people and roles. Keycloak (Apache-2.0) supports OpenID Connect, SAML 2.0 and LDAP or Active Directory federation, and MISP's OidcAuth plugin shows one way to connect an OpenID Connect provider. authentik is MIT-licensed except its enterprise directory, which carries a separate license. Confirm which protocols your MISP or OpenCTI version supports, how multi-factor authentication is enforced for analysts and administrators, and how you will remove access when a member leaves the sharing group.

What must be notified to the competent authority and when

Article 45(3) of DORA requires a financial entity to notify its competent authority of its participation in a threat information-sharing arrangement once its membership is validated, and again when membership ends, once that end takes effect. For a team running a self-hosted MISP or OpenCTI instance, the practical sequence is to record the date the community validates the membership, file the notification, and keep the evidence with the sharing agreement. The end-of-membership notice follows the same path, so the offboarding plan for a sharing group should include a dated notice step alongside revoking synchronization and removing the community's sharing groups from the instance.

The Regulation sets the obligation but not the form. Article 46 assigns supervision to the national competent authority for each type of financial entity, so the notification content, the channel and any required fields depend on which authority supervises your entity and how it has set up its reporting. Before the first sharing community is joined, confirm the format, the contact point and whether the authority expects the notice to name the platform, the community operator or the individual sharing groups. Record the answers in your DORA evidence file so the notice can be reproduced later.

The Digital Omnibus proposal, COM(2025) 837, and its procedure 2025/0360(COD) were still moving through the EU legislative process when this page was prepared, and they may change DORA reporting obligations. Check the current status of the proposal on the European Parliament Legislative Observatory) before you fix your notification procedure, and review the procedure again each quarter until the position is final. Confirm the position with your supervisor as well, since the authority's expectations apply to your entity regardless of how the legislation is amended.

How a financial entity gets from membership decision to first shared event

The sequence runs from a documented sharing policy and participation conditions through community governance, a hardened self-hosted instance, validated membership and notification, to curated sharing that can be shown to a supervisor. Each step closes with an artefact the entity can produce on request.

Define sharing rules and participation conditions
Compliance, the threat intelligence lead and legal counsel write the internal sharing policy before any platform work starts. Article 45(2) requires the arrangement to set conditions for participation, so the policy should state who may share, which information types are in scope (indicators of compromise, tactics, techniques and procedures, alerts and configuration tools), what is excluded, and how business confidentiality and GDPR limits apply to indicators that contain personal data. Done when the policy is approved by the owner of ICT risk and a named person can answer every participation condition the community sets.
Confirm community governance and membership terms
The entity reviews the rules of conduct of each trusted community it wants to join, including confidentiality, competition policy guidance and how membership is validated. Article 45(1)(b) and (c) make these rules the binding frame for sharing, and Article 45(2) allows public authorities and ICT third-party providers to be involved, which the entity must confirm with the community operator. Ask the community which MISP or OpenCTI operating model it uses, whether it runs a hub or peer synchronization, and what evidence it needs to validate membership. Done when the entity holds signed terms and a written list of the community's requirements.
Deploy and harden the self-hosted instance
The platform team installs MISP or OpenCTI inside the entity's own infrastructure, using the vendor's supported installation path for the version chosen. For MISP, the project recommends version 2.5 for new deployments and does not recommend new 2.4 installs, so confirm the version against the current download guidance before building. For OpenCTI, plan for Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and confirm the LTS or regular release line against the product life cycle. Harden access with the identity provider, restrict administrative roles and enable logging. Done when a hardening checklist is signed off and the instance passes an internal review.
Configure sharing groups, distribution and synchronization
The team builds sharing groups and sets distribution levels so each event and attribute reaches only the audiences the sharing policy allows. For MISP, distribution levels and custom sharing groups work down to individual attributes, and synchronization with community instances is configured only after those rules are tested with dummy events. Confirm which taxonomies and TLP-style markings the community expects, and document the mapping. Done when test events synchronize to the community test partner with the expected visibility and no event is visible beyond its sharing group.
Validate membership with the community
The community operator checks the entity's instance, sharing configuration and governance commitments before admitting it. Article 45(3) ties the notification duty to membership being validated, so the entity should keep the validation record, the date it took effect and the scope of membership. Ask the community what it will confirm in writing and whether membership can be suspended or ended. Done when the entity holds a written validation record that names its instance and the effective membership scope.
Notify the competent authority of participation
Once membership is validated, the entity notifies its competent authority of its participation, as Article 45(3) requires. The same notification process applies when membership ends, once that takes effect. Compliance prepares the notice from the validation record and the sharing policy, and the entity confirms the authority's preferred channel and format. DORA sets no certification scheme, so the evidence the entity keeps is its own notice, the authority's acknowledgement where provided, and the validation record. Done when the notice is filed and a copy sits in the compliance evidence store.
Start sharing with analyst curation
After notification, analysts begin sharing a small set of reviewed events, checking each one against the sharing policy before publication. The curation step confirms that personal data is removed or justified under GDPR, that the distribution level matches the policy and that indicators are tagged with confidence and an expiry so they can be aged out. The entity records each sharing decision in a log that links the shared event to the policy rule applied. Done when the first events are published, the log shows a reviewer for each one, and the entity can trace every shared item back to the approved policy.

What examiners ask to see as evidence of sharing

What proof of membership validation do examiners expect to see?

Examiners expect a dated record showing that the community or trusted arrangement validated your membership before you started sharing, with the conditions for participation that the arrangement set. Article 45(2) requires the arrangements to define those conditions, so the evidence starts with the written terms of the community and your acceptance of them. In a self-hosted MISP or OpenCTI deployment, the sharing group configuration and the onboarding ticket or approval email are the artifacts that tie your instance to that validated membership. Keep them in the same evidence store as your notification records so the timeline is easy to follow. Confirm with your competent authority which form of validation record it accepts.

Which signed rules of conduct must a sharing community provide?

The rules of conduct are the governance document your sharing community signed or accepted, covering business confidentiality, GDPR obligations and competition policy guidelines. Article 45(1)(b) and (c) require sharing to take place under rules of conduct that protect sensitive information and respect those three areas. Your organization should hold a signed or accepted copy, the date it took effect, and any amendments. Inside the platform, the rules show up as distribution levels, sharing groups and the TLP markings your analysts apply to each event. Ask the community operator for the current version and a record of your signature, because examiners often request both.

How do you export sharing group configuration from MISP or OpenCTI?

The sharing group configuration is exported from the platform itself, and it shows who can receive which intelligence and at what distribution level. In MISP, administrators can export sharing groups, organisation records and synchronization server settings through the administration interface or the API, and the configuration can be saved as a dated snapshot. OpenCTI keeps equivalent access controls in its platform settings and groups, which you can export through the GraphQL API or the administration screens. Store each snapshot with a change record so you can show what was shared with whom at any point. Confirm the export format and retention period your authority expects, and test the procedure on a non-production instance before the first examination.

Which audit logs of shared events do examiners request?

Examiners usually ask for logs that show which events and attributes you published, when, to which sharing group, and who approved or edited them. MISP records event creation, publication, edits and synchronization activity in its audit log, and the log can be filtered by date and user. OpenCTI records changes to objects and user activity, and the platform logs can be forwarded to your SIEM for retention. Keep the logs for the period your internal policy and the authority require, protect them from edit, and link each entry to the ticket or analyst decision behind it. Ask your implementation partner to document where each log lives and how you retrieve it under time pressure.

What copy of the Article 45(3) notification should you keep?

Keep a copy of the notification you sent to the competent authority about your participation, plus the date it was sent and the date your membership was validated. Article 45(3) requires you to notify the authority once membership is validated, and to notify it again when membership ends once that takes effect. The notification itself is a governance record, so it sits with your compliance function rather than in the threat intelligence platform, but the platform should reference it through a ticket or case identifier. Record the end-of-membership notification with the same care, including the effective date. Confirm the channel and form your authority uses, because the notification process is set nationally.

What post-incident review outputs prove sharing helped incident handling?

Post-incident review outputs show how shared intelligence was used during a major ICT-related incident, and whether procedures and actions were effective. Article 13(2) requires reviews after a major incident that disrupts core activities, covering promptness of response, quality and speed of forensic analysis, escalation and communication. For sharing evidence, the useful outputs are the timeline of indicators received and actioned, the events you published back to the community, and the changes made to detection rules afterwards. In a self-hosted deployment, these come from event histories, exported indicators to sensors such as Suricata and Zeek, and the review report itself. Entities other than microenterprises must communicate resulting changes to the competent authority on request, so keep the report ready.

What training records does DORA Article 13(6) require for threat intelligence staff?

Article 13(6) requires ICT security awareness programmes and digital operational resilience training as compulsory modules for all employees and senior management. For a sharing program, the records should show completion of these modules by every person who can view, publish or act on shared intelligence, including analysts and platform administrators. Your learning management system or HR system produces the completion records, and the threat intelligence team should add role-specific training on handling TLP markings and sharing groups. Keep attendance, dates and module versions, and review the list each time staff join or change roles. Confirm with your authority whether it expects separate records for senior management.

What tooling alone does not satisfy

A self-hosted MISP or OpenCTI instance gives a financial entity the technical means to share, but DORA Article 45 also expects signed arrangements, notifications, community rules and trained people. The four items below are where most sharing programs fall short, and each one produces evidence an auditor or supervisor will ask to see.

Membership and governance agreements

Article 45(2) requires sharing arrangements to define conditions for participation, and Article 45(1) requires rules of conduct that protect business confidentiality and personal data. Before the first indicator leaves your network, you need written agreements covering who may join, what may be shared, how it is labeled, and how a member is removed. Check that legal, compliance and the security team have each signed off on the same version. A platform setting cannot stand in for these documents, so ask who owns them and where they are stored.

The membership notification

Article 45(3) requires financial entities to notify the competent authority of their participation once membership is validated, and again when membership ends once that takes effect. The notification is a process with an owner, a template, a validation date and a record of who approved it. Build a register of communities joined, validation dates and exit dates, and link each entry to the agreement it relies on. Confirm the exact notification format and channel with your competent authority, because the Regulation does not prescribe them in the supplied text.

The community's own rules and vetting

A trusted community sets its own conditions for vetting members, distribution rules and sharing groups, and those rules decide what your MISP or OpenCTI instance may receive and send. Your platform must map community distribution levels onto your internal TLP labels so that restricted indicators are not pushed to a wider audience by default. Review how the community revokes access and how synchronization is turned off. Ask the community administrator for the written rules before you configure any sync connection.

Training and curation practice

Article 13(6) makes ICT security awareness and resilience training compulsory for all employees and senior management, so analysts who curate shared intelligence and the staff who act on it must be covered by a documented program. Curation rules also matter: who may publish an event, how false positives are aged out, and how a shared indicator is reviewed before it reaches blocking controls. Record training completion and curation decisions, because these records show that the sharing practice works in daily operation.

How much work does DORA information sharing take to set up?

What does a self-hosted MISP or OpenCTI setup for DORA sharing actually cost?

Neither MISP nor the OpenCTI Community Edition charges a license fee, so the cost sits in what you pay for and do. You pay for infrastructure, such as servers or cloud capacity, and for the components OpenCTI needs: Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage. You also pay for integration work, for analyst time spent curating indicators, and for any paid feeds. OpenCTI Enterprise Edition is a separate, proprietary license that you pay for only if you need its features. Infrastructure recurs every year, while design, integration and onboarding are mostly one-time. Ask any quote to split these lines.

What makes the effort go up or down for DORA information sharing?

The biggest drivers are the number of sharing communities you join, how many feeds and sources you ingest, and how many systems need indicators pushed into them. Effort also rises with the number of sharing groups and distribution rules you must define, the number of member instances you synchronize with, and whether you run the platform for a community rather than only as a member. Effort falls when you already run a SIEM, firewall and SOAR that accept STIX, TAXII or MISP formats, and when your sharing rules are already written down in a classification policy.

Can an internal team set up MISP or OpenCTI for DORA sharing alone?

A capable internal team can deploy and run MISP, since the project offers an installer for Ubuntu 24.04 and also lists Docker images, Ansible roles and packages as options. The harder parts are the trust rules: defining sharing groups, distribution levels, TLP handling and the conditions for participation that Article 45(2) asks arrangements to define. Those decisions need legal, compliance and threat intelligence staff, not only platform engineers. Many teams therefore split the work, with internal owners for governance and a partner for deployment and integration. Confirm your own skills against this split before deciding.

What does the work need from our own staff?

Expect to supply named owners in four areas: compliance or legal, for participation terms and the GDPR and competition rules that Article 45(1) requires sharing to respect; threat intelligence, for deciding which indicators are useful; security operations, for the systems that will consume indicators; and infrastructure, for hosting, backup and access control. Identify these people early, because sharing conditions and notification duties depend on decisions they make. Ask your partner to list the decisions it expects you to take and the dates by which it needs them.

Should we choose MISP or OpenCTI for DORA information sharing?

Choose MISP when the main job is exchanging indicators with trusted communities through sharing groups, distribution levels and automatic synchronization, since those are its core features. Choose OpenCTI when you need a knowledge graph of intelligence linked to ATT&CK, a STIX2-based schema and a GraphQL API for analysts. Many teams run both, with MISP for exchange and OpenCTI for analysis. Check whether the community you plan to join uses MISP, because membership depends on the platform its members run. Confirm which OpenCTI features you need, as some require the Enterprise Edition.

Is sharing mandatory under DORA, and what could change?

No. Article 45 allows financial entities to exchange threat information within trusted communities, so participation is voluntary. If you do join, Article 45(3) requires you to notify your competent authority once membership is validated and again when it ends. The Commission must review DORA by 17 January 2028 under Article 58(1), including the voluntary nature of significant cyber threat notification, so the rules could change. Separately, Article 13(1) requires you to gather threat information in any case. Confirm your authority's current notification format with them directly.

What should we ask a partner to include in a quote?

Ask for a written scope that lists the communities and feeds to connect, the sharing groups and distribution rules to configure, the integrations to the SIEM, firewall and SOAR, and the backup and upgrade routine. Ask which OpenCTI features require the Enterprise Edition and who pays that license. Request the infrastructure sizing and its assumptions, the components they will install, and the handover of documentation. Ask how they will prepare the authority notification and the evidence of your governance rules. Most engagements are fixed-scope, so confirm deliverables, timelines and acceptance criteria before work starts.

How DeployOpen scopes a sharing deployment

DeployOpen plans, implements, hardens and documents a self-hosted MISP or OpenCTI instance inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. The scope is agreed in writing before work starts, and the quote follows from that written scope. For a DORA sharing deployment, the scope usually has to settle which community the instance will join, how sharing groups and distribution levels map to your trusted-community rules, which authentication source the instance uses, and how the instance is connected to your SIEM and detection tools. Ask for a written scope that lists each of these items as a deliverable with an owner, so you can compare quotes on the same basis.

Two options are worth raising at scoping. The first is security testing of the instance itself, covering the web application, its API and the surrounding infrastructure, so that you can show your competent authority and your own risk committee that the sharing platform was tested before it held member data. The second is cyber range practice, where your analysts and incident responders rehearse receiving an indicator from a community, validating it and pushing it to detection controls in a private environment before a live event is shared. Both are priced in the written scope. Confirm with the partner which findings and exercise records they will hand over, and in what format, since those records are what your compliance and audit teams will ask for.

Once the instance is live, most financial entities need ongoing upgrades, patching of the MISP or OpenCTI stack and its dependencies, and support when a community changes its synchronization rules. DeployOpen offers these as retainers that run separately from the fixed-scope implementation. Before you sign, confirm the response expectations, the upgrade process for MISP 2.5 releases and any OpenCTI long-term support license you need, and who holds the administrative keys to the instance at the end of the engagement. Those answers decide whether the sharing platform stays under your control after the project closes.

How DeployOpen delivers and supports DORA sharing platforms

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted MISP or OpenCTI inside your own infrastructure, so your sharing platform stays under your control. The work starts with a written scope that ties the platform to the Article 45 arrangements your entity intends to join and to the notification evidence your competent authority will expect.

How we scope

Agree in writing which sharing communities, participation conditions and sharing groups the platform will serve.
Define the distribution and TLP rules that protect sensitive information before any indicator is imported.
Map the notification records DORA requires for membership validation and membership end, with named owners for each.

How we build

Deploy MISP or OpenCTI in your cloud accounts, data centers or air-gapped network, with the dependencies your chosen platform requires.
Configure synchronization, sharing groups and access through your identity provider, and test that restricted events stay restricted.
Connect indicator exports to your SIEM, network sensors and SOAR, and test each flow against a documented sample set.

How we hand over

Provide architecture, configuration, sharing rule and runbook documentation written for your security and compliance teams.
Walk your analysts through curation, sharing decisions and onboarding of new community members.
Record the evidence trail for participation decisions, notifications and access reviews so your assessors can trace each step.

How we support

Offer ongoing support, version upgrades and continuous testing as a retainer after handover.
Plan platform upgrades, including MISP 2.5 maintenance and OpenCTI release or LTS license management, as part of the agreed support scope.
Confirm with your legal and compliance advisers the GDPR, competition and business confidentiality rules that govern each community.