Guides

NIS2 Guide · 11 min

NIS2 for suppliers: you are not designated, but your customers are

Most companies are never formally designated as essential or important entities under NIS2. Many of them still have to meet it. If your customers fall under NIS2, the directive makes them responsible for the security of their supply chain, and that responsibility reaches you through contracts, questionnaires and ongoing monitoring. This guide explains how the obligation flows down to an undesignated supplier, what your customers will ask for, and how to respond credibly and turn it into a commercial advantage.

Key takeaways

  • NIS2 does not have to name you. If your customers are in scope, their Article 21(2)(d) supply-chain duty becomes your contractual reality.
  • Expect security questionnaires, evidence of the Article 21(2) measures, an incident-notification clause and, increasingly, acceptance of continuous monitoring.
  • Suppliers who can demonstrate their security on demand keep contracts and win new ones; those who cannot are quietly replaced.

How NIS2 reaches a supplier that was never designated

NIS2 applies directly only to organisations it classifies as essential or important entities, by sector and size. If you are not one of them, no national authority will send you a compliance order. That is where many suppliers stop reading, and where the misunderstanding begins.

The directive does not regulate your suppliers' suppliers directly. Instead it makes each in-scope entity responsible for the cybersecurity risk in its own supply chain (Article 21(2)(d)). To discharge that duty, your customers must assess, set requirements for and monitor the security of the suppliers they depend on. If you are one of those suppliers, their legal obligation becomes your commercial one. You are pulled in indirectly, through the relationship rather than through a designation.

What your in-scope customer is required to do, and why it lands on you

Article 21(2)(d) requires essential and important entities to manage supply chain security, including the security-related aspects of the relationship between each entity and its direct suppliers or service providers. In practice your customer has to:

  • Identify which suppliers are critical to its services and assess the cyber risk each one introduces.
  • Set security requirements for those suppliers and write them into contracts and data processing agreements.
  • Verify that the requirements are met, not once at onboarding but on a continuing basis.
  • Account for incidents that originate with a supplier, because under NIS2 a supplier-caused disruption is still the customer's incident to handle and report.
  • Show its supervisory authority evidence that this supplier oversight actually happens.

What your customers will ask you for

As that oversight matures, the requests landing on suppliers are converging on a recognisable set:

  • A security questionnaire or self-assessment, often mapped to the NIS2 Article 21(2) measures or to a standard such as ISO 27001.
  • Evidence behind the answers: policies, certificates and recent test or scan results, rather than unsupported claims.
  • An incident-notification clause committing you to alert the customer quickly when something affects them, so they can meet their own reporting deadlines.
  • Contractual security requirements and, for critical suppliers, a right to audit or to request independent assurance.
  • Acceptance of continuous external monitoring, because a point-in-time questionnaire answered last year no longer satisfies a continuing-basis obligation.

The Article 21(2) measures your customers expect you to have

Even though Article 21(2) binds your customer rather than you, its ten measures are the template most buyers reuse when they set requirements for suppliers. It is worth being able to show, in your own proportionate way, that you address each:

Risk management and policies

A documented, regularly reviewed approach to information security risk, owned at a senior level. (Art. 21(2)(a))

Incident handling

A defined process to detect, respond to and learn from security incidents. (Art. 21(2)(b))

Business continuity and backups

Backups, recovery plans and crisis management so service survives a disruption. (Art. 21(2)(c))

Supply chain security

Your own oversight of the sub-suppliers and providers you depend on; the duty cascades down the chain. (Art. 21(2)(d))

Secure acquisition, development and maintenance

Security built into how you procure, build and patch systems, including vulnerability handling and disclosure. (Art. 21(2)(e))

Assessing effectiveness

Periodic testing and review to confirm the measures actually work. (Art. 21(2)(f))

Cyber hygiene and training

Basic practices and staff awareness, kept current. (Art. 21(2)(g))

Cryptography and encryption

Appropriate use of cryptography to protect data in transit and at rest. (Art. 21(2)(h))

Access control and asset management

Knowing your assets and controlling who can reach what. (Art. 21(2)(i))

Multi-factor authentication and secure communications

MFA, and secured voice, video and text and emergency communications where relevant. (Art. 21(2)(j))

Incident reporting flows in both directions

NIS2 gives in-scope entities a tight clock: an early warning within 24 hours, a fuller notification within 72 hours and a final report within a month (Article 23). They cannot meet that clock if a supplier sits on bad news. So their contracts increasingly require you to notify them promptly when an incident affects, or could affect, the services you provide them.

For an undesignated supplier the practical consequence is simple: you need your own incident process, with clear internal escalation and a defined way to inform affected customers, so that a problem on your side does not become a missed deadline on theirs. A supplier that detects, contains and communicates well is far easier to keep than one that goes quiet.

A requirement worth treating as an advantage

It is easy to read all of this as a burden imposed by someone else's regulation. The suppliers that do best read it the other way. As more buyers fall under NIS2 and tighten their supply-chain checks, the ability to answer a security questionnaire quickly, with evidence, becomes a reason to win and keep business rather than a hurdle to clear.

The reverse is also true and quieter: suppliers who cannot demonstrate their posture are increasingly filtered out at procurement, often without being told why. Getting ahead of the questions, before a customer asks, turns NIS2 from a compliance cost into a sales asset.

