NIS2 supplier requirements | what customers will ask

Do NIS2 requirements for suppliers apply if we are not in scope?

NIS2 does not directly bind most suppliers, but the requirements still reach them through contracts. Article 21(2)(d) obliges essential and important entities to address security in their relationships with direct suppliers and service providers. An in-scope customer that sends a security questionnaire or contract addendum is therefore discharging its own duty, and it will ask you to show how your controls support its obligations. Being outside scope does not remove the request. It means the request arrives as a commercial term, and refusing or answering vaguely can cost you the contract even though no regulator is looking at you directly.

The exact clauses depend on the customer's sector, entity type, national transposition law and the role you play. Article 21(3) asks the customer to weigh each direct supplier's specific vulnerabilities and the quality of its products and secure development practices, so expect questions on those topics first. For digital infrastructure and digital provider entities, the implementing regulation lists contract topics such as incident notification without undue delay, audit rights or audit reports, vulnerability handling, subcontracting and exit obligations (Implementing Regulation 2024/2690, Annex, point 5.1.4). Confirm with each customer which of these apply to your service. Ask whether the clause is required by its national law or is its own policy choice, because the answer changes how much negotiation room you have.

Keep the division of roles clear in every response. You own your controls and you can prepare evidence for the customer, but you do not issue a NIS2 certificate, and no such certificate exists. Only an independent auditor or assessor issues reports, and any statement you make about your own compliance should be framed as your self-assessment unless a third party has tested it. Before answering a questionnaire, ask the customer what evidence it will accept, whether it requires an independent report, and how often it will reassess you. Those answers determine the effort, the recurring cost of evidence collection and whether an outside assessment is worth buying.

Which security clauses customers will ask for

Customers in scope of NIS2 pass their obligations down through contracts, and the implementing regulation lists the clause families they should consider for digital infrastructure and digital provider relationships. Customers apply these where appropriate, so each supplier should check every family against the services it actually delivers.

Cybersecurity requirements

Customers write minimum security standards into the contract, covering the controls the supplier must run on the services it provides to them. For a supplier, this means mapping each contractual control to a system, owner and evidence source before signing, rather than accepting a generic annex. Ask the customer which of its Article 21 measures the clause is meant to support, and confirm which party maintains each control over the contract term.

Staff training and background checks

Customers may require that supplier personnel with access to their systems receive security training and undergo background checks where that is appropriate to their role. The supplier should identify which staff roles touch customer environments, decide what screening the local law permits, and keep training records that a customer can review. Confirm early whether checks apply to subcontractor staff too.

Incident notification without undue delay

Customers need to learn about supplier incidents quickly so they can meet their own staged reporting duties under Article 23. The clause should set who notifies, through which channel, and what details the supplier provides at first contact. Suppliers should check that their detection and escalation process can deliver that notice on the timescale the contract sets, and that the contract names a single contact for incident communications.

Audit rights or audit reports

A customer may ask to audit the supplier directly or to accept independent audit reports in its place. Each option has a cost. Direct audits take staff time and access planning, while reports only help if their scope covers the services the customer buys. Suppliers should decide in advance which independent reports they can offer, confirm their scope and period, and agree how the customer can request additional evidence.

Vulnerability handling

Customers expect the supplier to find, track and fix vulnerabilities in the products and services they rely on, and to tell them when a fix affects their environment. The clause should define how vulnerabilities are reported, how severity is assessed and what timelines apply. Suppliers should check whether their patch process, advisory channel and end-of-support dates can meet those commitments for every component they deliver.

Subcontracting and exit obligations

Customers commonly require notice before the supplier passes work to subcontractors, and a right to leave the relationship without losing their data or service continuity. Suppliers should list their own subcontractors, record which of them handle customer data, and set out data return, deletion and transition support. Confirm that the exit terms match the restart and migration effort the customer would realistically need.

What happens after the contract is signed

Once the contract is in force, the customer runs its NIS2 supplier duties against you on a recurring basis, so the work shifts from paperwork to reporting, reassessment and controlled access. Each step below produces a record you should expect to supply and keep current.

