NIS2 Supply Chain Audit Checklist: 35 Controls Auditors Verify — and the 7 Most Entities Fail

When a NIS2 auditor reviews your Article 21(2)(d) supply chain measures, they rarely ask whether a supplier policy exists. They ask for the evidence behind it — the register entry, the contract clause, the review log — for one named supplier, on the spot. Most entities that stumble here don’t fail because they lack a policy. They fail because roughly 71% of organizations have no visibility into their suppliers’ suppliers, and that is exactly the layer auditors have started probing.^[5]

This checklist turns Article 21(2)(d) and its implementing detail in Commission Implementing Regulation (EU) 2024/2690, Point 5, into 35 audit-checkable controls, grouped the way an auditor actually works through them: classification, contracts, monitoring, and sub-processor visibility.^[1][2] It then names the 7 controls where audits fail most often, with the evidence behind that claim.

Who This Audit Applies To — and Who Owns Each Part

Article 21(2)(d) applies to every essential and important entity in scope of NIS2 that relies on direct suppliers or service providers for ICT products, systems, or processes — in practice, nearly all of them. It is reviewed as part of an entity’s overall Article 21(2) risk-management measures, whether through self-assessment, sector supervision, or a formal review by the national competent authority.^[1]

How often this gets tested varies by member state and sector — some national competent authorities run scheduled reviews of essential entities, others sample important entities reactively after an incident or a complaint — but the control set an auditor works from doesn’t change with the trigger. The same 35 items apply whether the review is a routine supervisory visit or a post-incident investigation, which is exactly why it’s worth having the evidence ready before either happens.

The 35 controls below aren’t equally relevant to every role in your organization. Here’s who needs what:

Role	What this checklist gives them
CISO / IT Security Lead	35 controls mapped to CIR 2024/2690 Point 5, so architecture decisions leave an audit trail
Compliance Officer / Legal	The specific evidence each control requires, ready before an auditor asks
Procurement / Vendor Management	The contract-clause checklist (controls 10–18) to raise at the next supplier renewal
Board / C-Suite	The 7 highest-failure controls — where residual risk actually concentrates

The 35-Control Checklist, by Category

Each control below is written as something an auditor can verify with a yes/no answer and a piece of evidence — not a restatement of the Directive’s language. Controls 1–27 map directly to CIR 2024/2690 Point 5’s sub-requirements; controls 28–35 extend into sub-processor visibility, which sits at the edge of what the Directive’s text requires but is where audits and real incidents increasingly land.^[2][3]

A — Supplier Classification & Selection (controls 1–9)

#	Control
1	A documented, management-approved supply chain security policy exists
2	The policy states the entity’s own role in the supply chain, including where it acts as a supplier itself
3	A supplier / service-provider register is current and complete
4	The register lists a contact point and the ICT products, services, or processes each supplier provides
5	Direct suppliers are classified by criticality or risk tier
6	Selection criteria assess supplier secure-development procedures
7	Selection criteria assess the supplier’s ability to meet the entity’s specified security requirements
8	Selection criteria assess the quality and resilience of the ICT products or services offered
9	Selection criteria assess supply-source diversification and vendor lock-in exposure

B — Contractual Security Clauses (controls 10–18)

#	Control
10	Contracts specify cybersecurity requirements aligned to the entity’s own Article 21(2) measures
11	Contracts require supplier staff awareness, training, and relevant certifications
12	Contracts require background verification for supplier staff with system access
13	Contracts obligate the supplier to notify incidents without undue delay
14	Contracts grant the entity audit rights over the supplier
15	Contracts specify vulnerability-handling and disclosure obligations
16	Contracts permit subcontracting only where equivalent security standards flow down
17	Contracts specify data retrieval and disposal obligations at termination
18	Active contracts use current clause wording — not inherited pre-NIS2 templates

C — Ongoing Monitoring & Review (controls 19–27)

