Article 45 DORA: information-sharing requirements and evidence

What DORA Article 45 asks financial entities to do with threat intelligence

Article 45 permits financial entities to exchange cyber threat information, but it does not oblige them to do so. Sharing indicators of compromise, tactics, techniques and procedures, cyber security alerts and configuration tools is allowed where it aims to strengthen digital operational resilience. The obligation that does apply is narrower: once an entity's participation in a sharing arrangement is validated, it must notify its competent authority, and it must notify again when that membership ends. An entity that joins a community without planning for that notice has a compliance gap from day one, so the first decision is who owns the notification and how it is tracked.

The article sets the conditions a community must meet. Sharing has to happen within trusted communities of financial entities, through arrangements that protect the sensitive nature of the information. The rules of conduct must respect business confidentiality, the GDPR and competition policy guidelines. Article 45(2) adds that the arrangement must define conditions for participation and, where appropriate, the role of public authorities, ICT third-party service providers and operational elements such as dedicated platforms. Read together with the Article 13(1) duty to gather and analyse threat information, these terms show that DORA expects threat intelligence to inform the entity's own risk work, not sit in a feed no one reviews.

The hard part is governance rather than tooling. Platforms such as MISP and OpenCTI can correlate, share and export indicators, but they cannot decide who may join, which fields may leave the organization, how personal data in logs is minimized, or how a competition lawyer reviews the exchange rules. Before any configuration work, confirm the community's written rules, the membership criteria, the data classification for shared items and the notification workflow with your legal, compliance and data protection teams. Ask your supervisor whether it expects anything beyond the Article 45(3) notices, because the Regulation itself does not say how those notices must be made.

Which entities, data and arrangements fall under Article 45 sharing

Before a financial entity joins or builds a sharing arrangement, it has to settle who participates, what information moves, who else is in the room and where the platform runs. Each of these choices changes the governance, confidentiality and notification work that Article 45 Information-sharing arrangements on cyber threat information require.

Which financial entity types take part

Article 2(1) covers 20 types of financial entity, so the first decision is whether your organization falls within that list and which sectoral rules apply to it. Article 45 sharing is open to financial entities in general, but a small firm, an insurer and a crypto-asset service provider will set different participation criteria and different trust levels for a community. Check your entity type against Article 2(1) and confirm with your competent authority how membership should be documented.

Which intelligence types count

Article 45(1) names indicators of compromise, tactics, techniques and procedures, cyber security alerts and configuration tools as shareable material. Each type carries a different sensitivity: an IP address or file hash exposes little, while a configuration tool or a TTP description can reveal how your detection works. Decide per category what you will share, what you will only receive, and what stays internal before any feed is connected.

Whether public authorities join

Article 45(2) allows arrangements to involve public authorities where appropriate. Their participation changes who sees your data, which legal basis governs the exchange and whether the arrangement's rules of conduct need separate terms. Ask the community operator to state in writing whether authorities receive raw data, aggregated summaries or only alerts, and how that flow is logged.

Whether ICT third-party providers join

Article 45(2) also allows ICT third-party service providers to take part in an arrangement. A managed threat intelligence provider or a cloud-hosted sharing platform then becomes a party that handles sensitive indicators and must be covered by your ICT third-party risk register and contracts. Confirm what the provider can access, where its processing happens, and how it would exit the arrangement without losing your data.

Hosting the shared platform in-house

A sharing platform can run in your own infrastructure or with a provider. In-house hosting keeps the data under your access controls, logging and retention rules, but it adds operational duties such as patching, backup and availability. Self-hosted open-source tools such as MISP (AGPL-3.0-only) and OpenCTI (Apache-2.0) support this model. Confirm each tool's current capabilities against its own documentation before you rely on them for a specific control.

Confidentiality and access limits

Article 45(1)(b) requires arrangements that protect the sensitive nature of the information, which is a design requirement for the platform as well as a policy statement. Access to shared content can be limited by group, IP address, file type and request context using controls such as Nextcloud's file access rules for documents exchanged alongside indicators. Test these restrictions with a sample user from each participating group before go-live.

