Article 29: Cybersecurity information-sharing arrangements

Article 29 requires that in-scope NIS 2 entities can voluntarily share relevant cybersecurity information (threats, vulnerabilities, near misses, IOCs, tactics, alerts, recommendations) through information-sharing arrangements, with appropriate safeguards. Operationalize it by standing up a governed sharing program: define what you share, with whom, how you protect sensitive data, and how you evidence participation. (Directive (EU) 2022/2555, Article 29)

Key takeaways:

• Stand up a governed, voluntary information-sharing program with clear scope, roles, and escalation paths. (Directive (EU) 2022/2555, Article 29)
• Treat “sharing” as a controlled process: sanitize, classify, approve, transmit, and retain evidence. (Directive (EU) 2022/2555, Article 29)
• Your audit-ready proof is participation plus guardrails: procedures, memberships, sample shares, and decision logs. (Directive (EU) 2022/2555, Article 29)

Article 29: cybersecurity information-sharing arrangements requirement is easy to misunderstand because it reads like a Member State obligation, but examiners will still pressure-test your organization’s readiness to participate in voluntary sharing. Practically, they want to see that you can exchange actionable cybersecurity information with peers and relevant communities without creating new legal, privacy, or operational risk. (Directive (EU) 2022/2555, Article 29)

For a CCO or GRC lead, the fastest path is to treat information sharing like any other regulated operational capability: define governance, define the information types, define channels, add safeguards (classification, sanitization/redaction, approval, secure transmission), and prove it works with retained artifacts. Your goal is not to “share everything.” Your goal is to share the right things quickly, safely, and consistently, and to show you made reasonable decisions when you chose not to share. (Directive (EU) 2022/2555, Article 29)

This page focuses on requirement-level execution. It gives you an implementable procedure, the minimum evidence set to retain, common audit questions, and the execution plan most teams can run without waiting for a major tool rollout.

Regulatory text

NIS 2 Article 29 states that Member States shall ensure that entities within scope of the Directive (and, where relevant, other entities) are able to exchange, on a voluntary basis, relevant cybersecurity information among themselves, including information on cyber threats, near misses, vulnerabilities, techniques and procedures, indicators of compromise, adversarial tactics, threat-actor-specific information, cybersecurity alerts, and recommendations. (Directive (EU) 2022/2555, Article 29)

Operator interpretation: you should be able to participate in information-sharing arrangements and exchange the listed categories of information in a controlled way. “Able to exchange” is what gets operationalized: defined intake and outbound sharing, approved channels, safeguards, and proof of participation. (Directive (EU) 2022/2555, Article 29)

Plain-English interpretation (what the requirement means)

Article 29 expects a working capability to:

• Receive threat intelligence and peer alerts (intake).
• Act on it (triage to detection engineering, vulnerability management, incident response).
• Share back what is relevant (outbound), voluntarily, with peers or trusted communities, without exposing sensitive business, customer, or security details. (Directive (EU) 2022/2555, Article 29)

A practical reading: build a repeatable “share/receive” workflow the same way you build incident reporting workflows. If you can’t describe who approves a share, what gets redacted, where it gets posted, and where the evidence lives, you don’t have an exam-ready program.

Who it applies to (entity + operational context)

Entities: organizations that fall within the scope of NIS 2 (your specific classification depends on national transposition and your sector/size), plus “where relevant” arrangements that may include other entities participating in the same sharing communities. Article 29 is framed as a Member State enablement duty, but you should still expect supervisory expectations to translate into operational readiness requirements for in-scope entities. (Directive (EU) 2022/2555, Article 29)

Operational contexts where you should implement it:

• Security operations and threat intel (intake/outbound sharing of IOCs, TTPs, alerts).
• Vulnerability management (sharing vulnerability context, exploitation signals, mitigations).
• Incident response (sharing near misses, techniques observed, and lessons learned at a safe level).
• Third-party and supply-chain security (sharing supplier compromise indicators or campaigns, sanitized).
• Industry coordination channels (ISAC-style communities, CERT-style interactions, peer groups). (Directive (EU) 2022/2555, Article 29)

What you actually need to do (step-by-step)

Use this as an implementable build sheet.

1) Assign ownership and define governance

• Name an Information Sharing Program Owner (often SOC lead or Threat Intel lead) and a Compliance/Risk approver for policy and guardrails.
• Define an approval model: what can be shared without escalation, what requires legal/privacy review, and what requires executive awareness.
• Document decision criteria for “share vs. don’t share” (relevance, confidence, sensitivity, contractual constraints). (Directive (EU) 2022/2555, Article 29)

Artifact: Information Sharing Standard Operating Procedure (SOP) with RACI.

2) Define the sharing scope (what data types, what formats)

