NIS2 Information Sharing: The Voluntary Programme With a Mandatory Filing

Your client joined a sector ISAC last autumn. Good call — early warning on the ransomware crews working their industry, in exchange for their own indicators going back into the pool.

Nine months later a supervisory officer asks which cybersecurity information-sharing arrangements the entity participates in. The participation is real. The filing is not. Nobody made one, because nobody read past the word "voluntary".

That is Article 29 of NIS2, and NIS2 information sharing catches people precisely because everything visible about it looks optional.

Article 29 makes the sharing voluntary and the paperwork mandatory

Article 29(1) requires Member States to ensure that entities in scope — and, where relevant, entities outside scope — are able to exchange relevant cybersecurity information on a voluntary basis. The directive spells out what counts: cyber threats, near misses, vulnerabilities, techniques and procedures, indicators of compromise, adversarial tactics, threat-actor-specific information, cybersecurity alerts, and recommendations on configuring tooling to detect attacks.

Two purpose tests gate it. Under Article 29(1)(a), the sharing must aim to prevent, detect, respond to or recover from incidents, or mitigate their impact. Under Article 29(1)(b), it must raise the level of cybersecurity more generally — threat awareness, limiting the spread of threats, supporting defensive capability, vulnerability remediation and disclosure, detection, containment and prevention, mitigation strategies, response and recovery, or collaborative threat research between public and private entities.

Article 29(2) constrains the form. The exchange has to happen within communities of essential and important entities and, where relevant, their suppliers or service providers. And it has to run through a cybersecurity information-sharing arrangement, precisely because the material is sensitive.

Then the sentence most programmes skip. Article 29(4): Member States shall ensure that essential and important entities notify the competent authorities of their participation in such arrangements upon entering into them, or of their withdrawal once the withdrawal takes effect.

No size threshold. No materiality test. No grace period written into the article. Join, and you file. Leave, and you file again.

An arrangement is not the same as a group chat

The word "arrangement" is doing real work here, and it is where most assessments go wrong in both directions.

Not an arrangement: four security leads swapping indicators in a WhatsApp group. A vendor's public threat blog. A conference hallway conversation. An open Telegram channel.

An arrangement: a sector ISAC with a charter and membership terms. A MISP community with defined TLP handling rules. A national exchange platform operated by the CSIRT or the competent authority. A formalised supplier-facing sharing agreement written into a contract.

Article 29(3) confirms the shape. Arrangements may specify operational elements including dedicated ICT platforms and automation tools, and the content and conditions of the sharing. If there is a membership, a set of rules and a handling scheme, treat it as notifiable and move on.

The grey zone is the vendor-run threat community — the kind an EDR or threat intel supplier operates for its customers. If your client signed terms to join it and shares back into it, that is an arrangement, whatever the marketing page calls it.

Member States built the plumbing differently

Germany's revised BSIG has been in force since 6 December 2025. The BSI operates an online platform for information exchange with important entities, especially important entities and federal bodies, and can draw manufacturers, suppliers and service providers into that exchange under conditions it sets itself.

The Netherlands has run sector ISACs through NCSC-NL for years. The Cyberbeveiligingswet took effect on 15 August 2026, with the RDI as a central supervisor — so the sharing communities predate the filing duty by a decade, and a lot of existing memberships have never been declared.

Poland's amended national cybersecurity system act took effect on 3 April 2026. Italy has been running under D.lgs. 138/2024 with ACN as the authority. France and Spain were still completing their transpositions during 2026, which does not remove the underlying EU obligation — it just means the national filing channel may not be the one you expect yet.

One rule cuts through all of it: you notify the competent authority that supervises the entity, not the body that happens to run the ISAC. If you are unsure which that is, start with NIS2 Article 26 and the jurisdiction test.