Agree the reporting calendar and contacts
Before the first service period closes, agree with the customer the schedule for SLA reports, the named security contacts on both sides, and the channel used for security notices. Confirm which information the customer expects in each report, such as availability, vulnerability status and open changes. Who does this: your service manager and the customer's supplier risk owner. Done when both parties hold a signed or recorded reporting schedule and contact list that the contract references. Ask the customer to confirm whether it expects a fixed format or its own template.
Deliver SLA reports the customer can monitor
Produce SLA reports at the agreed interval, covering service performance, security-relevant events, patch and vulnerability status for the systems you run for the customer, and any breaches of contractual security commitments. The customer must monitor these reports under the implementing regulation, so reports should be factual, dated and traceable to logs or tickets. Output: a report per period, retained with the underlying evidence. Your own records should show that each report was delivered on time and that corrective actions were tracked to closure.
Report and review supplier-related incidents
When an incident affects the customer's services or systems, notify the customer without undue delay using the channel and content the contract sets, including the information the customer needs to meet its own reporting duties. Then support a joint review of root cause, scope and corrective actions. Output: an incident record shared with the customer and a closed review with agreed actions. Confirm with the customer how quickly it expects first notice, since the contract, not the regulation, sets your deadline in most cases.
Request authorization before remote connections
Any remote session into the customer's network, including maintenance access, must first go through the customer's authorization process. Submit a written request that names the engineers, the systems, the purpose and the requested time window, such as a maintenance window. Access is granted only for that set period and is logged. Output: an approved access request on file, a session log and confirmation that access closed when the window ended. Do not reuse standing credentials to bypass this step, even for urgent fixes; agree an emergency route in advance if the contract allows one.
Keep staff training and background checks current
Where the customer extends its awareness programs or background checks to suppliers, complete the training it requires and provide evidence of completion for the engineers who touch its environment. Update the list of personnel with access when staff join or leave the engagement. Output: a current roster with training records and background check confirmations where the contract requires them. Ask the customer which checks it applies and how often it expects them to be refreshed.
Support the customer's planned reassessment
The customer reassesses suppliers at planned intervals and after significant changes or incidents. Prepare the evidence it will request: current security questionnaire answers, updated architecture or data flow descriptions, subprocessor and subcontractor lists, vulnerability handling status and any independent audit reports you hold. Output: a reassessment pack the customer accepts or queries in writing. Keep the pack dated so that the answers you gave in the last cycle can be compared with the current ones.
Notify changes and reassess after them
Tell the customer in advance of significant changes to your service, such as a new hosting location, a change of subcontractor, a major platform upgrade or a change in ownership. The customer may trigger an unscheduled reassessment, so the change notice should include the security impact and the evidence that supports it. Output: a dated change notice, the customer's response and an updated record of your security posture. Confirm the notice period and approval process for changes with the customer before the contract is signed, not after.

What changes by supplier type

Customers that run their services on a SaaS or cloud provider usually treat the provider as a direct supplier whose security practices feed into their own Article 21 risk assessment. The Implementing Regulation's supplier provisions list the topics that contracts should cover where appropriate, including incident notification, audit rights or audit reports, vulnerability handling, subcontracting and exit. Customers will expect the provider to show how it handles these in practice, not only in the terms.

Incident notification: a stated timeline for telling the customer about incidents affecting its data or service, with a named contact.
Audit rights or audit reports: access to an independent audit report or, where none exists, a right to assess controls.
Subcontracting: a current list of sub-processors and hosting locations, with notice before changes.
Exit obligations: data return and deletion terms that a customer can actually execute.
Vulnerability handling: a documented process for identifying, prioritizing and fixing vulnerabilities in the hosted service.

Before accepting a SaaS or cloud provider, confirm which of these points are in the contract, which are only in marketing material, and which the provider can evidence with reports and records.

Evidence a supplier should have ready

This table maps the requests an in-scope customer is likely to send its supplier to the evidence form, the party who owns it, and whether an independent auditor report can satisfy it. Read it as a checklist for supplier readiness: most requests are answered by operational records the supplier produces itself, and an auditor report covers only part of them. No standard or report certifies NIS2 compliance, so the customer still decides whether the evidence meets its own obligations.

Customer request	Evidence form	Owner	Can an auditor report satisfy it?
Security questionnaire	Completed questionnaire with references to policies, architecture and controls	Supplier security lead	Partly, as a supporting attachment
SLA report	Periodic report of agreed service levels, outages and security service metrics	Supplier service management	No, operational record
Vulnerability handling statement	Written process, patch timelines and records of recent vulnerability fixes	Supplier engineering and security	Partly, if the audit covers vulnerability management
Audit report or audit right	Independent report plus contract clause granting audit access and scope	Supplier management, with an independent auditor for the report	Yes, for the report; the audit right is a contract term
Subcontractor list	Current list of subcontractors with services provided and locations	Supplier procurement and legal	No, unless the auditor tested subcontractor oversight
Exit plan	Documented data return, deletion and service transition steps tested against the contract	Supplier account and legal teams	Rarely, as part of a broader assessment
Training records	Attendance logs, course content and completion dates for staff with system access	Supplier HR and security awareness owner	Partly, if sampled during the audit
Background check records	Confirmation that checks were run for relevant staff, with the policy governing them	Supplier HR	Partly, if the auditor sampled personnel files

