Article 29 NIS2 information sharing: duties and evidence

What Article 29 NIS2 information sharing asks an entity to do

If you are deciding whether to join a threat-sharing community, the most important point is that NIS2 does not make sharing threat information compulsory. Under Article 29, Member States must make sure entities *can* exchange cybersecurity information voluntarily, such as cyber threats, near misses, vulnerabilities, indicators of compromise, adversarial tactics and detection configuration recommendations. The exchanges take place within communities of essential and important entities and, where relevant, their suppliers and service providers, through cybersecurity information-sharing arrangements. The one step the law makes mandatory is telling your competent authority when you join an arrangement and when your withdrawal takes effect. Confirm with your national authority or CSIRT which form that notice takes and whether it must be filed on a specific portal or template, because national transposition laws set those details.

The risk this provision addresses is isolation. An organization that sees no peers' indicators, campaign details or near-miss reports often learns about an attack it could have blocked only after it has spread elsewhere. Sharing lets one entity's detection become another's preventive control, which is why ENISA's role under Article 29(5) includes helping communities get started. Remember that voluntary sharing does not reduce your own obligations: the Article 21 measures and Article 23 reporting duties still apply in full, and information received from a community does not replace your own threat monitoring.

The duty is hard to evidence because the records are scattered. A supervisor asking when you joined an arrangement, who was authorized to share, and what rules governed the handling of received data needs dates, membership approvals, notices sent to the authority, and the sharing policy in one place. Build a register that records each arrangement, its participants, your join date and any withdrawal date, the notification reference and the handling rules that apply to shared data, including what you may redistribute. Platforms such as MISP, which uses sharing groups and distribution levels to control who sees each event, and OpenCTI, which organizes intelligence as STIX-based entities, can hold much of this technical context, but the governance record must still be kept and reviewed by the organization.

Which entities, data and partners Article 29 information sharing covers

Before joining or running a sharing arrangement, an entity has to settle four questions: its NIS2 classification, whether it is in scope under national law, what kinds of information it will share, and whether suppliers can take part. Each answer changes what the arrangement must cover and what the entity must notify.

Essential or important classification

Article 29 applies to essential and important entities alike, so classification mainly changes how supervision works, not whether the sharing duties apply. Essential entities face ex ante supervision and important entities face ex post supervision. Confirm the classification with your national competent authority before you join, because it sets how closely your notifications will be reviewed.

In-scope status under national law

Article 29 notifications only bind entities that NIS2 covers in the Member State where they are established. Sector-specific laws can displace NIS2 for some organizations. Check the national transposition law and the competent authority's guidance first, since the national rules determine who must notify joining and withdrawal.

Information types you will share

Article 29(1) lists cyber threats, near misses, vulnerabilities, indicators of compromise, adversarial tactics, threat-actor information and detection configuration recommendations. Decide category by category what you will publish and what you will only receive. Sharing detection rules exposes your monitoring design, so the internal review for those items is usually longer.

Suppliers and service providers as members

Article 29(2) allows exchanges with suppliers or service providers where relevant, so managed security providers and cloud operators can sit inside a community. Decide whether each supplier gets full membership, read-only access or no access. Document the decision in the arrangement terms, since the contract with each supplier must match what it can see.

Personal data in shared records

Indicators of compromise often include IP addresses, email addresses, account names or other data that is personal under GDPR. Filter or pseudonymize these fields before they leave your environment, and record the legal basis you rely on. Confirm with your data protection officer which fields may be shared and how long recipients may keep them.

Client confidentiality and distribution rules

Shared intelligence may reveal customer names, contract details or incident specifics that your clients expect to stay confidential. Set distribution levels for each event and agree handling rules with the community. The national competent authority and the arrangement's own rules set the detail, so ask them in writing which obligations you must keep when information cannot be shared.

How an assessor tests Article 29 participation and notifications

This table compares each test step an assessor is likely to take on Article 29 participation, the evidence requested for it and the findings that most often appear. Read it as a checklist for your own records before any review, since the Directive sets the obligations but does not prescribe an audit procedure.

Test area	Evidence requested	Common findings
Membership status in each arrangement	Current membership register listing each sharing arrangement, the entity's role, join date and named contact, plus the signed or accepted participation terms	Arrangements referred to in emails or chat logs but missing from the register; no record of which community the entity belongs to
Notification on joining	Copy of the notice sent to the competent authority, its date, the recipient and the confirmation or acknowledgment received, if any	No notice on file; notice sent to an unidentified mailbox; joining date in the register does not match the notice date
Notification on withdrawal	Withdrawal notice, the date it was sent and the effective date of withdrawal as recorded in the arrangement	Withdrawal decided but never notified; notice dated after the effective date; access kept active after withdrawal took effect
Record of authority informed	Log showing which competent authority or authorities received each notification, reflecting the entity's Member State jurisdiction	No record of which authority was informed; notices sent to a different authority than the one supervising the entity
Confidentiality and proportionality of shared content	Sample of outbound shares with the sharing rules, distribution settings and a reviewer's approval note where the policy requires one	Shared items include personal data or customer details without a documented reason; distribution set wider than the community in the arrangement terms
Use of received intelligence	Internal records showing how received indicators or threat reports were triaged, actioned, suppressed or escalated, with dates and owners	Intelligence received but no record of use; indicators loaded to detection tools without a tracked decision
Voluntary notifications under Article 30	Notification log for voluntary reports of incidents, threats or near misses, including the recipient and the date sent	Voluntary reports made by email with no retained copy; mixing voluntary reports with mandatory Article 23 reports without marking which is which

Setting up an information-sharing arrangement step by step

This sequence takes an entity from deciding to share threat intelligence to a working, documented arrangement with a platform, sharing rules, distribution groups and the authority notifications that Article 29 expects. Each step closes with a record you can show an assessor or supervisor.

Confirm eligibility and choose the community
Start by establishing whether your organization is an essential or important entity under NIS2, since Article 29 sharing takes place within communities of those entities and, where relevant, their suppliers or service providers. Identify the candidate communities, such as a sector body, a national CSIRT-led group or a peer group, and check their membership criteria and the types of information they exchange. Close the step with a short eligibility memo signed by the management body or its delegate, naming the community and the reason it fits your sector and risk profile.
Agree sharing rules and information classification
Before any data moves, write the rules that govern it: which information types you will share (threats, near misses, vulnerabilities, indicators of compromise, adversarial tactics, threat-actor information and detection configuration recommendations), how each is labeled, what must be anonymized, and what is never shared, such as personal data or customer-confidential details. Ask legal and privacy counsel to review the rules against GDPR. Close the step with an approved participation agreement and a classification scheme that every member signs.
Deploy the sharing platform and access controls
Install the platform that will hold and move the shared information, such as MISP or OpenCTI, inside your own infrastructure, and harden it with named accounts, role-based access, multi-factor authentication, logging and backups. Confirm the license terms of the chosen tool before deployment. Test that users can only see events their role allows. Close the step with a configuration baseline and an access review record listing who holds which role and when it was last checked.
Set up distribution and sharing groups
Translate the classification scheme into technical controls. In MISP, for example, this means defining distribution levels and sharing groups so that each event reaches only the organizations intended to receive it. Map each information class to a distribution setting and each partner to the groups it belongs to. Test the matrix with sample events before any live data flows. Close the step with a signed sharing-group matrix that shows which information class goes to which group, and a test log showing the expected results.
Notify the competent authority on joining
Article 29(4) requires essential and important entities to notify their competent authorities when they join an information-sharing arrangement. Confirm with your national competent authority or CSIRT which notification form, channel and details they expect, since the procedure is set by national transposition law. Submit the notification before exchanging information through the arrangement. Close the step with a dated notification record, the authority's acknowledgment if one is issued, and a note of the arrangement's name, scope and participating communities.
Define the withdrawal procedure and notice
Article 29(4) also requires notification when withdrawal from an arrangement takes effect, so plan the exit before you need it. Write a procedure that covers who decides to leave, how partners are told, how access and stored data are revoked or returned, and how the authority is notified. Confirm the notice periods in the participation agreement and with your national authority, since no period is set in the Directive itself. Close the step with an approved withdrawal procedure and a tested checklist that shows access removal and the notification would be completed.