How to respond credibly

You do not need to become an essential entity overnight. You need to be ready for the questions and able to back your answers. A proportionate path:

  • Know your own external posture first: domains, certificates, email authentication, exposed services and known vulnerabilities, the same things a customer's assessment will look at.
  • Close the common gaps that questionnaires and scans flag: enforce TLS 1.2+, publish SPF, DKIM and DMARC, patch promptly, require MFA, and remove exposed admin interfaces.
  • Write down the basics: a short information security policy, an incident process and a record of who owns security. Evidence beats assertion.
  • Keep your answers current. Treat assurance as continuous, because that is increasingly how your customers treat it.
  • If you serve larger or regulated buyers, consider ISO 27001 or an equivalent as a recognised shorthand, but do not wait for it to start.

Source: Directive (EU) 2022/2555 (NIS2), Article 21(2) Member States implement NIS2 through national law, so confirm the exact supplier expectations with your customers and, where needed, your competent authority.

How norppa.io helps

norppa.io gives an undesignated supplier the same continuous, evidence-backed view of its security that a NIS2 customer now expects to see. Your domains are checked across more than a hundred control points daily, the time-sensitive ones every six hours, and each finding is mapped to the NIS2 article it relates to, so you can answer a questionnaire with current evidence rather than assertions.

The self-assessment questionnaire captures your process and contractual controls, and each answer is set against the live technical profile, so when a customer's procurement team asks for proof you can hand over a clear, corroborated picture instead of a spreadsheet that was true last spring.

Be ready before your customers ask

See a sample supplier report (findings, NIS2 article mapping and evidence) in about two minutes.

View sample report

Last reviewed: 19 June 2026

This guide is general information about EU law, not legal advice. NIS2 takes effect through each EU Member State's national transposition law, which can differ in detail. Verify the obligations that apply to you with your competent authority or legal counsel.

Related guides

How to comply with NIS2: a step-by-step roadmap

The steps to NIS2 compliance in order: confirm scope, register, management accountability (Art. 20), the Article 21(2) measures, supply-chain security, incident reporting (Art. 23) and continuous, evidenced assurance.

Who is in scope for NIS2? Essential vs important entities, sectors and size thresholds

Determine whether NIS2 applies to you: the two tiers, the Annex I/II sectors, the size thresholds, size-independent exceptions, and how the supply chain pulls you in even if you're not designated.

NIS2 and the supply chain requirement: what it means in practice

NIS2 requires essential and important entities to assess their supply chain cyber risks. Supplier tiering, 4th-party risk, Art. 23 notification, and what auditors look for.

Supplier cyber risk assessment: what automated NIS2 monitoring checks

All check categories explained: ransomware, dark web leaks, TLS/DNSSEC, cookie security, CVE/EPSS, sanctions, MX blacklists and SAQ. Finding lifecycle and NIS2 article mapping.

NIS2 Art. 21(2): supplier security checklist

Checklist for procurement and security teams: what to ask, what evidence to collect, and how to respond when a supplier falls short. Includes suggested evidence documents.

NIS2 supplier questionnaire (SAQ): what to ask, how to score it, and a free template

What to ask suppliers under Art. 21(2)(d), how to score answers and respond to gaps, why self-attestation needs verification, and a free copy-paste questionnaire template.

NIS2 incident reporting: the 24- and 72-hour deadlines explained

What counts as a significant incident, the Article 23 timeline (24-hour early warning, 72-hour notification, one-month final report), and when a supplier's incident becomes your obligation.

NIS2 and management responsibility: what boards and leadership must know

What NIS2 expects of the management body: approval and oversight duties, personal liability (Art. 20), training, board reporting KPIs, and the penalties under Art. 34.

ISO 27001 and NIS2: what your ISMS already covers, and the gaps it doesn't

If you hold ISO 27001, what carries over to NIS2 and what does not: statutory incident reporting, management liability, registration, and continuous supply-chain assurance: plus how to close the gap.

NIS2 vs DORA: how they differ, where they overlap, and which one applies to you

How the two EU regimes differ and overlap, why DORA is lex specialis for financial entities, which applies to you, and what both mean for third-party and supply-chain risk.

GDPR vs NIS2: how they overlap, where they differ, and when one incident triggers both

How GDPR and NIS2 differ and overlap, when one incident triggers both (GDPR Art. 33 72h to the DPA vs NIS2 Art. 23 24h/72h/1-month to the CSIRT), the Art. 35 cooperation and no-double-fine rule, and what both mean for supplier due diligence.

The EU Cyber Resilience Act (CRA): scope, timeline and what it means for your supply chain

What the CRA requires, its phased dates (in force 2024, reporting Sept 2026, full compliance Dec 2027), who is in scope and why pure SaaS often isn't, how it complements NIS2, and what it means for procurement and supplier due diligence.

The EU AI Act: risk tiers, the timeline, and what deployers must do (Article 26)

What the EU AI Act requires: the risk tiers, the phased dates (in force 2024, prohibited Feb 2025, GPAI Aug 2025, high-risk Aug 2026), the Article 26 deployer obligations, how it stacks with NIS2 and the GDPR, and what it means for AI procurement.