NIS2 supplier requirements land on the in-scope company, not on the agency or freelancer it hires. The contract is the channel through which those duties reach the supplier. And the supplier building your software usually isn't an NIS2 entity itself, which changes what you can ask for and what you can't.
Outsourced and nearshore development raises four questions: where the supplier duty comes from, what the Commission's implementing rules say about outsourced development, where developer access to repos and production fits, and what a contract can carry. The general contracting side sits in EU engineering hiring compliance: contracts, IP and GDPR. None of this is legal advice, and national law decides the details.
What NIS2 actually asks of an entity about its suppliers
The supplier duty comes from Article 21 of Directive (EU) 2022/2555, the NIS2 Directive. Paragraph 1 says Member States "shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures". The measures are the entity's. Nothing in that sentence addresses a supplier directly.
Paragraph 2 lists the minimum topics those measures cover, and two of them reach straight into outsourced development. Point (d) is "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". Point (e) is "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure".
Read together, they cover the same relationship. A company that has software built for it by an outside team is buying "development" under (e) from a "direct supplier" under (d). Both points apply to the same relationship.
Paragraph 3 is a factor for the supply-chain measures in point (d). Entities have to "take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures." It isn't a supplier-selection rule; the selection criteria sit in point 5.1.2 of the Regulation's Annex. But the last three words matter most for this audience. Secure development procedures are named in the Directive itself, so "how does your team handle secrets and code review" is a legitimate procurement question, not a paranoid one.
Note the word "direct". The Directive frames the obligation around direct suppliers. How far down a subcontracting chain an entity has to look is a question for the national law and for counsel, and the text of Article 21 doesn't answer it.
Who carries the obligation: you or the dev supplier?
The in-scope entity does. Article 21(1) puts the measures on "essential and important entities", and Article 20(1) puts the accountability on their management bodies. Those bodies "approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation", and they "can be held liable for infringements by the entities of that Article."
So a CTO can't hand the duty to a vendor by signing a contract. What the CTO can do is make sure the contract gives the company enough to meet its own obligation: information, notice, access to evidence.
Is your nearshore supplier in scope itself? Usually not, on the face of the text. Annex I lists "Managed service providers" under "ICT service management (business-to-business)", so the question is whether a development team fits that category. The definition in Article 6 of the same Directive says a managed service provider "provides services related to the installation, management, operation or maintenance of ICT products, networks, infrastructure, applications or any other network and information systems, via assistance or active administration carried out either on customers' premises or remotely".
Software written for a client and handed over isn't that on its face. Building an application isn't installing, managing, operating or maintaining the client's systems through active administration. The edge is a team that also runs the client's infrastructure, holds ongoing admin rights, or operates the production environment as a service. That begins to look like the definition, and it's a point to take to counsel rather than settle by reading one paragraph. A support or maintenance retainer is a closer call, because the Article 6 definition covers maintenance via assistance or active administration. Delivery-only build work is the clearer case, and the retainer is one to ask counsel about.
The practical consequence: because the supplier is often outside NIS2's direct reach, the contract does the work. The entity can consider a supplier's NIS2 compliance statements, and ENISA lists them as a selection criterion, but it can't rely on them alone, and a development supplier often has none. So it needs terms and evidence of its own.
One exception sits outside this whole discussion. For financial entities, the Directive's recital 28 says "Member States should therefore not apply the provisions of this Directive on cybersecurity risk-management and reporting obligations, and supervision and enforcement, to financial entities covered by Regulation (EU) 2022/2554." That's DORA, and it replaces the NIS2 duties for those entities. If that's your situation, hiring fintech developers under DORA and GDPR is the page to read instead.
What Regulation 2024/2690 says about outsourced development
The Directive sets the principle. Implementing Regulation (EU) 2024/2690 sets out detail, and one passage in it speaks directly to this topic. Point 6.2.1 of the Annex tells the relevant entities to apply secure development rules "when developing network and information systems in-house, or when outsourcing the development of network and information systems."
That's the closest the official text gets to saying "your outsourced developers are covered." The development rules follow the entity into the outsourcing arrangement. They don't stop at the contract boundary.
Point 5.1 of the Annex covers supply chain security policy and gives the most concrete material. It requires the entities to "establish, implement and apply a supply chain security policy which governs the relations with their direct suppliers and service providers". Selection criteria must include "the cybersecurity practices of the suppliers and service providers, including their secure development procedures". Contract content, review cycles and the rest follow in the how-to section below.
Does this apply to your company? Only if you're one of the entity types the Regulation names. Article 1 lists "DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers (the relevant entities)".
For a manufacturer, a health operator or an energy company, the Regulation isn't binding in the same way. National law sets the measures for them. But it's still the most detailed official text on what supplier controls look like, so counsel and procurement teams often use it as a reference point. That's a use of the document, not a legal duty, and the distinction should stay visible in any contract that cites it.
Developer access to repos, CI and production: where the supplier risk actually sits
"Supplier risk" in a software contract isn't abstract. It's a short list of access paths: who can commit code, who can read CI secrets, who can deploy, and who can reach production data.
The legal text is thin here, and that's worth saying plainly. Article 21(2)(d) and (e), quoted above, cover supplier relationships and secure development and maintenance. Recital 49 mentions "the limitation of administrator-level access accounts" among cyber hygiene practices, and it's a recital, not an obligation. Nothing in the quoted text says "restrict a contractor's CI permissions to X."
What follows is illustrative practice, not a legal requirement. It shows how the two Article 21 points translate to a development team.
Commit and merge rights. Under "secure development", a supplier developer who can push straight to the main branch is a development-process gap, whoever employs them. Branch protection and required review apply to contractors and employees alike, and the entity needs a way to show it knows that.
CI secrets and deployment credentials. These are the highest-value items a contractor can touch. The practical question is whether a supplier developer can read production secrets, or only trigger a pipeline that uses them.
Production and data access. This is where administrator-level accounts show up. Separate accounts for supplier staff, scoped to what the work needs, mean the entity can answer "who had access" when something goes wrong. It also makes offboarding a single, checkable step.
Vulnerability handling. Article 21(2)(e) says "vulnerability handling and disclosure". For a supplier, that translates to who patches the dependencies in code they wrote, how fast, and how they report a flaw they find.
Each of these maps to contract language and to evidence the entity can request. That's the point of the next section.
How to put NIS2 supplier terms into a software development contract
Point 5.1 of the Regulation's Annex is a useful template, even for entities it doesn't bind. Here's how its elements map to a development contract.
1. Identify your role and tell the supplier
Start with the entity's own position. Point 5.1.1 of the Annex asks the entity to identify "their role in the supply chain and communicate it to their direct suppliers and service providers". Roles in the text include ICT supplier, manufacturer, managed service provider, managed security service provider and cloud provider. Step one is working out which role applies and telling the supplier in the contract or its security schedule.
As practice, not something point 5.1.1 requires, it also helps to name the regime the entity operates under, and the national law behind it, in the contract. That gives the supplier a reason for every other clause.
2. Set selection criteria before you sign
Point 5.1.2(a) of the Annex names "the cybersecurity practices of the suppliers and service providers, including their secure development procedures" among the selection criteria, echoing Article 21(3) of the Directive. In practice that's a pre-contract questionnaire or a conversation: how code is reviewed, how secrets are stored, how developers are onboarded and offboarded, how dependencies are patched.
Keep the answers. They're useful evidence of the measures taken.
3. Write the contract terms from point 5.1.4
Point 5.1.4 of the Annex says "the relevant entities shall ensure that their contracts with the suppliers and service providers specify, where appropriate through service level agreements, the following, where appropriate". Two "where appropriate" qualifiers sit in that sentence, so each item is included where appropriate to the engagement, not as a checklist where every item applies to every contract.
Items (a) to (h), as the Regulation sets them out, cover these topics for a development supplier:
- cybersecurity requirements for the supplier (what controls apply to the development work)
- staff awareness, skills and certifications
- background verification of the supplier's staff
- notice of incidents: an obligation to notify, in the text's words, "without undue delay" of incidents "that present a risk to the security of the network and information systems of those entities"
- an audit right: "the right to audit or right to receive audit reports"
- vulnerability handling
- "requirements regarding subcontracting"
- "retrieval and disposal of the information obtained by the suppliers and service providers", meaning, as an illustration of information obtained by the suppliers in the exercise of their tasks, what happens to code, data and credentials when the contract ends
Expect the audit item to draw pushback from small suppliers, and the text itself leaves room: the right to audit or to receive audit reports. A supplier that won't allow an on-site audit may still hand over an independent report or a completed security questionnaire. Counsel can say which is adequate for a given engagement.
Subcontracting deserves attention in a nearshore setup, where a supplier may bring in freelancers or a partner agency. A subcontracting clause that requires notice and equivalent terms keeps the "direct supplier" the Directive talks about from becoming a gap. The general clauses sit in a software development agreement for EU hiring, and the security terms above slot in as a schedule.
4. Line up incident notice with your own clock
The entity's reporting deadlines are set by Article 23(4) of the Directive. It requires an early warning "within 24 hours of becoming aware of the significant incident", an incident notification "within 72 hours of becoming aware of the significant incident, with the aim, in particular, of updating information", and "a final report not later than one month after the submission of the incident notification".
Those clocks run for the entity, from the point it becomes aware. The supplier's own duty comes only from the contract. The Regulation's "without undue delay" sets no number of hours, and a supplier that takes five days to mention that a developer laptop was compromised delays when the entity becomes aware, which leaves it less time to act once it does. Whether a supervisor would treat a late supplier notice as the point when the entity "should have known" is a question for counsel.
The text points to the contract as the place where "without undue delay" could get a number. Whether to write hours, and how many, is a question to ask counsel and the security lead. The 24-hour early warning on the other side is the reason it matters.
5. Review at planned intervals
Point 5.1.6 of the Annex asks entities to "review the supply chain security policy and monitor, evaluate and, where necessary, act upon changes in the cybersecurity practices of suppliers and service providers, at planned intervals and when significant changes to operations or risks or significant incidents related to the provision of ICT services or having impact on the security of the ICT products from suppliers and service providers occur". For a development supplier, that means a standing review, not a one-off questionnaire at signing. Developer turnover, new subcontractors, new tooling and new access paths all change the risk after the contract is signed.
The event triggers are in the text: significant changes to operations or risks, and significant incidents. Only the length of the "planned intervals" is open, so ask counsel what interval to write into the contract.
Cross-border: client in one member state, developers in another
A common nearshore setup has a client in Germany and developers in Poland or Romania. Which national NIS2 law applies?
The Directive is a minimum standard. Recital 5 describes it as "setting out minimum rules regarding the functioning of a coordinated regulatory framework", which leaves room for each Member State to set its own details when it transposes. Which member state's law applies depends on the entity type and where it's established, so check with counsel for each case.
For contracts, ask counsel whether to name the national regime in the security schedule. A clause that says "the supplier will meet the client's obligations under NIS2" is vague. For example, if the client were an important entity under Germany's implementing law, a clause saying "the client is an important entity under the German implementation, and these controls follow from it" would give the supplier something specific to check.
Developers outside the EU add a separate layer, and it's GDPR rather than NIS2. Serbia, for example, is not an EU member, so personal data a Serbian team accesses can raise third-country transfer questions. The international data transfer agreement: IDTA vs EU SCCs page covers the transfer mechanisms. The NIS2 security schedule and the data protection terms need to say consistent things about access, subprocessors and incident notice, because the same developer account often falls under both.
Where transposition stands as of the Commission's July 2026 update
National law is where NIS2 becomes concrete, and it's still being completed. The Commission's NIS2 page says "Member States had until 17 October 2024 to transpose the NIS2 Directive into national law." That deadline has passed.
The Commission's transposition page records what followed: "On 7 May 2025 the European Commission sent a reasoned opinion to 19 Member States". In July 2026, according to the Commission's NIS2 page, it decided "to refer Ireland, Spain, France and the Netherlands to the Court of Justice of the European Union for failing to notify measures transposing the NIS2 Directive."
There's also a pending change. On 20 January 2026, the same page says, the Commission "proposed targeted amendments to the NIS2 directive to increase legal clarity" as part of a cybersecurity package. That's a proposal. It isn't adopted law, and a contract shouldn't be drafted as if it were.
The Commission named the 19 member states that received reasoned opinions in May 2025 and referred four to the Court in July 2026, but it doesn't give a count of complete transpositions, so this article doesn't either. National laws differ, and some are still being finished. Check the current text of the law in the member state that governs the entity, and ask counsel whether contract references should be written to survive amendment, for example "as implemented in the applicable national law from time to time".
FAQ
Is my software development supplier subject to NIS2?
Usually not directly. NIS2 applies to essential and important entities, and a supplier is covered only if it falls into a listed sector. Software built and delivered to a client isn't the "managed service provider" definition on its face. A team that also administers the client's systems might fit it, so ask counsel where the roles blur.
Does NIS2 require a specific clause in my contract with a developer agency?
The Directive doesn't prescribe clause wording. Regulation 2024/2690, binding for the entity types it names, lists contract topics in point 5.1.4 of the Annex: security requirements, incident notice, audit rights, subcontracting, and retrieval and disposal of information at the end. For other entities it's a reference point, and national law sets the measures.
Do the 24-hour and 72-hour incident deadlines apply to my supplier?
They apply to the in-scope entity, running from when it becomes aware of a significant incident under Article 23(4). A supplier that isn't itself an entity has only the duties the contract gives it. That's why the notice clause matters: a slow supplier notice delays when the entity becomes aware and leaves less time to act. Whether a supervisor would treat it as the entity "should have known" is a question for counsel.
Does Regulation 2024/2690 apply to my company?
Only if you're one of the entity types it names, such as a managed service provider, a cloud or data centre provider, an online marketplace, a search engine, a social platform or a trust service provider. Other in-scope companies fall under national law, and points 5.1 and 6.2.1 of the Regulation's Annex are a reference point rather than binding rules.