NIS2 Implementation Status by Country (2025–2026)
✅
Fully in force
🇧🇪Belgium
🇭🇷Croatia
🇭🇺Hungary
🇱🇹Lithuania
🇱🇻Latvia
🇮🇹Italy
6 countries
📋
Adopted — late 2025
🇩🇪Germany
🇨🇿Czech Republic
🇫🇮Finland
3 countries
⏳
In progress — expected 2026
🇳🇱Netherlands
🇫🇷France
🇪🇸Spain
🇵🇱Poland
🇦🇹Austria
🇸🇪Sweden
🇮🇪Ireland
7 countries

Article 29 is not Article 23, and not Article 30

Three different mechanisms get collapsed into "reporting" in most client conversations. They are not the same thing.

Article 23 is mandatory incident reporting to the CSIRT or competent authority — 24-hour early warning, 72-hour notification, final report within a month. Not optional, triggered by a significant incident. The mechanics are covered in detail in our breakdown of the NIS2 reporting deadlines.

Article 30 is voluntary notification. Entities in scope can report incidents, cyber threats and near misses that fall below the Article 23 threshold, and entities outside scope can report too. Nothing compels it.

Article 29 is horizontal — entity to entity, not entity to state. The exchange itself is voluntary. The single mandatory element is telling the authority that you are part of it.

Conflating them produces two failure modes. Clients who file an Article 29 notification and think they have discharged an incident report. And clients who report incidents diligently and have never told anyone about the three communities they belong to.

Does the filing duty apply to your client?

Work it in this order.

Is the entity essential or important under NIS2? If it is neither, Article 29(4) does not bite — though a supplier inside a sharing arrangement may still be bound by the arrangement's own terms.

Does the entity participate in a structured arrangement as described above? Membership terms, a defined community, handling rules.

Has a notification been filed with the competent authority, dated at or near the point of joining? Not "we mentioned it during registration". A filing.

Two out of three is not compliance.

The withdrawal half is where records break

Participation gets remembered because somebody signs something. Withdrawal does not.

Memberships lapse when a champion leaves. Subscriptions are not renewed. A MISP community goes dormant and nobody formally exits. A managed security provider is replaced and the client quietly loses access to the community that came with the contract.

Article 29(4) attaches the notification to the moment the withdrawal takes effect. That means somebody has to notice the withdrawal. In practice this is a register problem, not a legal one.

Keep one list per client: arrangement name, operator, date joined, date notified, reference of the notification, contact who owns the membership, and renewal date. Review it when you review registration data — most national laws already require registration details to be kept current, so you are opening the file anyway. Our registration obligation walkthrough covers that cadence.

What supervisors actually ask for

Expect the question to arrive inside a broader documentation request rather than on its own. The evidence set is small:

• The list of arrangements the entity participates in
• Proof of notification for each, with dates
• The terms or charter of each arrangement
• Your handling policy for received information — classification, storage, who may act on it
• Evidence that shared outbound information was cleared before it left

That last one is underrated. Sharing indicators from a live incident can collide with legal privilege, contractual confidentiality and GDPR at the same time. Decide in advance who signs off on outbound sharing and write it down. For broader documentation expectations, see our supervisory audit evidence checklist.

Make it part of onboarding, not an annual clean-up

The practical fix takes about an hour per client and never needs to be redone from scratch.

Add two questions to your onboarding questionnaire: which threat-sharing communities does this organisation belong to, and who inside the organisation owns each membership. Most clients will name one and forget two — check the security tooling stack and the CSIRT relationships for the rest.

Then file the notifications that are missing, log them, and put the register on the same review cycle as registration data.

Consultants who handle this well end up with something more useful than a compliance artefact: a live map of where each client's threat intelligence actually comes from. That tends to be the first thing a new CISO asks for, and almost nobody has it.

If you want a structured view of where a client stands across Article 21, Article 23 and the governance duties before you start filing anything, run a free NIS2 readiness assessment and work from the gaps it surfaces.

Sharing threat intelligence is one of the few NIS2 obligations that makes an organisation measurably safer rather than merely documented. The filing duty is the cheap part. Do it once, keep the register current, and the voluntary work stays voluntary.