Procurement forwards you a supplier contract for security review — a renewal, due back by Friday. You know NIS2 expects supplier contracts to carry security-related requirements. Which requirements, exactly? The directive itself won't tell you: Article 21(2)(d) is one line. But there is an official answer, and it has eight items.
Where the list actually comes from
The directive's supply chain clause — Article 21(2)(d) — requires measures covering "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Deliberately general. The concrete articulation arrived two years later, in Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, whose Annex spells out what a supply chain security policy should contain — including, in point 5.1.4, the list of things supplier contracts should specify.
One nuance worth being precise about, because it's the kind auditors notice: the implementing regulation is binding only for specific entity types — DNS service providers, top-level domain registries, cloud computing services, data centres, content delivery networks, managed service providers, managed security service providers, online marketplaces, search engines, social networks, and trust service providers. For everyone else, ENISA's Technical Implementation Guidance (June 2025) presents the same content as best practice. If you're not on that list, the eight items below are not a legal checklist — but they are the most concrete articulation of what "appropriate" contract measures look like that any EU authority has published, and your supervisor has read them too.
The eight requirements
Point 5.1.4 says contracts with suppliers and service providers should specify, where appropriate through service level agreements, the following — each "where appropriate," a phrase we'll come back to.
(a) Cybersecurity requirements for the supplier
The baseline: what security you actually require of them, including security requirements for the ICT products and services you acquire from them. In practice this is a schedule referenced from the contract — your minimum controls, proportionate to what the supplier touches. A managed IT provider with privileged access gets a longer schedule than a stationery vendor. The evidence, later, is the schedule itself plus whatever the supplier provided to show they meet it.
(b) Awareness, skills, training and certifications of supplier staff
If the supplier's people operate your systems or handle your data, the contract can require that those people are trained for it — and certified where the role warrants it. Mostly relevant for services delivered by identifiable humans: managed services, support, development.
(c) Background verification of supplier staff
The narrowest of the eight, and the one most clearly gated by "where appropriate" — background checks make sense for personnel with privileged or physical access to sensitive environments, and rarely otherwise. Requiring it everywhere reads as copy-paste; requiring it precisely reads as judgment.
(d) Incident notification without undue delay
The load-bearing clause. The supplier must notify you of incidents that present a risk to the security of your network and information systems — without undue delay. This is the clause that connects their bad Tuesday to your Article 23 reporting ladder: your own 24-hour and 72-hour clocks start when you become aware, and this clause is what obliges the supplier to make you aware. If you retrofit only one clause at renewal, it is this one.
(e) The right to audit, or the right to receive audit reports
Note the "or." The regulation explicitly accepts receiving audit reports as the alternative to auditing yourself — which is fortunate, because a mid-market buyer was never going to send an audit team to a hyperscaler. For most supplier relationships, an annual right to current third-party audit reports and certifications is both negotiable and sufficient. Reserve genuine audit rights for the handful of suppliers where nothing else would do.
(f) An obligation to handle vulnerabilities
The supplier must deal with vulnerabilities that present a risk to your systems — not merely know about them. For software and service providers, this pairs naturally with a disclosure expectation: how you hear about it, and in what timeframe fixes land for issues that touch you.
(g) Subcontracting requirements
If you allow the supplier to subcontract, the contract should require that subcontractors meet the same cybersecurity requirements you set in point (a). This is the contractual side of sub-processor visibility: the clause sets the requirement downstream, and the supplier's disclosed sub-processor list at each review is how you see whether the downstream exists at all.
(h) Obligations at termination
Exit is a security event. The contract should say what happens to your information when the relationship ends — retrieval, disposal, and in what timeframe. This clause costs nothing to include at signature and is nearly impossible to improvise at termination, which is the exact moment goodwill is at its lowest.
"Where appropriate" is doing real work
The regulation hedges twice — contracts should specify these things "where appropriate," possibly "through service level agreements." That is not an escape hatch; it is proportionality, and it cuts both ways. You are not expected to put all eight clauses in every contract. You are expected to be able to say why a given clause is or isn't there. A documented, tier-driven position — full clause set for critical suppliers, the incident-notification and termination clauses as the floor for everyone else — is defensible. Silence is not.
Retrofitting: the renewal-cycle approach
Nobody renegotiates two hundred live contracts at once, and no authority expects it. The workable sequence: tier your suppliers first, then let the contract work ride the renewal calendar. High-tier suppliers get the clause review at their next renewal; where renewal is years away and the supplier matters, a short security addendum does the job. And where a supplier won't sign — it happens, particularly with large platforms whose terms are take-it-or-leave-it — record the gap and the decision to accept it, with a reason and a name attached. A documented accepted risk is a defensible position. An undocumented one is a finding.
What emerges from that sequence is a tracking problem: two hundred suppliers, eight possible clauses, three states each — present, absent-and-accepted, pending renewal. The moment the coverage picture matters is never a calm one; it's a supplier incident or an auditor's follow-up question, when "which contracts oblige the supplier to notify us?" needs an answer from records, not from whoever remembers the negotiation.
Where this fits in the tooling — honestly
Vittnor — Supply Chain Assurance for the mid-market — holds contract clauses as evidence records per supplier — linked to the relationship, dated, versioned, exportable alongside the rest of the review. So the coverage question above is a lookup. What it does not do is draft the clauses: that is your counsel's work, and this post is background for that conversation, not a substitute for it.
If you want the wider picture of where your supplier programme stands against Article 21(2)(d) — contracts included — the NIS2 Supplier Exposure Assessment maps it in two to three weeks, at a fixed price, with the report as the deliverable. For the directive text itself, the plain-language walkthrough lives at Article 21(2)(d), explained.