8 NIS2 Vendor Contract Clauses You’re Missing — Exact Drafting Language for Art. 21(2)(d)

Most vendor contracts signed by NIS2-in-scope companies today have a single line about supplier security: “Supplier shall use commercially reasonable efforts to maintain adequate security.” Commission Implementing Regulation (EU) 2024/2690 doesn’t recognise that sentence. Its Annex lists eight specific matters — lettered (a) through (h) — that a compliant supply chain contract has to address, and none of them is “reasonable efforts” [3].

This isn’t a procurement checklist or a supplier-scoring framework — for that, see our companion guide on classifying and vetting suppliers under Article 21(2)(d). This is what Legal needs sitting in the actual contract: the exact clause categories, the sub-processor flow-down language that makes the cascade to Tier-2 vendors enforceable, the audit-rights wording that holds up when a supplier stalls, and the indemnity allocation NIS2 itself is silent on but your organisation’s penalty exposure makes unavoidable to negotiate.

Scope: Who CIR 2024/2690 Actually Binds — and Why Everyone Else Should Still Use It

In short: if you’re drafting or reviewing vendor contracts for NIS2 compliance, the fastest way to fail an audit is a vague security clause where a regulator expects eight named obligations. The rest of this article gives Legal the exact clause categories, the cascade language, and the audit-rights wording — not a checklist, the drafting language itself.

NIS2 Directive Article 21(2)(d) requires every in-scope entity — essential or important, any sector — to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” Article 21(3) adds that entities must weigh “the vulnerabilities specific to each direct supplier and service provider” and the “overall quality of products and cybersecurity practices” of those suppliers [1]. That much is binding law for everyone.

What the Directive doesn’t do is tell Legal what to type into the contract. That’s where Commission Implementing Regulation (EU) 2024/2690 comes in — with a caveat most “NIS2 contract clause” articles skip. CIR 2024/2690 is legally binding only on ten categories of digital-infrastructure and ICT entities: DNS service providers, TLD registries, cloud computing providers, data centre providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers [2]. If your organisation sits in one of those ten, the Annex isn’t guidance — it’s the regulatory text an auditor will check line by line.

If you’re outside that list — manufacturing, healthcare, energy, transport, public administration, and most other sectors — CIR 2024/2690 doesn’t bind you directly. But it remains the most detailed statement the European Commission has published on what “appropriate” supply chain measures under Article 21(2)(d) look like, and Germany’s NIS2 competent authority has already pointed regulated entities generally toward these same contractual categories, not just the ten in-scope sectors [4]. In practice, the eight clauses below can serve as strong evidence of “appropriate and proportionate” measures for any NIS2 entity, even where the Annex doesn’t legally apply to you — and getting them wrong is exactly the kind of gap that shows up in a post-incident review once Article 34 enforcement is on the table.

Weak supply chain clauses rarely fail in isolation. A vendor agreement with no defined notification threshold, no working audit right, and no cascade to subcontractors also tends to be the agreement your own Article 21(2)(a) risk register hasn’t scored accurately — because Legal, Procurement, and the CISO were never working from the same clause list. That’s the gap this article closes.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

The 8 Clause Categories CIR 2024/2690 Point 5.1.4 Requires

Point 5.1.4 of the Annex lists eight specific matters that a supply chain security policy must address contractually, “where appropriate,” through the contract itself or an accompanying SLA [3]. Here is each one, quoted, with what it means for the document Legal is drafting:

Clause	CIR 2024/2690, point 5.1.4	What Legal drafts
(a) Cybersecurity requirements	“cybersecurity requirements for the suppliers or service providers”, including acquisition security	A defined schedule of technical/organisational controls, referenced by number elsewhere in the contract
(b) Training & certification	“awareness, skills and training, and where appropriate certifications” for supplier staff	Named certification or training cadence, not “appropriately trained personnel”
(c) Background verification	verification of the background of suppliers’ and service providers’ employees	Screening obligation scoped to personnel with system/data access
(d) Incident notification	notify “without undue delay” incidents presenting a risk to the entity’s network and information systems	A defined maximum hour count, not just the statutory phrase
(e) Audit rights	“the right to audit or right to receive audit reports”	Enforceable frequency, trigger, and fallback (see below)
(f) Vulnerability handling	obligation to handle vulnerabilities presenting a risk to the entity’s systems	Remediation SLA tied to severity
(g) Subcontracting / cascade	requirements for subcontractors “in accordance with” point (a)	Flow-down + retained-liability language (see below)
(h) Termination	obligations at termination, “such as retrieval and disposal” of information obtained	Explicit data return/deletion with certification

Five of the eight — (a), (b), (c), (f), and (h) — are close cousins of clauses most IT security schedules already carry in some form. The three that routinely get drafted badly or skipped entirely are (d)’s notification threshold, (e)’s enforceability, and (g)’s cascade — because each one asks Legal to bind behaviour it can’t fully control after signature. Indemnity and liability allocation isn’t on this list at all; CIR 2024/2690 is silent on it, which is its own drafting trap, covered further down.

