How to assess suppliers under NIS2

How to assess suppliers under NIS2 before you sign or renew

An entity covered by NIS2 owns the supplier assessment, and no one else can issue it for them. Under Article 21(3), the entity must take into account each direct supplier's specific vulnerabilities, the overall quality of the supplier's products and cybersecurity practices, including secure development, and the results of EU coordinated supply chain risk assessments under Article 22(1). Implementing Regulation (EU) 2024/2690 adds the duties to keep a registry of direct suppliers and service providers and to reassess them at planned intervals and after significant changes or incidents. No NIS2 certificate exists for a supplier, so the evidence you rely on is what you collect and document yourself.

The depth of the assessment should follow two things: the role the supplier plays in your services and the risk that role carries for your network and information systems. A supplier that hosts production data, holds privileged access or runs security monitoring for you warrants far more scrutiny than one that supplies office software. Before any signature or renewal, confirm the supplier's role, the ICT products, services and processes it provides, and the contact points you will use during an incident. Record these in the supplier registry so that the entry and the contract stay consistent. Ask the supplier for its vulnerability handling process, its secure development practices and its commitments on component information and security updates, then check the answers against the requirements in your own supply chain security policy.

No assessor issues a NIS2 certificate for a supplier, and a supplier's ISO/IEC 27001 certificate or SOC 2 report does not by itself show that the supplier meets your needs. Treat such reports as inputs. Read their scope, their date and their exclusions, and ask which of your services and locations they cover. Where a supplier cannot show the evidence you need, decide before signing whether to accept a compensating control, limit the supplier's access or choose another provider. Confirm with your national competent authority or legal adviser how your Member State's transposition law treats supplier diligence, since the duties apply through national law.

What Article 21(3) asks you to weigh for each supplier

Article 21(3) names three inputs an entity must take into account for each direct supplier: specific vulnerabilities, overall product and practice quality, and EU coordinated risk assessment results. Each input needs different evidence, so collect them separately and record how each one shaped the supplier decision.

Supplier-specific vulnerabilities

Start with what is known about this supplier's own weaknesses, not the sector in general. Review its vulnerability disclosures, published advisories affecting the products you buy, and any known exposure in the systems it operates for you. Ask the supplier how it finds, ranks and fixes its vulnerabilities, and what it shares with customers and when. Record each open finding, its severity and the agreed fix date, because a supervisor will ask how the entity weighed it before buying.

Overall product quality

Assess whether the products and services are fit for the security job they will do. Ask for the supplier's security specifications, its approach to product resilience, and how it validates releases before delivery. Check the update policy: how long security updates continue, and what happens at end of support. Under the acquisition rules in Implementing Regulation 2024/2690, you must also know the hardware and software components inside what you buy, so request component information and confirm it matches what you receive.

Cybersecurity practices and secure development

Judge how the supplier builds and operates its services, not only whether it holds a certificate. Look for evidence of a secure development lifecycle, such as code review, dependency management, security testing before release and separation of production and development environments. Ask how staff access is controlled and how the supplier reviews its own subcontractors. Request concrete artifacts, such as its test summaries, change records and access review outputs, and confirm that the scope of any certificate covers the service you buy.

Coordinated EU supply chain risk assessments

Article 22 allows the Cooperation Group, the Commission and ENISA to run coordinated security risk assessments of critical ICT supply chains, and in-scope entities must take their results into account. Before approving a supplier, check whether any coordinated assessment covers its product category, country of origin or dependency. Record the assessment you consulted, the date you checked and the mitigation you chose. Where no assessment exists for a supplier, document that check so the gap is visible to your management body.

Independent evidence and its limits

Treat supplier certificates and attestations as inputs that support, but do not replace, your own review. An ISO 27001 certificate or a SOC 2 report shows that an audit took place against a defined scope and period, not that the supplier meets every NIS2 requirement. ENISA's mapping does not measure equivalence. Ask which controls the report covers, which it excludes, the period it tests, and which findings were raised, then decide what remains for your own assessment or contract clauses.

Which selection criteria the implementing regulation expects

Implementing Regulation (EU) 2024/2690 expects an entity to select suppliers against four criteria, set out in point 5.1.2 of its Annex: the supplier's cybersecurity practices, its ability to meet the entity's security specifications, the quality and resilience of its products, and its ability to help the entity diversify supply and limit vendor lock-in. These criteria are not a checklist to be ticked once. They must be written into a supply chain security policy, and the entity must be able to show that it applies them the same way to every supplier in scope, so that a supervisor can compare a selection decision for one provider with another.

