When a vulnerability disclosure is published: what it costs to be wrong
Being wrong here costs time you no longer have. Once a vulnerability disclosure is public, the clock for assessment, notification and remediation starts running immediately, whether or not you have confirmed exposure yet. Guessing at severity, or delaying the internal review, turns a technical problem into a contractual and regulatory one within hours, not weeks.
The legal basis
Directive (EU) 2022/2555 (NIS2) sets the EU-wide baseline for handling and reporting cybersecurity incidents, including vulnerabilities that surface through public disclosure. Each Member State transposes NIS2 into its own law, and the operative notification deadline is fixed by that national transposition, not by the directive itself. Where the vulnerable system incorporates an AI component, Regulation (EU) 2024/1689 (AI Act), in force from 2 August 2026, adds a separate layer of serious-incident reporting once it applies.
Neither instrument tells you, on its own, what your national regulator expects within the first hours after disclosure. That detail sits in national implementing law, which this page does not reproduce.
What changes in practice
Once a disclosure is public, three audiences see it at once: attackers, customers, and any regulator that monitors public advisories. Internally, the question moves from "is this real" to "how fast did we react", and counterparties ask that question before a regulator does.
If patching or containment requires routing data through a new processor, notification duties toward data subjects stack on top of the incident-reporting duty; see When personal data flows to a new subprocessor explained.
| Signal | What it usually means | What moves first |
|---|---|---|
| Disclosure names your product directly | Exposure is confirmed, not suspected | Internal assessment clock |
| Disclosure names a library you use | Exposure depends on how the library is deployed | Dependency mapping |
| Disclosure comes from a researcher, not a regulator | No enforcement clock yet, but a public one | Communications, then assessment |
| Disclosure follows a failed private report | Coordinated disclosure norms were not met | Root-cause review, then notification |
What to do, in order
- The security team confirms within hours whether the disclosed flaw applies to your systems.
- Logs, timestamps and the disclosure text itself are preserved before anything is patched.
- Compliance assesses whether the incident meets the threshold your national NIS2 transposition sets, with counsel where the answer is unclear.
- The designated contact files with the competent authority or CSIRT on the timeline that authority sets.
- Customers and partners under contract receive the disclosure the contract requires, in the form the contract requires.
- Every judgement call on severity and timing is recorded, because that trail is what a regulator reviews later.
Who decides
The competent national authority or CSIRT designated under the NIS2 transposition receives the notification and judges whether the response was adequate. Where a distributor resells the affected product under its own brand, that distributor's regulator may open a parallel review; see When a distributor is sued over your product step. Internally, the call on severity and timing belongs to whoever your incident response policy names, not to whoever happens to be available.
Where this splits
If the vulnerable code is licensed to you under field-of-use terms, the same disclosure can put you outside the licence as well as inside a security incident; see When field-of-use limits are ignored explained.
If the affected system also supports a tokenised offering, the disclosure reaches into the controls that keep the issuer and the platform operationally separate; see When the issuer and the platform are related and.
If no customer data was ever exposed, the incident may stay purely technical. Confirm this before treating the event as reportable at all.
What this page does not cover
This page does not set the exact notification deadline your national law imposes, because that number sits in the national implementing legislation, not in the directive. It does not cover the technical remediation itself, and it does not cover indemnities with your suppliers, which depend on the wording of each contract.
Verified
Last checked 15 March 2025, against Directive (EU) 2022/2555 (NIS2) and Regulation (EU) 2024/1689 (AI Act). Primary sources: the Directive and Regulation texts published on EUR-Lex and the European Commission's digital strategy pages.
Related situations
A different clock runs when retention itself is the problem, not disclosure: When logs are kept longer than the policy says.
If a disclosure naming your product has just gone public, treat the first hour as the one that matters most. Aurelis can assess exposure and draft the notification your file needs.
FAQ
What is the first step when a vulnerability disclosure is published?
Confirm whether the disclosed flaw actually applies to your systems. That assessment starts the moment the disclosure becomes public, regardless of whether a regulator has already contacted you.
Which deadline is already running?
The clock for assessing, and where required reporting, the incident starts running as soon as the disclosure is public. The exact number of hours or days is set by the national law that transposes Directive (EU) 2022/2555 (NIS2), not by this page.
Who decides, and on what evidence?
The competent authority or CSIRT designated under your national NIS2 transposition decides, based on the notification you file and the evidence trail your incident response team preserves from the first hour.