Running MISP and OpenCTI as self-hosted sharing tools

Article 29 does not require a particular tool, but a self-hosted sharing platform gives an entity control over where its threat information goes and a record of what was shared. MISP and OpenCTI cover two different parts of the workflow. MISP, licensed under AGPL-3.0-only, is built around sharing events. It synchronizes events between instances, applies granular distribution levels and sharing groups so that each indicator reaches only the communities you choose, and records sightings when an indicator is observed in your environment. Its correlation engine matches indicators by exact value and by advanced patterns such as fuzzy hashes and CIDR overlaps. Its REST API exports to STIX 1 and 2, CSV, and Suricata, Snort and Zeek rule formats, so detection teams can push validated indicators into existing sensors.

OpenCTI, licensed under Apache-2.0, is oriented toward analysis. It stores intelligence as STIX-based entities, relationships and containers, which helps analysts show how an actor, campaign and indicator connect. Data arrives through connectors, TAXII, RSS, CSV and JSON feeds, or manual file upload, and knowledge leaves through native feeds and exports. Many organizations run both: OpenCTI as the analytical record and MISP as the exchange layer. Before deployment, confirm with your engineers which connectors and feed formats your existing intelligence sources need, and who in the organization owns the decision about which sharing group receives each event.

The AGPL-3.0-only license of MISP carries a caveat. If you modify MISP and make it available to users over a network, the license may require you to offer those users the modified source. Confirm the obligations with counsel before you customize the platform or expose it to partner organizations. The platform also produces sharing logs and distribution records, which are useful evidence that information was exchanged. It does not decide which arrangement you join, what terms apply, or when a notification to the competent authority is due. Those remain organizational records, and they should be maintained in your governance documentation and reviewed by the people who own the arrangement.

Evidence that shows sharing arrangements and notifications

Article 29 is voluntary in its exchanges but not in its paperwork: once an entity joins or leaves a sharing arrangement, the competent authority must be told, and the entity should be able to show what it shared, with whom, and under which rules. The six artifacts below form the file an assessor or supervisor can follow from membership through to each exchange. Review each one on a fixed cadence so it stays accurate between audits.

Signed arrangement or participation terms

The signed agreement, charter or participation terms that set out the community, its purpose, membership rules and what members may share. Check that the document names the entity, the signatory and the effective date, and that it states how information is classified and who may receive it. Review membership against the terms every quarter, and file any amendment the day it is signed so the version in force is always identifiable.

Authority notifications for joining and leaving

Copies of the notices sent to the competent authority when the entity joins an arrangement and when its withdrawal takes effect, as Article 29(4) requires. Each record should show the date sent, the arrangement name, the date the membership began or ended, and the proof of transmission. Confirm with your national competent authority which channel and form it accepts, because the format is set nationally, not by the Directive.

Sharing-group and distribution configuration exports

Exports of the sharing groups, distribution levels and synchronization settings that control who receives each event. In MISP, for example, the sharing group and distribution fields determine which partner instances can see an event, so a dated export of those settings proves what was permitted at a given time. Run the export after every change and before each quarterly membership review, and compare it with the signed terms to catch drift.

Sightings and internal handling records

Records of the sightings reported against shared indicators and of how the entity handled what it received, including who triaged each item, which detections were updated and which were rejected. These records show that intelligence was used, not just collected. Keep the log of sightings in the platform, and tie each received indicator to a ticket or decision so the trail survives staff changes.