Clause (d) deserves a closing note before moving on: “without undue delay” is the statutory phrase, but it isn’t your deadline — it’s the supplier’s. Your own clock, once you know about a significant incident, runs on the Article 23 early-warning and notification timeline to your CSIRT or competent authority. A supplier notification clause that only says “without undue delay” gives the supplier the same flexible standard the law gives you — which can eat most of your own reporting window before you’ve heard anything. Defining a maximum hour count in the contract, tighter than the statutory phrase, is what actually protects your Article 23 clock.

The Sub-Processor Cascade — Getting One Level Down Right

Point (g) is the clause most templates skip, because it asks Legal to bind a party — the subcontractor — that never signs the agreement. The operative text: “requirements regarding subcontracting and, where the relevant entities allow subcontracting, cybersecurity requirements for subcontractors in accordance with the cybersecurity requirements referred to in point (a)” [3]. Translated: whatever cybersecurity requirements Clause (a) imposes on your direct supplier, your direct supplier must impose the same requirements on its own subcontractors — one level down, not the whole chain.

That boundary tracks the Directive itself. Article 21(2)(d) and 21(3) scope the entity’s own duty to direct suppliers [1]. NIS2’s non-binding recitals encourage looking further down the chain, but the mechanism that actually reaches indirect suppliers is this flow-down obligation — not a direct contractual relationship between your organisation and a Tier-2 vendor [1][3]. Practically, Legal doesn’t need, and generally can’t get, audit rights against a supplier’s own subcontractors. What Legal needs is a clause that obligates the direct supplier to pass the requirement down and stays on the hook if it doesn’t.

A drafting pattern that does both:

“Supplier shall not subcontract, in whole or in part, its obligations under this Agreement relating to the Services without Customer’s prior written consent. Where subcontracting is permitted, Supplier shall impose on each subcontractor cybersecurity requirements no less protective than those set out in Clause [X] (Cybersecurity Requirements) of this Agreement, and shall remain fully liable to Customer for the acts and omissions of its subcontractors as if they were its own.”

Two details separate a cascade clause that survives scrutiny from one that only looks compliant. First, name the specific clause number the subcontractor requirement must match — a bare “equivalent security obligations” invites an argument about what “equivalent” means later. Second, add the retained-liability sentence: without it, a supplier can technically impose the requirement on paper and walk away once a subcontractor ignores it, leaving you with no one to hold accountable.

The clause also has to work in the direction Legal usually forgets: notice. If your Tier-1 supplier delegates part of the service to a subcontractor mid-contract, clause (g) is only useful if it also obliges the supplier to tell you when and to whom — otherwise your supplier directory under point 5.3.1 goes stale the moment the subcontracting happens, and the criticality assessment behind it is now wrong [3]. Add a notice-of-subcontracting obligation alongside the cascade language, not as a separate clause.

Audit Rights Language That Survives Supervisory Scrutiny

Point (e) is the shortest clause in the Annex — “the right to audit or right to receive audit reports” [3] — and the easiest to draft in a way that looks compliant but collapses the first time it’s actually needed. Two failure patterns are common in legacy IT contracts: audit rights that require long notice periods and customer-funded costs, which makes them impractical to use immediately after an incident; and audit rights with no fallback if the supplier simply declines access, leaving Legal with a breach dispute instead of an audit.

BSI, Germany’s NIS2 competent authority, frames the standard worth drafting to: regulated entities should contractually bind suppliers to security measures “und sich dies auch nachweisen lassen” — and have that compliance actually demonstrated to them, not merely promised [4]. That’s an evidentiary bar, not a courtesy clause.

As a general drafting pattern — industry practice rather than a CIR requirement, so treat it as a starting point to negotiate from, not a mandated formula — audit clauses that hold up typically combine: an annual audit right exercisable directly or via an accredited third party; an additional ad hoc audit right triggered by a significant incident affecting the services; acceptance of a current ISO/IEC 27001 certificate (with its Annex A statement of applicability) or a SOC 2 Type II report covering the Security and Availability trust criteria as a substitute for a full on-site audit, at the supplier’s option; and a hard fallback — if the supplier declines a requested audit within a defined number of business days, the customer may treat the refusal as a material breach [6].

File the audit reports somewhere your own internal audit programme can find them. A right that exists in the contract but produces no evidence trail is functionally the same as no right at all when a supervisory authority asks what your audit preparation actually covered for third-party risk.

Indemnity and Liability Allocation — Where the Regulation Stops

None of CIR 2024/2690’s eight points mention indemnity, liability caps, or who pays when a supplier’s failure triggers your organisation’s own penalty exposure under NIS2 [3]. That gap is Legal’s to close commercially — the regulation sets the security requirements; allocating the financial consequences of a breach is ordinary contract law, not a CIR obligation.

