NIS2 makes your vendors a legal obligation. Here's what Article 21 actually requires.

NIS2 replaced the original 2016 NIS Directive with a much wider net. Where NIS1 covered a handful of “operators of essential services”, NIS2 sets out eighteen sectors across two annexes — energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management, public administration and space in Annex I; postal services, waste management, chemicals, food, manufacturing, digital providers and research in Annex II — and applies a size-cap rule: medium and large organisations in those sectors are in scope by default, with smaller organisations pulled in where they are the sole provider of a service or their disruption would have a significant impact.

Entities are classed as either essential or important. The obligations are the same for both; what differs is the supervisory regime (essential entities face proactive supervision, important entities are supervised after the fact) and the ceiling on fines — up to €10 million or 2% of global annual turnover for essential entities, and up to €7 million or 1.4% for important ones.

Article 21(1) requires essential and important entities to take “appropriate and proportionate technical, operational and organisational measures” to manage the risks to their network and information systems. Article 21(2) then lists the minimum set of measures those must include — ten of them. Supply chain security is measure (d), and it is the one that most organisations have the least evidence for.

Article 21(2)(d): what “supply chain security” means in the text

Two words carry the weight. “Relationships” means the measure is about how you manage the supplier over time — not a one-off assessment at purchase. “Direct” bounds the obligation to the suppliers you actually contract with, but Article 21(3) immediately widens the lens to their suppliers too.

Article 21(3): assess each supplier specifically, and look one layer further

This is the paragraph that rules out a generic annual questionnaire. The assessment has to be specific to each supplier (“vulnerabilities specific to each direct supplier”), has to cover the quality of their security practices rather than just their paperwork, and has to consider their suppliers — the fourth-party layer most vendor programmes never map. The same paragraph also asks entities to take into account the results of the EU-coordinated risk assessments of critical supply chains under Article 22 — the mechanism that produced the 5G toolbox and is now being applied to other critical technologies.

Article 20: management bodies own it

Article 20 requires the management body — the board, or the directors — to approve the Article 21 measures, oversee their implementation, and undertake training so they can assess cybersecurity risk. Member states must ensure management bodies can be held liable for infringements. For vendor risk, that means the board needs to have seen the programme, approved the policy, and be able to show that it has oversight of the organisation’s third-party exposure — not just that a policy document exists somewhere in the compliance folder.

Article 23: the incident clock starts with your vendors too

Significant incidents must be reported to the competent authority or CSIRT with an early warning within 24 hours of becoming aware, a full incident notification within 72 hours, and a final report within a month. Nothing in Article 23 exempts incidents that arrive through a supplier. If a vendor with access to your systems is breached and it affects your services, the 24-hour clock is yours — which means you need to find out about vendor incidents fast enough to report them, not whenever the vendor gets round to telling you.

Most organisations in scope for NIS2 are also pursuing or maintaining ISO 27001, going through SOC 2 for their enterprise customers, or — in financial services — building a DORA programme. The good news is that the vendor-risk substance overlaps almost completely. The bad news is that each regime uses its own vocabulary, so it is easy to believe you have covered one and discover a gap under another. The table below maps the supply-chain obligations across the four; the ISO 27001 supplier management guide and the SOC 2 vendor management guide go deeper on each.

Article 21 tells you what to achieve, not how. The ten areas below are the structure we use in the NIS2 Vendor Risk Readiness Checklist — 35 items, each phrased as the evidence a regulator or auditor would ask for. Work through them in order: each builds on the last, and the first two are where most programmes are weakest.

1. Vendor register and inventory

You cannot manage relationships you have not listed. The register is the foundation of every other area, and it is the first thing a regulator asks for — usually in the form “show me every third party with access to your systems or data”. A complete register covers cloud providers, SaaS tools, contractors, agencies and data processors, classifies each by criticality (critical, important, standard), records what access each has, is updated as vendors are onboarded and offboarded, and retains former vendors as archived records rather than deleting them.

• A complete, current register of all active vendors and third-party service providers
• Each vendor classified by criticality — critical, important or standard
• The register updated at onboarding and offboarding, not once a year
• Access scope documented per vendor: which systems, which data, which applications
• Inactive vendors archived with their offboarding date — never deleted

2. Vendor risk assessment

