The supplier register NIS2 Article 21(2)(d) expects

NIS2 — Directive (EU) 2022/2555 — applies to medium-sized and larger entities in the sectors of Annexes I and II, and to a few kinds of entity regardless of size (Article 2). Most startups and SMEs are not in scope. Their customers often are, and Article 21(2)(d) makes those customers responsible for the security of their supply chain, “including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”. That sentence is why a small supplier receives a security questionnaire, and it is also the specification for the register a small company should keep of its own suppliers. This guide sets out what that register must hold.

What Article 21 actually requires

Article 21(1) requires essential and important entities to take “appropriate and proportionate technical, operational and organisational measures” to manage the risks to the security of their network and information systems. Article 21(2) lists ten measures the approach must “at least” include; (d) is supply-chain security. Article 21(3) adds the detail: when deciding which supply-chain measures are appropriate, entities “shall take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures”.

Three words carry the register. Each direct supplier: not the important ones, all of them. Specific vulnerabilities: per supplier, not a generic statement. Practices: what the supplier actually does, which you learn from its security page, its DPA, its certifications and its incident history. Article 20(1) puts approval and oversight of these measures on the management body, which can be held liable, so the register is a board document as much as an operational one. Article 23 sets the incident-reporting clock — early warning within 24 hours, notification within 72, final report within a month of the notification — and in a supply-chain incident the entity needs to know within hours which supplier, which service and whom to call.

The Commission’s Implementing Regulation (EU) 2024/2690, which spells Article 21 out for cloud, DNS, data-centre, managed-service and similar providers, says it plainly in section 5 of its Annex: a supply-chain security policy, and an up-to-date registry of direct suppliers and service providers with a contact point for each and a list of the products, services and processes each provides. It binds only the entities it names, but it is the most concrete statement of what a regulator means by “supplier register”, and the model a customer in any sector will recognise.

What the register must hold

One row per supplier. Legal name, country, what it does for you, whether it is in use, who owns the relationship internally. Suppliers you evaluated and did not choose stay in the register with that status; the decision is evidence too.

The services and systems each supplier is part of. The register answers “who do we depend on”; the system view answers “what depends on them”. Link them both ways, so that an incident at the e-mail provider tells you which of your services stops sending. This is the “list of products, services and processes” of the Implementing Regulation.

The documents you rely on. The DPA, the terms, the security page, the sub-processor list, the SLA, the AI policy — as read on a date, with the facts you extracted and the passages they came from. See reading a supplier’s DPA for the DPA specifically.

The supplier’s own suppliers. Article 21(3)‘s “specific vulnerabilities” include where the data sits and who else touches it. The sub-processor list, with countries, belongs here.

Security commitments and their evidence. Encryption, MFA, logging, backups, penetration testing, certifications — each with its source. “Practices” in Article 21(3) means what you can show, not what you were told at a sales meeting.

Contacts and SLA terms. The support route, the incident route, the hours, the availability commitment and the credits. In an incident these are what you need first — see SLAs for small companies.

What you asked and what they answered. Findings from your reading are questions to the supplier; the supplier’s answers, dated, close them or keep them open.

Changes. What changed in each document, when, whether it was material, who reviewed it. A register that shows only the current state cannot demonstrate that the review process runs.

The decision. Accepted, accepted with conditions, under review, replaced — by whom and when. This is the line the management body stands behind under Article 20(1).

What a customer in scope will ask you

When your customer is the NIS2 entity, the register is the answer to its questionnaire. It will ask for your sub-processors and their countries, your security measures with evidence, your incident notification window and contact route, your continuity arrangements, your development practices, and whether you assess your own suppliers. The last question is the one small companies fail: the customer’s Article 21(3) obligation reaches through you to your suppliers, and “we use reputable providers” is not an assessment. A register with the rows above answers it in a sentence and a screenshot.

What the register is not

It is not an archive of contracts; your signed agreements live in your own records, and the register holds what they say and where. It is not a compliance certificate for any supplier; a row that reads “DPA read 2026-09-24, breach window 48 hours, deletion within 30 days, sub-processors in DE and IE” states facts, and the decision to keep using the supplier is yours. And it is never finished: Article 21(2)(f) requires “policies and procedures to assess the effectiveness” of the measures, which for a register means re-reading, re-checking and re-deciding on a schedule.

How Maditon does this

The supplier register is where every Maditon account starts. You add a supplier and the addresses of its documents; Maditon fetches them, reads them, quotes the passage each fact rests on, and lists what a document of that kind owes and does not state. Suppliers link to your systems and services, and each system carries its own documents and its support note. The SLA and contacts view shows, for each supplier, what it promised and whom to call, with the document and date each value came from. Changes arrive in a daily e-mail. A PDF package puts a system with its suppliers, or the whole register, on paper for a customer, an auditor or the day you have no access at all. Every reading is a draft until a named user accepts it, and every finding is a question to the supplier, not a verdict.

See What are systems and services in Maditon? and What is in a Maditon PDF package?, or build the first row in the app.