NIS2 Supply Chain Policy Template: It’s Not One Document, It’s Four

A supply chain security policy that has been sitting in a compliance folder since the drafting sprint usually has one tell: it promises things three other documents were supposed to deliver. It says suppliers are “classified by criticality” with no register showing the classification. It says due diligence is “performed before onboarding” with no questionnaire on file. It says confidentiality and data protection are “addressed contractually” with no NDA or DPA anyone can produce. Reviewing policies like this is less about finding what’s wrong in the writing and more about finding what’s missing behind it — the policy reads fine on its own, right up until someone asks to see the document it’s referring to.

That’s the actual failure mode behind most NIS2 supply chain policy reviews: not bad writing, but a single document trying to do the job of four. Article 21(2)(d) of the NIS2 Directive requires a supply chain security policy specifically — but a compliant policy sits at the top of a small stack of documents, each with a different legal basis and a different job. This article is about that stack: what the policy itself must contain, what belongs in a companion document instead, and where the line between “embedded” and “referenced” actually needs to sit for a due diligence procedure to hold up under review.

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.

Does This Apply to You?

In short: if your organisation is an essential or important entity under NIS2, Article 21(2)(d) requires a written supply chain security policy regardless of sector — this isn’t limited to IT or digital-infrastructure companies.

Your role	What this article gives you
Compliance Officer	The exact list of mandatory elements the policy document must contain, and where evidence needs to live for an audit trail
CISO / IT Security Manager	The embedded-vs-referenced decision for the due diligence procedure, and how classification criteria should sit inside the policy versus the supplier register
SME Owner / Non-technical lead	A plain-language map of which of the four documents you actually need, so you’re not paying a consultant to draft four when two will do
Legal	Where the security policy’s scope should stop, and where a separate NDA or GDPR Article 28 DPA is legally required instead

One scope note before the detail: Article 21(2)(d) binds every essential and important entity, in every sector, to address supply chain security — the obligation itself doesn’t depend on your industry [1]. What does vary by sector is the level of technical prescription. Commission Implementing Regulation (EU) 2024/2690 adds more granular contractual specification for ten categories of digital-infrastructure and ICT service entities (cloud providers, DNS operators, managed service providers, and similar). If your organisation sits outside those ten categories, that regulation doesn’t bind you directly — but its level of detail is a reasonable benchmark for what “appropriate and proportionate” looks like in practice.

What Article 21(2)(d) Actually Requires From the Policy Document

In short: the Directive’s own text is short — it names the requirement, not the paperwork. Two provisions do the real work: Article 21(2)(d) creates the obligation, and Article 21(3) tells you what your risk-based reasoning inside the policy has to account for.

Article 21(2)(d) requires “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” [1]. Article 21(3) adds the reasoning standard: when deciding what’s “appropriate” under point (d), entities must take into account “the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices” of those suppliers, including their secure development procedures [1].

Neither provision specifies a document template. What they do imply, read together, is a minimum set of things the written policy has to actually say something about, not just gesture at:

• Purpose and legal basis — the policy names Article 21(2)(d) and states what it governs (relationships with direct suppliers and service providers, not the entity’s general IT security posture, which belongs in a separate information security policy)
• Classification criteria — the factors used to sort suppliers by criticality, stated in the policy even if the register itself lives elsewhere (more on this split below)
• A due diligence procedure — how supplier vulnerabilities and “overall quality of products and cybersecurity practices” get assessed before and during the relationship, per Article 21(3) [1]
• Contractual security requirements — a statement of what supplier contracts must contain, cross-referencing the separate clause document rather than restating it
• Monitoring and review triggers — what causes a supplier to be reassessed (renewal, incident, significant change in service)
• Roles and ownership — who classifies, who assesses, who signs off on exceptions
• Document control — version history and a defined review cycle

None of this replaces the deeper mechanics covered elsewhere on this site: for the full scoring methodology behind supplier classification, see our guide to classifying suppliers by criticality, and for the broader Article 21 obligation set this sits inside, see our complete Article 21 walkthrough. What follows here is the part those guides don’t cover: how the policy document itself should be structured, and which content belongs in a separate document instead.

The Four Documents Auditors Expect — Not One

In short: “the supply chain policy” is really a short stack — a security policy, a set of contractual security clauses, a confidentiality statement (NDA), and, where personal data is involved, a GDPR data processing agreement. Treating them as one document is the single most common reason a policy reads as incomplete.

These four instruments look similar because they all involve suppliers and all touch security, but they have different legal bases and different audiences, and conflating them is where policies fall apart under review:

Document	Legal basis	What it covers	Signed by supplier?
Supply Chain Security Policy	NIS2 Art. 21(2)(d) & 21(3)	Your organisation’s internal rules: classification criteria, due diligence procedure, review triggers, ownership	No — internal governing document
Supplier Security Clauses	Contract law, informed by NIS2 Art. 21(2)(d)	What the supplier is contractually bound to do — security requirements, notification obligations, audit rights	Yes — part of or attached to the commercial contract
Confidentiality Statement (NDA)	Contract law / trade secret protection	Non-disclosure of confidential information exchanged between the parties, independent of any security standard	Yes — standalone or embedded in the master agreement
Data Processing Agreement (DPA)	GDPR Article 28	Subject-matter, duration, nature and purpose of processing, data categories, and the processor’s binding obligations where the supplier handles personal data [5]	Yes — mandatory wherever a supplier processes personal data on your behalf