How an assessor tests Article 45 membership and sharing arrangements

This table sets out how an assessor tests each element of Article 45 for a financial entity, what evidence the entity should produce from its own records, and where findings usually arise. The assessor tests the entity's own arrangements and notifications, not the trusted community's internal governance. Use it to check your records before an inspection, and to see which items need owner sign-off.

Element tested	Evidence the assessor requests	Common finding
Written sharing arrangements exist	Signed participation terms or agreements with each community, dated and version-controlled, showing what information may be shared	Sharing happens through informal chat groups or email with no written arrangement on file
Participation conditions defined	Onboarding criteria, approval records showing who validated membership, and any role limits for public authorities or ICT providers	Membership approved by a team member with no documented authority, or conditions not recorded
Protection of sensitive information	Classification rules, sharing markings such as traffic light protocol labels, access restrictions on the sharing platform and staff handling records	Indicators shared without markings, or platform accounts still active for former staff
Rules of conduct on confidentiality	The conduct rules the entity accepted, confirmation of staff briefings, and records of how the entity applied them to specific shares	Conduct rules signed at joining but never briefed to the staff who actually share
GDPR and competition policy safeguards	Procedure for removing personal data before sharing, legal review notes, and competition policy guidance the entity applied	No documented check for personal data in shared indicators or for competition risk in exchanged information
Notification at validation (Article 45(3))	Copy of the notice sent to the competent authority, its date, and the membership validation record it refers to	Notice never sent, or sent before membership was validated
Notification at end of membership (Article 45(3))	Notice of withdrawal or termination, its date against the date membership ended, and removal of platform access	Membership ended in practice but no notice filed, a common gap when the community stops being used
Ongoing record of participation	Register of active communities with dates, named contacts, and evidence that the register matches the notifications filed	Register missing or out of step with the notifications the authority received

Steps to set up a compliant threat intelligence sharing arrangement

This sequence takes a financial entity from a documented purpose to a working, governed sharing arrangement that the competent authority knows about. Each step produces a record that an assessor can inspect, so the arrangement can be shown to serve digital operational resilience from the start.

Define the resilience purpose of sharing
The management body or the team that owns ICT risk sets out what the entity wants to improve by exchanging threat information, such as faster detection of a phishing campaign targeting its customers or better coverage of a vulnerability in software it runs. Article 45(1) requires the sharing to aim at enhancing digital operational resilience, so the purpose must be written in those terms and linked to the entity's ICT risk management framework. The output is a short purpose statement approved by the responsible body, which later sets the scope of what may be shared.
Select the trusted community
The entity identifies the other financial entities, and where relevant public authorities or ICT third-party providers, with which it would share. Selection should consider whether members hold similar threat profiles, can keep information confidential and can meet the same handling standards. Article 45(1) requires sharing within trusted communities, so the entity should record why each candidate is trusted and what due diligence it performed. The output is a documented community list with the reasons for inclusion.
Draft participation conditions and rules of conduct
Legal, compliance and information security staff write the conditions for joining and the rules that govern behavior inside the community. Article 45(2) requires the arrangement to define participation conditions and, where appropriate, the role of public authorities, ICT third-party providers and shared platforms. The rules of conduct must protect sensitive information and respect business confidentiality, the GDPR and competition policy guidelines under Article 45(1). The output is a draft arrangement reviewed by counsel and approved by the responsible decision makers.
Decide the technical platform and access controls
The entity chooses how indicators, tactics, techniques and procedures will be exchanged and stored, including whether it runs its own instance of a sharing platform or uses a shared one. Access controls should match the sharing groups and distribution levels the rules allow, and the entity should confirm that its chosen platform can enforce those distinctions. Self-hosted tools such as MISP and OpenCTI offer sharing groups, distribution settings and STIX-based exports that can be configured to follow the rules, but the entity must test these settings rather than assume them. The output is a platform design record with access matrices and a configuration baseline.
Validate membership before participating
Before sharing begins, the entity confirms that each prospective member meets the participation conditions and has signed or accepted the arrangement. Validation is the point at which membership takes effect, and Article 45(3) keys the duty to notify the competent authority to that validation. The entity should keep a membership register showing who was validated, when, and against which conditions. The output is a validated membership record that feeds the notification in the next step.
Notify the competent authority of participation
Once membership is validated, the entity notifies its competent authority of its participation in the arrangement. Article 45(3) requires this notification, and the authority identified under Article 46 for the entity's type of financial entity receives it. The entity should confirm with that authority the format and channel it expects, because the Regulation does not set a template in the text reviewed here. The output is a notification record that shows the date sent, the arrangement named, and the members covered.
Set a review and exit process
The entity schedules periodic reviews of the arrangement, its membership, its platform configuration and the information it handles, and defines how it will leave. Article 45(3) also requires notice to the competent authority when membership ends, so the exit process must include that step and the return or deletion of shared material. Reviews should check whether members still meet the conditions and whether the purpose is still being served. The output is a review schedule, an exit checklist and a dated record of each review and any end-of-membership notification.

