NIS2 Article 19: When Vendor Silence Breaks Your Incident Reporting Chain

A critical vulnerability surfaces in a widely used enterprise component. Your SOC flags it at 03:47 UTC on May 29. By 04:12, you’ve confirmed exploitation attempts against your infrastructure. At 04:30, you notify the vendor—only to receive radio silence. The 72-hour clock under NIS2 Article 19 is ticking, and your vendor’s non-disclosure is now your compliance risk. This scenario is not hypothetical; it is the reality for essential and important entities across the EU as NIS2 enforcement begins on 17 October 2024. The question is no longer *if* this will happen, but *how* you will document the silence to protect your organisation from regulatory exposure.

---

The May 29 Cascade: Why Vendor Silence Matters Under NIS2

NIS2 Article 21(2) requires entities to “take appropriate and proportionate technical, operational and organisational measures” to manage supply chain risks. When a vendor fails to disclose a vulnerability—or delays disclosure—your ability to implement those measures is compromised. The regulatory consequence is clear: silence does not absolve you of reporting obligations. Article 19(1) mandates that you notify the competent authority “without undue delay and in any event within 72 hours” of becoming aware of an incident having a “significant impact” on service continuity.

The May 29 scenario illustrates the cascade effect:

1. 103:47 UTC: Your SOC detects anomalous behaviour linked to CVE-2024-XXXX.
2. 204:12 UTC: You confirm active exploitation and classify the incident as “significant” under NIS2 Article 23(3).
3. 304:30 UTC: You notify the vendor via their published security contact (as required by the relevant provision on coordinated vulnerability disclosure).
4. 405:00–72:00 UTC: The vendor does not acknowledge, disclose, or provide mitigations.

At this point, the vendor’s silence becomes *your* incident. The absence of a patch or workaround does not pause the 72-hour clock. Your obligation is to report *what you know*, not what you wish you knew.

---

Article 19 Reporting Trigger: When Does Silence Become Your Liability?

The reporting trigger under Article 19 is not contingent on vendor confirmation. It is triggered when you become “aware” of an incident with a “significant impact”. The European Union Agency for Cybersecurity (ENISA) clarifies in its *NIS2 Implementation Guidelines* that “awareness” is met when your organisation has “sufficient information to reasonably conclude that an incident has occurred and that it meets the significance threshold”.

Key considerations:

• Significance threshold: Article 23(3) defines this as incidents causing “substantial operational disruption” or “financial loss”. ENISA’s guidelines provide sector-specific examples, such as a 4-hour outage for a cloud provider or a 10% degradation in service for a manufacturer.
• Vendor silence as a risk multiplier: If the vulnerability is unpatched and actively exploited, the incident’s impact may escalate *because* of the vendor’s non-disclosure. This escalation does not relieve you of reporting; it *accelerates* the obligation.

Practical implication: If you confirm exploitation at 04:12 UTC, the 72-hour clock starts then—not when the vendor responds, not when a patch is released. Silence is not a shield; it is a compliance risk.

---

Building the Disclosure Chain: Documentation Templates for Auditors

Auditors will scrutinise two elements: (1) your awareness of the incident, and (2) your efforts to obtain vendor disclosure. To satisfy both, you need a disclosure chain: a timestamped, immutable record of every interaction with the vendor.

Template 1: Initial Vendor Notification

[Timestamp] [Your Organisation] → [Vendor Security Contact]
Subject: URGENT: Active Exploitation of CVE-2024-XXXX in [Product/Version]
Body:
1. Description of observed exploitation (e.g., IOCs, affected systems).
2. Request for:
   - Confirmation of receipt.
   - Disclosure timeline (if not already published).
   - Mitigation guidance (e.g., workarounds, temporary fixes).
3. Escalation path if no response within [X] hours (e.g., 4 hours for critical vulnerabilities).

Critical note: Use the vendor’s *published* security contact (e.g., security@vendor.com). If none exists, document your attempt to locate it (e.g., via their website, support portal, or public vulnerability disclosure policy).

Template 2: Follow-Up Escalation

[Timestamp] [Your Organisation] → [Vendor Support Escalation]
Subject: ESCALATION: No Response to Critical Vulnerability Notification (CVE-2024-XXXX)
Body:
1. Reference to initial notification (timestamp, subject).
2. Confirmation of no response received.
3. Request for immediate escalation to [named role, e.g., “Chief Security Officer”].
4. Statement of intent to notify [your competent authority] if no response within [X] hours.