#	Control
19	A policy review cadence is documented and followed at planned intervals
20	Ad-hoc review is triggered by significant operational or risk changes
21	Ad-hoc review is triggered by significant supplier-related incidents
22	SLA compliance reports are collected from suppliers on schedule
23	Incident reviews are conducted for supplier-caused incidents
24	A documented process exists for deciding when an unscheduled review is warranted
25	The risk register is updated when supplier-related risk changes are identified
26	Article 22(1) coordinated risk-assessment findings, where published for the sector, feed into supplier decisions
27	Monitoring evidence shows continuous oversight, not a one-time onboarding check

D — Sub-Processor Visibility & Incident Flow-Down (controls 28–35)

#	Control
28	The register captures whether each direct supplier uses subcontractors for in-scope services
29	Contracts require suppliers to disclose material subcontractors before use
30	Contracts require the same security clauses to flow down to named subcontractors
31	Sub-processor changes are shown to have been reviewed, not just logged
32	Incident notification obligations explicitly extend to incidents originating at a sub-processor
33	At least one traced cascade scenario — sub-processor incident through to entity notification — is documented
34	Concentration risk is assessed where multiple suppliers depend on the same fourth party
35	A fourth-party register, or equivalent tracking, exists for the entity’s most critical direct suppliers

The 7 Controls That Fail Most NIS2 Supply Chain Audits

Sub-processor cascade evidence (control 33) fails first, and it fails hardest. A single vendor breach now produces an average of 5.28 downstream victims — the highest figure on record — and an estimated 26,000 companies were pulled into 2026 breach cascades without ever being named in a public disclosure.^[6] If your entity can’t trace one hypothetical incident from a named sub-processor through to your own Article 23 notification timeline, you have no evidence this control works — only a policy that says it should.

Fourth-party visibility (control 35) is close behind. Only around 29% of organizations report having visibility into the Nth parties that touch their sensitive data — meaning roughly seven in ten cannot answer a basic auditor question about who their critical suppliers depend on.^[5] The BSI, Germany’s national cybersecurity authority, explicitly flags this as a gap: its NIS2 supply-chain guidance calls for monitoring supplier cybersecurity practices “beyond immediate suppliers,” not just the entity directly under contract.^[4]

Subcontractor disclosure (control 29) is a related, quieter failure. Only 36% of organizations say they’re notified when a third party shares their information with an Nth party they have no direct relationship with — which means most entities learn about a material subcontractor only after something has already gone wrong with it.^[5]

Contract clause completeness (control 18) fails less dramatically but just as often. Entities that signed supplier agreements before 2022 frequently carry clause language written for GDPR data-processing obligations, not NIS2’s incident-notification, audit-rights, and subcontracting requirements under CIR 2024/2690 Point 5.1.4 — and nobody revisited the wording at renewal.^[2]

Continuous monitoring (control 27) is a documented industry-wide gap, not just a NIS2 one: only 14% of procurement professionals and 13% of supplier-management professionals report using continuous monitoring tools after a supplier is onboarded.^[5] Most organizations do their diligence once, at signature, and call it done.

Incident-notification flow-down (control 32) matters because of where breaches actually originate: 38% of organizations that suffered a third-party breach attribute it to an Nth party, and 12.7% of third-party breaches cascade into a fourth-party incident.^[5] If your incident-notification clause only covers your direct supplier’s own systems, it misses the source of more than a third of the incidents that will actually reach you.

The unscheduled-review trigger (control 24) is the one we see missing most often in practice when reviewing audit findings alongside compliance officers — not because entities disagree it should exist, but because nobody assigned ownership for deciding when a “significant change” has actually happened. A policy that says reviews happen “when warranted” without naming who decides, and against what threshold, tends to mean reviews happen never.

Gap Analysis: From “We Have a Policy” to “We Can Prove It”

The honest version of most Article 21(2)(d) programs sits somewhere between fully documented and fully aspirational. This maps the gap to the effort required to close it.