Create a scope table aligned to Article 29 categories:

Category (Article 29 examples)	Inbound handling	Outbound sharing rule
Threats / alerts / recommendations	Triage within security ops	Share sanitized summary + actionable mitigations
Near misses	Log and learn; feed detections	Share anonymized pattern + control gap (no sensitive details)
Vulnerabilities	Route to vuln mgmt	Share affected product class, exploitation signals, mitigations
Techniques/procedures, IOCs, adversary tactics	Validate and enrich	Share verified IOCs with timestamps/context; avoid victim identifiers
Threat-actor-specific info	Treat as intelligence	Share cautiously; source-tag; avoid speculation

Keep it operational: define required fields for an outbound “share package” (confidence level, observed timeframe, environment notes, recommended actions, contact point).

3) Choose arrangements and channels (and control them)

• List your information-sharing arrangements (communities, sector groups, CERT interactions, peer channels).
• Approve authorized channels (portal, email lists with encryption, ticket-based exchanges) and ban ad hoc sharing in unmanaged chat rooms for anything non-public.
• Require identity and access controls for any platform used to exchange information (membership vetting, role-based access). (Directive (EU) 2022/2555, Article 29)

Artifact: Register of information-sharing arrangements (name, purpose, scope, membership, channel owner).

4) Build safeguards: classification, sanitization, and legal/privacy checks

Implement a simple control set:

• Data classification rule: label outbound shares (for example: Public / Community-Restricted / Confidential) and define what each label permits.
• Sanitization checklist: remove customer identifiers, sensitive internal IP ranges, employee personal data, exploit code where inappropriate, and operational details that increase attacker advantage.
• Third-party constraints check: verify contracts and NDAs before sharing supplier-related information; document exceptions.
• Record what you changed: keep a short redaction note (“hostnames removed; customer identifiers removed; internal ticket IDs removed”). (Directive (EU) 2022/2555, Article 29)

5) Operationalize intake: make inbound intel actionable

• Create an intake queue for inbound shares (email alias, ticket type, or platform integration).
• Define triage SLAs as internal guidance (no external numeric claims needed): who reviews, how to validate, how to disseminate to detection engineering/vuln mgmt.
• Track outcomes: detection added, rule tuned, vuln prioritized, advisory issued internally. (Directive (EU) 2022/2555, Article 29)

Artifact: Threat intel intake log with disposition and actions taken.

6) Run outbound sharing as a controlled workflow

Minimum workflow steps:

1. Trigger (incident, near miss, campaign observed, vuln exploitation evidence).
2. Draft share package (using the required fields).
3. Apply sanitization and classification.
4. Obtain required approvals (based on sensitivity).
5. Transmit via approved channel.
6. Capture evidence (what shared, when, where, by whom, to which arrangement).
7. Follow-up handling (responses, additional indicators, internal improvements). (Directive (EU) 2022/2555, Article 29)

7) Prove it’s real: test the process

Do periodic tabletop tests of the workflow:

• Simulate an outbound share (near miss or vuln exploitation signals).
• Validate that approvals, redaction, transmission, and retention all work.
• Capture gaps and remediation actions. (Directive (EU) 2022/2555, Article 29)

8) Tie it into your NIS 2 obligation tracking

Article 29 becomes shelfware when it’s disconnected from your wider NIS 2 program management. Maintain a NIS 2 obligation register with jurisdictional applicability notes, owners, and milestones, and link Article 29 to your incident handling and third-party dependency controls. Daydream is typically the system teams use to keep that obligation register current and audit-ready without losing track across jurisdictions and control owners. (Directive (EU) 2022/2555)

Required evidence and artifacts to retain

Keep evidence that shows both capability and operation:

Program governance

• Information Sharing SOP (scope, RACI, approval paths). (Directive (EU) 2022/2555, Article 29)
• Register of information-sharing arrangements and approved channels. (Directive (EU) 2022/2555, Article 29)
• Data classification + sanitization/redaction checklist for shares. (Directive (EU) 2022/2555, Article 29)

Operational records

• Outbound share log: date/time, arrangement, topic, classification, approver, redaction note, reference ID. (Directive (EU) 2022/2555, Article 29)
• Inbound intake log: source, summary, validation notes, actions taken (detections/vuln/IR). (Directive (EU) 2022/2555, Article 29)
• Samples of shared advisories/IOCs with sensitive elements removed. (Directive (EU) 2022/2555, Article 29)

Testing and oversight

• Tabletop/test results and remediation tickets. (Directive (EU) 2022/2555, Article 29)
• Periodic metrics pack for management (qualitative trends, participation notes, major shares). (Directive (EU) 2022/2555, Article 29)

Common exam/audit questions and hangups

Auditors and supervisors tend to ask:

