Article 30: Voluntary notification of relevant information

To operationalize the article 30: voluntary notification of relevant information requirement, you need a controlled way to submit relevant cyber risk information to the appropriate national CSIRT or competent authority even when Article 23 mandatory incident reporting is not triggered. Build a repeatable intake, decision, approval, and evidence process so voluntary notifications are accurate, timely, and consistent across EU jurisdictions. (Directive (EU) 2022/2555, Article 30)

Key takeaways:

• Create a documented decision tree that separates Article 23 mandatory reporting from Article 30 voluntary notifications. (Directive (EU) 2022/2555, Article 30)
• Assign owners, approval authority, and templates so voluntary notifications can be made without ad hoc judgment calls.
• Retain evidence of what you knew, when you knew it, why you notified (or didn’t), and what you sent.

Article 30 of NIS 2 exists to make voluntary notifications possible in addition to the mandatory incident notification obligations in Article 23. Practically, that means supervisors want a channel where organizations (and other parties allowed by national law) can share “relevant information” with the national CSIRT or competent authority even if the situation does not meet the threshold of a reportable incident.

For a CCO, GRC lead, or security compliance owner, the operational challenge is not drafting another policy. The challenge is making voluntary notification a controlled action: consistent criteria, the right approvers, correct routing to the right authority in the right Member State, and defensible records. Voluntary notifications can help reduce systemic risk and build credibility with authorities, but sloppy submissions can also create avoidable follow-up scrutiny if you provide incomplete facts, contradict later incident reports, or notify the wrong authority.

This page gives requirement-level implementation guidance you can put into your incident governance and regulatory engagement model quickly: scope, triggers, roles, workflow steps, artifacts, audit questions, common mistakes, and a practical execution plan aligned to how NIS 2 supervision works through national transposition. (Directive (EU) 2022/2555)

Regulatory text

Excerpt (provided): “Member States shall ensure that, in addition to the notification obligation provided for in Article 23, notifications can be submitted to the CSIRTs or, where applicable, the competent authorities, on a voluntary basis…” (Directive (EU) 2022/2555, Article 30)

Plain-English interpretation

• Your Member State(s) must provide a way to submit voluntary notifications to the national CSIRT or competent authority beyond mandatory reporting. (Directive (EU) 2022/2555, Article 30)
• For operators, the requirement becomes operational readiness: you should be able to decide when a voluntary notification is appropriate, route it to the correct body, and keep a record that stands up to supervisory questions. (Directive (EU) 2022/2555, Article 30)

Operator intent: Treat voluntary notification as a governed regulatory communication pathway, not an informal email sent by whichever engineer happens to be talking to a CSIRT.

Who it applies to (entity and operational context)

Because Article 30 is written as a “Member States shall ensure…” obligation, your exact ability and method to submit voluntary notifications depends on the national transposition in each Member State where you operate and which authority is designated for your sector. (Directive (EU) 2022/2555)

In practice, you should operationalize this if you are:

• A NIS 2 in-scope organization (essential or important entity) building a complete incident reporting and regulatory engagement program. (Directive (EU) 2022/2555)
• A group with multiple EU establishments that needs consistent handling across jurisdictions (for example, shared SOC but country-specific legal entities).
• A regulated entity that routinely discovers “near misses,” vulnerabilities, third-party compromises, or threat intel that could be relevant to national cyber defense, even when it’s not clearly a mandatory incident under Article 23.

Operational contexts where voluntary notifications come up

• You identify a credible threat campaign targeting your sector and can provide indicators of compromise (IOCs) or TTPs to the CSIRT.
• You experience a security event with limited impact but high learning value (for example, successful containment before disruption).
• A critical third party notifies you of an incident that does not yet impact your services but may become relevant to national situational awareness.
• You discover a material vulnerability in an exposed system and want to coordinate disclosure/mitigation signals with authorities.

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

Build a “Voluntary Notification” capability as a small extension of your Article 23 reporting workflow. The key difference: the trigger is relevance, not mandatory threshold. (Directive (EU) 2022/2555, Article 30)

Step 1: Add Article 30 to your obligation register and jurisdiction map

1. List each EU Member State where you have NIS 2 exposure (entity established, services provided, or supervised).
2. For each state, capture:
   • Designated CSIRT / competent authority (as defined locally once transposed).
   • Submission mechanism (portal, email, required forms) once available.
   • Language expectations and required data fields if prescribed nationally.

Daydream fit: In Daydream, track Article 30 as a requirement with a per-jurisdiction applicability note, a control owner, and an implementation milestone so you don’t lose local nuances in a central program.

Step 2: Define a “voluntary notification” decision rule you can defend

Create a short decision tree embedded in your incident/runbook tooling:

Decision points

• Does this meet your Article 23 mandatory notification criteria? If yes, follow the mandatory workflow, and do not substitute Article 30. (Directive (EU) 2022/2555, Article 30)
• If not mandatory, is the information “relevant” to national cyber situational awareness or risk reduction?
  • Could it help prevent harm to others (IOCs, exploited vulnerability patterns, sector-targeting campaign)?
  • Does it involve critical services, widely used products, or a systemic third party dependency?
  • Is there a credible risk of escalation that authorities should monitor?

Governance rule: Require a documented rationale for “notify” and “do not notify” decisions.

Step 3: Assign owners and approvals (so the right people press send)

Minimum roles to define:

• Process owner: typically CISO operations, incident response lead, or GRC incident governance owner.
• Approval authority: Legal/Compliance plus Security leadership, with a named backup.
• Sender of record: a controlled mailbox or portal account owned by a function, not an individual.

Also define who must be consulted:

• Data protection/privacy (if personal data could be implicated).
• Third-party risk owner (if a third party is involved and contractual notice constraints apply).
• Product/security engineering (for technical accuracy).

Step 4: Standardize the content (template) and classification checks

Create a voluntary notification template that captures:

• What happened / what was observed (facts only).
• Affected environment boundaries (systems, services, geography).
• Confidence level and what is still unknown.
• IOCs, TTPs, or vulnerability details as appropriate.
• Mitigations applied and recommended actions others can take.
• Contact point for follow-up.

Add two gating checks before submission:

• Accuracy check: avoid speculative statements presented as fact.
• Confidentiality check: confirm you are not breaching contractual confidentiality with a third party or disclosing sensitive exploitation details in an unsafe channel.

Step 5: Route to the correct body and record the submission

Operationalize routing:

• Maintain a directory that maps “entity + Member State + sector” to CSIRT/competent authority.
• Use a single intake queue to coordinate multi-country submissions so you do not send conflicting messages.

Recordkeeping:

• Save the exact submission content (PDF export or message copy).
• Save portal confirmation receipts or email headers.
• Save internal approvals and the decision rationale.

Step 6: Integrate third-party dependency signals

Voluntary notifications often start with a third party: SaaS compromise, managed service provider issue, telecom disruption warnings.

Actions:

• Require third parties to provide structured incident advisories (what/when/scope/IOCs).
• Triage whether the third party’s event creates “relevant information” for authorities even before your services are impacted.
• Keep a separate “third party notification pack” so you can share what’s permissible without disclosing the third party’s confidential details.

Step 7: Add exam-ready testing

Test the workflow the same way you test mandatory incident reporting:

• Tabletop a “near miss with sector-wide IOCs” scenario.
• Verify you can identify the correct authority, produce the template, obtain approvals, and generate an evidence package.

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository with retention aligned to your broader incident governance program:

1. Article 30 procedure/runbook (including decision tree and roles). (Directive (EU) 2022/2555, Article 30)
2. Jurisdiction routing matrix (CSIRT/competent authority per Member State, once known via transposition). (Directive (EU) 2022/2555)
3. Voluntary notification template (version-controlled).
4. Voluntary notification log/register with:
   • Date/time of decision
   • Decision outcome (notify / do not notify)
   • Rationale
   • Approvers
   • Submission channel and confirmation reference
5. Copies of submissions and proof of transmission/receipt.
6. Supporting technical evidence (redacted as needed): incident tickets, SOC alerts, forensic summary, IOCs shared.
7. Third-party communications that informed the decision (advisories, emails, portal notices), with confidentiality markings.

Common exam/audit questions and hangups

Expect supervisors or internal audit to probe:

• “Show me how you distinguish voluntary from mandatory notifications.” Have the decision tree and examples ready. (Directive (EU) 2022/2555, Article 30)
• “Who is authorized to notify a CSIRT?” If the answer is “anyone,” you will get a governance finding.
• “How do you ensure completeness and accuracy?” Point to template fields, technical review, and legal/compliance approval steps.
• “How do you handle multi-country operations?” Auditors want consistency and avoidance of contradictory submissions.
• “How do third parties factor in?” Have the dependency workflow and contractual review approach.

Hangups that slow teams down:

• Waiting for perfect certainty before sharing time-sensitive IOCs.
• Confusing “voluntary” with “informal,” then losing evidence.
• Not knowing which national body to contact due to incomplete jurisdiction mapping. (Directive (EU) 2022/2555)

Frequent implementation mistakes and how to avoid them

Mistake	Why it hurts	How to avoid
Treating Article 30 as optional “nice to have” and never wiring it into operations	You end up with ad hoc outreach with no controls	Add an explicit workflow step in incident triage for “consider voluntary notification”
Sending speculative narratives	Creates credibility problems and follow-up burden	Separate “known facts,” “assessment,” and “unknowns” in your template
Not retaining evidence of “do not notify” decisions	You can’t defend your judgment later	Maintain a notification register that logs both notify and no-notify outcomes
Routing to the wrong authority	Wastes time and can create supervisory friction	Keep a maintained routing matrix by jurisdiction and sector
Oversharing third-party confidential details	Contract breach risk; may reduce third-party cooperation	Redact, summarize, and coordinate with legal and the third party where feasible

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so you should treat enforcement expectations as driven by national transposition and supervisory practice. (Directive (EU) 2022/2555)

Risk implications to manage anyway:

• Regulatory relationship risk: poorly controlled voluntary notifications can create preventable supervisory follow-ups.
• Legal and confidentiality risk: voluntary sharing can conflict with third-party contractual terms or ongoing investigations if not reviewed.
• Operational readiness risk: if you cannot execute voluntary notification cleanly, it is a signal you may also struggle with mandatory reporting under Article 23 during a real crisis. (Directive (EU) 2022/2555, Article 30)

Practical 30/60/90-day execution plan

You asked for speed. Use this as an operator checklist, not a transformation program.

First 30 days (foundation)

• Name an Article 30 owner and an approval authority (primary and backup).
• Add Article 30 to your obligation register with jurisdictions in scope. (Directive (EU) 2022/2555, Article 30)
• Draft the decision tree and integrate it into incident triage.
• Create the notification template and controlled mailbox/portal account approach.
• Start a notification register (log) and define evidence storage location.

Next 60 days (operationalization)

• Build the jurisdiction routing matrix as Member State details become available through transposition. (Directive (EU) 2022/2555)
• Train SOC/IR leads, legal, comms, and third-party risk on:
  • When to propose a voluntary notification
  • What content is acceptable
  • Who approves
• Run one tabletop focused on a “relevant information” scenario (IOCs, vulnerability, third-party advisory).
• Add third-party intake fields to capture “relevance signals” (sector-wide exposure, shared dependencies).

Next 90 days (validation and audit readiness)

• Perform a retro review of recent security events and document at least a few “would we voluntarily notify?” decisions in the register.
• Implement quality checks: template completeness review, redaction rules, and final approval capture.
• Add metrics that help management oversight without inventing targets:
  • Count of considered voluntary notifications
  • Common reasons for notify/no-notify
  • Time from identification to decision (track internally for improvement)
• Package artifacts into an “exam binder” folder so you can respond to supervisory questions quickly.

Mapping to related compliance frameworks (for operators)

Use these frameworks to operationalize controls without inventing new governance:

• ISO/IEC 27001: align the voluntary notification procedure to your incident management and external communication controls.
• NIST CSF: align to incident response, communications, and improvements (post-event learning and sharing).

(These are implementation aids; your legal obligation remains NIS 2 as transposed nationally.) (Directive (EU) 2022/2555)

Frequently Asked Questions

Does Article 30 create a mandatory obligation for my company to submit voluntary notifications?

Article 30 requires Member States to ensure voluntary notifications can be submitted; it does not read as a direct duty that every event must be voluntarily reported. You still need an internal process to decide and document when you will submit. (Directive (EU) 2022/2555, Article 30)

How do we decide what “relevant information” means in practice?

Define relevance criteria tied to sector-wide risk, actionable technical indicators, systemic third-party dependencies, or credible escalation risk. Require a short written rationale each time you choose to notify or not notify. (Directive (EU) 2022/2555, Article 30)

Can voluntary notification replace Article 23 mandatory incident reporting?

No. Your workflow should first test for Article 23 mandatory triggers, then consider Article 30 only for non-mandatory but relevant information. Keep the two paths separate in your runbooks and evidence. (Directive (EU) 2022/2555, Article 30)

Who should be allowed to send a voluntary notification to a CSIRT?

Restrict sending authority to a small set of named roles or a controlled mailbox with approvals from Security and Legal/Compliance. This reduces the risk of inconsistent statements and missing evidence.

What if the information originates from a third party and they ask us not to share it?

Run a confidentiality and contractual review before submission, and share only what you can substantiate and are permitted to disclose. When possible, share generalized indicators or patterns without identifying the third party unless disclosure is authorized.

How do we stay consistent across multiple EU Member States?

Maintain a jurisdiction routing matrix and a centralized notification register, then allow local adaptations only where national transposition requires different fields or channels. This prevents conflicting submissions and simplifies audit response. (Directive (EU) 2022/2555)