The distinction that trips up most drafts: a signed NDA is not a substitute for a DPA, and a DPA is not a substitute for the security clauses. An NDA protects confidential business information generally; a DPA exists because GDPR Article 28 specifically requires a written contract governing personal data processing, with defined contents the DPA has to include — subject-matter, duration, purpose, data categories, and processor obligations such as acting only on documented instructions and assisting with data-subject rights [5]. Security clauses under Article 21(2)(d) are about the supplier’s cybersecurity posture and incident behaviour, which is a different question from what happens to personal data. A supplier who never touches personal data — a hardware vendor, say — still needs security clauses and may still need an NDA, but has no reason to sign a DPA at all.

The security policy’s job, then, isn’t to restate any of the other three. It’s to say that they exist, name which suppliers need which combination based on classification, and reference where the current signed versions are filed. For the exact clause language that belongs in the contract itself — the eight categories a compliant clause set typically covers — see our dedicated vendor contract clauses guide rather than duplicating it inside the policy.

Supplier Classification: In the Policy vs. in the Register

In short: the classification criteria belong in the policy. The classification results — which supplier sits in which tier today — belong in a separate, living register, not frozen inside the policy text.

This split causes more drafting confusion than almost anything else in the document. A policy that lists actual supplier names next to tier assignments is stale within a quarter — vendors get added, contracts lapse, services change. A policy that says nothing at all about how classification works gives an auditor no way to judge whether the tiering behind the register is defensible.

The working split: the policy states the criteria (system access level, data sensitivity, service substitutability, and business-continuity impact are the four dimensions most classification frameworks use) and the number of tiers, in enough detail that someone could reproduce the scoring without asking. The register — a separate, actively maintained document — holds the actual list: which supplier, which tier, when last assessed, and what’s on file. One document defines the rule; the other applies it. If your organisation hasn’t built the scoring methodology yet, our supplier classification guide walks through a four-tier scoring matrix in full — this article assumes that methodology exists and focuses on where each half of it should live.

Due Diligence: Does Your Policy Embed the Procedure, or Just Promise an Audit?

In short: a one-line promise (“suppliers are assessed before onboarding”) is not a due diligence procedure — it’s a due diligence procedure’s absence, dressed up as a sentence. The procedure itself needs to live somewhere concrete, and the policy needs to say exactly where.

There are two defensible ways to handle this, and the wrong choice isn’t picking one — it’s picking neither. Embedded means the step-by-step assessment procedure sits inside the policy document itself: the questionnaire structure, the scoring thresholds, the escalation path for a failed assessment, spelled out in the policy’s own text. Referenced means the policy states that a due diligence procedure exists, names the separate document it lives in (a supplier self-assessment questionnaire and a compliance scoring checklist, typically), and points to it — without repeating its contents.

Both are defensible under Article 21(3)’s standard of accounting for supplier vulnerabilities and product/practice quality [1]. What isn’t defensible is a policy that neither embeds the procedure nor names where it’s referenced — which, in the drafts that come across a compliance review most often, is exactly the gap. A sentence like “due diligence is performed prior to contract award” answers nothing an auditor would actually ask next: assessed how, against what criteria, scored by whom, filed where.

BSI, Germany’s NIS2 competent authority, frames the practical bar worth drafting toward: entities should contractually bind suppliers to security measures and “also have that compliance demonstrated to them” — not merely promised [4]. That’s an evidence standard, and it applies as much to the procedure that gathers the evidence as it does to the evidence itself. If your due diligence section can’t point to a specific artifact — a questionnaire, a scoring sheet, an assessment log — the policy is describing a process that, on paper, doesn’t exist yet.

Where the Policy’s Scope Should Stop

In short: Article 21(2)(d) and 21(3) scope the entity’s own duty to direct suppliers and service providers [1]. A policy that quietly expands its own scope to cover every subcontractor, or claims to address risks the Directive handles at EU level instead, is overreaching in ways that create audit exposure rather than reduce it.

Two boundaries are worth stating explicitly in the policy rather than leaving implicit:

Direct suppliers, not the whole chain. The entity-level obligation reaches direct suppliers and service providers [1]. Coverage further down the chain — a supplier’s own subcontractors — is achieved through a flow-down obligation written into the supplier contract (requiring the direct supplier to impose equivalent terms on its subcontractors), not through a direct relationship your policy can claim to manage. A policy that states it “ensures security across the full multi-tier supply chain” is overstating what an entity-level document can actually enforce; a policy that states it governs direct suppliers, and requires direct suppliers to cascade equivalent requirements downward, matches what the Directive’s mechanism actually does.