How MISP and OpenCTI support the sharing workflow

A self-hosted platform can hold, correlate and distribute threat intelligence, but it only supports the Article 45 workflow once the organization has decided who may receive what. In MISP, the working unit is the event, and each event and attribute carries a distribution level that decides whether it stays inside one organization, goes to a community, or is shared through a sharing group. Sharing groups let the organization name the members of a trusted community and limit which instances receive a given event, so the configuration itself becomes the record of who was trusted with what. Before onboarding a community, the organization should confirm in its own MISP instance that distribution levels are set as its sharing rules require and that synchronization only reaches the intended peers.

MISP's correlation of indicators by exact match and advanced patterns such as fuzzy hashes and CIDR overlaps helps analysts link a new report to observations already held. Sightings, which record that an indicator was seen in the organization's environment, give the sharing community evidence of relevance rather than unverified claims. Exports to STIX 1 and 2, CSV and Suricata, Snort and Zeek formats, available through the REST API, let the same intelligence feed detection tooling and partners that use other formats. The organization should test each export and API path it relies on, because the format it sends is what the recipient receives.

OpenCTI takes a different role. It organizes threat intelligence as STIX-based entities, relationships and containers, so analysts can model threat actors, campaigns and observables and see how they connect. Connectors and TAXII, RSS, CSV and JSON feeds, or manual file upload bring data in, and native feeds and exports send knowledge out. Many organizations run both platforms: MISP for fast indicator exchange with a community and OpenCTI for curated analysis. Neither platform makes membership compliant. Article 45(3) still requires the entity to notify its competent authority once membership is validated and again when it ends, and the rules of conduct on confidentiality, GDPR and competition must be written and followed. Confirm each capability named here in your own environment, and record how it was configured.

Evidence that satisfies Article 45 and how to keep it current

Article 45 is tested through documents and records that show who may share, under what rules, and when the competent authority was told. The cards below cover each artifact an assessor is likely to ask for, and how to keep each one accurate between formal reviews.

Signed sharing arrangement

The written arrangement that sets up the trusted community is the anchor document for Article 45. It should name the participating financial entities, the purpose of sharing (enhancing digital operational resilience), the types of information exchanged, and the operational elements such as the dedicated platform. Check that the signatories are authorized, that the version history shows each amendment, and that the document is reviewed whenever membership or platform scope changes. Confirm the exact content requirements with your competent authority.

Participation conditions and rules of conduct

Article 45 requires the arrangement to define who may join and the rules that protect the information. Keep a dated record of the admission criteria, the rules on business confidentiality, personal data handling under the GDPR, and competition policy guidance. Review these rules at least once a year and after any incident in which shared material was misused, and record each review with its outcome.

Distribution and sharing-group configuration exports

If your team runs MISP or a similar platform, exports of distribution levels, sharing groups and synchronization settings show how the rules are enforced in practice. Export these configurations on a fixed schedule and after each change, then compare them with the signed rules to find gaps, such as an overly broad sharing group. Keep the exports under version control so an assessor can see what was in force on any given date.

Membership validation and notification records