In practice, the cybersecurity practices criterion means asking how a supplier develops and maintains its products, how it handles vulnerabilities and what evidence it can produce. The specification criterion means translating your own security requirements into terms the supplier can accept or reject before signature. The product quality and resilience criterion asks whether the supplier can keep its service running and patched over the period you depend on it. The lock-in criterion is often neglected: record, for each critical supplier, whether you could move to an alternative and what that would take. Each finding should be written down in the selection file, with the person who made the decision and the date.

Confirm applicability before you build the policy around these criteria. The Annex binds specific service provider types, including DNS, TLD, cloud, data center, CDN, managed and managed security service providers, online platforms and trust service providers. Entities outside those types should not assume the Annex applies to them directly, and should ask their national competent authority how it expects the same criteria to be documented. The ENISA technical implementation guidance gives examples of evidence that can help frame that conversation.

How the supplier assessment runs from inventory to decision

The sequence turns a loose list of vendors into a documented decision for each supplier, with the registry, evidence file and contract terms that a supervisor or auditor can follow back from any single supplier relationship. It is built around the supplier criteria in Implementing Regulation (EU) 2024/2690, so each step produces an artifact you can show.

Build the supplier inventory
Start by listing every direct supplier and service provider that touches your network and information systems, including managed service providers, cloud and hosting providers, software vendors, open-source maintainers you pay for support, and hardware suppliers. Record a contact point and the ICT products, services and processes each one provides. The output is the first version of your supplier registry, owned by a named person in the organization. You know the step is done when every system in your asset inventory maps to at least one registry entry and nobody can name a critical service without an owner.
Classify suppliers by criticality
Rank each registry entry by how much harm a failure, breach or loss of that supplier would cause to your essential or important services. Consider access to sensitive data, privileged access to systems, dependence for recovery, and whether the service is hard to replace. Assign a criticality tier and record the reasoning in one sentence per supplier. The output is a tiered registry that tells you how deep each later step must go. Confirm the tiering method with your risk owners so that it matches the risk assessment you already run under Article 21.
Collect evidence and questionnaires
For each supplier in the higher tiers, send a structured questionnaire and request supporting documents such as policies, certifications, penetration test summaries, and SLA reports. Ask for dated evidence and for the scope of any certificate, because a certificate covers only the scope it names. Compare answers against your own minimum requirements and log gaps as open items with owners. The output is an evidence file per supplier. You know this step is done when every question has an answer, a source document, or a recorded reason it was not provided.
Review secure development and vulnerability handling
Assess how the supplier builds and maintains what it delivers. Look at its secure development practices, how it tracks vulnerabilities in its own products and third-party components, how quickly it issues security updates, and whether it publishes information on hardware and software components. Article 21(3) asks you to weigh the quality of suppliers' products and cybersecurity practices, including secure development, so this review must be explicit. The output is a short technical assessment with a finding for each area. Where evidence is thin, record it as a risk rather than assuming good practice.
Assess diversification and lock-in
Check how dependent your organization would be on this supplier and whether you could move the service elsewhere. Review whether the supplier's products use proprietary formats or interfaces, whether data can be exported in usable form, and whether a second source exists for critical functions. Implementing Regulation (EU) 2024/2690 expects supplier selection to consider the ability to diversify supply and limit vendor lock-in. The output is a documented lock-in and diversification rating, with a note on the exit path for each critical supplier.
Record the risk decision
Bring the evidence, technical findings and lock-in rating together in a decision record for each supplier. State whether you approve, approve with conditions, or reject the supplier, name the accountable manager, and list the conditions and the reassessment trigger. Keep the record with the registry entry so the chain from inventory to decision is traceable. Management oversight of these decisions is part of the Article 20 duties of the management body. The output is a signed-off decision record per supplier. You know the step is done when every registry entry in the higher tiers has one.
Sign the contract with the security terms
Turn the decision conditions into contract clauses before signature. Typical terms cover security requirements, incident notification, audit rights or independent reports, vulnerability handling, subcontracting, exit assistance, and time-limited remote access. Check that the clauses match the findings in your decision record. The output is a signed contract and a clause checklist filed with the decision record. Confirm with counsel which clauses your national transposition law requires, because the details vary by Member State.
Monitor and reassess on a schedule
After signature, track the supplier's SLA reports, review supplier-related incidents, and reassess the supplier at planned intervals and whenever a significant change or incident occurs. The implementing regulation requires these monitoring duties for the entity types it covers. Update the registry and decision record each time you reassess. The output is a dated monitoring log and a reassessment history. You know the monitoring works when each reassessment produces a new decision or a documented reason to keep the existing one.

