Guide · 8 min read
NIS2 Art. 21(2): supplier security checklist
A working script for procurement and security teams: for onboarding a new supplier and for the annual review alike. For each of the six supply-chain-relevant clauses of NIS2 Article 21(2): what to ask, why it matters, the evidence to request, and how to respond when the answer falls short.
Key takeaways
- Six Article 21(2) sub-clauses carry most of the supply-chain weight: here is what to ask for each, and the document that proves it.
- Half of them are technical and shift without warning, so they need continuous checking rather than a line in a yearly questionnaire.
- A gap isn't a verdict. A documented, owned remediation decision is what makes your position defensible to an auditor.
Article 21(2)(d) makes assessing your suppliers' security part of your own risk management, and it isn't a one-off. The duty covers the supplier you're about to sign and the one you've worked with for years, with an annual review as the floor, not the ceiling. The hard part is that the standard (“appropriate measures”) scales with risk and never sits still, so a clean assessment in spring can tell you very little by autumn.
What follows walks the six Article 21(2) sub-clauses that carry the most supply-chain weight. Each is set out the way it's actually useful in the room: what to ask, why it matters, and the document to request as proof. Treat it as the script for an onboarding conversation and the annual review alike, and read the technical clauses as things to verify continuously, not once.
A note on scope. This is guidance, not a legal opinion: your competent authority or auditor may expect more given your sector and size, and contractual wording is worth a lawyer's eye. The timeframes mentioned (patch windows and the like) are sensible benchmarks, not statutory NIS2 deadlines.
The six sub-clauses, in the order worth asking them:
Art. 21(2)(a)Risk management
Begin with the difference between a supplier who manages cyber risk as a standing discipline and one who scrambles once a year. A documented information security management system (ISO 27001 is the clean shorthand, though a written ISMS policy will do) shows the process exists; the more telling question is when senior management or the board last reviewed it, and whether critical systems and data have actually been inventoried and classified. Ask for the policy or certificate and note the date of that last review: a programme nobody has opened in two years is one in name only.
Art. 21(2)(b)Incident handling
If this supplier is significant enough that their breach could disrupt your service, their incident starts your Article 23 reporting clock, and you can only meet it if they tell you fast. Goodwill won't carry that; the contract has to: a defined window to notify you of a security incident, a named contact who answers around the clock, and a tested response plan behind it rather than a document nobody has rehearsed. Ask for the incident-response plan in summary, and make the 24-hour notification a written term, not a line in an email.
Art. 21(2)(d)Supply chain
Your exposure runs past the supplier you signed to the ones they depend on: fourth-party risk. A capable supplier can name the sub-contractors that touch your data or systems, holds them to security terms written into its own contracts rather than a vague nod to “industry standards”, and reassesses them at least yearly. Ask whether they can produce a sub-contractor register and describe how they vet those parties; a supplier who can't name its critical fourth parties has just told you something worth knowing.
Art. 21(2)(e)Procurement and development
Known, unpatched vulnerabilities and end-of-life software are among the most-used ways in, so the supplier should show that vulnerability management is real rather than aspirational. Reasonable benchmarks: nothing past end-of-support running in production, critical flaws (CVSS 9.0 and above) patched within roughly a month of disclosure, and anything on the CISA Known Exploited Vulnerabilities catalogue treated as an emergency. Ask for a description of the patching process and a recent vulnerability snapshot: the distance between the policy and the latest scan is usually where the truth lives.
Art. 21(2)(h)Cryptography
This is the most externally visible clause, and the one that slips most quietly. Expired or self-signed TLS certificates, sites that don't force HTTPS, and email authentication left half-configured are all common, all change without warning, and are all checkable from the outside. The bar is unglamorous: valid certificates everywhere, HTTPS enforced on every site and API, and SPF, DKIM and DMARC actually configured (hardfail, signed, at least a quarantine policy) rather than left at their defaults. Ask for the certificate-management process and a DMARC or DNS readout.
Art. 21(2)(i)/(j)Access control and authentication
Stolen credentials remain the most common way an attacker gets a foothold, so a supplier needs to show both that misuse is hard and that it would be caught quickly. In practice that means multi-factor authentication enforced on every critical system and admin account with no quiet exceptions, monitoring for leaked credentials surfacing in breach and dark-web data, and the habit of rotating any exposed login at once and writing the incident down. Ask to see the MFA enforcement policy and how credential-leak monitoring is run.
When a supplier falls short
A single gap is rarely a reason to walk away; what a supervisor (and your own board) will look for is evidence that you noticed it and made a deliberate, owned decision about it. Scale the response to how much is missing, and where.
One or two gaps: document and accept
Record them in your supplier register, ask for a remediation plan within about 90 days, and follow up at the next review. A noted, accepted risk is a defensible position; a forgotten one is not.
Three to five gaps, or any gap in incident handling: tighten the watch
Move the supplier into a higher-risk tier, ask for a written remediation plan with dates, and consider limiting their access to your most critical systems until the gaps close.
Six or more gaps, or a critical technical vulnerability: escalate
Take it to your CISO or senior management, weigh the contractual remedies you actually hold, and (if the supplier can reach production data or systems) consider suspending that access until the picture is clear.
What you can't do by hand
Several of these checks are technical, and they decay without anyone sending you a notice: a certificate expires, a credential surfaces in a leak, a supplier lands on a ransomware victim list. A questionnaire answered once a year sees none of it: which is exactly the gap between a paper review and the ongoing diligence the “appropriate measures” standard expects.
norppa.io runs the technical half of this list every day, across every supplier you add:
- Cryptography (h): TLS certificate validity and HTTPS enforcement, SPF/DKIM/DMARC configuration, DNSSEC
- Access and authentication (i): employee and customer credentials surfacing in breach and dark-web data
- Procurement and development (e): exploited-vulnerability catalogue listings and severity-scored vulnerability findings
- Incident handling (b): ransomware victim-list appearances, with an alert the moment a supplier shows up
The process-level clauses (risk management, incident handling and supply-chain governance) are what the self-assessment questionnaire is for; you can send it to a supplier straight from the portal and read their answers next to the technical findings.