Article 45(3) requires you to notify the competent authority of your participation once membership is validated, and of the end of membership once it takes effect. Keep a register that records the validation date, the date the notification was sent, the date the authority acknowledged it where that applies, and the date membership ended. Set a recurring review, such as quarterly, that compares the register with the live membership list and flags any gap.

Membership end notices

When your organization leaves a trusted community, the notice to the authority and the revocation of platform access should happen on the same timeline. Keep copies of the notice, the date access was removed, and confirmation from the platform that the account or sharing group no longer receives data. Auditors often test this pairing, so retain both records together rather than in separate folders.

Access logs and sharing activity records

Logs of who viewed, imported, exported or re-shared threat information show that the rules were applied to real activity. Retain authentication events, sharing actions and sightings for a period your policy defines, and confirm that log integrity is protected. Review a sample of records against the membership register each quarter to confirm that only current members appeared in the community.

What meeting Article 45 costs in people, platforms and legal review

This table breaks down the cost components of running an Article 45 information-sharing arrangement, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to shape the scope you request in a quote, since platform licences are only one line among several. The main takeaway is that open-source tooling removes licence spend but leaves legal drafting, analyst time and governance effort in place.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Legal drafting of the arrangement and rules of conduct	Outside counsel or internal legal team	One-time, with periodic revision	Number of participants, confidentiality terms, and alignment with GDPR and competition guidance
Platform hosting and configuration	Implementation partner or internal platform engineers	One-time setup, then recurring operations	Number of sharing communities, integrations with existing SIEM and TIP tooling, and hosting model
Analyst triage and sharing	Internal threat intelligence analysts	Recurring	Volume of indicators, degree of manual review before sharing, and number of feeds ingested
Governance and membership reviews	Management body delegates, compliance and risk staff	Recurring	Frequency of membership validation, number of participating entities, and change in community rules
Notifications to competent authorities	Compliance staff	Recurring, per membership event	Number of joins and exits and how the authority expects notices to be filed
External legal or privacy review	External counsel or data protection specialists	Periodic, plus on material change	Cross-border participants, personal data in shared artifacts, and new public authority or provider involvement
Platform licence spend	Vendor, where a commercial product is chosen	Recurring	Number of users and instances. Self-hosted open-source tools such as MISP and OpenCTI remove this line, though confirm current licence terms with each project
Infrastructure and security hardening	Cloud provider or data center, and security staff	Recurring	Hosting location, access controls for shared data, and the sensitivity of stored intelligence

Who owns the sharing arrangement, who builds the platform, and who assesses it

The financial entity owns the decision to join a sharing arrangement, the rules that govern what it shares, and the notifications that Article 45(3) requires. Legal and compliance review the membership terms against confidentiality, GDPR and competition policy expectations. Security operations decide which indicators and alerts leave the organization and how they are handled internally. The management body remains accountable for the ICT risk framework that the sharing feeds into, so its approval should be recorded.

Legal and data protection: review the participation conditions, confidentiality terms and personal data handling in the arrangement's rules of conduct.
Security operations: define what categories of indicators are shared, what is withheld, and who can approve outbound sharing.
Compliance: own the notification to the competent authority once membership is validated and again when it ends, and keep the dated records.
Management body: approve participation as part of the ICT risk management framework and review reports on its value.
Ownership of the decision: no partner or platform vendor should be recorded as the party that chose the community.

Confirm internally who signs the membership decision and who holds the notification calendar before any platform work begins.

Common gaps that fail Article 45 reviews and how to close them

Article 45 reviews rarely fail on the idea of sharing. They fail on missing paperwork, unsafe distribution and notifications that were never sent. The cards below cover the gaps assessors and supervisors most often find, each with the closing action that addresses it.

Sharing without written arrangements

Analysts often exchange indicators in chat channels or over email with peers they trust, with no agreement behind it. Article 45(2) expects arrangements that define conditions for participation, including who may join and on what terms. Check that every sharing relationship has a signed arrangement covering membership criteria, roles of public authorities or ICT providers where relevant, and the operational platform used. Close the gap by writing the arrangement before the next indicator is shared.

Missing GDPR and competition safeguards

