Guide · 12 min read
NIS2 and the supply chain requirement — what it means in practice
The NIS2 directive has reshaped cybersecurity obligations across Europe. One of the most concrete requirements concerns the supply chain: you must manage your suppliers' cyber risks, not just your own. This does not mean a questionnaire sent once a year. The transposition deadline (17 October 2024) has passed and the obligations now apply; Member States are bringing NIS2 into national law at varying speeds, and enforcement has begun.
Who does the requirement apply to?
NIS2 divides entities into two categories based on sector and size:
Essential entities
Energy, transport, banking and financial markets, healthcare, drinking water, wastewater, digital infrastructure, government ICT, and space.
Important entities
Postal and courier services, waste management, chemicals, food production, manufacturing, digital services, and research organisations.
The size threshold is generally 50 employees or €10 million in annual turnover. Companies above this threshold fall within NIS2 automatically.
Importantly, smaller companies can also become subject to requirements via contract — if you supply critical services to a NIS2-obligated customer, they will likely impose compliance requirements on you contractually.
Official source: NIS2 Directive on EUR-Lex — see recitals 80–90 and Art. 21 specifically.
What does Art. 21(2)(d) concretely require?
Article 21(2)(d) mandates measures for supply chain security and supplier relationships. Based on ENISA guidance and national supervisory authority interpretations, the requirement has four core elements:
Supplier risk assessment before contracting
Before onboarding a new supplier, you must assess their cybersecurity posture. This is not just a questionnaire — it means verifiable assessment: has this supplier experienced a breach, do they have known vulnerabilities in their infrastructure, are their certificates valid? The assessment should cover the supplier's entire internet-facing footprint — not only the main domain, but also IP addresses and infrastructure that sit outside it (e.g. VPN gateways, mail relays, dedicated hosts).
Contract clauses and incident notification obligations
Contracts must include a clause requiring suppliers to report security incidents without undue delay. Without this, you cannot fulfil your own 24-hour initial notification obligation to the supervisory authority if a supplier incident affects your services.
Continuous monitoring throughout the contract
This is where most organisations are still behind. In practice, NIS2's 'appropriate measures' standard calls for continuous monitoring — not just an annual check. A supplier's situation can change radically within a day: ransomware, a breach, a critical vulnerability. An annual assessment is unlikely to catch these in time.
Documented audit evidence
The supervisory authority can request evidence of how you have managed supplier risks. "We have been monitoring the situation" is not sufficient — you need timestamped documentation of findings, actions taken, and accepted risks.
Why annual assessments alone are insufficient
A traditional supplier audit — a questionnaire once a year, perhaps a certificate — meets the baseline intent of NIS2 but does not satisfy the continuous monitoring obligation. Consider these real-world scenarios:
Your supplier is hit by ransomware in January. Your annual review was completed in March. You find out in June when a project is delayed.
Your supplier's employee credentials are leaked to dark web markets. You are unaware until an attacker uses them to access systems to which the supplier has access.
Your supplier's TLS certificate expires and their service stops working. You discover this via customer complaints.
All three are recognisable scenarios — typical ways in which supplier risk materialises. Continuous monitoring means detecting these changes within days, not months.
Supplier tiering: how to prioritise
Not all suppliers need to be monitored at the same intensity. Risk-based tiering is both practical and consistent with the spirit of the directive:
Tier 1 — Critical suppliers
Direct access to your systems, data, or production environments. Highest monitoring level, full SAQ, continuous technical monitoring. Examples: cloud providers, ERP vendors, managed security services.
Tier 2 — Important suppliers
Significant role in operations but limited direct access to critical systems. Regular technical monitoring, lighter SAQ. Examples: HR software, marketing tools, logistics partners.
Tier 3 — Low-risk suppliers
Limited or no direct access to critical data. Annual review is sufficient. Examples: office supplies, cleaning services, catering.
Fourth-party risk — the often overlooked layer
NIS2 is not limited to your direct suppliers. Your suppliers' own suppliers can pose risk to you. If your cloud provider uses a subcontractor for data centre services, and that subcontractor suffers an attack, the impact can cascade through the entire chain.
This is why supplier assessment should include the question: does the supplier know their own critical subcontractors, and do they assess them in turn?
Art. 23: incident notification from supplier incidents
If a supplier's security incident causes significant disruption to your own services, you have a 24-hour initial notification obligation to the national supervisory authority, followed by a 72-hour full notification and a one-month final report.
The practical problem: to know about a supplier incident in time, you need real-time visibility into their status. Suppliers do not always report incidents proactively — or they do so too late. Continuous monitoring bridges this gap.
ENISA guidance: ENISA NIS2 implementation resources — guidelines on incident reporting and security measures.
What do supervisory authorities look for?
National supervisory authorities assess compliance through practical evidence, not assertions. Documents useful in an audit include:
- Supplier register with tiering and risk classification
- SAQ responses with dates
- Technical monitoring logs — what was checked, when, what was found
- Accepted risk documentation — a written decision for risks that have been noted and accepted
- Response history — how findings were acted upon, and by when
These documents must be producible on request. Documentation assembled retrospectively after an inquiry is rarely sufficient in practice.
How norppa.io helps
norppa.io is designed to address exactly these challenges. Every monitored supplier domain is checked across 100+ checkpoints daily, with critical events monitored every six hours — automatically, without manual effort. Findings are mapped to NIS2 articles automatically, the monthly PDF report is in executive-ready format, and the full history can be exported as CSV for auditors.
The self-assessment questionnaire (SAQ) is sent to suppliers directly from norppa.io, and responses combine with the technical risk profile — giving you a unified view of both the process and technical layers.