NIS2 Disclosure Deadlines: When Vendor Silence Becomes Your Liability

On 29 May 2026, eight critical CVEs land in your inbox—same day, different vendors. One issues a patch within hours; another imposes a 14-day embargo; a third goes silent. NIS2 Article 19(1) starts the 24-hour “awareness” clock, but whose awareness counts? When vendor timelines diverge, your legal exposure compounds. This is not a hypothetical. It is the first major test of NIS2’s disclosure regime, and the difference between compliance and a €10M fine hinges on how you sequence reporting when vendors dictate the rhythm.

The May 29 Disclosure Gap: 8 Critical Vulns, Staggered Vendor Timelines

On 29 May 2024, a coordinated disclosure by CERT-EU revealed seven critical CVEs in widely deployed network appliances and one zero-day in a cloud orchestration layer. The scenario repeats in 2026: eight vulnerabilities, same disclosure date, divergent vendor responses.

• Vendor A (network appliance): publishes advisory + patch at 09:00 CET, no embargo.
• Vendor B (firewall): advisory at 09:00, patch embargoed until 12 June.
• Vendor C (cloud orchestrator): no advisory, no response to PSIRT queries.
• Vendor D (endpoint agent): advisory at 09:00, patch available but silent on exploitability.

For an essential entity under NIS2, the clock starts at 09:01 CET. Yet the entity cannot patch Vendor B until 12 June, and Vendor C’s silence leaves the vulnerability unmitigated. The question is not whether to report, but when—and how to document the delay without incurring liability.

NIS2 Article 19 vs Vendor Embargo: Where Your Reporting Clock Actually Starts

NIS2 Article 19(1) states: “Member States shall ensure that essential and important entities notify… without undue delay and in any event within 24 hours after having become aware of the incident.” The key phrase is “having become aware.”

ENISA’s draft *Guidelines on Incident Notification* (December 2023) clarify that awareness is triggered when the entity has “sufficient information to determine that the incident is likely to have a significant impact.” This is not contingent on patch availability or vendor confirmation. If the CVE score is ≥9.0, exploit code is public, and the asset is in scope, the 24-hour clock starts regardless of vendor silence.

Vendor embargoes do not pause the clock. They merely shift the entity’s burden from patching to mitigation and documentation. The entity must still report within 24 hours, even if the root cause remains unpatched due to vendor delay.

The 72-Hour Rule Under Pressure: When Vendor Silence Triggers Mandatory Disclosure

Within 72 hours of the 24-hour notification, NIS2 Article 19(3) requires a “detailed incident notification.” This is where vendor silence becomes a liability.

• If Vendor C remains unresponsive after 72 hours, the entity must report the vulnerability as an “unmitigated critical risk” in the detailed notification.
• The report must include: - CVE identifier (if available) - Affected assets - Current mitigation status (e.g., “no patch available, compensating controls in place”) - Vendor communication timeline (e.g., “PSIRT query sent at 10:00 CET, no response as of 12:00 CET”)

Failure to disclose the unpatched vulnerability within 72 hours risks a finding of “undue delay,” even if the vendor is at fault. The entity’s obligation is to report its own risk posture, not the vendor’s patch timeline.

Documentation Strategy: Proving Due Diligence When Vendors Go Dark

To defend against liability, entities must demonstrate that they took “all reasonable steps” to mitigate the risk, even when vendors failed to cooperate. The following documentation trail is critical:

1. 1PSIRT Query Log: Timestamped emails or portal submissions to the vendor’s PSIRT, including: - CVE identifier - Request for exploitability assessment - Request for patch ETA - Escalation path (e.g., “If no response within 4 hours, escalate to [vendor executive]”)

1. 1Compensating Controls Register: Evidence of temporary mitigations, such as: - Network segmentation changes - IPS/IDS rule updates - Workload isolation - Disabling vulnerable services (if feasible)

1. 1Impact Assessment: A dynamic risk assessment that updates as new information emerges, including: - CVSS score and exploitability metrics - Asset criticality (aligned with NIS2 Article 21(2) risk management measures) - Likelihood of exploitation (e.g., “exploit code observed in the wild”)

1. 1Regulatory Correspondence: If the entity seeks guidance from the CSIRT or competent authority, document: - The question posed (e.g., “Does vendor silence justify delayed reporting?”) - The authority’s response (if any) - How the response informed the entity’s actions