Article 21(3) is explicit: the assessment has to be specific to each supplier and has to look at the quality of their security practices. In practice that means a formal assessment before onboarding for every critical and important vendor, covering cybersecurity posture, data handling, financial stability, ESG exposure and regulatory compliance; sanctions screening before onboarding and on an ongoing basis (OFAC, UN, EU, UK OFSI and Australian DFAT as the minimum set); an exposure assessment — what could this vendor reach if compromised?; proportionality, so critical vendors get the rigorous treatment and low-risk tools do not; and a timestamped, auditable record of each assessment. A verbal assessment with no record is not an assessment for NIS2 purposes.

3. Continuous monitoring

Article 21(2)(d) speaks of relationships, and 21(2)(f) requires you to assess whether your measures are effective. Together they rule out the point-in-time model. A vendor assessed once at onboarding and never again is not being managed. Monitoring means an ongoing cadence for critical vendors, alerts for material changes — sanctions listings, breach disclosures, rating movements — re-assessment when access scope, ownership or incident history changes, and evidence that all of this is happening: screening timestamps, alert records, review logs. Not a policy saying you do it.

4. Contractual protections

NIS2 expects the security-related aspects of the relationship to be governed in the contract. For critical vendors that means explicit cybersecurity obligations, a breach-notification window short enough for you to meet your own 24-hour early-warning duty, a right to audit or to receive assurance such as certifications, a current DPA where personal data is processed, and exit provisions covering data return, deletion and access revocation. It also means knowing when each contract expires — a renewal that lapses onto old terms quietly resets your protections, which is why vendor contract management is a NIS2 control rather than a finance chore.

5. Vendor onboarding

Due diligence before access, not after. A documented onboarding process that every new vendor goes through; a security questionnaire aligned to a recognised framework — ISO 27001, SOC 2 or NIS2 itself; verification of certification claims against the issuing body rather than accepting a logo on a website; access provisioned only once onboarding is complete; and records of all of it, stored where an auditor can find them.

6. Vendor offboarding

One of the most commonly failed areas in any audit, and squarely within Article 21(2)(i)’s access control and asset management. A vendor whose contract ended but whose API keys, OAuth tokens and user accounts did not is a live gap. Offboarding has to be a documented process followed every time: access revoked first, data return or deletion requested and confirmed, the offboarding recorded with a timestamp and reason, and post-termination obligations discharged before the relationship is closed. The vendor offboarding guide sets out the full sequence.

7. Incident response for third-party events

Article 21(2)(b) requires incident handling; Article 23 sets the reporting clock. Both apply to incidents that originate with a vendor. You need a defined process for responding to a third-party incident — not just your own — a way of knowing within 24 hours that a critical vendor has suffered a breach (which requires monitoring, not waiting to be told), a documented escalation path to senior management and, where required, the regulator, and at least an annual test of the process. A process that has never been exercised will fail on the day it matters.

8. Governance and management accountability

Article 20 makes this personal. There must be a named owner for vendor risk; senior management must have approved the vendor risk policy and be aware of the programme; the programme must be reviewed at least annually and updated on material change; and you must be able to demonstrate board-level awareness of third-party exposure on demand — evidence of active governance, not a signature on a policy from three years ago.

9. AI and emerging-technology risk

Not a named NIS2 measure, but a direct consequence of Article 21(3)’s “quality of products and cybersecurity practices of their suppliers”. Vendors that have added AI features may now be routing your data through model providers you never assessed or contracted with. Regulators and auditors have started asking. You should know which vendors added AI features in the last twelve months, whether that routes your data to a third-party model provider, whether your questionnaires ask, and whether contracts updated since 2023 address AI data processing.

10. Audit readiness

The test of every area above is whether you can produce the evidence immediately. When a regulator asks, “two weeks” is not an answer. On demand you should be able to produce the complete vendor register, risk-assessment records for every critical vendor with timestamps, sanctions screening history, contract status and expiry for critical vendors, evidence of ongoing monitoring, and incident-response records for any third-party event in the past 24 months.