Classification and pre-sharing confidentiality rules

The written rules that set how information is labelled before it leaves the entity, such as which fields are stripped, which tags apply to personal data or customer details, and who approves release. The rules should cover indicators that could reveal a victim or an unpatched system. Test them with a sample exchange each year and keep the results, since an assessor will ask how a confidential detail was prevented from leaving the organization.

Withdrawal notice and effective date

The written notice of withdrawal, the date it was sent, the date it took effect, and confirmation that the entity stopped receiving and sending through the arrangement from that date. Article 29(4) ties the notification duty to the effective date, so the notice should state that date explicitly. Remove the entity from sharing groups and revoke its access on or before that date, and keep the access-removal log with the notice.

What information sharing under Article 29 costs to run

This table compares the main cost components of running an Article 29 information-sharing arrangement, showing who is paid, whether each cost is one-time or recurring, what drives it and how to keep it down. Open-source platforms can remove license spend, but hosting, engineering, analyst time and review still carry cost, so request a written scope and quote from any partner and confirm hosting costs in your own environment.

Cost component	One-time or recurring	What drives it and how to keep it down
Platform licenses	Recurring if any	MISP (AGPL-3.0-only) and OpenCTI (Apache-2.0) carry no license fee, so spend is often zero. Confirm any paid add-ons, connectors or support contracts in writing.
Hosting and infrastructure	Recurring	Driven by instance count, storage for retained indicators and sightings, and availability needs. Confirm the cost of your own cloud or data center capacity before committing.
Engineering time to deploy and integrate	One-time, then recurring upkeep	Driven by the number of feeds, SIEM or EDR connections and sharing-group design. Keep it down by standardizing one deployment pattern and documenting configuration.
Feed and connector maintenance	Recurring	Driven by how many external sources and TAXII or CSV feeds you ingest and how often formats change. Keep it down by limiting sources to those your team will triage.
Analyst time to triage and share	Recurring	Driven by event volume, false-positive rates and how many communities you exchange with. Keep it down with clear sharing rules, distribution levels and a defined triage workflow.
Legal review of arrangement terms	One-time per arrangement, plus review on change	Driven by the number of arrangements, data-protection terms and confidentiality rules. Ask counsel for a fixed-fee scope and reuse a template across communities.
Evidence upkeep	Recurring	Driven by records of joining and withdrawal notices to authorities, sharing decisions and configuration history. Keep it down by logging these events at the point they occur.
External review or advisory	Occasional	Driven by whether you want an independent check of the arrangement design or an outside assessor's view of your processes. Request a written scope from any partner, and note that only independent auditors issue reports or certificates.

Your team, an implementation partner and the auditor

Your organization owns the decisions that make a sharing arrangement compliant. Article 29 is voluntary in that no entity is forced to join a community, but once you join, the obligations are yours to meet. Management and the security function decide whether to participate, which communities to join, what information to share and what to keep internal.

Membership decisions: Decide which information-sharing arrangements you join, who in the organization may represent you, and the criteria for leaving.
Signed arrangement: Hold the written terms that govern exchanges, including confidentiality, handling rules and withdrawal.
Authority notifications: Notify the competent authority when you join an arrangement and when your withdrawal takes effect, and keep proof of each notice.
Sharing policy: Define what categories of information you share, how you sanitize personal and customer data, and how you handle what others send you.
Ownership of records: Keep the register of arrangements, notices and decisions current, since these records are what a supervisor or auditor will ask for first.

Confirm with your national competent authority which notification channel and form it expects, because transposition laws in each Member State may add detail.

Where organizations fall short on Article 29 and how to close each gap

Article 29 sharing is voluntary, but once an entity joins a community it still has to notify authorities of joining and withdrawal, and it has to control what leaves its walls. The gaps below cluster around records, controls on distribution and data, and the suppliers invited into the community. Each one has a specific closing action that an assessor can check.