Template 3: Internal Incident Log

Incident ID: [Unique Identifier]
Detection Time: [Timestamp]
Classification: Significant (NIS2 Article 23(3))
Vendor: [Name]
Product/Version: [Details]
CVE: [CVE-2024-XXXX]
Vendor Contact Attempts:
- [Timestamp]: Initial notification sent to [contact].
- [Timestamp]: Follow-up sent to [escalation contact].
- [Timestamp]: Phone call attempted to [number]; no answer.
Mitigation Actions Taken:
- [Timestamp]: [Action, e.g., “Isolated affected systems”].
- [Timestamp]: [Action, e.g., “Deployed temporary firewall rules”].

Pro tip: Store these templates in your incident response platform (e.g., TheHive, ServiceNow) and export them as PDFs with cryptographic hashes (e.g., SHA-256) to prove immutability.

---

The 72-Hour Clock Starts—But Your Vendor Hasn't Responded

The 72-hour window under Article 19 is not a grace period; it is a *hard deadline*. If the vendor remains silent, you must report *partial information* to your competent authority. ENISA’s guidelines state that “the obligation to report is not contingent on having complete information”.

What to Report at T+0 Hours

• Incident description: “Active exploitation of CVE-2024-XXXX in [Vendor] [Product] affecting [your systems].”
• Impact assessment: “Potential for [e.g., data exfiltration, service disruption] based on observed IOCs.”
• Vendor status: “Vendor notified at [timestamp]; no response received as of [timestamp].”
• Mitigation actions: “Affected systems isolated; temporary firewall rules deployed.”

What to Report at T+24 Hours

• Updated impact: “Confirmed [e.g., 20% of production systems affected].”
• Vendor status: “No response to follow-up escalation sent at [timestamp].”
• Additional mitigations: “Deployed [e.g., custom IDS signatures] to detect further exploitation.”

What to Report at T+72 Hours

• Final impact: “Incident contained; [X] systems affected; [Y] data records potentially exposed.”
• Vendor status: “No disclosure or patch provided by vendor. Competent authority notified of supply chain risk.”
• Lessons learned: “Vendor contact process failed; updating internal procedures to include [e.g., alternative contact methods, contractual penalties for non-disclosure].”

Key point: The report is *iterative*. You are not expected to have all answers at T+0, but you *are* expected to update the authority as new information becomes available.

---

Proof of Due Diligence: How to Evidence Vendor Contact Attempts

Auditors will ask: *Did you make reasonable efforts to obtain vendor disclosure?* Your documentation must answer this definitively. Here’s how to evidence due diligence:

1. Use Multiple Channels

• Email: Send via your organisation’s official domain (e.g., security@yourcompany.com) to the vendor’s published security contact. CC your legal team.
• Phone: Call the vendor’s support line and request escalation to their security team. Document the call time, recipient name, and outcome.
• Web form: If the vendor provides a vulnerability disclosure form, submit it and save the confirmation page.
• Social media: As a last resort, send a *public* but professional message (e.g., “@VendorSecurity, we’ve detected active exploitation of CVE-2024-XXXX. Please contact us urgently.”). Document the timestamp and platform.

2. Leverage Third Parties

• CERT/CSIRT: Notify your national CERT (e.g., CERT-EU, ANSSI, BSI) and request assistance in contacting the vendor. Document the notification and any responses.
• Industry groups: If the vendor is part of a sector-specific ISAC (e.g., FS-ISAC for financial entities), notify them and request escalation. Document the interaction.

3. Contractual Evidence

• Review your contract: Does it include a clause requiring the vendor to disclose vulnerabilities within a specified timeframe? If so, cite it in your follow-ups.
• Penalties: If the contract includes penalties for non-disclosure, document your intent to enforce them (e.g., “Pursuant to Clause 12.3, we reserve the right to invoke penalties for failure to disclose.”).

4. Technical Evidence

• Packet captures: If the vendor’s product is communicating with external servers (e.g., for updates), capture the traffic to prove you attempted to reach them.
• Logs: Retain logs of all outbound communications (e.g., SMTP logs for emails, SIP logs for calls).

---

Cross-V