• The register is a spreadsheet nobody owns. It was accurate the month it was built. Since then three tools were replaced, two contractors were onboarded by a team lead, and an AI note-taker was added by half the sales team. The first thing a supervisor does is compare the register to reality — and the gap is the finding.
• Assessments are generic, not supplier-specific. Every vendor got the same 40-question form, whether they host your production database or design your slide templates. Article 21(3) asks for the vulnerabilities specific to each supplier; one questionnaire for all of them evidences neither proportionality nor specificity.
• Monitoring exists as a policy, not as records. The policy says critical vendors are reviewed quarterly. When asked for the last four quarters of reviews, the organisation can produce one, undated. Under NIS2 the absence of evidence is treated as the absence of the control.
• Contracts predate the programme. The critical vendors were signed years ago, on their standard terms, with no breach-notification window, no audit right and no exit provisions. Retrofitting is possible but slow — and until it is done, the “security-related aspects of the relationship” are governed by nothing.
• Nobody can answer the fourth-party question. “Which of your critical vendors process data through the provider that was breached last week?” takes a week of reading vendors’ legal pages to answer. Article 21(3) expects you to have looked already.

You do not need a GRC team or a six-figure platform to satisfy Article 21(2)(d). You need a system that produces the evidence a supervisor will ask for, consistently and without heroics. This is the order that works for organisations building from a spreadsheet:

1. 1

   Weeks 1–2: build the register from every source

   Procurement records, cloud and SaaS subscriptions, contractor agreements, the GDPR processor register, and a sweep of who holds API credentials and production access. Classify every entry critical, important or standard. This single step moves most organisations from “high risk” to “partial” on the checklist.

2. 2

   Weeks 3–4: assess critical and important vendors

   Run supplier-specific assessments: security posture, data handled, certifications verified against the issuer, sanctions screening across the five major lists, exposure if compromised. Record the date, the outcome and who reviewed it. Standard vendors get a lighter, proportionate check.

3. 3

   Weeks 5–6: fix the contracts that matter

   For critical vendors, get breach notification, audit or assurance rights, DPAs and exit provisions in place — a security addendum is usually faster than renegotiating the whole agreement. Record every expiry and notice period so nothing lapses onto old terms.

4. 4

   Weeks 7–8: turn on monitoring and the incident path

   Set a re-screening cadence by criticality, switch on alerts for sanctions and breach events, and write down — then test — what happens when a critical vendor reports an incident, including who calls the regulator inside 24 hours.

5. 5

   Weeks 9–10: map the fourth parties

   For each critical vendor, capture their published subprocessor list — who, what for, where. You are not assessing every subprocessor; you are making the concentration and residency questions answerable.

6. 6

   Weeks 11–12: governance and the evidence pack

   Name the owner, take the policy and the programme summary to the board, minute the approval, and run a first export of the evidence pack — register, assessments, screening history, contracts, monitoring log, incident records. If that export takes more than an afternoon, that is the next thing to fix.

Vendorapp’s Readiness hub turns the 35-item NIS2 checklist into a live dashboard: 48 controls across the same ten areas, each marked in place only when your tenant’s data evidences it. The score reflects what your programme has actually done — not what the software could do — so a gap on the hub is a real gap, with a “Fix this” link to the part of the product that closes it.

1. 1

   A register that classifies itself

   Search 22M+ vendors by name or URL, set criticality, and every vendor with a contract carries a documented access scope. Offboarded vendors are archived with their date and timeline — never hard-deleted — which is exactly the record NIS2 auditors ask about.

2. 2

   Supplier-specific assessment at onboarding, on a schedule after

   Every vendor is pre-screened before a contract can exist: exposure risk, ESG risk and sanctions across OFAC, UN, EU, UK and Australian lists. Re-screening then runs automatically by criticality — critical vendors every three months, important every six, standard every twelve — and each run is timestamped in the vendor timeline.

3. 3

   Contracts with the NIS2 fields extracted

   Upload a contract and Vendorapp Intelligence extracts the expiry, notice period, breach-notification window, DPA status and data-return-on-exit terms — with 90/60/30-day reminders so nothing lapses onto old terms.

4. 4

   Incident response and drills, recorded

   The breach module records vendor incidents with severity, evidence, the 24-hour acknowledgement and escalation to senior management or the regulator. Incident drills are logged on the Readiness hub so the “tested annually” control is evidenced, not asserted.

5. 5

   Fourth parties from primary sources

   On the Expert plan, every screening also reads the vendor’s own published subprocessor register and builds an evidence-linked fourth-party list — who, what for, where — so the Article 21(3) question about your suppliers’ suppliers has an answer.

6. 6

   Governance and the evidence pack on demand

   Record the approved policy, the named owner and the annual programme review on the hub, then export the vendor register, contract register, monitoring evidence, incident register and a board summary as spreadsheets — the evidence pack a supervisor asks for, in minutes rather than weeks.