When a vulnerability disclosure is published: what to do first
Rasa Tumenaite writes the data, security and AI layer of this practice.
When a vulnerability disclosure is published, first confirm whether it touches a system you run, a product you supply, or only a third party. Log the exact moment you learned of it — that moment decides every later deadline. Freeze planned changes to the affected component, notify the internal owner, and open an incident record before anyone drafts an external statement.
Legal basis
For entities within scope of Directive (EU) 2022/2555 (NIS2), publication of a vulnerability disclosure does not, by itself, create a reporting duty. The duty attaches to a significant incident: actual or attempted exploitation with an operational effect on your services or systems. NIS2 sets the categories of essential and important entities and the tiered structure of early warning and follow-up notification. The exact hours, the receiving authority, and the notification channel run from the national implementing legislation and from the competent authority's own guidance, not from the directive text itself.
A second layer can run in parallel. If the vulnerable component sits inside a system that qualifies as an AI system, Regulation (EU) 2024/1689 (AI Act) starts applying its post-market monitoring and incident-reporting duties for high-risk systems from 2 August 2026 (position as at 20 May 2025). Where both regimes apply, the two clocks run independently, and meeting one does not close the other.
Practical consequence
The practical effect starts before any authority is involved. Your internal assessment clock starts the moment the disclosure becomes known to you — through a CVE entry, a researcher's write-up, or general coverage. Until exploitability is tested against your actual version and configuration, exposure is unassessed. Any external or contractual notification duty stays undated, because no trigger has been established yet.
This is also the point where evidence quality decides the rest of the file. A vague advisory and a confirmed exploitation attempt produce two different files, two different deadlines, and two different decision makers.
| Situation | Reporting duty under NIS2? | Who confirms it |
|---|---|---|
| Disclosure with no evidence of exploitation | Not yet — monitor and log | Security lead |
| Confirmed exploitation attempt, no service or data impact | Depends on the significance criteria your policy uses | Security lead with legal counsel |
| Confirmed exploitation with service disruption or data compromise | Very likely — treat as a significant incident | Legal counsel, then the competent authority |
| Vulnerability sits in a third-party component you embed | Duty may sit with the supplier, not with you | Legal counsel, on contract review |
What to do first
- Security lead confirms whether the disclosed vulnerability affects a system you run, a product you supply, or only a third party.
- Compliance officer records the exact source and date of first knowledge in the incident register.
- Engineering freezes any planned change to the affected component until the assessment closes.
- Security lead tests exploitability against your actual version, patch level, and configuration, not against the vendor's generic advisory.
- If exploitation is confirmed, compliance officer opens the notification file and calendars the tiered deadlines from the moment of confirmed detection.
- Legal counsel drafts any external or contractual statement only after step four closes, not before.
Who decides
Inside the company, the decision on whether a reportable incident exists sits with whoever holds the incident-response mandate under your own policy — typically the security lead, confirmed by legal counsel. Outside the company, the competent national authority or CSIRT designated under the domestic transposition of NIS2 receives the notification and decides whether the classification holds.
Neither body waits for full certainty before the clock starts. The relevant moment is credible knowledge of a significant incident, not a finished investigation.
If your situation differs
If the affected component runs under a vendor licence and the vendor is slow, or insolvent, to patch, check licence continuity before you plan the fix yourself — see When a licence survives insolvency, or does not. A lapsed licence changes who is even permitted to apply a patch.
If the vulnerable feature is protected by a patent and a competitor already ships an unaffected alternative, the disclosure can turn into a design-around question rather than a pure security one — related: When a rival launches an obvious workaround and the.
If the vulnerability sits with a subprocessor rather than your own stack, mapping the personal data that flows through that subprocessor becomes the first task — see When personal data flows to a new subprocessor and.
If the disclosure concerns a platform used to issue tokens and the issuer is closely linked to that platform, responsibility for the fix may not follow the chain you expect — related: When the issuer and the platform are related.
What this page does not cover
This page does not assess your specific exposure, does not draft a notification, and does not decide whether your entity falls inside the NIS2 scope categories — that classification depends on sector, size, and service type, and needs a dedicated review. It does not cover contractual liability toward customers affected by the same vulnerability, and it does not address a vulnerability found in a system you build rather than one you disclose publicly yourself.
Related reading
A related question inside the same practice: When logs are kept longer than the policy says. Retention gaps often surface during exactly this kind of assessment.
Verified
Position as at 20 May 2025. Primary sources: Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2024/1689 (AI Act).
FAQ
What is the first step when a vulnerability disclosure is published?
Confirm whether it affects a system you run, a product you supply, or only a third party, and log the exact moment you learned of it. That log is the reference point for every later deadline.
Which deadline is already running?
The internal one. Your own incident policy sets the window for assessing exploitability. The external notification clock under NIS2 only starts once a significant incident is confirmed, and its exact length is fixed by national implementing legislation, not by this page.
Who decides, and on what evidence?
Internally, the security lead confirms the classification with legal counsel, based on evidence of actual or attempted exploitation and its operational effect. The existence of a public disclosure alone does not decide anything.