What the supplier registry must hold and who maintains it

This table sets out the fields an entity's supplier registry should hold, drawn from the Implementing Regulation's requirement for direct suppliers and service providers, with the internal fields most teams add to make reassessment workable. Read the first two rows as the required content and the rest as the working fields that let the management body and supervisors see who owns each relationship and when it was last reviewed. The main takeaway is that the entity owns this register even when a partner builds or maintains the spreadsheet or tool.

Registry field	What it holds	Who maintains it
Contact points	Named contacts at each direct supplier and service provider, including a security or incident contact	Entity procurement or security team, updated by the supplier
ICT products, services and processes	What each supplier provides to the entity, such as hosting, managed detection, software or support processes	Entity service owner, confirmed with the supplier
Internal owner	The named person inside the entity accountable for each supplier relationship	Entity management, reviewed when roles change
Criticality tier	The entity's rating of how much the supplier's failure or compromise would affect its services	Entity risk function, set from the supplier impact assessment
Date of last reassessment	When the supplier's security practices, SLA reports and incidents were last reviewed	Internal owner, recorded after each review
Next planned reassessment	The interval-based review date, plus triggers such as significant changes or supplier incidents	Entity risk function, driven by the tier
Supplier incident and SLA review log	Supplier-related incidents and SLA reports reviewed, with the outcome of each review	Internal owner, with evidence attached
Partner-built components	Where a partner set up the registry, the configuration, data sources and access controls	Partner builds it, entity owns and approves it

Monitoring and reassessing suppliers after onboarding

Monitoring is the routine work that tells you whether a supplier is still meeting the expectations you set at onboarding. The implementing regulation requires covered entities to monitor supplier service level agreement reports and to review supplier-related incidents (Annex, points 5.1.6 and 5.1.7). Monitoring therefore needs a defined input, a named owner and a record of what was decided.

Collect SLA reports on a fixed schedule: Agree in the contract which reports the supplier delivers, how often, and in what format, then check that each report arrives and matches the agreed metrics.
Review supplier incident records: Ask for the supplier's incident log for your services, including detection times, root causes and corrective actions, and compare it with the notifications you received.
Track vulnerability and patch performance: For products and managed services, record how quickly the supplier fixes known vulnerabilities that affect your environment.
Log exceptions and open actions: Keep a register of missed SLAs, late reports and unresolved findings, with an owner and a due date for each.
Connect findings to the supplier registry: Update the contact points and the list of ICT products, services and processes each supplier provides when monitoring reveals a change.

Check that someone in your organization reads these reports, because a report that nobody reviews does not show that monitoring happened.

How coordinated EU supply chain risk assessments feed your review

Entities must take the results of EU coordinated supply chain risk assessments into account when they review their suppliers. Under Article 22, the Cooperation Group, the Commission and ENISA may run coordinated security risk assessments of critical ICT supply chains. Article 21(3) then requires in-scope entities to factor those results into their supplier decisions, alongside each direct supplier's specific vulnerabilities and the quality of its products and secure development practices. The Directive does not say how a given assessment changes a given contract, so the practical task is to build a step that records which assessments exist, which of your suppliers or product categories they touch, and what you decided as a result.

Start by keeping a current list of the coordinated assessments that cover the ICT products, cloud services or managed services in your supplier registry. Check the outputs your national competent authority publishes, since they show how the findings apply in your Member State. For each relevant finding, record the supplier or component affected, the risk identified, the mitigation you chose (for example, a stronger contract clause, a limit on privileged access, or a plan to move to an alternative vendor), and the date of review. A supervisor will look for this trail, not for a general statement that you monitor the EU landscape.

A proposal of 20 January 2026 would extend this approach. The Commission's revised Cybersecurity Act proposal sets out a framework to identify and mitigate ICT supply chain risks from third-country suppliers across the 18 critical sectors. It is a proposal only, and it has not been adopted by the European Parliament or the Council, so do not treat it as an obligation today. Confirm its status with your national authority and the Commission before you rely on it, and note that any future measure would add to, not replace, the Article 21(3) duty you already carry.

Where supplier assessments stall or fail a supervisor review

