NIS2 and DORA: Supply Chain Requirements for Tech Vendors

NIS2 supply chain requirements now reach far beyond the EU businesses the directive directly regulates. NIS2 (Directive (EU) 2022/2555) makes supply chain security a mandatory control for every essential and important entity, and DORA (Regulation (EU) 2022/2554) makes ICT third-party risk management mandatory for EU financial entities, so both laws turn your EU client's compliance program into your vendor questionnaire. Neither law usually regulates a non-EU software vendor directly. Both regulate you commercially, through the contract, the moment an EU client needs to prove its own supply chain is under control.

This guide is for technology vendors, including Israeli software houses, serving EU clients, and for the EU buyers evaluating them. It covers what NIS2 and DORA actually require, where the two overlap and diverge, the narrow cases where a vendor falls into direct scope, and a concrete checklist for what to have ready. This is general information, not legal advice; confirm specifics with your own counsel before relying on it.

What Are NIS2 and DORA, and Why Do Tech Vendors Care?

NIS2 is the EU's cross-sector cybersecurity directive, replacing the original 2016 NIS Directive. As a directive rather than a regulation, it does not apply automatically: each EU member state had to transpose Directive (EU) 2022/2555 into national law, with a deadline of 17 October 2024.

DORA is different in form. It is a regulation, so Regulation (EU) 2022/2554 applies directly and identically across the EU without national transposition, and it has applied to EU financial entities since 17 January 2025.

Neither law was written with software vendors as its primary target. Both reach vendors because the entities they do regulate, ordinary EU businesses under NIS2 and financial institutions under DORA, are legally required to manage the cybersecurity risk their suppliers create. The simplest way for those entities to demonstrate that is to push documented requirements down into vendor contracts, which is exactly what shows up on a supplier's desk as a security questionnaire, a new contract clause, or a request for an exit plan.

Who Does NIS2 Actually Regulate?

NIS2 sorts in-scope organizations into two tiers, essential entities and important entities, across 18 sectors split between Annex I ("sectors of high criticality") and Annex II ("other critical sectors"). The tier and the size of the organization together decide the level of scrutiny.

The size-cap rule uses two thresholds. Medium enterprises, meaning 50 or more employees or annual turnover above EUR 10 million, and larger organizations are generally in scope if they sit in a covered sector. Large enterprises, 250 or more employees or turnover above EUR 50 million, in an Annex I sector become essential entities; medium-sized organizations in Annex I, and medium or larger organizations in Annex II, become important entities. A short list of categories, including DNS providers, top-level domain registries and public administration bodies, are in scope regardless of size.

The distinction matters for penalties. Essential entities face fines of up to EUR 10 million or 2% of global annual turnover, whichever is higher; important entities face up to EUR 7 million or 1.4%.

Transposition itself has been slow. By mid-2026, roughly 22 of the 27 member states had adopted NIS2 into national law, with France, Ireland, Luxembourg, the Netherlands and Spain still finishing. In July 2026 the European Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice of the EU for failing to notify complete transposition, a step that can lead to financial penalties against the state itself. For a vendor, the practical lesson is not to wait for a client's country to finish transposing: large EU organizations are building NIS2-equivalent requirements into their vendor programs regardless of exactly where their national law stands.

What Does NIS2 Require for Supply Chain Security?

Article 21 is the core of NIS2's technical obligations. It requires essential and important entities to take appropriate and proportionate technical, operational and organizational measures across ten areas, including risk analysis, incident handling, business continuity and backup management, cryptography, access control, and staff training in basic cyber hygiene.

Supply chain security is one of those ten areas in its own right. Article 21(2)(d) requires entities to address "security-related aspects concerning the relationships between each entity and its direct suppliers or service providers," and to weigh the vulnerabilities specific to each supplier along with the overall quality of that supplier's products and cybersecurity practices, including its secure development procedures. That single clause is the legal reason a due diligence questionnaire lands on a vendor's desk: your EU client cannot satisfy its own Article 21 duty without an answer from you.

NIS2 also standardizes how fast a significant incident must be reported, under Article 23:

1. Early warning within 24 hours of becoming aware of a significant incident.
2. Incident notification within 72 hours, updating the early warning with an initial severity and impact assessment.
3. Final report within one month, covering root cause and remediation.

If your work touches a client's essential or important service, expect your contract to require you to notify them well inside that 24-hour window, since they need time to assess your incident before their own regulatory clock starts.

What Does DORA Require for ICT Third-Party Risk?

DORA applies directly to financial entities as defined in its Article 2, a list running from banks and insurers to investment firms, payment institutions and crypto-asset service providers, and it reaches their ICT vendors through two mechanisms.