Entity-level risk-based measures, not EU-level coordinated assessment. Recital 90 describes a separate mechanism — coordinated security risk assessments of critical supply chains carried out at EU level by the Cooperation Group, the Commission, and ENISA, looking at factors including “undue influence by a third country on suppliers and service providers” such as concealed vulnerabilities, backdoors, technological lock-in, or provider dependency [3]. As a recital, this describes an EU-level process rather than creating a binding obligation on individual entities [3]. Your policy’s due diligence procedure is the entity-level counterpart — proportionate, supplier-by-supplier — not a substitute for, or a claim to replicate, that coordinated assessment.

Reviewing policies that try to do too much, the pattern is consistent: broad, sweeping scope language reads as more thorough, but it’s the sentence most likely to be challenged, because it promises coverage the rest of the document doesn’t actually back up. A narrower, accurately scoped policy that matches its own due diligence and monitoring sections holds up better than one that claims more.

A Working Skeleton: Section-by-Section Anatomy

In short: here’s a section order that keeps the mandatory elements traceable and the scope honest, without duplicating content that belongs in the register, the clauses, or the NDA/DPA.

Section	Contents	Effort
1. Purpose & scope	Legal basis (Art. 21(2)(d)), direct-suppliers boundary, what this policy does not cover	Low
2. Roles & ownership	Who classifies, who assesses, who approves exceptions	Low
3. Classification criteria	Scoring dimensions and tier definitions (results live in the separate register)	Medium
4. Due diligence procedure	Embedded steps or a named reference to the assessment questionnaire/checklist	Medium
5. Contractual security requirements	What must be in every supplier contract, cross-referenced to the clause document	Low
6. Companion documents	Where the NDA and, where applicable, the GDPR Art. 28 DPA sit relative to this policy	Low
7. Monitoring & review triggers	Reassessment cadence, incident-triggered review, contract-renewal review	Medium
8. Document control	Version history, approval date, next scheduled review	Low

Notice what’s absent from this list: the actual scoring matrix output, the questionnaire questions, and the clause wording. Those live in their own documents and get referenced by name and location, not reproduced. A policy that tries to be self-contained by pasting in every downstream artifact usually ends up both bloated and out of sync the first time any one of those artifacts is updated. For a broader comparability check against a management-systems framework your organisation may already run, our NIS2 vs. ISO 27001 comparison covers how this document structure maps to ISO’s supplier-relationship controls.

The Drafting Mistakes That Fail a Review

Five patterns show up repeatedly in policies that get sent back for revision:

• Restating instead of referencing. Pasting full clause language or NDA text into the policy body, so the policy and the contract drift out of sync the first time either one is updated.
• Frozen classification data. Naming actual suppliers and tiers inside the policy text rather than in a maintained register — accurate on the day it’s signed, wrong within a quarter.
• An unclaimed due diligence procedure. A sentence promising assessment with no questionnaire, scoring method, or filed record behind it — the gap covered above.
• Scope creep into the full supply chain. Claiming coverage of subcontractors and sub-subcontractors directly, instead of describing the flow-down mechanism that actually reaches them.
• No document control. No version history or review date, which makes it impossible to tell whether the policy reflects the current supplier list or one from two contract cycles ago.

The clearest sign a policy was drafted in a single afternoon: it defines four supplier tiers in Section 3, then never uses the word “tier” again for the rest of the document — the classification exists in name only, disconnected from the due diligence and monitoring sections that should key off it.

Frequently Asked Questions

Do I need a separate NDA and DPA, or can one document cover both?
They can be combined into a single signed agreement in practice, but they remain legally distinct obligations — an NDA protects confidential information generally, while a DPA exists specifically to satisfy GDPR Article 28’s requirements wherever personal data is processed [5]. If a supplier never touches personal data, no DPA is needed regardless of whether an NDA is in place.

What’s the minimum a small or medium entity actually needs?
At minimum: the policy itself (with classification criteria and a named due diligence procedure), security clauses in supplier contracts, and a basic supplier register. An NDA and DPA are only needed for suppliers where confidentiality or personal data processing actually applies — not every direct supplier requires all four documents.

Does the policy need to name individual suppliers?
No — and doing so is a common mistake. Name the classification criteria and tiers in the policy; keep the actual supplier list, with current tier assignments and assessment dates, in a separate register that can be updated without revising the policy itself.

How often should the policy be reviewed?
Article 21(2)(f) requires entities to assess the effectiveness of their cybersecurity risk-management measures generally [1]; in practice, that means the supply chain policy should be reviewed on a defined cycle (annually is common), and whenever a significant incident, regulatory change, or shift in the supplier base occurs.

Sources

1. Directive (EU) 2022/2555 (NIS2), Article 21(2) and 21(3) — nis-2-directive.com
2. Directive (EU) 2022/2555 (NIS2), Official Journal L 333, 27.12.2022 — EUR-Lex
3. Directive (EU) 2022/2555 (NIS2), Recital 90 — nis-2-directive.com
4. BSI (Bundesamt für Sicherheit in der Informationstechnik) — “#nis2know: Sichere Lieferkette”, German national competent authority guidance
5. Regulation (EU) 2016/679 (GDPR), Article 28(3) — gdpr-info.eu