Supplier assessments tend to fail at the same handful of points: an incomplete registry, questionnaires that go unanswered, certificates taken at face value, untested exit options, no trigger for reassessment, and no management sign-off. Each card below names one of these gaps and the check that closes it before a supervisor asks.

No complete supplier registry

Implementing Regulation 2024/2690 expects a registry of direct suppliers and service providers, with contact points and the ICT products, services and processes each one provides. Many entities keep procurement lists that omit small SaaS tools, managed services bought by business units, or open-source support contracts. Reconcile the registry against accounts payable, cloud billing and contract repositories, and assign an owner to each row. Confirm that every entry names what the supplier actually touches.

Questionnaires without follow-up

A returned questionnaire is evidence of a request, not of an assessment. Supervisors look for answers that were challenged, compared against the supplier's risk profile and tied to a decision. Flag answers that are blank, generic or contradicted by other documents, and record the follow-up request and its outcome. Keep the reviewer's conclusion next to the questionnaire so the file shows what was accepted and why.

Certificates accepted without scope review

A certificate proves that a specific scope passed a specific assessment on a specific date. It does not prove that the product or service you buy falls inside that scope. Check the certified boundary, the standard version, the assessment period and any exclusions, then compare them with the services and locations you use. ENISA's mapping of the Implementing Regulation to ISO/IEC 27001:2022 does not measure equivalence, so treat any certificate as one input among several.

Missing lock-in and exit analysis

Article 21(3) and the supplier criteria in the Implementing Regulation ask entities to weigh the ability to diversify supply and limit vendor lock-in. Assessments that score security alone leave no record of how the entity would move data, identities or operations if the supplier failed or was sanctioned. Document the exit path, the data return format, the dependency on proprietary components and any alternative supplier. Test at least one exit scenario on paper before the contract is signed.

No triggered reassessment after incidents

The Implementing Regulation requires entities to reassess suppliers at planned intervals and after significant changes or incidents, and to review supplier-related incidents and SLA reports. Many programs run an annual questionnaire and nothing else. Define triggers in the supplier procedure: a reported breach, a change of ownership or hosting location, a new subprocessor, a missed SLA, or a critical vulnerability in a product you depend on. Log each trigger, the reassessment performed and the date it closed.

Assessments management never approves

Article 20 places approval and oversight of the risk-management measures with the management body. When supplier decisions for critical or high-impact suppliers never reach the board or an accountable executive, the file shows delegated activity with no owner for the residual risk. Set a threshold for which supplier results go to management, record the approval with the risks accepted, and schedule the review of those accepted risks. Keep the minutes or sign-off as part of the evidence set.

Who owns the supplier decision, who prepares the evidence, and who assesses

The entity's management body keeps the supplier decision. Under NIS2 the management body approves and oversees the Article 21 measures, so it must be able to show who was assessed, what was weighed and why a supplier was accepted, kept or exited. Compliance and security leads run the program day to day and answer for its records.

Supplier selection criteria: Approve the supplier policy and the criteria covering cybersecurity practices, ability to meet security specifications, product quality and resilience, and the ability to diversify supply and limit vendor lock-in.
Registry ownership: Maintain the registry of direct suppliers and service providers, with contact points and the ICT products, services and processes each provides.
Risk decisions: Record which supplier risks are accepted, mitigated or grounds for exit, and who signed off.
Reassessment triggers: Set when suppliers are reviewed, including after significant changes or incidents.
Management competence: Confirm that the people approving these decisions have the training their role requires.

Before the first assessment cycle, check that a named individual can explain the criteria and the registry without referring to a consultant.

Questions buyers ask about NIS2 supplier assessments

Does NIS2 require suppliers to hold a certificate?

No. NIS2 does not create a certificate of compliance, and no supplier certificate is required by the Directive itself. Entities must take into account each direct supplier's specific vulnerabilities, the overall quality of its products and cybersecurity practices, including secure development, and the results of relevant EU coordinated supply chain risk assessments. A certificate such as ISO/IEC 27001 is one piece of evidence you can weigh, but ENISA's mapping of Implementing Regulation (EU) 2024/2690 to ISO/IEC 27001:2022 does not measure equivalence, so a certificate does not by itself show that a supplier meets your NIS2 obligations. Certificates also cover a defined scope at a point in time. Check which services and sites the certificate covers, when it was issued, and whether the auditor was independent. Confirm with your national competent authority how it expects supplier evidence to be presented.

