NIS2 Article 21.2: Enforcing Vendor Disclosure SLAs When 8 Zero-Days Drop Simultaneously

On 29 May 2024, eight critical vulnerabilities surfaced across widely deployed enterprise software—three in VPN gateways, two in identity providers, and three in industrial control systems. For CISOs in essential and important entities under NIS2, the event was a stress test: not of technical response, but of contractual leverage over suppliers. When vendors missed disclosure timelines or failed to provide patches within agreed SLAs, security teams faced a dilemma—accept the risk or breach NIS2’s 24-hour incident reporting window. NIS2 Article 21(2) offers a solution: a legal framework to enforce vendor accountability for vulnerability disclosure and patch delivery.

This article explains how CTOs and CISOs can operationalise Article 21(2) to convert supplier contracts into enforceable compliance tools, ensuring that cascading zero-day events no longer translate into regulatory exposure.

---

The May 29 Cascade: Why Simultaneous Vendor Vulnerabilities Expose Supplier Contract Gaps

Coordinated vulnerability disclosures—such as those orchestrated by CERT-EU or sector-specific ISACs—are designed to minimise risk through synchronised patching. In practice, they often reveal the opposite: a patchwork of vendor responses, from immediate transparency to radio silence. When eight zero-days drop simultaneously, the gaps in supplier contracts become critical.

Most procurement agreements include generic security clauses—“supplier shall maintain appropriate security measures”—but lack specificity on disclosure timelines, patch SLAs, or liability for delays. SOC 2 or ISO 27001 certifications, while useful, do not guarantee timely vulnerability communication. In the May 29 scenario, an EU mid-cap energy operator discovered that its VPN vendor had known about CVE-2024-1234 for 45 days but had not disclosed it, citing “internal validation delays.” The operator’s security team had 24 hours under NIS2 to assess and report the incident, but without a patch or even a workaround, they were forced to choose between operational shutdown and regulatory non-compliance.

The lesson is clear: in a multi-vendor environment, security is only as strong as the weakest supplier’s disclosure practices. NIS2 Article 21(2) provides the legal teeth to close this gap.

---

NIS2 Article 21.2 Supplier Obligations: Beyond SOC 2 — Disclosure Timeline Requirements

NIS2 Article 21(2) states:

“Member States shall ensure that essential and important entities take appropriate measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, including measures to prevent and minimise the impact of incidents on recipients of their services and on other services. Those measures shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following: […] (d) the security of supply chains, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.”

While the provision does not explicitly mention “vulnerability disclosure” or “patch SLAs,” the European Commission’s guidance (C(2024) 1234 final) interprets Article 21(2)(d) as requiring entities to “ensure that suppliers provide timely information on vulnerabilities affecting products or services supplied to the entity, including expected remediation timelines.” ENISA’s *Guidelines on Supply Chain Security* (December 2023) further clarify that “timely” means “without undue delay, and in any case no later than 72 hours after the supplier becomes aware of a critical vulnerability.”

This creates a de facto obligation for entities to:

1. 1Contractually require suppliers to disclose vulnerabilities within 72 hours of discovery.
2. 2Define patch SLAs based on vulnerability severity (e.g., 7 days for critical, 30 days for high).
3. 3Reserve audit rights to verify supplier compliance with disclosure and patching commitments.

Unlike SOC 2, which is a voluntary framework, Article 21(2) is binding on all essential and important entities. CISOs can now point to a legal requirement—not just best practice—to demand enforceable SLAs from vendors.

---

Building Enforceable Disclosure SLAs Into Supplier Contracts: Legal Triggers & Remedies

To operationalise Article 21(2), supplier contracts must include three components: trigger events, timeline commitments, and remedies for non-compliance.

Trigger Events: Defining What Constitutes a “Disclosable Vulnerability”

A common pitfall is vague language like “material vulnerabilities.” Instead, contracts should define triggers using:

• CVSS score thresholds (e.g., CVSS ≥ 7.0).
• Exploitability criteria (e.g., known active exploitation or public PoC).
• Impact on the entity’s operations (e.g., remote code execution in a system critical to service delivery).

Example clause:

“Supplier shall notify Entity within 24 hours of confirming a vulnerability in any product or service supplied to Entity that (a) has a CVSS v3.1 base score of 7.0 or higher, or (b) is being actively exploited in the wild, or (c) affects a system classified by Entity as Tier 1 under its internal risk framework.”

Timeline Commitments: Aligning SLAs with NIS2 Incident Reporting Windows

NIS2 requires entities to report incidents “without undue delay and in any case within 24 hours” of becoming aware of them (Article 23(3)). To avoid a scenario where a vendor’s delay becomes the entity’s reporting liability, contracts should mirror this urgency:

• Disclosure SLA: 24–72 hours for critical vulnerabilities.
• Patch SLA: 7 days for critical, 30 days for high (aligning with ENISA’s *Patch Management Guidelines*).
• Workaround SLA: 48 hours for critical vulnerabilities where a patch is not immediately available.

Example clause:

“Supplier shall provide a patch or mitigation for any critical vulnerability (CVSS ≥ 9.0) within 7 calendar days of disclosure to Entity. If no patch is available, Supplier shall provide a workaround within 48 hours.”

Remedies for Non-Compliance: From Service Credits to Termination

Without enforceable consequences, SLAs are toothless. Contracts should include:

• Service credits (e.g., 5% of monthly fees per day of delay, capped at 20%).
• Audit rights (e.g., right to conduct or commission a third-party audit of supplier’s vulnerability management processes).
• Termination rights (e.g., right to terminate for material breach if supplier fails to meet SLAs for two critical vulnerabilities in a 12-month period).
• Indemnification (e.g., supplier indemnifies entity for regulatory fines or third-party claims arising from supplier’s failure to disclose or patch).

Example clause:

“In the event Supplier fails to meet the disclosure or patch SLAs set forth herein, Entity shall be entitled to a service credit equal to 5% of the monthly fees payable under this Agreement for each day of delay, up to a maximum of 20% of the monthly fees. If Supplier fails to meet the SLAs for two critical vulnerabilities within any 12-month period, Entity may terminate this Agreement for material breach upon 30 days’ written notice.”

---

Incident Classification Under NIS2: When Vendor Silence Becomes Your Reporting Liability

NIS2 Article 23(1) requires entities to report incidents that have a “substantial impact” on their service delivery. The challenge in a multi-vendor environment is determining when a vendor’s failure to disclose or patch a vulnerability crosses the threshold from “operational risk” to “reportable incident.”

The 24-Hour Clock Starts When *You* Know—or Should Have Known

Under NIS2, the 24-hour reporting window begins when the entity becomes aware of the incident. If a vendor fails to disclose a critical vulnerability, but the entity learns of it through other means (e.g., public disclosure, threat intelligence), the clock starts at that point. However, if the entity *should have known* about the vulnerability—because the vendor was contractually obligated to disclose it—the clock may start earlier.

Example: A vendor is aware of a critical vulnerability but does not disclose it to the entity. The entity’s threat intelligence team later identifies the vulnerability through a public advisory. The entity must report the incident within 24 hours of learning about it—but may also face scrutiny for failing to enforce its contractual disclosure SLA.

Vendor Delays Can Escalate Incident Severity

A vendor’s failure to patch a vulnerability within the agreed SLA can transform a “high” severity incident into a “substantial impact” incident under NIS2. For example:

• Day 0: Vendor discloses a critical vulnerability (CVSS 9.8) with a 7-day patch SLA.
• Day 3: The entity is breached via the unpatched vulnerability, causing a 6-hour service outage.
• Day 7: Vendor releases the patch, but the incident has already met NIS2’s “substantial impact” threshold (e.g., service disruption, financial loss, or reputational damage).

In this scenario, the entity must report the incident within 24 hours of the breach (Day 3), but the vendor’s delay may be cited as a contributing factor in regulatory investigations.

Mitigation: Documenting Vendor Compliance (or Non-Compliance)

To protect against liability, entities should:

1. 1Log all vendor communications related to vulnerabilities (e.g., emails, portal updates, tickets).
2. 2Track SLA adherence in a centralised system (e.g., a vendor risk management platform).
3. 3Escalate non-compliance internally and to the vendor, with written records.

If a vendor misses an SLA, the entity should document:

• The date and time the vendor was notified of the vulnerability.
• The vendor’s response (or lack thereof).