The Register of Information. Under Article 28(3), financial entities must maintain and keep updated, at entity, sub-consolidated and consolidated level, a register of every contractual arrangement for ICT services from third-party providers, distinguishing arrangements that support a critical or important function from those that do not. The register follows a standardized, machine-readable format set by Commission Implementing Regulation (EU) 2024/2956, and financial entities submit it to their national competent authority annually, with the first cycle completed in 2025. As a vendor, expect your client to ask for exactly what that register needs: your legal entity, a clear service description, where the service is delivered from and where data is processed, and whether the engagement supports a critical or important function.

Mandatory contract terms. Article 30 sets minimum content for every ICT contract: a clear service description, data location, security obligations, cooperation with the financial entity's regulators, and termination rights with minimum notice periods. Contracts supporting critical or important functions carry a stricter, additional tier, including audit and access rights, subcontracting transparency, and cooperation with resilience testing.

Direct oversight of the largest providers. DORA also lets the European Supervisory Authorities designate the most systemically important ICT providers as critical ICT third-party providers, or CTPPs, for direct oversight rather than leaving scrutiny entirely to individual financial entities. On 18 November 2025, the EBA, EIOPA and ESMA designated the first CTPPs, reported at 19 providers across cloud, infrastructure, data center and financial-technology categories, with oversight led by whichever authority matches the sector: EBA for banking-focused providers, ESMA for capital markets, and EIOPA for insurance. A designated CTPP that fails to cooperate with its Lead Overseer can face a periodic penalty payment of up to 1% of average daily worldwide turnover, charged daily for up to six months. This tier is built for hyperscale cloud and infrastructure providers, not for a typical development, DevOps or security services vendor.

NIS2 vs DORA: How the Two Regulations Compare

| Dimension | NIS2 | DORA | | --- | --- | --- | | Legal form | Directive (EU) 2022/2555, transposed into each country's own law | Regulation (EU) 2022/2554, applies directly and identically EU-wide | | Who it binds | Essential and important entities across 18 sectors | Financial entities defined in Article 2: banks, insurers, investment firms and more | | Key date | Member states had to transpose it by 17 October 2024 | Directly applicable since 17 January 2025, no transposition needed | | Main vendor mechanism | Article 21(2)(d) supply chain security, flowing down through contracts | Register of Information plus Article 30 mandatory contract clauses | | Direct vendor oversight | Only specific non-EU categories under Article 26 (cloud, DNS, MSP, MSSP) | Only ESA-designated critical ICT third-party providers (19 as of November 2025) | | Incident reporting | 24-hour early warning, 72-hour notification, 1-month final report | 4-hour initial notification after classification, 72-hour update, 1-month final report | | Penalties | Essential entities: up to EUR 10 million or 2% of turnover. Important entities: up to EUR 7 million or 1.4% | Set nationally for financial entities; ESAs can fine designated CTPPs directly, up to 1% of daily turnover per day | | Overlap rule | Yields to DORA for financial entities under Article 4 | Article 1(2) makes DORA lex specialis over NIS2 for ICT risk, incident reporting and testing |

Does NIS2 or DORA Apply Directly to a Non-EU Software Vendor?

For most custom software development, DevOps or cybersecurity engagements, the answer is no. Both laws are built to bind EU entities, and EU financial entities, directly, and to reach their suppliers through the contract rather than through direct statutory reach into a company based in Israel, the US or anywhere else outside the EU.

One exception is worth checking against your own service lines. NIS2's Annex I includes an "ICT service management (business-to-business)" sector covering managed service providers and managed security service providers, defined broadly as an entity that installs, manages, operates or maintains a client's ICT products, networks, infrastructure or applications, including through active administration carried out remotely. If a vendor's offering fits that definition and it delivers those services within the EU without an EU establishment, NIS2 Article 26 requires it to designate a representative in a member state where it offers the service, which brings it under that state's direct NIS2 jurisdiction rather than leaving it purely as an indirect, contract-driven obligation.

DORA has a comparable direct-scope path only through the CTPP designation described above, which is not a realistic classification for a development, DevOps or managed security vendor of ordinary scale, however large its client list.

The practical read: assume indirect, contract-driven obligations as the default for project-based development work, and check the managed service provider definition specifically if part of a vendor's business is ongoing managed DevOps, cloud operations or managed security and SOC services delivered on a continuous basis rather than a defined project.

What Evidence Should a Tech Vendor Have Ready?

EU clients increasingly ask for evidence, not assurances. Work through this list before a prospective client's security review reaches your desk:

1. A written information security policy and a current risk register, not just a certification logo on a slide.
2. Evidence of incident response testing, such as a tabletop exercise or drill, completed within the last 12 months.
3. A named, reachable point of contact for security incidents, with response times committed in writing.
4. A current subcontractor and sub-processor list, including each one's role and location.
5. An incident notification window to your client tight enough for them to meet their own 24-hour NIS2 warning or DORA's faster classification clock.
6. Audit rights your client can realistically exercise, not a clause that only reads well.
7. A documented exit plan describing how you would return data, code, infrastructure access and documentation if the relationship ended.
8. Specific evidence for critical or important functions, since a DORA-regulated client will apply Article 30's stricter tier and expect cooperation with its resilience testing.
9. Clarity on where data is processed and stored, since both laws care about data location as a first-class fact.
10. A direct, written answer on whether your company itself sits in NIS2 or DORA's direct scope, and if not, how you meet the standard contractually anyway.

| What your EU client needs | Why they are asking | What to have ready | | --- | --- | --- | | Proof of supply chain security (NIS2 Article 21) | Their own risk-management duty covers your cybersecurity practices | Security policy, risk register, secure development process summary | | A Register of Information entry (DORA Article 28) | An annual regulatory filing that names every ICT vendor | Legal entity name, service description, data location, criticality flag | | Article 30 contract terms (DORA) | Mandatory minimum content for ICT service contracts | Willingness to accept audit rights, exit terms and incident clauses | | Fast incident notification | To meet their own 24-hour or 4-hour regulatory clock | An internal SLA tighter than your client's regulatory deadline | | Subcontractor transparency | Their own register and risk assessment need your sub-processors too | A current, shareable subcontractor list | | An exit plan | Both laws expect continuity if a vendor relationship ends | A written plan for data return, access revocation and handover |

Illustrative scenario: a Dutch payment institution, a DORA-regulated financial entity, is onboarding an Israeli software house to build a feature that touches transaction data. Assumptions: the work counts as supporting an important function, so DORA's stricter contract tier applies, and the vendor is not itself a financial entity or a designated critical ICT third-party provider.

Before development starts, the payment institution's vendor risk team requests four things: the details needed for its own Register of Information entry, meaning the vendor's legal name, a service description, and where the work will actually be performed; a signed contract carrying DORA Article 30 terms, including a four-hour internal escalation commitment so the client can hit its own incident-classification clock; a current subcontractor list; and a written exit plan covering source code, credentials and documentation handover. None of DORA's direct obligations apply to the vendor itself, since it is neither a financial entity nor a designated CTPP. Every one of these requests still lands on its desk, because its client's own DORA compliance depends on being able to answer for its vendors.

How Agentixly Approaches NIS2 and DORA Readiness for Clients

At Agentixly, vendor-readiness work for EU clients runs alongside our cybersecurity practice rather than as a one-time paperwork exercise before a contract is signed.

1. Scoping. We start by identifying whether a client is itself NIS2 or DORA-relevant, and if so, which contract tier and evidence set that triggers.
2. Documented controls. Security policy, risk register and secure development practices are mapped to NIS2's Article 21(2) categories, so answers to a client's questionnaire point to real, current documents rather than being written for the occasion.
3. Contract-ready terms. Audit rights, incident notification SLAs tighter than the regulatory clock, and a written exit plan are negotiated once as a standard package and reused across engagements, rather than improvised under deadline pressure.
4. Subcontractor transparency. We keep a current list of the tools and any subcontractors involved in each engagement, ready to share the moment a client's register needs it.
5. Continuity evidence. Where a client also needs backup and resilience evidence, this work ties directly into our cloud disaster recovery practice.

Clients preparing for a broader certification push alongside NIS2 or DORA readiness often run this work in parallel with our ISO 27001 vs SOC 2 guide, and EU or UK companies evaluating an Israeli partner for the first time should also read our guide to GDPR and Israel's adequacy status, since data protection and supply chain security questions usually arrive in the same due diligence round.

The Bottom Line

NIS2 supply chain requirements and DORA's third-party rules rarely bind a non-EU tech vendor directly. They bind your EU clients, and your clients cannot satisfy either law without a straight answer from every supplier in their chain, including you. NIS2 pushes supply chain security down through Article 21(2)(d); DORA pushes it down through a Register of Information and Article 30 contract terms; both increasingly show up as the same questionnaire on a vendor's desk regardless of which law technically applies.

Treat the checklist and table above as a baseline you can answer before a client asks, not after. If you want a development and security partner that already builds this evidence into delivery, see how our cybersecurity team works, or get in touch to talk through what your next EU engagement will require. If you are still comparing Israel against other outsourcing destinations for an EU-facing build, our guide to outsourcing software development to Israel covers the broader decision.