• “Which information-sharing communities are you part of, and who owns them internally?” (Directive (EU) 2022/2555, Article 29)
• “Show me the last outbound share and the approvals/redaction steps.”
• “How do you prevent accidental disclosure of personal data or sensitive system details?”
• “How do inbound alerts change your detections or vulnerability priorities?”
• “If you chose not to share, show the decision record and rationale.” (Directive (EU) 2022/2555, Article 29)

Hangups that slow teams down:

• Legal review becomes a bottleneck because there is no sensitivity-based approval matrix.
• SOC shares informally, but there is no retained evidence trail.
• Threat intel exists, but it doesn’t land in engineering backlogs.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating Article 29 as optional “nice-to-have.”
   Avoidance: treat it as a required capability; set ownership and create a basic workflow and log. Voluntary refers to participation, not to having no process. (Directive (EU) 2022/2555, Article 29)

2. Mistake: oversharing sensitive incident details.
   Avoidance: enforce classification and a redaction checklist; default to sharing patterns and IOCs, not victim identifiers or internal architecture. (Directive (EU) 2022/2555, Article 29)

3. Mistake: no proof of operation.
   Avoidance: maintain inbound/outbound logs and retain sanitized samples; evidence beats narrative in an exam. (Directive (EU) 2022/2555, Article 29)

4. Mistake: inbound intel is not actioned.
   Avoidance: require a disposition for each inbound item and link it to a ticket or control change. (Directive (EU) 2022/2555, Article 29)

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for Article 29, so this page does not list specific cases. (Directive (EU) 2022/2555, Article 29)

Risk to manage anyway:

• Supervisory credibility risk: inability to show a functioning exchange process can make your broader incident readiness look immature.
• Confidentiality risk: uncontrolled sharing can expose sensitive security data, customer information, or third-party confidential data.
• Operational risk: weak intake handling wastes intel and increases dwell time for known campaigns. (Directive (EU) 2022/2555, Article 29)

Practical execution plan (30/60/90-day)

Day 30 (Foundation)

• Appoint owner, publish SOP outline, and define approval matrix. (Directive (EU) 2022/2555, Article 29)
• Inventory current sharing channels and communities; designate approved channels. (Directive (EU) 2022/2555, Article 29)
• Stand up inbound/outbound logs (even if it’s a controlled spreadsheet stored in your GRC repository).

Day 60 (Operationalize)

• Implement classification labels + sanitization checklist and train SOC/IR on it.
• Create a standard “share package” template for IOCs/alerts/near misses.
• Run one internal tabletop on outbound sharing and capture evidence + remediation tasks. (Directive (EU) 2022/2555, Article 29)

Day 90 (Prove and scale)

• Produce an audit pack: SOP, arrangement register, sample shares, logs, tabletop results.
• Integrate intake outcomes into vulnerability management and detection backlogs.
• Add Article 29 to your NIS 2 obligation register with owners and recurring review, and manage it in Daydream if you need consistent evidence across jurisdictions and teams. (Directive (EU) 2022/2555)

Frequently Asked Questions

Do we have to join an ISAC or a specific community to meet Article 29?

Article 29 requires the ability to exchange information through arrangements on a voluntary basis; it does not name a specific forum in the provided text. Pick arrangements that fit your sector and document why they are appropriate. (Directive (EU) 2022/2555, Article 29)

What is the minimum we should share without creating legal risk?

Share sanitized, actionable items like validated indicators of compromise, high-level tactics observed, and practical mitigation recommendations, with victim identifiers removed. Use an approval matrix for anything sensitive or third-party related. (Directive (EU) 2022/2555, Article 29)

Can we satisfy this with only inbound threat intel subscriptions?

Subscriptions help intake, but Article 29 is about exchanging among entities through arrangements; auditors will expect a defined outbound capability even if you share infrequently. Maintain a process and a log that shows you can execute safely. (Directive (EU) 2022/2555, Article 29)

How do we handle “near misses” without exposing embarrassing details?

Document and share the pattern: attack vector, control that detected it, what would have happened, and what mitigations you implemented. Remove internal hostnames, ticket IDs, and any customer or employee data. (Directive (EU) 2022/2555, Article 29)

Who should approve outbound shares?

Set tiered approvals: SOC leadership for routine IOCs and alerts, privacy/legal for anything that could include personal data or contractual constraints, and executive awareness for high-sensitivity incident narratives. Write this into the SOP so the SOC is not improvising. (Directive (EU) 2022/2555, Article 29)

What will an auditor accept as evidence that the program operates?

A dated SOP, an arrangement register, inbound/outbound logs, and a small set of anonymized sample shares with approval/redaction notes typically satisfies “ability to exchange” better than policy statements alone. (Directive (EU) 2022/2555, Article 29)