Current state	Audit-ready state	Effort
Supplier register has no subcontractor field	Add a subcontractor-use column; populate it for top-tier suppliers first	Low
One generic contract clause set for every supplier	Segment clauses by criticality tier; update at next renewal cycle	Medium
Reviews only happen at onboarding	Add a calendar-triggered cadence, plus named ad-hoc triggers	Medium
No visibility past direct suppliers	Request a subcontractor list from your 10 most critical suppliers this quarter	Low–Medium
Incident clauses silent on sub-processor origin	Add an explicit clause plus an internal escalation path to Article 23 timelines	Medium
No documented cascade scenario	Run one tabletop exercise tracing a hypothetical sub-processor incident end to end	Low

Building the Evidence Trail Auditors Actually Request

An auditor rarely wants to read your policy document in full. They want to sample it against evidence. Building this once and keeping it current is far cheaper than reconstructing it under time pressure after an auditor’s request lands with a two-week deadline. Before a review, have these ready:

• Signed, dated supply chain security policy (control 1)
• Current supplier register export, with contact points and product/service listings (controls 3–4, 28)
• Sample contracts showing controls 10–17 language for at least one supplier per criticality tier
• SLA compliance reports covering the last 12 months (control 22)
• A review log with dates and the trigger for each entry — planned or ad-hoc (controls 19–21, 24)
• Incident register entries showing supplier-origin, and where applicable sub-processor-origin, incidents alongside your Article 23 notification records (controls 23, 32)
• Any Article 22(1) sector risk-assessment reference used in a supplier decision (control 26)

Frequently Asked Questions

Does Article 21(2)(d) require me to audit my suppliers’ suppliers directly?
No. The Directive’s operative text is scoped to “direct suppliers or service providers.”^[1] What CIR 2024/2690 Point 5 does require is that your risk assessment and monitoring reflect realistic risk — and auditors increasingly treat total sub-processor blindness as evidence the underlying risk assessment itself is incomplete, which is why controls 28–35 above are framed as good practice rather than a literal legal mandate.

How many of the 35 controls do I need to pass to be “compliant”?
NIS2 doesn’t score compliance as a pass rate out of 35 — it’s a risk-based obligation covering all of Article 21(2)’s measures, of which supply chain security is one.^[1] Auditors use a checklist like this to sample evidence, not to issue a numeric grade. Treat every failing control as a genuine gap in your supply chain security program, not a rounding error.

What happens if an auditor finds a gap in one of these controls?
Consequences depend on the national competent authority’s process and the severity of the gap — ranging from a corrective-action deadline to, in serious or repeated cases, the penalty regime for essential and important entities. This article provides general information only and does not predict how a specific finding will be treated in your jurisdiction.

Should smaller suppliers get the same 35 controls as large, critical ones?
No — CIR 2024/2690’s own selection criteria call for weighing “the vulnerabilities specific to each direct supplier,” not applying one uniform bar to every relationship.^[1][2] In practice, that means the full 35-control set is most defensible for your highest-criticality suppliers (control 5’s classification), while a lower-risk vendor supplying a non-critical, low-access service can reasonably carry a lighter version of controls 10–18 and 28–35. What auditors object to isn’t proportionality — it’s the absence of any documented criteria for why one supplier gets less scrutiny than another.

Key Takeaway

The pattern across the 7 highest-failure controls is consistent: entities document what they can see and stop at the edge of the contract they signed. Auditors — and increasingly, attackers — don’t stop there. If you can already produce evidence for controls 1 through 27, the fastest way to close the remaining gap isn’t a longer policy document. It’s picking your five most critical direct suppliers and running controls 28 through 35 against just those five this quarter. That’s enough to turn “we don’t know” into a documented answer for the suppliers that matter most — which is exactly what an audit is trying to verify.

Sources

• NIS2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
• Commission Implementing Regulation (EU) 2024/2690, Annex Point 5 — EUR-Lex
• Advisera, CIR 2024/2690 Annex 1 technical requirements — advisera.com
• BSI (Bundesamt für Sicherheit in der Informationstechnik), NIS2 supply chain guidance — bsi.bund.de
• Secureframe, Third-Party Risk Statistics 2026 — secureframe.com
• Black Kite, 2026 Third-Party Breach Report — blackkite.com

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.