No record of joining or withdrawal

Entities must notify competent authorities when they join an information-sharing arrangement and when their withdrawal takes effect. Many teams make the decision in a chat thread and never write down the dates, the arrangement name or the authority contacted. Keep a dated register with the arrangement, the join date, the notification sent, the effective withdrawal date and the matching confirmation. Ask the authority which channel it accepts before you need it.

Notifications sent without a kept copy

Notices to a competent authority that go out by email or phone without a retained copy cannot be shown later. Store every notification, reply and acknowledgment in the same controlled repository as the rest of your compliance evidence, with the sender, timestamp and recipient. Test the process once a year by pulling a past notification and confirming you can produce it within minutes.

Sharing groups that reach outsiders

A sharing group set to broad distribution can send an indicator to parties that were never part of the agreed community. MISP supports granular distribution levels and sharing groups, so the risk lies in configuration, not capability. Review each event's distribution setting before publishing, audit which instances synchronize with which, and remove partners who no longer belong to the community. Confirm the current feature behavior against the MISP documentation for your version.

Personal and client data shared unfiltered

Threat reports often contain email addresses, customer identifiers, IP addresses tied to individuals or internal hostnames that reveal client systems. Without a classification rule, analysts decide case by case and errors reach partners. Define three or four sharing classes, state which fields must be stripped or pseudonymized for each class, and require a second reviewer before any record that mentions personal or client data leaves the organization. Involve your data protection officer in the rule.

Intelligence received but never used

Indicators that arrive from a community and sit unread add no protection and leave no trace of what was done. Import received data into your threat intelligence platform, record sightings when an indicator matches your logs, and convert useful indicators into detection rules. OpenCTI organizes intelligence as STIX-based entities and relationships and can ingest feeds through connectors, so you can show which intelligence was reviewed and acted on. Track the count of imported items and actions taken each quarter.

Suppliers admitted without terms checked

Article 29 allows exchanges with suppliers and service providers where relevant, so a managed provider may join a community. Before admission, check the supplier's confidentiality terms, its own sub-processors, where it stores shared data and how it handles a withdrawal request. Record the decision and the terms in the supplier file, and make admission conditional on a signed agreement that covers use limits, retention and deletion on exit.

Questions buyers ask about Article 29 information sharing

Is sharing threat intelligence under NIS2 mandatory?

No. Article 29 makes voluntary exchange of cybersecurity information possible within communities of essential and important entities, and it does not require any entity to share. The only mandatory step is administrative: essential and important entities must notify their competent authority when they join a cybersecurity information-sharing arrangement and when their withdrawal takes effect. Member States must ensure the channel exists, but an entity decides what it shares, with whom, and whether it participates at all. Your legal team should still confirm how your national transposition law words these duties, because Member States implement the Directive through their own laws.

How much effort does a typical information-sharing setup take?

Effort depends mainly on how many feeds, partners and internal systems are involved. The main work is usually defining what you will share and receive, setting distribution rules so sensitive data stays within agreed groups, mapping intelligence to detection tools, and training analysts to triage what arrives. Costs fall into three groups: internal staff time, platform hosting and maintenance, and any outside help for design or integration. Platform licences are often not the largest item. Ask any implementation partner for a fixed-scope written proposal that lists the feeds, sharing groups, integrations and handover documentation included. DeployOpen does not publish prices, and a quote follows from that written scope.

Can a small security team run MISP or OpenCTI itself?

A small team can run either platform if it has someone comfortable with Linux, databases, backups, access control and upgrades. MISP is licensed under AGPL-3.0-only and OpenCTI under Apache-2.0, so licensing terms should be checked against your own distribution plans. MISP correlates indicators by exact match and advanced patterns, synchronizes events between instances with distribution and sharing groups, and exports to STIX, 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 feeds. Where the team lacks capacity, a retainer for upgrades, monitoring and support is one option to consider.