Who owns the controls and who issues the report

The supplier owns its controls and its contractual commitments. A NIS2 customer can write security clauses, ask for evidence and set audit rights, but it cannot make a supplier's controls the customer's controls. The supplier runs its own access management, change control, logging and vulnerability handling, and it is the party that answers for them in the contract. Before signing, check which obligations the supplier accepts in writing, who is accountable for each one, and what the supplier must show if a customer or authority asks for proof. An implementation partner such as DeployOpen can help a supplier build or harden the systems and documentation behind those commitments, but the supplier stays responsible for operating them.

A partner can prepare systems, logging, documentation and evidence inside the supplier's own environment, such as configuration baselines, access review records, backup test results and incident runbooks. That work makes the supplier's claims checkable. It does not make the partner an assessor. Only an independent auditor, assessor or certification body issues an audit report or certificate, and the customer should confirm the independence of whoever produces the assurance it relies on. Ask the supplier which report it can provide, who issued it, what scope it covers and whether the period tested matches the services the customer buys.

NIS2 creates no certificate of compliance. National competent authorities supervise entities through inspections, audits, scans, information requests and fines, and they do not certify suppliers. A customer therefore relies on the contract terms and on whichever assurance reports it chooses to accept. Decide in advance which evidence is acceptable for each clause, such as an independent report, a certification the supplier already holds, or customer-run testing, and write that choice into the contract. Where a supplier holds no independent assurance, the contract should say what evidence it must provide and how often, and the customer should plan its own verification.

How to prepare before the first customer audit

A customer in scope of NIS2 will usually test its suppliers against the contract and the implementing regulation before it tests anything else. The six items below are the records and routines that answer those first questions, and each one can be checked internally before the audit request arrives.

Contract clause inventory

List every customer contract and standard terms document, then record which NIS2-driven clauses each one contains: cybersecurity requirements, staff training, background checks, incident notification, audit rights or audit reports, vulnerability handling, subcontracting and exit. Mark gaps by contract, not by template, because older agreements often lack clauses that newer ones carry. Confirm with counsel which clauses the customer's own contract terms actually require, since the customer's obligations flow through its contracts.

Documented vulnerability handling

Customers will ask how you find, triage, fix and disclose vulnerabilities in the products or services they depend on. Check that a written procedure exists, names an owner, sets severity-based response targets, and records each finding and its closure. Test it once with a sample vulnerability so you can show a dated trail, and confirm that the process covers third-party components you ship.

Incident notification matched to customer timelines

Your notification duty to a customer must fit inside the customer's own reporting clock, which can be as short as the 24-hour early warning in Article 23. Map each customer's notification window against your detection, triage and escalation steps. Run a tabletop exercise that times the path from alert to notice and confirm that a named person can send the message out of hours.

Subcontractor register

Keep a current list of every subcontractor and hosting provider that touches customer data, systems or connections, with the service, location, data types and contract reference for each. Customers test this list against their own supplier register, and the implementing regulation expects them to reassess suppliers after significant changes. Check that the register is updated when a subcontractor changes, and that each entry links to the flow-down clauses in its contract.

Access controls for customer connections

Where you connect to a customer network, the customer may allow access only after an authorization request and for a set period, such as a maintenance window. Inventory every remote access path, the accounts that use it, and the approval record for each session. Check that access is removed when the window closes, that privileged accounts use multi-factor authentication, and that session logs can be produced for the customer on request.

Named owner for security questionnaires

Customer security questionnaires, audit requests and evidence packs arrive on short timelines and touch engineering, legal and operations. Assign one named owner who holds the master answer set, approves each response and keeps a log of what was sent, to whom and when. Confirm that the owner can pull evidence from the controls above without waiting for a project, and that answers are reviewed when a product or subcontractor changes.

NIS2 supplier questions buyers ask

Does NIS2 apply to a non-EU supplier that serves an EU customer?