Article 45(1) requires rules of conduct that respect business confidentiality, the GDPR and competition policy guidelines. Threat indicators often contain personal data, such as email addresses or IP addresses tied to individuals, and exchanges between competing firms can raise competition questions if they reveal commercial plans. Check that the rules of conduct address personal data minimization, retention and competition limits. Close the gap by having legal and data protection staff sign off the rules before onboarding members.

Notifications never sent at validation or exit

Article 45(3) requires financial entities to notify competent authorities of their participation once membership is validated, and of the end of membership once it takes effect. Teams often join a community and forget the notification, or leave without telling the authority. Check a register of every community the entity belongs to, with the validation date and exit date recorded for each. Close the gap by assigning one owner to send both notifications and keeping copies with the arrangement.

Distribution settings exposing sensitive data

Sharing groups and distribution levels in a threat intelligence platform decide who can see each event. A default setting that reaches the whole community, or a sync that pushes events to instances outside the agreed group, can expose sensitive internal information. Check the distribution level and sharing group on each event type, and confirm which instances receive synchronized events. Close the gap by setting restrictive defaults, testing them with a non-member account, and reviewing them after each change to the community.

Shared intelligence not linked to Article 13(1)

Article 13(1) requires capabilities and staff to gather information on vulnerabilities and cyber threats and analyze their likely impact. Sharing that does not feed this analysis looks like a membership with no operational purpose. Check that shared indicators are triaged, that analysts can show how a shared item affected detection, patching or incident response, and that the threat intelligence process is documented. Close the gap by mapping each intelligence feed to a named analysis step and a recorded outcome.

No record of what was shared and why

Assessors look for evidence that sharing follows the arrangement. Without logs, a firm cannot show which indicators left the organization, to whom, or under which rule. Check that imports, exports and sightings are recorded with their source and sharing group, and that a reviewer can trace a shared item back to its approved arrangement. Close the gap by configuring audit logging on the platform and reviewing a sample of exchanges each quarter.

Article 45 questions buyers ask before bringing in help

Is Article 45 mandatory for a financial entity to join a threat intelligence community?

No. Article 45(1) allows financial entities to exchange cyber threat information and intelligence, so participation is permissive, not a duty to join a particular sharing group. The obligation is narrower: if your entity does take part, Article 45(3) requires you to notify your competent authority once membership is validated and again when it ends. What drives your decision is the operational value of the community, such as whether its indicators and TTPs match the threats you actually face. Before joining, confirm with your supervisor how they expect notifications to be made, since the Regulation sets the duty but not the format. Your own threat intelligence capability still matters, because Article 13(1) separately requires you to gather and analyse threat information internally.

What must a notification to the competent authority contain under Article 45?

Article 45(3) requires notice of participation once membership is validated and notice of the end of membership once it takes effect. The provision itself does not list further data fields, so the content should be confirmed with your national competent authority before you submit anything. In practice, expect the notice to identify your entity, the sharing arrangement you have joined, the date membership was validated, and a point of contact. Keep an internal record of both dates, because the trigger events are validation and termination, not the day you first discussed joining. A partner can help you draft and track these notices, but the notice is your entity's statement and must be sent by you.

How much effort does an information-sharing arrangement take to run?

The effort depends on how the arrangement is designed, and no duration or staffing figure is supplied for this topic. The main drivers are the number of communities you join, how many feeds you ingest, whether indicators are shared automatically or reviewed by analysts, and how much of the sharing is governed by rules covering confidentiality, GDPR and competition policy under Article 45(1)(b) and (c). Ongoing work includes triaging incoming indicators, keeping distribution settings correct, reviewing rules of conduct, and maintaining the membership notices. Ask any provider to break their estimate into one-time setup and recurring operations, and to state which of those tasks sit with your analysts and which with the provider.

Can an implementation partner build the sharing platform for us?

