Guide · 11 min read
NIS2 supply chain security: what Article 21(2)(d) actually requires
Your own defences can be flawless and still be beside the point if the supplier with a VPN tunnel into your network is breached on a quiet Tuesday. That is the gap NIS2 Article 21(2)(d) closes: it makes you accountable for the cyber risk your suppliers carry, not only the risk inside your own walls. The transposition deadline of 17 October 2024 has passed, Member States are finishing their national laws at different speeds, and the first enforcement actions have begun. This is the practical version of the rule: who is covered, what the article asks for in concrete terms, and how to produce evidence an auditor will actually accept.
Key takeaways
- Article 21(2)(d) makes your suppliers' cyber risk your problem, and managing it your responsibility.
- A questionnaire answered once a year describes a single day. A supplier can be ransomed, breached, or left exposed by a critical vulnerability the day after they hit submit.
- When the regulator asks, the answer is documents: who you monitor, what you found, what you did, and what you knowingly accepted, each with a date.
Who has to do this?
NIS2 sorts the organisations it covers into two tiers, by sector and by size. The duty to manage supplier risk is identical for both. What differs is how closely you are supervised and how large the penalties can grow.
Essential entities
Energy, transport, banking and financial market infrastructure, health, drinking and waste water, digital infrastructure, B2B ICT service management, public administration, and space. Supervised proactively: audits and information requests can arrive without any incident.
Important entities
Postal and courier services, waste management, chemicals, food, manufacturing of certain products (medical devices, electronics, machinery, vehicles), digital providers, and research organisations. Supervised reactively: authorities step in when there is reason to.
As a rule the threshold begins at 50 staff, or €10 million in annual turnover or balance-sheet total. Reach that inside a covered sector and you are generally in scope. Some entities are covered at any size regardless, including DNS and top-level-domain operators, trust service and public communications providers, and the sole provider of an essential service in a country.
There is a second, quieter way in. Sell a critical service to a customer who is bound by NIS2, and their obligations tend to arrive on your desk through the contract: security clauses, a questionnaire, and a standing right to ask for evidence. Many small suppliers meet NIS2 in their inbox long before any regulator writes to them.
Official source: NIS2 Directive on EUR-Lex — Article 21, with the supply-chain rationale set out in recitals 85–90.
What Article 21(2)(d) asks for, concretely
The article itself is a single line: take appropriate measures for supply chain security, including the security-related aspects of the relationship between you and your direct suppliers. Read alongside ENISA's guidance and how national authorities are applying it, that line resolves into four things you need to be able to demonstrate.
Assess a supplier before you sign
A signed questionnaire is a starting point, not an answer: it records what the supplier says about itself, not what is true. Set it against what you can verify from the outside. Has the company surfaced in breach or ransomware data? Are there unpatched, internet-facing vulnerabilities? Are the basics in place, such as a valid TLS certificate and sane email authentication? And look past the obvious front door. A supplier's exposure spans its whole external footprint: not just the domain on the contract, but the VPN gateway, the mail relays, and the forgotten staging host sitting on a different IP range.
Write the notification duty into the contract
If a supplier's incident can halt your service, you may have to report it to the authority within hours (see Article 23 below). You can only do that if the supplier tells you quickly. So the obligation has to be in writing: a defined window to notify you of a security incident, a named contact who answers, and a right to request evidence afterwards. A goodwill promise is worth nothing at two in the morning on a Saturday.
Keep watching for the life of the relationship
This is the part most programmes still get wrong, because it is a standing habit rather than a one-off task. The standard of appropriate measures is not a fixed checklist; it scales with the risk, and the risk refuses to sit still. The supplier that passed review in March can be on a ransomware leak site in April and have employee logins for sale in May. A yearly snapshot sees none of it. Continuous, in practice, means you find out in days.
Keep the evidence, and date it
Eventually someone asks you to prove the above: an auditor, a customer's security team, your own board after a close call. "We keep an eye on things" is not evidence. What counts is a dated trail of what you checked, what you found, what you fixed, and the risks you reviewed and chose to accept on purpose.
Why a yearly review is not enough
An annual supplier audit, a questionnaire and perhaps a certificate on file, is a reasonable floor. It is not continuous monitoring, and the distance between the two is exactly where incidents live. Three ordinary ways it fails:
A supplier is hit by ransomware in January. Your review was done in March and looked clean. You learn the truth in June, when a delivery quietly slips.
Employee logins from a supplier turn up in an infostealer dump. Nobody notices until those credentials are used to reach a system the supplier can touch, and through it, yours.
A supplier's TLS certificate lapses and the integration breaks. Your first alert is a customer complaint.
None of these is exotic. They are the everyday shape of supply-chain risk. The job of monitoring is not to predict them, but to notice them in days instead of reconstructing them in a post-mortem.
See how your suppliers actually score
7-day free trial · no credit card · cancel anytime
Tiering: spend attention where it counts
Watching every supplier with equal intensity is neither realistic nor expected. Sorting them by the access and impact they actually carry is both practical and squarely within the meaning of appropriate measures.
Tier 1: critical
A direct line into your systems, data, or production. These earn the full treatment: a complete questionnaire and continuous technical monitoring. Cloud and hosting providers, your ERP, managed IT or security partners.
Tier 2: important
Material to operations, but without deep access to the crown jewels. Regular technical monitoring and a lighter questionnaire are usually proportionate. HR and marketing platforms, logistics partners.
Tier 3: low risk
Little or no access to anything sensitive. A periodic review is enough. Office supplies, cleaning, catering.
Fourth-party risk: the layer behind the layer
Your exposure does not stop at the suppliers you signed. Their suppliers can reach you too. If your cloud provider depends on a single sub-processor for storage and that sub-processor is attacked, the disruption travels straight down the chain, and you never had a contract with the company that caused it.
You cannot monitor a company you have no relationship with, so the lever is the question you put to your direct supplier: do you know which of your own sub-contractors are critical, and do you hold them to the standard you are agreeing to with us? A supplier who cannot name their critical fourth parties has just told you something worth knowing.
Article 23: when a supplier's incident becomes your deadline
If a supplier incident causes significant disruption to the services you provide, the reporting clock is yours, not theirs. It starts a 24-hour early warning to your CSIRT or competent authority, then a fuller incident notification within 72 hours and a final report within one month, or a progress report at the one-month mark if you are still handling it.
The catch is the timing. The clock runs from when you become aware, not from when the supplier eventually gets round to telling you, and a disclosure that lands a week late has already burned the deadline. The only real defence is independent visibility into a critical supplier's trouble: a ransomware listing, a credential dump, a service that goes dark, without waiting for their email.
ENISA guidance: ENISA NIS2 implementation resources — on incident reporting and security measures; confirm the exact channel with your national CSIRT.
What an auditor actually wants to see
Supervisors weigh what you can show, not what you assert. The artefacts that tend to decide it:
- A supplier register: who they are, their tier, their risk classification
- Questionnaire responses: each with the date it was given
- Monitoring records: what was checked, when, and what it found
- Accepted-risk decisions: a written, owned choice for every risk you noted and decided to live with
- A response trail: what you did about findings, and by when
The quiet test is whether these already exist. A file assembled the week after the regulator calls tends to read exactly like a file assembled the week after the regulator calls.
Enforcement, and why the board is on the hook
NIS2 deliberately puts cyber risk on the management agenda. The management body has to approve the risk-management measures and oversee them, and its members can be held personally liable when that oversight fails (Art. 20). The fines are not symbolic: up to €10 million or 2% of worldwide annual turnover for essential entities, and up to €7 million or 1.4% for important ones (Art. 34); for essential entities, a supervisor can even suspend management functions until things are put right. Supply-chain risk is explicitly one of the measures leadership must oversee, which is the real reason current, documented proof of supplier monitoring belongs in the boardroom and not only in the security team's notes.
Official source: NIS2 Directive on EUR-Lex — Article 20 (governance) and Article 34 (penalties).
Where norppa.io fits
This is the work norppa.io is built to carry. Every supplier domain you add is checked across more than a hundred external controls each day, with ransomware and dark-web sources re-checked roughly every six hours and an alert the moment something critical appears. Each finding is mapped to the relevant NIS2 article as it is recorded, the report is written for management as much as for engineers, and the full history exports to CSV when an auditor asks.
The self-assessment questionnaire goes out to suppliers from the same place, and their answers sit next to the technical findings. So when a supplier states that all traffic is encrypted and the scan shows an expired certificate, the contradiction is in front of you rather than buried.