NIS2 does not apply to a supplier directly just because it is outside the EU, but the customer's obligations can still reach it. Article 21(2)(d) requires an in-scope entity to address security in its relationships with direct suppliers and service providers, so the requirements usually arrive as contract terms. Whether a non-EU supplier must also meet a national rule depends on whether it is itself an in-scope entity under the law of a Member State, which is a question for national counsel. Ask the customer which clauses it will require and whether its own national law adds anything. The Commission's January 2026 proposal on ICT supply chain risk from third-country suppliers is a proposal only and does not yet bind anyone.

Must a supplier hold a NIS2 certificate to win an EU customer?

No. NIS2 creates no certificate of compliance, so no document exists that proves NIS2 compliance on its own. Customers instead assess suppliers against the security clauses in their contracts, their questionnaires and any evidence the supplier provides. Some customers accept an ISO/IEC 27001:2022 certificate or a SOC 2 report as supporting evidence, but that acceptance is a commercial decision by the customer, not a NIS2 requirement. Check the customer's written requirements before assuming a certificate will be accepted, and ask which report type or scope it expects.

How long does a supplier security questionnaire take to answer?

The time depends on how much evidence the supplier already has and how many people must review each answer. No standard duration applies, so ask the customer for its expected response window in writing before the questionnaire arrives. Drivers include the number of questions, whether policies and test reports already exist in a form that can be shared, and whether the answers need sign-off from legal or the management team. Suppliers that keep a current, reusable set of policies, evidence and architecture documents usually spend less effort on each request than suppliers who rebuild answers from scratch.

What does a customer security audit of a supplier involve?

A customer audit tests whether the supplier does what its contract and questionnaire say. Implementing Regulation (EU) 2024/2690 lists audit rights or audit reports among the clauses a contract may cover for digital infrastructure and digital provider entities, so the scope depends on what the contract grants. Typical steps include a document review, interviews with staff, a sample check of access reviews, change records, backup restores and incident logs, and a review of any independent audit report the supplier holds. Agree the scope, notice period, evidence list, cost allocation and confidentiality terms in the contract before the audit starts, and confirm which parts the customer may test directly.

Can a supplier refuse a customer's audit rights?

A supplier can refuse terms it has not agreed to, but a refusal can end the commercial relationship. The customer must address supplier security in its contracts under NIS2, so it may treat the absence of audit rights as a reason to decline or reassess the supplier. Suppliers often offer an independent audit report, a shared assessment or a limited scope test as an alternative, and the customer decides whether that meets its needs. Legal teams should review audit terms with data protection obligations under GDPR in mind, since customer audits can expose personal data and shared infrastructure.

How could the January 2026 NIS2 proposal change supplier obligations?

The proposal, COM(2026) 13, would amend NIS2, but it is not law until the European Parliament and the Council adopt it. Its main effect on suppliers would come through scope changes, such as a new small mid-cap category, which could change which customers are in scope and therefore which clauses they request. Separately, the Commission's revised Cybersecurity Act proposal of 20 January 2026 would set a framework for ICT supply chain risk from third-country suppliers. Until those texts are adopted, keep existing contract clauses in place and review them when the final wording and national transposition are known.

How DeployOpen prepares supplier evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For NIS2 requirements for suppliers, we help the customer prepare the systems, controls and records that its contracts and supplier reviews will ask for, while the customer keeps ownership of its supplier decisions and contracts.

How we scope

Each engagement starts with a written scope that names the platforms, environments and supplier-facing evidence covered.
We confirm which direct supplier relationships and service connections the customer must document under its own NIS2 obligations.
Scope, deliverables and timelines are agreed in writing before any work begins, and the quote follows from that scope.

How we build

We configure supplier access, remote connections and authorization windows so each connection can be approved and logged.
We set up logging and records for supplier SLA reports, supplier-related incidents and reassessment dates.
We run security testing of supplier-facing applications and APIs where the written scope includes it, and record the findings.

How we hand over

We deliver configuration records, procedures and evidence packs that map to the supplier clauses the customer has agreed to.
We document how each supplier review, reassessment and incident notification step is performed and who owns it.
We provide handover sessions so the customer's staff can operate, update and show the evidence to its own assessors.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We update supplier evidence after significant changes to platforms, suppliers or contract terms, as the written scope allows.
Independent auditors and certification bodies, not DeployOpen, assess the controls and issue any reports or certificates.

NIS2 requirements for suppliers