NIS2 Supplier Registry — Supply Chain Security for SMEs | Practical Guide • Meteora Web Agency

Have you ever considered what would happen if your invoicing software provider got hacked? Or if a third-party plugin in your e‑commerce site introduced a backdoor? We at Meteora Web have seen clients come to us with infected websites exactly because of that: a third-party component not updated, a supplier without controls. NIS2 understands this and introduces a specific requirement: the supplier registry for supply chain security. It's not red tape for its own sake — it's about protecting your revenue and business continuity.

This guide shows you how to align without going crazy, starting from your company's concrete problem. No abstract theory — just what you need to secure the digital supply chain.

What is the supplier registry in NIS2?

The supplier registry is a structured inventory of all third parties that provide goods, services, or software essential to your operations. The NIS2 directive (transposed into Italian law via Legislative Decree 138/2024, effective from 2025) requires companies considered “essential entities” or “important entities” to map, assess, and monitor risks in the digital supply chain.

A simple list of names and addresses is not enough. The registry must contain, for each supplier:

Service category (cloud, software, connectivity, maintenance, etc.)
Criticality: impact on essential service if the supplier is compromised
Security certifications held (ISO 27001, SOC 2, Cyber Essentials)
Date of last risk assessment
Cybersecurity contractual clauses and audit rights
Status of periodic checks (penetration test reports, vulnerability scans)

We treat it as a balance sheet asset: an insecure supplier is a hidden cost. We learned this managing the ERP of a clothing store — a faulty inventory module froze entire seasons. Here the damage can be much worse.

Which suppliers must be included in the registry?

Not all suppliers need to be included. NIS2 refers to “contractual relationships” that can affect the security of essential services. In practice, you should include:

Cloud service providers (AWS, Azure, Google Cloud, or even small hosting providers)
Critical software vendors (ERP, CRM, payment systems, e‑commerce platforms)
Connectivity providers (ISP, CDN, DNS)
IT subcontractors (external developers, maintenance staff, consultants with system access)
Hardware suppliers with updatable firmware (routers, firewalls, servers)
Any integration partners handling sensitive data.

Typical exclusion: stationery suppliers or cleaning services, unless they have physical access to your IT premises. In that case, assess them.

A good rule of thumb: if the supplier has access to data, logs, servers, or networks, include it. If it could cause an interruption of an essential service, include it.

How to assess a supplier's risk?

Risk assessment is not a university exam — it's a practical process. We break it down into three phases:

1. Impact classification

Assign each supplier a level (Low, Medium, High) based on:

How critical a service interruption would be to your continuity
What data it processes (personal data, trade secrets, payments)
How exposed it is to threats (public cloud vs on‑premises, supplier size)

2. Objective information gathering

Don't ask the supplier “how secure are you?”. Verify:

Security certifications (ISO 27001, SOC 2 Type II)
Recent penetration test reports (no older than 12 months)
Bug bounty program or vulnerability disclosure policy
Mean time to respond to incidents (MTTR)
Presence in GDPR processing register (if it handles EU data)

One concrete action you can take right now: check your suppliers' TLS certificates with a simple command. If they don't use HTTPS, they are already a risk.

# Check TLS version and certificate validity of a supplier
curl -vI https://supplier.com 2>&1 | grep -E 'SSL|TLS|certificate|expire'

TLS 1.2 or higher is the minimum. If they still use TLS 1.0, flag them immediately.

3. Normalised risk score

Create a scale (e.g., 1–10) by multiplying impact × likelihood. Define a threshold above which the supplier must be replaced or asked for a remediation plan.

What are the minimum contractual requirements?

The registry alone is not enough: every critical supplier must have a contract that includes cybersecurity clauses. Here's what should not be missing:

Right to audit: you can request security evidence at any time (with reasonable notice)
Incident notification obligation: the supplier must inform you within 24 hours if it suffers an attack that could affect your service
Minimum security requirements: encryption, backups, patch management, multi‑factor authentication
Subcontracting clause: the supplier cannot delegate to third parties without your approval
Business continuity plan (BCP) of the supplier to guarantee service during an incident
Consequences for non‑compliance: penalties, termination rights, removal from registry

We have inserted these clauses in contracts for our clients with software houses and cloud providers. In one case, the right to audit revealed that a hosting provider had not made backups in six months. We replaced them before it was too late.

How to manage the registry in practice?

A paper or Excel registry is fine to start, but if you are a NIS2 entity you must demonstrate a process that is updatable and traceable.

Recommended tools

A spreadsheet (Google Sheets or Excel) shared with the IT and compliance team: columns for supplier, service, criticality, assessment date, next audit.
A ticketing system (Jira, Trello) to manage review deadlines.
A simple database (SQLite, Airtable) for queries and reports.

Here is an example JSON structure for an automatable registry:

[
  {
    "supplier": "CloudHost SPA",
    "service": "VPS Hosting",
    "criticality": "High",
    "certifications": ["ISO 27001", "SOC 2"],
    "last_assessment": "2025-06-01",
    "next_assessment": "2026-06-01",
    "outcome": "Pass",
    "notes": "Annual pen test required — received 2024 report OK"
  }
]

You can use this JSON to feed a small internal tool or a WordPress plugin (we have developed a custom module for a client using Laravel).

Review frequency

Suppliers classified “High” must be assessed at least every 12 months. “Medium” every 18 months. “Low” every 24 months. And always after a known security incident at the supplier.

A common mistake: forgetting to update the registry after a supplier change. We recommend tying the registry to your procurement process — when you purchase a new service, the acquisition form includes a field “supplier ID in registry”. If it doesn't exist, the supply is not activated.

What to do next

You don't have to implement everything in one week. Follow these 5 actions in order:

Map critical suppliers — list all who have access to data, logs, servers, or networks. Do it with your IT and commercial teams.
Classify each supplier by impact (High, Medium, Low) using the table above.
Collect security evidence for every High supplier: certifications, reports, policies. Use the curl command for a quick TLS check.
Insert contractual clauses — request right to audit, incident notification, MFA. If the supplier refuses, look for an alternative.
Document and schedule periodic reviews in your calendar. Set the next date for each supplier.

If you want to go deeper on applying NIS2 to your entire company, read our NIS2 pillar guide — covering scope, penalties, and a complete roadmap (Italian version, English soon).

We at Meteora Web help SMEs secure their supply chain with concrete tools, without selling snake oil. If you need help setting up the registry or conducting an audit of your suppliers, get in touch. Digital security is like accounting: if you don't keep it in order, sooner or later the fine comes — or worse, the damage.