Cross-Vendor Coordination: Managing Disclosure Sequencing Across Your Stack

When multiple vendors are involved, the entity must sequence disclosures to avoid regulatory overlap or contradiction. A phased approach is recommended:

1. 1Immediate (24-hour) Notification: - Report all eight CVEs as a single incident if they are part of a coordinated attack chain (see Section 7). - If unrelated, report each CVE separately but reference the others in the “context” field.

1. 172-hour Detailed Notification: - Update the report for each CVE as new information emerges. - For Vendor B (embargoed patch), state: “Patch expected on 12 June; compensating controls in place.” - For Vendor C (silent), state: “No vendor response; risk remains unmitigated; active monitoring for exploitation.”

1. 1Final Report (1 month): - NIS2 Article 19(4) requires a final report within one month, including: - Root cause analysis - Lessons learned - Vendor performance assessment (e.g., “Vendor C failed to respond; contract under review”)

Regulatory Interpretation: ENISA Guidance on Vendor-Caused Reporting Delays

ENISA’s *Guidelines on Incident Notification* (expected final version Q1 2025) address vendor-caused delays explicitly. Key takeaways:

• No Safe Harbor for Vendor Silence: The entity’s reporting obligations are independent of the vendor’s actions. ENISA states: “The absence of a vendor patch does not absolve the entity of its duty to report.”
• Mitigation as a Reporting Trigger: If the entity implements compensating controls, it must report the vulnerability as “mitigated but not remediated.” This satisfies the 24-hour requirement while acknowledging the residual risk.
• Authority Coordination: ENISA encourages entities to notify the CSIRT even if the vendor has not yet confirmed the vulnerability. The CSIRT can then coordinate with other affected entities, reducing the risk of fragmented disclosures.

Incident Classification Trap: Single Vulnerability vs Coordinated Attack Chain

A critical decision in the May 2026 scenario is whether to report the eight CVEs as a single incident or multiple incidents. NIS2 Article 19(5) defines an incident as “an event compromising the availability, authenticity, integrity or confidentiality of network and information systems.”

• Single Incident: If the CVEs are part of a coordinated attack chain (e.g., CVE-1 enables exploitation of CVE-2), they should be reported as one incident. This avoids regulatory duplication and aligns with ENISA’s guidance on “cascading incidents.”
• Multiple Incidents: If the CVEs are unrelated (e.g., different vendors, no exploit chain), they must be reported separately. However, the entity can cross-reference them in the “related incidents” field.

Misclassification risks under-reporting (if unrelated CVEs are grouped) or over-reporting (if a single attack chain is split). In the May 2026 case, the eight CVEs are likely part of a coordinated disclosure but not necessarily an attack chain. Default to separate reports unless evidence of chaining emerges.

Audit-Ready Evidence: Building Your Vendor Communication Trail

In the event of an audit or enforcement action, the entity must prove that it acted diligently despite vendor delays. The following evidence is essential:

1. 1Vendor Contracts: - PSIRT response SLAs (e.g., “Vendor shall respond to critical vulnerability reports within 4 hours”). - Patch release commitments (e.g., “Vendor shall provide patches for critical vulnerabilities within 14 days”). - Liability clauses for non-compliance (e.g., “Vendor shall indemnify the entity for fines arising from delayed patches”).

1. 1Communication Logs: - Email threads with vendors, including read receipts and delivery confirmations. - PSIRT portal screenshots showing submission timestamps and status updates. - Escalation emails to vendor executives (e.g., CISO, CEO) if initial queries go unanswered.

1. 1Mitigation Records: - Change management tickets for compensating controls (e.g., firewall rule updates). - Logs showing the implementation and effectiveness of mitigations (e.g., IPS alerts for exploit attempts). - Risk assessment updates reflecting the changing threat landscape.

1. 1Regulatory Correspondence: - Emails or portal submissions to the CSIRT or competent authority. - Meeting minutes with legal or compliance teams discussing the incident. - Board-level briefings on the entity’s response (if the incident is material).

Next Step with NexCyber

NIS2’s disclosure deadlines do not pause for vendor silence. By May 2026, essential and important entities must have a documented process for managing staggered vendor timelines, compensating controls, and audit-ready evidence. NexCyber’s NIS2 Compliance Assessment maps your