NIS2 supplier contracts need eight security clauses. A DPA covers five at best.

Your CI provider holds a deploy key to production. It builds every commit, runs the tests, and pushes the container that serves your customers. It has never seen a customer's name or email address, so there is no data processing agreement with it and it appears on no sub-processor list. Anyone who compromises it ships code to your production systems. If you sell SaaS in the EU and employ 50 or more people, you are probably in scope of NIS2, and Article 21(2)(d) of the directive then makes the security of your relationship with that supplier one of the measures you are required to take 1. For cloud and managed service providers, the European Commission has gone further and written down what the contract with that supplier has to say.

That is a different question from the one your vendor list was built to answer. GDPR sorts vendors by whether they handle personal data on your behalf. NIS2 sorts them by whether they can damage the systems you run your service on. A vendor can sit on one list and not the other, and the contract terms the second list wants include several that the first one never asks for.

Supply chain security sits inside Article 21, and Article 20(1) puts the management body, meaning whoever actually signs off on how the company is run, under a duty to approve those measures and oversee them, and it can be held liable for the entity's infringements of that article 1. Fines for infringing the same article reach at least 7 million euros or 1.4% of worldwide turnover, whichever is higher, for an important entity, which is where a medium-sized cloud provider lands. Grow past the medium-sized ceilings and you become an essential entity, where the figures are 10 million or 2% 1. All of this reaches you through your own country's NIS2 law rather than from Brussels directly, and several member states have still not written it into theirs.

Which vendors does NIS2 reach?

Your direct suppliers and service providers. Article 21(2)(d) names "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" 1. Article 21(3) adds what you weigh when deciding what is appropriate: the vulnerabilities specific to each direct supplier, and the overall quality of their products and their cybersecurity practices, including their secure development procedures 1.

The word direct bounds the work. You are not being asked to map every dependency of every dependency. Your duty stops at the companies you have a relationship with, and you reach past them by requiring things of them in writing rather than by auditing strangers.

Two further boundaries make the list smaller than it first looks. The first is your own scope. The directive's recitals name Software as a Service as one of the service models of cloud computing 1, and the size test has two more limbs than the headcount: you stay outside it while you have fewer than 50 staff and under 10 million euros in both turnover and balance sheet 1. Neither test is as settled as it sounds, and I worked through both in an earlier post on whether NIS2 applies to a SaaS company.

The second is the filter on each vendor, which is a security question: can this supplier affect the security of the network and information systems you use to provide your service? Your hosting, managed database, CI/CD, secret manager, DNS, monitoring, identity provider and any package registry you hold a commercial account with all clear that bar. Some of them have a DPA with you. Several do not. Verizon's 2026 Data Breach Investigations Report found a third party involved in 48% of breaches, up 60% year on year, so this is where the incidents are coming from.

What does the contract have to say?

For one group of companies, the Commission has written the list out, and if you sell SaaS you are in that group as a cloud computing service provider. Commission Implementing Regulation (EU) 2024/2690 binds eleven digital entity types: cloud computing service providers, data centres and managed service providers among them, plus eight other digital service categories listed in its Article 1 2. It is a regulation rather than a directive, so it took effect directly on 7 November 2024 and specifies what the Article 21 measures have to contain.

Point 5.1.4 of its Annex says contracts with suppliers and service providers shall specify the following, where appropriate through service level agreements 2:

Each of those carries the qualifier "where appropriate", and the regulation says what that qualifier costs you. The second subparagraph of Article 2(2) of the same regulation says that where an entity considers a requirement not appropriate, not applicable or not feasible, it "shall in a comprehensible manner document its reasoning to that effect" 2. So a clause you leave out of a supplier contract is a decision you are expected to be able to produce on request. The regulation lets you drop one that does not fit a particular supplier, provided you have written down the reason before anyone asks for it.

If your company is in scope of NIS2 but not on that list of eleven entity types, the implementing regulation does not bind you directly. Article 21(2)(d) still does, through your own country's NIS2 law, and the eight points remain the most detailed published statement of what the Commission thinks adequate looks like. Enterprise buyers have already noticed: these eight points are turning up in security questionnaires whether or not the regulation names you.

How much of this does a DPA already cover?

Five of the eight at best, by my count, and only for vendors that have one. GDPR Article 28(3) stipulates what a processor contract must contain, and the overlap is partial in a way that is easy to miss when a signed DPA sits in the folder and feels like an answer 3.

Three of the eight have no counterpart in Article 28(3) at all. It does not require anything about the training, skills or certifications of the supplier's staff, point (b). It does not require background verification of their employees, point (c). And it does not oblige the supplier to handle vulnerabilities in what it sells you, point (f), which for an infrastructure vendor carries the most operational weight of the eight. A particular vendor's DPA may promise some of this voluntarily; the point is that the law behind it compels none of it.

Two more look like matches and are narrower than they appear. Article 28(3) and Article 33(2) put a processor under a duty to tell you about a personal data breach 3; point (d) asks to be told about any incident that presents a risk to your network and information systems, whether or not a single personal data record is involved. Article 28(3)(g) has the processor delete or return personal data at the end of the contract 3; point (h) covers the information the supplier obtained in doing the work, which is a larger set than the personal data in it.

The three that do line up reasonably well are audit rights, subcontracting and, through the Article 32 security obligation, a general security requirement.

Then there is the structural gap, and it matters more than the clause-by-clause comparison. A DPA exists only where the vendor is your processor. That test is worth running on its own terms, and my post on sorting a vendor list by processor role walks it, but it produces the wrong list for this purpose. The CI provider in the opening has no DPA because it needs none. Your infrastructure-as-code provider, your artifact registry and your on-call paging tool may be in the same position. Every one of them can reach your production systems.

How should you pick a supplier in the first place?

Against written criteria, and point 5.1.2 of the Annex names the four your own supply chain security policy has to carry 2:

• Their cybersecurity practices, including their secure development procedures
• Their ability to meet cybersecurity specifications you set
• The quality and resilience of the product, and the security built into it
• Your own ability to diversify supply and limit vendor lock-in, where applicable

The fourth is the one people miss. If a supplier goes down or is compromised and you have no second source and no way to move, the incident is yours for as long as theirs lasts.

One more requirement is easy to miss because it is not about contracts at all. Point 5.1.1 asks you to identify your own role in the supply chain and tell your direct suppliers what it is, and in the technical implementation guidance from ENISA, the EU's cybersecurity agency, the evidence for having done so is as ordinary as an email 4. That guidance walks every requirement in the Annex and is the clearest account of what they mean in practice, though ENISA is explicit that it is advisory rather than binding.

Vendor lists also decay, because adding a vendor is something an engineer does in an afternoon and telling anyone is a separate step nobody owns. Nothing will keep your supplier register current for you, including us. The gap we do close is the one in your published documents. Lawcel is a compliance platform that watches the changes your team ships in GitHub, Linear and Jira. When one of them affects a legal document, such as the sub-processor list a new vendor belongs on, it opens a case with proposed edits your team reviews and publishes.

Where should you start?

Take the vendor list you built for GDPR and add every supplier that can affect your systems but handles no personal data. That addition is the list this obligation is about.

For each supplier on it, put the four selection questions from point 5.1.2 in front of the person who signs, before the renewal rather than at it.

Compare the contracts you already hold against the eight points, and expect the gaps to sit at staff vetting, training and vulnerability handling. Where a clause genuinely does not fit that supplier, write down why, because the regulation asks you for that reasoning rather than for the clause.

And send your direct suppliers a line stating your own role in their supply chain. It is the cheapest item on the list and the one most likely to be missing.