NIS2 Article 29 Explained: How to Join an ISAC, Share Threat Intelligence, and Protect Your Information Under EU Law
When a ransomware campaign hits one European logistics company, the indicators of compromise — IP addresses, file hashes, and attack signatures — are often already sitting in another operator’s threat logs, unshared. The NIS2 Directive creates two distinct mechanisms for voluntary cybersecurity information sharing: Article 29, which establishes the legal framework for ongoing participation in Information Sharing and Analysis Centres (ISACs), and Article 30, which lets any organisation voluntarily notify a CSIRT of threats or near-misses without triggering additional compliance obligations.
For compliance teams, the practical questions are specific. Which article covers which type of sharing? Which ISACs are active in your sector? What must you tell your competent authority when you join one? And what legal protections apply to the information you share?
This guide answers all of those questions using the directive text and ENISA guidance. It also clarifies a distinction most NIS2 articles blur: Article 29 (ongoing ISAC participation) and Article 30 (one-off voluntary CSIRT notification) serve different purposes with different legal consequences. Knowing which to use — and when — is the difference between participating strategically and leaving threat intelligence on the table.
Three Channels, One Framework: Articles 23, 29, and 30 Compared
NIS2 creates three distinct channels for communicating cybersecurity events to other entities or authorities. Each has different triggers, obligations, and legal effects. Most compliance guidance focuses almost entirely on the mandatory channel — leaving organisations unaware of the protections and strategic value the voluntary channels provide.
Article 23 is mandatory. When an essential or important entity experiences a “significant incident” — one causing severe operational disruption, substantial financial loss, or material harm to others — the entity must submit an early warning within 24 hours, an incident notification within 72 hours, and a full report within one month. Failure to report carries penalties up to EUR 10 million or 2% of global annual turnover for essential entities.
Article 29 is voluntary and ongoing. It creates the legal framework for entities to exchange cybersecurity information within structured communities — ISACs being the primary mechanism — on a continuous basis. There is no reporting deadline and no penalty for non-participation, with one exception: joining or withdrawing from an ISAC triggers a mandatory notification to your competent authority under Article 29(4).
Article 30 is voluntary and event-triggered. It allows any organisation — including those outside NIS2 scope — to notify their national CSIRT of a specific incident, threat, or near-miss that does not meet the Article 23 significance threshold. Voluntary notification triggers no additional compliance obligations and carries guaranteed confidentiality protection.
| Article 23 | Article 29 | Article 30 | |
|---|---|---|---|
| Type | Mandatory | Voluntary, ongoing | Voluntary, one-off |
| Primary trigger | Significant incident | Joining or leaving ISAC | Any incident, threat, or near-miss |
| Who must act | Essential and important entities | Essential and important entities + suppliers | Any entity, including out-of-scope organisations |
| Information flows to | Competent authority / CSIRT | ISAC community peers | CSIRT or competent authority |
| Non-compliance penalty | Up to EUR 10M / 2% turnover | None for non-participation | None |
What Article 29 Actually Requires
Article 29 of Directive (EU) 2022/2555 establishes the voluntary information-sharing framework in five paragraphs. Most compliance guidance mentions only that participation is voluntary — but each paragraph carries distinct operational implications.
Article 29(1): What can be shared
Member States must ensure that entities within NIS2 scope — and, where relevant, entities outside scope — can exchange “on a voluntary basis relevant cybersecurity information among themselves.” The directive specifies the categories of shareable information:
- Cyber threats and adversarial tactics
- Near misses — events that could have caused incidents but were contained
- Vulnerabilities and indicators of compromise (IoCs)
- Techniques, tactics, and procedures (TTPs)
- Threat-actor-specific intelligence
- Cybersecurity alerts and configuration recommendations for detection tooling
The sharing must aim to prevent, detect, respond to, or recover from incidents — or to raise general cybersecurity awareness. This scope is broad enough to encompass most operational threat intelligence that security teams generate from day-to-day monitoring.
Article 29(2): Communities of entities
Information exchange occurs “within communities of essential and important entities, and where relevant, their suppliers or service providers.” This is the directive’s explicit endorsement of ISACs — though the directive uses the term “cybersecurity information-sharing arrangements” rather than “ISAC.” Critically, suppliers are included: an essential entity’s cloud provider or SaaS vendor can participate in the same ISAC, directly aligning Article 29 with the supply chain security obligations under Article 21(2)(d).
The arrangements must “respect the potentially sensitive nature of the information shared” — the legal basis for confidentiality mechanisms like the Traffic Light Protocol (see Section 6 below).
Article 29(3): Operational framework
Member States must facilitate these arrangements, which may specify “operational elements, including the use of dedicated ICT platforms and automation tools.” National competent authorities and CSIRTs may impose conditions on information they contribute — for example, restricting redistribution of threat intelligence originating from government sources to protect source identity or active investigations.
Article 29(4): The notification obligation most compliance teams miss
When an essential or important entity joins or withdraws from a cybersecurity information-sharing arrangement, it must notify its competent authority. This is an obligation, not a recommendation. If your organisation plans to join an ISAC, the Art. 29(4) competent authority notification must appear in your onboarding checklist — before sharing begins, not after. Member states maintain registers of participating entities, and the notification also creates a documented audit trail of your engagement with NIS2’s information-sharing framework.
Article 29(5): ENISA’s role
ENISA is assigned a formal coordination role: it provides assistance for establishing information-sharing arrangements by exchanging best practices and providing guidance. In practice, ENISA publishes ISAC cooperative models, hosts the annual EU ISACs Summit, and operates the EU ISACs Council for cross-sector coordination.
What Article 30 Provides: Voluntary CSIRT Notification
Where Article 29 governs ongoing peer-to-peer sharing within communities, Article 30 governs one-off voluntary reports submitted directly to national authorities. The two articles are complementary — an organisation can use both simultaneously for the same event.
Who can notify
Article 30 is broader than most of NIS2 in one important respect: it explicitly applies to “entities other than those referred to in [Article 23(1)] regardless of whether they fall within the scope of this Directive.” In plain terms, organisations that are not classified as essential or important entities can use Article 30. Sector-adjacent companies, mid-market suppliers, and public bodies outside NIS2 scope all qualify.
What triggers voluntary notification
Article 30 covers incidents, cyber threats, and near-misses that do not reach the “significant incident” threshold required by Article 23. In practice this includes: ransomware attacks contained before causing significant disruption; phishing campaigns detected at the gateway before reaching users; vulnerabilities with significant exploitation potential that have been patched internally; suspicious supply chain activity that was mitigated; and DDoS attempts absorbed without service loss. The intent is to encourage shared learning across sectors, not just to capture major incidents.
Legal protections under Article 30
The directive is explicit: “voluntary reporting shall not result in the imposition of any additional obligations upon the notifying entity to which it would not have been subject had it not submitted the notification.” Two protections apply simultaneously:
- CSIRTs must maintain “confidentiality and appropriate protection” of the reported information
- Reporting cannot trigger enforcement action, fines, or new compliance requirements
Member States may prioritise mandatory Article 23 reports over voluntary ones, but both must be processed. The CSIRT typically anonymises voluntary reports before using the information for sector-wide alerting — so competitors within your ISAC community or sector will receive the threat intelligence without knowing its source.
EU-Level ISACs: Sector by Sector
ISACs — Information Sharing and Analysis Centres — are the primary organisational mechanism through which Article 29 sharing arrangements operate in practice. ENISA defines them as “non-profit, trusted hubs designed to improve cybersecurity resilience across critical sectors by enabling the collection, analysis, and secure exchange of threat information between public and private stakeholders.”
The following ISACs are active across the EU and map to NIS2’s sectors of high criticality:
| Sector | ISAC Name | Notes |
|---|---|---|
| Energy | European Energy ISAC (EE-ISAC) | Covers electricity, gas, and energy infrastructure operators |
| Finance | European FI-ISAC | Supported by ENISA; banks, payment systems, insurance |
| Healthcare | Health-ISAC (H-ISAC) | Global ISAC; EU members receive NIS2-aligned guidance |
| Automotive | Auto-ISAC Europe | Formal collaboration with ACEA and CLEPA since 2022 |
| Space | EU Space ISAC | Established with EUSPA support; aligned with NIS2 and CER Directive |
| Cross-sector | ENISA EU ISACs Council | Coordination body bringing together EU ISAC operators annually |
NIS2’s ten sectors of high criticality each have at least one relevant ISAC or an emerging community. Sectors without an established ISAC — including parts of water management and public administration — are actively encouraged by ENISA to begin establishing new arrangements. The agency can connect organisations in sectors lacking an ISAC with cross-sector alternatives while a dedicated community is being built.
How to Join an ISAC: A Four-Step Process
Joining an ISAC is a structured process — not a form submission. ISACs are trust communities, and membership involves vetting, relationship-building, and a technical integration step that most compliance guides overlook entirely.
Step 1: Identify your sector ISAC
Start at the ENISA ISACs page. ENISA maps each NIS2 sector to the relevant community and can connect organisations with emerging ISACs or cross-sector alternatives where a dedicated hub does not yet exist. For organisations in the energy, finance, or health sectors, the relevant ISAC is already established and accepting members.
Step 2: Review membership criteria
ISACs vary significantly in acceptance procedures. Common models include voting by current members on new applicants (most typical for ISACs with established communities), sponsorship by an existing member, sector or geographic alignment requirements, and mandatory face-to-face meetings before admission. According to MISP’s ISAC governance guidelines — the reference framework for most EU information-sharing communities — approximately 30% of member organisations actively contribute threat data. ISACs deliberately accept this ratio rather than requiring uniform contribution levels: passive recipients still expand the coverage and response reach of shared intelligence.
Step 3: Onboard and integrate technically
Most EU ISACs use MISP (Malware Information Sharing Platform) as their technical backbone. MISP supports automated indicator exchange, sharing groups for sub-community compartmentalisation, and flexible taxonomies for classifying IoCs and threat intelligence. You will typically need to connect a MISP instance — either self-hosted, ISAC-hosted, or hybrid — and align your security tooling to consume the ISAC’s intelligence feeds. Expect an initial onboarding period of two to four weeks for technical integration.
Step 4: Notify your competent authority under Article 29(4)
This step is mandatory and must not be treated as optional. As soon as your organisation formally joins an ISAC, notify your national competent authority. The procedure varies by member state — check your NCA’s website or national NIS2 transposition legislation for the specific notification channel and form. Document the date of notification and any acknowledgement received in your ISMS as audit evidence of NIS2 compliance.
Confidentiality Protections: TLP and Legal Safeguards
One of the most common reasons organisations hesitate to share threat intelligence is concern that sensitive information will reach competitors, trigger regulatory scrutiny, or create downstream liability. NIS2 addresses this through two complementary mechanisms: the Traffic Light Protocol at the operational level, and explicit legal safeguards at the legislative level.
Traffic Light Protocol (TLP v2.0)
TLP is maintained by FIRST (Forum of Incident Response and Security Teams) and is the standard confidentiality classification system used by EU ISACs and CSIRTs. TLP version 2.0 became the authoritative standard in August 2022 and introduced TLP:AMBER+STRICT as a new label for organisation-only sharing.
| TLP Label | Permitted Sharing | Typical ISAC Use Case |
|---|---|---|
| TLP:RED | No further disclosure — recipients only | Sensitive threat-actor intelligence shared only in real-time closed sessions |
| TLP:AMBER+STRICT | Within the originating organisation only | Intelligence affecting a specific organisation’s systems |
| TLP:AMBER | Organisation and named clients, need-to-know basis | Sector-level threat briefings requiring controlled distribution |
| TLP:GREEN | Within the ISAC community, not publicly | Most operational threat intelligence — IoCs, TTPs, alerts |
| TLP:CLEAR | No restriction | General awareness bulletins and public cybersecurity advisories |
Legal safeguards under NIS2
Article 29(2) requires information-sharing arrangements to “respect the potentially sensitive nature of the information shared” — the legislative basis for TLP and equivalent classification schemes within ISAC communities. Article 30 goes further: voluntary CSIRT notifications carry guaranteed confidentiality and cannot trigger additional compliance obligations. An organisation that reports a near-miss under Article 30 cannot be penalised on the basis of that report, cannot have new audits imposed as a direct consequence, and can expect the CSIRT to anonymise the information before any wider sectoral dissemination.
The Often-Missed Article 29(4) Obligation
Article 29(4) creates a specific procedural obligation that most compliance guides omit entirely: when an essential or important entity joins or withdraws from a cybersecurity information-sharing arrangement, it must notify its competent authority. This mirrors the logic of other NIS2 registration requirements — member states need to know which entities are participating in structured sharing communities in order to map sectoral coverage and identify gaps.
For entities, the notification also creates a formal audit trail demonstrating proactive engagement with NIS2’s information-sharing framework — relevant context during any supervisory review of your organisation’s overall security posture.
Practical compliance steps for Article 29(4):
- Include the competent authority notification as an explicit step in your ISAC onboarding checklist, to be completed before sharing begins
- Locate your national NCA’s notification procedure on their official website or transposition legislation
- Record the notification date and acknowledgement in your ISMS documentation
- Repeat the notification if you withdraw from an ISAC or transfer to a different sharing arrangement
ENISA Resources for Information Sharing
Under Article 29(5), ENISA is assigned a formal coordination and capacity-building role in the NIS2 information-sharing ecosystem. ENISA’s NIS2 Technical Implementation Guidance covers Article 29 implementation alongside the technical security measures under Article 21. The following resources are directly relevant to information sharing compliance:
- ENISA ISACs Toolkit: Practical guidance for ISAC operators, including TLP implementation, governance models, and technical platform selection
- ISAC Cooperative Models report: Covers governance structures, membership models, and ENISA’s strategic role in building EU-wide ISAC capacity
- EU ISACs Summit: Annual event bringing together ISAC operators, ENISA staff, and national authorities — the primary forum for cross-sector threat coordination across the EU
- ENISA CISP (Cybersecurity Information Sharing Platform): The operational EU-level platform for exchanging cybersecurity information, available for both Article 29 ISAC communities and Article 30 voluntary notifications to authorities
Frequently Asked Questions
Does my organisation have to join an ISAC under NIS2?
No. Article 29 enables but does not mandate ISAC participation. However, joining a relevant ISAC signals proactive risk management to competent authorities and auditors, and sector supervisors in high-risk sectors — energy, finance, and healthcare in particular — are increasingly treating active ISAC participation as a positive indicator of security culture. Participation also gives your security team access to real-time threat intelligence that is not available through public channels.
Can our suppliers join the same ISAC as us?
Yes. Article 29(2) explicitly includes suppliers and service providers of essential and important entities. This is deliberate: sharing threat intelligence with critical suppliers through a structured ISAC arrangement directly supports the supply chain security requirements of Article 21(2)(d). An essential entity and its cloud provider participating in the same ISAC is the intended use case.
What if our sector has no active ISAC?
Contact ENISA directly. The agency actively supports the creation of new ISACs for sectors where communities do not yet exist and can connect your organisation with emerging arrangements or cross-sector alternatives. Documenting your outreach to ENISA or to an adjacent sector ISAC is also useful audit evidence that your organisation has made a genuine attempt to engage with Article 29 — even where an appropriate ISAC does not yet exist.
Can we use Article 30 and Article 29 for the same event?
Yes. They serve different audiences and different timescales and are not mutually exclusive. An organisation can simultaneously report a specific near-miss to its CSIRT under Article 30 and share the associated indicators of compromise with its ISAC community under Article 29. Article 30 is event-triggered and directed at national authorities; Article 29 sharing is ongoing and directed at sector peers.
Do voluntary Article 30 notifications appear on any public register?
No. The directive requires CSIRTs to maintain confidentiality of voluntary notifications. Before using any voluntary report for sector-wide alerting, the CSIRT must anonymise the information so that the reporting entity cannot be identified. The legal prohibition on using voluntary reports to impose additional obligations provides a further layer of protection.
Legal Disclaimer
This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.
Sources
- Article 29: Cybersecurity Information-Sharing Arrangements — NIS-2-Directive.com
- Article 30: Voluntary Notification of Relevant Information — NIS-2-Directive.com
- Voluntary NIS 2 Incident Reporting: How Article 30 Builds Trust and Resilience — ISMS.online
- Information Sharing and Analysis Centers (ISACs) — ENISA
- Information Sharing and Analysis Center (ISACs) — Cooperative Models — ENISA
- Traffic Light Protocol (TLP) — FIRST.org
- Guidelines to Set Up an ISAC — MISP/misp-compliance
- Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex
