Article 12: Coordinated vulnerability disclosure and a European vulnerability database

Article 12 requires you to be ready to receive, assess, and coordinate vulnerability disclosures, including working with your national CSIRT coordinator as a trusted intermediary when needed, and aligning your processes with EU-level vulnerability disclosure expectations and the European vulnerability database. Build an intake channel, triage workflow, coordination playbook, and retention-ready evidence. (Directive (EU) 2022/2555, Article 12)

Key takeaways:

• Stand up a coordinated vulnerability disclosure (CVD) capability: intake, triage, remediation, communication, and closure.
• Pre-wire escalation paths with your national CSIRT CVD coordinator for complex, cross-border, or contested disclosures.
• Retain exam-ready artifacts: disclosures received, decisions made, timelines, communications, and remediation proof.

A CCO, GRC lead, or security compliance owner typically meets Article 12 in two ways: (1) your organization receives vulnerability reports from researchers, customers, or third parties; (2) you discover vulnerabilities in ICT products or ICT services you provide, or that you rely on, and you need a predictable way to coordinate remediation and communications. Article 12 is not an “incident reporting clock” requirement by itself; it is an operational requirement to support coordinated vulnerability disclosure, with Member States designating a CSIRT to coordinate and act as a trusted intermediary where necessary. (Directive (EU) 2022/2555, Article 12)

Operationalizing Article 12 is mostly about readiness. Examiners and competent authorities will expect you to show that you can (a) accept reports safely, (b) make consistent triage decisions, (c) engage the right internal owners and affected third parties, (d) coordinate externally when the situation warrants it, and (e) close the loop with evidence. Done well, this reduces operational risk (unpatched exposures, rushed releases, reputational harm) and compliance risk (being unable to demonstrate control operation under supervision). (Directive (EU) 2022/2555, Article 12)

Target keyword

Article 12: coordinated vulnerability disclosure and a european vulnerability database requirement (Directive (EU) 2022/2555, Article 12)

Regulatory text

What the text says (operator-relevant excerpt)
Each Member State designates a CSIRT as a coordinator for coordinated vulnerability disclosure (CVD). That CSIRT coordinator acts as a trusted intermediary to facilitate interaction between the person reporting a vulnerability and the manufacturer or provider of the potentially vulnerable ICT products or ICT services, when requested by either party. (Directive (EU) 2022/2555, Article 12)

What this means for you as an operator

• You should expect a national CSIRT CVD coordinator function to exist (or be designated under national transposition), and you need a practical way to engage it when coordination is needed. (Directive (EU) 2022/2555, Article 12)
• You must be able to handle inbound vulnerability reports in a controlled way and coordinate with affected manufacturers/providers or downstream customers, rather than treating reports as ad hoc security tickets. (Directive (EU) 2022/2555, Article 12)
• You should prepare to support disclosure workflows that may feed into EU-level vulnerability knowledge sharing and the European vulnerability database, even if your day-to-day interaction is through national channels. (Directive (EU) 2022/2555, Article 12)

Plain-English interpretation

Article 12 expects a functioning “front door” for vulnerabilities and a disciplined process behind it. People need a safe way to report issues; you need a method to validate and prioritize them; and you need a plan for coordinating communications and remediation with the right parties. When the disclosure is sensitive, disputed, multi-party, or cross-border, your national CSIRT coordinator may broker communication as a trusted intermediary. (Directive (EU) 2022/2555, Article 12)

Who it applies to (entity and operational context)

Entities: NIS 2 regulated entities (essential and important) that manufacture, provide, operate, or depend on ICT products or ICT services in scope of their NIS 2 obligations. (Directive (EU) 2022/2555)

Operational contexts that trigger Article 12 work:

• You publish software, firmware, cloud services, managed services, or digital products and receive vulnerability reports.
• You operate critical business systems and discover vulnerabilities that affect customers, patients, citizens, or counterparties.
• A third party discloses a vulnerability in a product/service you use, and you must coordinate patching, mitigations, and communications across internal owners and suppliers.
• A vulnerability researcher requests coordination or asks you to involve a CSIRT intermediary due to responsiveness concerns. (Directive (EU) 2022/2555, Article 12)

Practical scope call: Treat Article 12 as a cross-functional requirement spanning security operations, product/security engineering, legal, communications, and third-party risk management.

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

Step 1: Assign ownership and define your CVD “system of record”

1. Name a CVD process owner (often Product Security, Security Operations, or GRC with Security). Record backup owners for coverage.
2. Choose a system of record (ticketing platform or case management) where every disclosure becomes a case with immutable timestamps, workflow states, and attached evidence.

Exam lens: Authorities look for accountable ownership and repeatable execution, not a shared mailbox with best-effort responses.

Step 2: Create secure intake channels and publish clear reporting guidance

1. Stand up an intake channel suitable for external reporters (security.txt on your primary domains, a dedicated email alias, or a web form with safe file handling).
2. Publish disclosure guidelines: what to include, what to avoid (no production data), safe harbor language as approved by counsel, and expected response pattern.
3. Add authentication and monitoring to the channel (anti-phishing controls, alerting to on-call, logging).

Common hangup: If Legal blocks publishing a policy, at minimum publish a contact route and internal handling procedure so you can show controlled intake.

Step 3: Triage and validate consistently

Build a triage runbook with explicit decision points:

1. Acknowledge receipt and assign a case owner.
2. Validate reproducibility (sandbox testing, version confirmation, exploitability).
3. Determine scope: your product/service, a third-party dependency, customer misconfiguration, or a non-issue.
4. Classify severity using an internal standard (many teams use CVSS internally; use what your org can operate consistently).
5. Decide coordination path:
   • Internal fix only
   • Joint coordination with a supplier/manufacturer
   • Engage national CSIRT coordinator as intermediary if requested by either party or if coordination is otherwise necessary (multi-party, stalled communications, sensitive impact). (Directive (EU) 2022/2555, Article 12)

Operator tip: Write down the escalation triggers in plain language so on-call staff can use them without interpretation debates.

Step 4: Coordinate remediation across internal owners and third parties

1. Open remediation work items for engineering/operations with a clear target state (patch, configuration change, compensating control).
2. If a third party product/service is involved, open a third-party issue record tied to the disclosure case:
   • Supplier contact details and contractual notice mechanism
   • Your requested remediation or mitigation
   • Confirmation artifacts (release notes, advisories, hotfix IDs, support tickets)
3. Track communications: who was contacted, when, and what was agreed.

Third-party risk tie-in: Integrate critical third-party dependencies into risk assessments and remediation tracking so vulnerability response does not die in email threads. This aligns to practical governance expectations highlighted in the provided control recommendations. (Directive (EU) 2022/2555, Article 12)

Step 5: Manage disclosure communications (internal, reporter, and external)

1. Reporter communications: keep them informed of validation status and expected next updates; maintain a single thread attached to the case.
2. Customer communications: prepare templates for advisory, mitigations, and patch availability; coordinate with Support and Account teams.
3. Public disclosure decision: document who approves public advisories and when.
4. CSIRT coordinator involvement: if engaged, record the reason, what the CSIRT coordinated, and outcomes. (Directive (EU) 2022/2555, Article 12)

Step 6: Close the loop with lessons learned and measurable outputs

1. Closure criteria: fix deployed, mitigations applied, customer guidance issued as needed, and reporter notified.
2. Post-case review: capture root cause themes (dependency hygiene, secure coding gaps, missing monitoring).
3. Feed governance: roll up into your NIS 2 obligation register with owners and milestones so your CVD capability is tracked like other NIS 2 deliverables. (Directive (EU) 2022/2555, Article 12)

Required evidence and artifacts to retain

Keep artifacts in a way that supports supervision and internal audit testing:

Core records ¹

• Intake record with timestamps and reporter identity (as available)
• Triage notes (repro steps, affected versions, severity rationale)
• Decision log: internal-only vs supplier coordination vs CSIRT coordinator engagement (Directive (EU) 2022/2555, Article 12)
• Communications log (reporter, supplier, customers, internal approvers)
• Remediation proof (commit IDs, change tickets, patch release references, configuration baselines, monitoring alerts)

Program-level artifacts

• CVD policy and runbook (roles, escalation triggers, approval matrix)
• Contact directory (including national CSIRT coordinator contact path if publicly available in your jurisdiction) (Directive (EU) 2022/2555, Article 12)
• Training/enablement records for triage staff
• Metrics used for governance (backlog, aging, recurrence themes), presented qualitatively if you cannot support strict quantification

Daydream note (earned mention): Daydream is a practical place to keep your NIS 2 obligation register, control owners, and evidence links so CVD artifacts stay audit-ready alongside incident and third-party dependency workflows. (Directive (EU) 2022/2555, Article 12)

Common exam/audit questions and hangups

Expect questions like:

• “Show me how an external researcher reports a vulnerability and how you track it end-to-end.”
• “Who can approve contacting a supplier, and what is the escalation path if they do not respond?”
• “When would you involve the national CSIRT coordinator, and where is that documented?” (Directive (EU) 2022/2555, Article 12)
• “How do you prevent vulnerability reports from being treated as generic support tickets?”
• “Where is the evidence that remediation was implemented and verified?”