Is a supplier registry mandatory under NIS2, and what should it contain?

Yes, under the technical requirements of Implementing Regulation (EU) 2024/2690, in-scope entities covered by that regulation must keep a registry of direct suppliers and service providers. The registry should record a contact point for each supplier and the ICT products, services and processes that supplier provides to you. In practice, most teams add the data classification the supplier touches, the criticality rating, the date of the last assessment, the contract owner and the status of open supplier-related incidents. Keep the registry current, because it drives monitoring and reassessment. Confirm with your national authority which entity types and supervision regime apply to you, since the obligations depend on your classification.

How should we scale supplier assessment effort by criticality?

Scale effort to the harm a supplier failure would cause to your network and information systems, not to the size of the contract. Start by classifying each direct supplier by the systems, data and services it can reach, whether it has privileged or remote access, and whether you could replace it quickly. Suppliers with privileged access or a role in monitoring, backups or incident handling need deeper review, including evidence of secure development, vulnerability handling and SLA reporting. Low-impact suppliers may need only a short questionnaire and a periodic check. The implementing regulation also expects you to reassess suppliers at planned intervals and after significant changes or incidents, so set the interval per tier and write the triggers down.

Can our in-house team run supplier assessments alone?

Often yes for low-criticality suppliers, if the team has security, contract and procurement skills and clear criteria. Assessing critical suppliers usually needs more: reviewing evidence of secure development, validating how products are tested against your security specifications, checking component information and lifetime security update commitments, and interpreting supplier SLA reports. Many organizations assign these tasks to a small internal owner and bring in outside help for specialist reviews or for building the criteria and registry. Whatever the split, your management body remains accountable for the decisions, and the assessment record must show who reviewed what and why. An implementation partner can prepare the templates, workflows and evidence, but the organization owns the decision.

What drives the cost and effort of supplier assessments?

The main drivers are the number of direct suppliers, how many are critical, how much evidence each one can provide, and how often you reassess. Costs have two parts. One-time costs cover setting criteria, building the registry, designing questionnaires and mapping suppliers to systems. Recurring costs cover monitoring SLA reports, reviewing incidents, running reassessments and updating the registry after changes. Internal staff time is usually the largest share. External costs depend on whether you buy specialist review, testing of supplier-provided systems or advisory support. When requesting a quote, ask for the scope in writing: the supplier list, the tiers, the deliverables (criteria, registry, templates, reports), the reassessment cadence and what is excluded. Ask the provider to separate one-time work from ongoing support.

Can a consultant take over the supplier decision for us?

A consultant can prepare the work, but cannot take over the decision or the accountability. Under NIS2, the management body approves and oversees the risk-management measures, and the entity remains responsible for its supplier choices. A consultant or implementation partner can design the criteria, collect evidence, run technical reviews and document the results, which your team then reviews and approves. Be wary of any proposal that presents an outside party as the approving authority or as the source of a certificate. Only an independent auditor or certification body issues audit reports or certificates. Ask your national authority what documentation it expects to see when it inspects your supplier decisions.

How DeployOpen prepares supplier evidence for your NIS2 program

DeployOpen helps your team gather and organize the evidence that supports supplier assessments under NIS2, including the supplier registry and monitoring records. Your organization keeps ownership of supplier decisions and the management body remains accountable, while an independent auditor or assessor is the only party that issues reports or certificates.

How we scope

Agree in writing which supplier categories, services and ICT products the assessment covers.
Define the supplier registry fields, including contact points and the ICT products, services and processes each supplier provides.
Confirm which existing supplier documents, certificates and SLA reports will be reviewed as inputs.

How we build

Set up a supplier registry and assessment workflow inside your own infrastructure using self-hosted open-source tools.
Draft supplier selection criteria covering security practices, product quality, resilience and vendor lock-in limits.
Configure recurring reassessment triggers for planned intervals, significant changes and supplier-related incidents.

How we hand over

Deliver the supplier registry, assessment records and policy documents in formats your assessors can review.
Map each assessment record to the relevant NIS2 requirement so reviewers can trace evidence to obligations.
Walk your security and procurement teams through the workflow so they can run future reassessments without us.

How we support

Provide ongoing support, upgrades and documentation maintenance through a retainer when your program needs it.
Review changes to supplier risk, including outcomes of coordinated EU supply chain risk assessments, as they apply to your scope.
Confirm with your auditor or competent authority which evidence formats and retention periods they expect before final delivery.

How to assess suppliers under NIS2