Yes, a partner can plan, install, configure and document a self-hosted platform inside your own infrastructure. DeployOpen works this way for open-source platforms, which can be deployed in your cloud accounts, data centers or air-gapped networks. For this topic, MISP can synchronize events between instances with granular distribution and sharing groups and can export to STIX 1 and 2, CSV and Suricata, Snort and Zeek formats through its REST API. OpenCTI organizes intelligence as STIX-based entities and relationships and ingests data through connectors and TAXII, RSS, CSV and JSON feeds. Confirm in writing which connectors, sharing groups and access rules are in scope, and who will operate the platform after handover.

What does our internal team need to supply for a sharing arrangement?

Your team owns the decisions the platform cannot make for you. You need named owners for the arrangement and its membership notices, a decision on which communities you will join and on what terms, and rules for what you share, with whom and under which confidentiality conditions. Article 45(1)(b) and (c) require that sharing respect business confidentiality, GDPR and competition policy guidelines, so legal and data protection staff should review the rules of conduct. Analysts must be able to judge incoming indicators and decide what to act on, consistent with the capability Article 13(1) requires. Access control matters too: where sensitive files are involved, a tool such as the File Access Control app in Nextcloud can block upload, download or sync based on user group, IP address or file tags. Confirm each of these inputs before the scope is fixed.

Can a partner issue an attestation that our Article 45 arrangement is compliant?

No. DeployOpen prepares systems, controls and evidence, but it does not issue audit reports, attestations or certifications. DORA sets no certification scheme for information sharing, and the only authority-issued attestation the Regulation provides for concerns threat-led penetration testing under Article 26(7). Compliance with Article 45 is supervised by your competent authority using the powers in Article 50, so the evidence you assemble, including membership notices, rules of conduct and platform configuration records, is what supervisors will review. Ask any partner to state clearly what it delivers and what remains your responsibility.

Does the Digital Omnibus proposal change how we report sharing?

It may, but the outcome is not settled. The Commission's proposal COM(2025) 837 of 19 November 2025 would amend DORA Article 19 so that major incident reports and voluntary threat notifications go through a single entry point under NIS2. The European Parliament's Legislative Observatory lists procedure 2025/0360(COD) as awaiting committee decision as of October 2026. Until the procedure concludes, keep your current notification process documented and review it when the text is final. Check with your competent authority and legal counsel which version applies to your entity at the time you act, and build your platform so that notification routing can be changed without rebuilding the sharing arrangement.

How DeployOpen prepares Article 45 sharing evidence

DeployOpen's part in Article 45 sharing starts with a written scope that the client approves before any work begins. The scope names the sharing platform (for example, a self-hosted MISP instance, an OpenCTI deployment or both), the trusted community or communities it serves, the user groups and roles that can read, publish and export data, and the access model that governs them. It also records which intelligence feeds are ingested, which external parties are excluded, and where the platform runs inside the client's own cloud account, data center or air-gapped network. Because the arrangement must define its own conditions for participation under Article 45(2), this scope is the document the client's governance team will compare against its legal terms, so it should be reviewed by the client and its advisers before implementation.

Once the scope is agreed, DeployOpen deploys and hardens the tooling inside that environment. For MISP, this covers sharing groups and distribution levels that match the agreed community rules, synchronization settings that reach only approved partner instances, and export paths for STIX, CSV and detection rule formats. For OpenCTI, it covers connector configuration, feed ownership and the handling of TLP-marked material. Where shared files are involved, access controls such as the Nextcloud File Access Control app can deny upload, download or sync based on group, IP address or file type. DeployOpen then exports configuration, role assignments, sharing group definitions and access logs in a form the governance team can file. These exports are evidence of how the arrangement is set up. They do not show that the community's rules of conduct were legally sound or that the client's sharing decisions were appropriate.

DeployOpen does not issue audit reports, attestations or certifications, and it does not decide whether the client joins or leaves a sharing community. Legal drafting of the rules of conduct covering business confidentiality, GDPR and competition policy, the decision to join, and the notifications to the competent authority under Article 45(3) remain with the client and its advisers. The client should confirm with its competent authority which notification format and timing apply to its entity type, and should ask its implementation partner to label every exported artifact with the date and the person who approved the configuration. An independent assessor or the supervisor, not DeployOpen, decides whether the evidence is sufficient for the client's obligations.

Article 45 Information-sharing arrangements on cyber threat information