Hangups that slow teams down:

• Legal vs Security disagreements on safe harbor language and public disclosures
• Unclear ownership for dependency vulnerabilities (Product vs Infrastructure vs Procurement)
• No single record of decisions and communications

Frequent implementation mistakes and how to avoid them

1. Mistake: A mailbox with no workflow.
   Avoid: require every report to become a tracked case with states (new, triage, coordinating, fixed, closed).

2. Mistake: No supplier coordination playbook.
   Avoid: predefine supplier notification templates and escalation paths; link cases to third-party management records.

3. Mistake: “Severity” is a debate, not a method.
   Avoid: standardize your severity rubric and require a written rationale for exceptions.

4. Mistake: CSIRT coordinator is unknown internally.
   Avoid: add a step in the runbook: “If external coordination is requested or necessary, consult the national CSIRT coordinator path,” and rehearse it in tabletop exercises. (Directive (EU) 2022/2555, Article 12)

5. Mistake: Closing cases without verification evidence.
   Avoid: define closure criteria that include validation of the fix and retention of proof.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 12, so this page does not list cases.

Risk implications still matter operationally:

• Operational risk: unmanaged disclosures lead to missed fixes, rushed patches, inconsistent customer comms, and duplicate work.
• Supervisory risk: inability to demonstrate a working CVD process can create findings even if your technical teams fix issues informally, because you cannot prove governance, coordination, and traceability. (Directive (EU) 2022/2555, Article 12)

Practical 30/60/90-day execution plan

First 30 days (stand up the basics)

• Confirm scope: which products/services and business units receive disclosures.
• Assign a process owner and backups; create the case workflow in your system of record.
• Stand up an intake channel and internal triage checklist.
• Draft and approve a short CVD runbook, including CSIRT coordinator escalation triggers. (Directive (EU) 2022/2555, Article 12)

Days 31–60 (make it repeatable)

• Publish external reporting guidance (or at minimum a contact route plus internal process).
• Build supplier coordination templates and embed them into third-party management workflows.
• Create an approval matrix for external advisories and sensitive communications.
• Run one tabletop exercise for a high-impact vulnerability that requires multi-party coordination. (Directive (EU) 2022/2555, Article 12)

Days 61–90 (make it exam-ready)

• Audit your first set of cases for evidence completeness and decision traceability.
• Add governance reporting to your NIS 2 obligation register: owners, status, and milestones. (Directive (EU) 2022/2555, Article 12)
• Tune your escalation: when to engage the national CSIRT coordinator, who contacts them, and what to document. (Directive (EU) 2022/2555, Article 12)
• Formalize retention: where artifacts live, who can access them, and how long you keep them per your internal policy.

Frequently Asked Questions

Do we need to contact the national CSIRT coordinator for every vulnerability report?

No. Article 12 describes the CSIRT coordinator acting as a trusted intermediary when necessary and upon request of either party. Build the ability to engage them, then use defined triggers for when coordination is needed. (Directive (EU) 2022/2555, Article 12)

Does Article 12 require a public vulnerability disclosure policy?

Article 12 focuses on coordinated disclosure and intermediary coordination. A published policy is a practical way to prove you can receive and manage reports, but your minimum bar is a controlled intake channel and a documented internal process you can evidence. (Directive (EU) 2022/2555, Article 12)

How should we handle vulnerabilities that originate in a third-party product we rely on?

Treat them as first-class disclosure cases with linked third-party remediation tracking. Document supplier contact, agreed mitigations, and verification evidence so you can show coordination and closure. (Directive (EU) 2022/2555, Article 12)

What evidence is most important for supervisors or auditors?

End-to-end traceability: intake timestamp, triage decision rationale, coordination communications, remediation proof, and closure criteria. Program artifacts (runbook, ownership, escalation triggers) matter because they show repeatability. (Directive (EU) 2022/2555, Article 12)

How does the European vulnerability database change what we do operationally?

Assume that your disclosure handling may need to align with EU-level reporting and information-sharing structures via national channels. Keep your records consistent and exportable, and document when you coordinate externally, including via the CSIRT coordinator. (Directive (EU) 2022/2555, Article 12)

We already have incident response. Can we treat vulnerability reports as incidents?

Sometimes a vulnerability becomes an incident, but many do not. Keep a distinct vulnerability intake and coordination workflow, and define when a vulnerability escalates into incident handling so both processes stay clean and auditable. (Directive (EU) 2022/2555, Article 12)

Footnotes

1. Directive (EU) 2022/2555, Article 12