What does the work need from management and legal?

Management needs to approve the decision to participate, the risk appetite for sharing, and the named owner accountable for the arrangement. Legal and compliance need to review the terms of each sharing arrangement, confidentiality and handling rules, personal data in shared indicators, and the notification steps required in your Member State. Under NIS2 the management body must oversee the Article 21 risk-management measures, so sharing decisions should be recorded as part of that governance. Ask counsel to confirm how the arrangement interacts with contracts, competition rules and any sector-specific obligations that apply to your entity.

How long does it take to be ready to share?

Readiness depends on the factors that set the work, not on a fixed period. The main drivers are whether a sharing arrangement already exists and can be joined, how mature your threat intelligence process is, whether a platform is already deployed, how many partners are involved, and how long the legal and governance review takes. Notification to the authority is needed when you join and when withdrawal takes effect, so plan that step into the timeline. Ask any delivery partner for a written schedule tied to a defined scope, and confirm with your national authority which notification format it expects.

Will an auditor issue a report on information sharing?

No. Auditors and certification bodies issue reports or certificates. NIS2 creates no certificate of compliance, and national competent authorities oversee compliance through inspections, audits, scans and information requests. An independent assessor may test whether your notifications to the authority were made and whether your sharing process matches what you documented. DeployOpen prepares systems, configurations and evidence, such as platform configuration, sharing group records and process documentation, but it does not issue audit reports, attestations or certifications. Confirm with your assessor which evidence they expect before the engagement starts.

Does voluntary incident notification under Article 30 differ?

Yes. Article 29 covers voluntary exchange of threat information among entities, while Article 30 covers voluntary notification of incidents, cyber threats and near misses to authorities. Under Article 30, essential and important entities may notify voluntarily, and voluntary reporting imposes no additional obligations on the notifying entity. Mandatory incident reporting under Article 23 is a separate duty with its own deadlines. Keep the two processes distinct in your procedures so that a voluntary near-miss report is not mistaken for a mandatory significant incident notification.

What risks should we weigh before sharing intelligence?

The main risks are leaking confidential information about your environment, sharing personal data without a lawful basis, acting on unverified indicators that cause outages, and relying on partners whose security practices you have not assessed. Use distribution levels and sharing groups to limit exposure, validate indicators before automated blocking, and review what leaves your organization. Where shared data includes personal information, check your GDPR obligations with counsel. Include partners and suppliers in your supplier risk process, since the Directive also contemplates sharing with suppliers and service providers where relevant.

How DeployOpen scopes and prepares Article 29 evidence

DeployOpen plans and deploys self-hosted open-source threat intelligence sharing inside your own infrastructure, so your organization decides what it shares and with whom. We prepare the systems, sharing configuration and records that show your participation in an information-sharing arrangement, while your management and legal team own the arrangement itself and the notifications to authorities.

How we scope

Written scope agreed before work starts, listing the sharing communities, platforms and data types in the arrangement
Confirmation of which suppliers or service providers, if any, will take part in exchanges
Agreed deliverables for join and withdrawal records, so the authority notification steps are documented from day one

How we build

Deployment of MISP and OpenCTI inside your cloud accounts, data centers or air-gapped network, as agreed in scope
Configuration of distribution levels and sharing groups so only the agreed communities receive your data
Integration of feeds and exports with your detection tools, with testing of rule formats such as Suricata, Snort and Zeek before go-live

How we hand over

Written documentation of the architecture, access model, sharing rules and operating procedures
A record template for each join and withdrawal, with dates, scope and the contact points your authority requires
Handover sessions for your security team and a review of the evidence set with your independent assessor if one is engaged

How we support

Fixed-scope delivery, with any changes to sharing communities handled through a written change to scope
Ongoing support, upgrades and continuous testing available as a retainer
Confirmation with your legal team and national authority of the notification requirements that apply in your Member State