The recurring pattern worth checking in existing vendor paper: liability caps set at roughly twelve months’ fees paid, with no carve-out for the supplier’s own indemnification obligations [7]. For most services contracts, that cap is a rounding error against the real cost of a breach — regulatory notification, forensics, downstream customer claims, and, for the customer, potential enforcement exposure can run to many multiples of a modest annual services fee.

The fix commonly recommended in contract-drafting practice — general commercial guidance, not a NIS2-specific rule — is to keep the liability cap for ordinary breach-of-contract claims, but explicitly exclude indemnification obligations for data breaches, security incidents, and third-party claims arising from the supplier’s failure to meet the Clause (a) cybersecurity requirements from that cap, or to negotiate a separate, higher cap where a full carve-out isn’t achievable — commonly cited in practice as two to three times annual fees [7].

One negotiating reality worth planning for: large ICT suppliers with significant market power routinely resist amending standard paper, including indemnity carve-outs [5]. Where leverage is limited, prioritise the carve-out for clause (d) incident notification and clause (g) subcontracting liability first — both directly protect your own incident-reporting timeline and your ability to enforce the cascade — before spending negotiating capital on liability-cap multiples.

Who Owns Each Clause — A Role-Responsibility Table

The eight clauses don’t belong to Legal alone, and treating them as a pure legal drafting exercise is how technical requirements end up vague. A working split:

Clause	Drafts / defines	Negotiates / verifies
(a) Cybersecurity requirements	CISO defines the control schedule	Legal drafts; Procurement negotiates scope
(b) Training & certification	CISO/HR set the requirement	Legal drafts the obligation
(c) Background verification	HR/Legal (jurisdiction-dependent)	Procurement confirms with supplier
(d) Incident notification	CISO sets the hour threshold	Legal drafts enforceability; Compliance Officer owns escalation
(e) Audit rights	Legal drafts the clause	CISO / Internal Audit exercises it
(f) Vulnerability handling	CISO defines the remediation SLA	Legal drafts the obligation
(g) Subcontracting / cascade	Legal drafts flow-down + liability	Procurement tracks the supplier’s sub-list
(h) Termination	Legal drafts the obligation	CISO/IT verifies data retrieval on exit
Indemnity / liability	Legal drafts; Finance sets risk appetite	Board informed for high-value contracts

Retrofitting Legacy Vendor Contracts — A 6-Point Gap Check

For contracts signed before your NIS2 programme existed, don’t rewrite from scratch. Run this check against each critical supplier agreement in your supplier directory — the register CIR 2024/2690 also expects you to maintain and keep current [3] — and prioritise by effort:

Gap	Typical legacy state	Fix	Effort
No named cybersecurity requirements	Generic confidentiality clause only	Add Clause (a) referencing your control framework	Medium
Notification tied to “material breach”	Weeks-long discovery-to-notice gap in practice	Tighten to “without undue delay” with a defined hour count [1][3]	Low
Audit rights unused	Right exists on paper, never exercised, no certificate substitute	Add annual + post-incident trigger, ISO 27001/SOC 2 substitution	Low
Subcontracting silent	Supplier can subcontract without notice	Add consent + cascade + retained-liability language	Medium
Liability cap silent on indemnity	Cap applies to everything, including indemnification	Carve out indemnification for security incidents	High
No termination data-return obligation	Standard “return upon request” only	Add explicit retrieval/disposal with deletion certification	Low

Frequently Asked Questions

Does CIR 2024/2690 apply if I’m not a cloud provider, MSP, or one of the other listed sectors?
Not directly — Article 1 limits the Regulation to ten digital-infrastructure and ICT entity categories [2]. Your organisation is still bound by Article 21(2)(d)’s general supply chain security duty [1]; the eight clauses are the Commission’s most detailed template for what “appropriate” looks like, not a separate legal requirement specific to your sector.

What if a supplier refuses audit rights or the subcontracting cascade?
Treat it as a risk-management input, not just a drafting failure. Article 21(3) requires you to weigh supplier vulnerabilities in your own risk assessment [1]; a supplier unwilling to accept baseline clauses is a documented risk to escalate, and may justify reclassifying that supplier’s criticality in your supplier directory.

Does NIS2 override my existing liability cap or force unlimited indemnity?
No — NIS2 doesn’t regulate indemnity or liability caps at all [3]. That allocation remains ordinary contract negotiation between the parties [7].

Sources

1. Directive (EU) 2022/2555 (NIS2), Article 21(2)(d) and 21(3) — nis-2-directive.com
2. Commission Implementing Regulation (EU) 2024/2690, Article 1 (Scope) — EUR-Lex
3. Commission Implementing Regulation (EU) 2024/2690, Annex, Section 5 (Supply chain security), point 5.1.4 — EUR-Lex
4. BSI (Bundesamt für Sicherheit in der Informationstechnik) — NIS-2: Sichere Lieferkette, German national competent authority guidance
5. DLA Piper — “NIS2 directive explained Part 3: Supply chain security” (dlapiper.com)
6. isms.online — Which Clauses Prove NIS 2 Compliance in Supplier Contracts Today?
7. NH Business Review — The fine print: key contract clauses impacting cyber liability