NIS2 and the Supply Chain: Why Your Vendors' Security is Now Your Problem

The questionnaire that exposes the supply chain

Anna receives the questionnaire at 9:13 a.m. The DACH B2B supplier has 54 employees, supplies industrial customers across the DACH region, and relies on an external IT service provider, a CRM, an accounting platform, a website host, several SaaS tools, and a few n8n automations. Until that email, the setup felt sensibly distributed. Now a major customer asks for supplier-security evidence: who processes customer data, which vendors have privileged access, where restore proof is stored, who receives incident notices, and which suppliers have been technically reviewed?

No single person has the full answer. Lena in procurement knows contracts and renewal dates. Markus, the technical coordinator, knows the CRM, website, automations, and backup questions. Omar, the external MSP contact, administers identity, endpoints, and several SaaS integrations. Anna ultimately has to decide which response is safe to send to the customer. The questionnaire is not the real problem. It only reveals that the digital supply chain has been living across invoices, admin panels, email threads, and personal memory.

The scenario is illustrative, but the pattern is realistic for SMEs with 10 to 100 employees. Many companies outsource sensitive digital capabilities before they build an internal operating view. One provider hosts the website, another holds backups, a SaaS tool stores about 18,000 customer records, four suppliers have privileged access, seven workflows touch customer data, and nine automations run daily. As long as nothing happens, this can feel manageable. When a customer, insurer, auditor, or incident asks, it becomes an evidence problem.

Why NIS2 turns supplier risk into operations

NIS2 is not just a new label for IT security. Directive (EU) 2022/2555 connects cybersecurity risk management with technical, operational, and organisational measures. For entities in scope, Article 21 refers to risk analysis, incident handling, business continuity, backup, crisis management, supply-chain security, secure acquisition, effectiveness checks, cyber hygiene, training, access control, and asset management. This article is not legal advice and does not decide whether your company is essential, important, or outside direct scope. It looks at the operational work created by supplier risk.

The supply-chain point matters because responsibility no longer stops at systems you operate yourself. Article 21 refers to security in relationships with direct suppliers and service providers. Germany's BSI guidance on supply-chain security frames it as part of comprehensive risk management: provider lists, processes, effectiveness checks, audits, crisis exercises, SLAs, incident handling, patch management, and traceable procedures matter more than a folder full of certificates. The BSI also cautions that standards or checks do not automatically prove fulfilment. A certificate can help. It does not replace knowing which vendor affects which workflow.

For many SMEs, the pressure does not arrive first through a regulator. It arrives through customers, parent companies, insurers, tenders, or management questions. A larger customer has to explain its own supply chain and asks the smaller supplier for evidence. A cyber insurer wants to know which service providers administer critical systems. An incident at a SaaS vendor forces management to decide whether customer data, delivery commitments, or recovery capability are affected. Legal classification remains a separate assessment. The operational question starts earlier: which suppliers could you explain tomorrow?

The five vendor risks SMEs should map first

A supplier register becomes noisy if every subscription looks equally important. A small team should first map the risks that most often trigger NIS2, customer, and incident questions. The first category is data processing. Which vendors store, transfer, or analyse customer data, contract data, payment data, production data, or support history? A newsletter tool should not be evaluated the same way as a CRM that holds full customer history. A file store with project documents is different from a booking tool without sensitive content.

The second category is privileged access. The external MSP, the agency with CMS admin rights, the cloud partner with root access, the monitoring tool with infrastructure read access, and the automation account with write access to CRM and accounting are not normal suppliers. They can improve stability, but they can also amplify damage when access, offboarding, MFA, logging, and break-glass rules are not clear. Trust is not enough as an operating model. You need an owner, purpose, scope, review date, and documented removal path.

The third category is critical workflows. A vendor can hold little sensitive data and still be business critical. If a logistics provider supplies shipping status, a SaaS platform controls quote approvals, or a payment provider can block invoicing, the issue is availability and decision capability. The fourth category is backup and recovery. Who holds restore evidence? Who can trigger recovery? Which providers influence RTO, RPO, encryption, retention, or test logs? The fifth category is incident communication: who reports an incident, to whom, within which route, with which information, and through which escalation path?

The BSI's risk analysis guidance recommends identifying assets and business processes, assessing confidentiality, integrity, and availability needs, considering threats and vulnerabilities, assigning owners, and documenting results. That logic translates directly to suppliers. The goal is not to assess every vendor perfectly on day one. The goal is to make the top 10 risks visible before the next questionnaire demands an immediate answer.

From supplier register to evidence workflow

A spreadsheet can be a useful start. It becomes useless only when it is treated as an archive. An effective supplier register answers more than who you pay. It shows which digital capability a supplier touches, which data class is involved, who owns the relationship internally, which evidence exists, when the next review is due, and which exception was consciously accepted. That turns a list into an operating artifact.

The base fields are straightforward: supplier name, service, business owner, technical owner, data class, criticality, access type, contract or SLA context, incident contact, last evidence, next review date, open gaps, and decision. For suppliers with customer data, privileged access, or recovery impact, a commercial owner is not enough. Markus reviews technical evidence, Anna decides critical exceptions, Lena tracks due dates and contacts. n8n sends reminders for due reviews, escalates overdue evidence, and creates a status list for the monthly review.

The most important part is the review gate. Every new or renewed critical supplier gets a 15-minute supplier check. The questions are simple: what data does the supplier process? What access does it hold? Which workflow does it affect? Which incident contact is valid? Which recovery path depends on it? Which evidence exists, and which evidence is missing? A missing answer is not automatically a blocker. It is a decision: accept, request, compensate, replace, or escalate.

A realistic SME scenario: 36 vendors, one customer, one deadline

Return to this DACH B2B supplier. The customer's questionnaire contains 42 security questions. In the old state, the team would have spent two days searching. Lena would open contracts, Markus would collect screenshots from admin interfaces, Omar would answer backup and identity questions, and Anna would mediate between sales and technical reality. The final answers might be partly accurate, but they would not become reusable evidence.

After a first vendor-risk sprint, the working state is different. Not everything is solved, and that has to be stated clearly. Out of 36 digital suppliers, the top 10 are prioritized. Four vendors with privileged access now have an owner, access purpose, MFA status, contact path, review date, and open evidence gaps. Two restore proofs that previously sat only with the service provider have been requested. One SaaS workflow with customer data gets a documented failure path and a human review boundary. Lena sees missing evidence monthly. n8n escalates overdue entries. Anna makes only the exceptions that genuinely carry business risk.

The outcome is not "compliance complete." That would be inaccurate. The outcome is decision capability. The team can tell the customer which suppliers were reviewed, where evidence exists, where gaps remain, and who owns the next decision. It can also explain that legal reporting or customer communication duties remain with data-protection roles, legal counsel, management, or official channels, while the operating workflow provides the facts. That separation matters: architecture supports compliance readiness; it does not replace legal judgement.

Objections also become more practical. "We are too small for NIS2" is separated from "Can we answer customer questions?" "Our MSP handles security" becomes "Who owns MSP access, restore evidence, incident contact, and offboarding?" "The vendor has ISO 27001" becomes "Which of our workflows does that touch, and which exception have we accepted?" The discussion moves away from reassurance and toward responsibility.

Technical deep-dive: building the vendor-risk loop

The technical core is not a heavy GRC suite. For an SME without a dedicated security or platform team, a lightweight architecture often works better: one central register as the source of truth, an evidence folder or Git repository, an n8n workflow for due dates and escalations, a supplier-incident runbook, a management review note, and access checks for privileged suppliers. The crucial property is repeatability.

A simple data structure can look like this:

vendor-risk-register
├── supplier: name, service, contract owner, technical owner
├── exposure: data class, privileged access, critical workflow, recovery role
├── evidence: certificate, SLA, security contact, restore proof, questionnaire
├── review: due date, reviewer, decision, exception, next action
├── incident: contact path, notification source, affected workflows, runbook
└── audit trail: timestamp, change, reviewer, accepted risk, follow-up

The register can start as a structured table. In more technical environments, it can live in Git so changes become reviewable. The important point is not the platform. It is the ownership boundary: every row has a business owner and a technical owner. Every critical exception has a decision. Every missing piece of evidence has a date. Every supplier incident has a contact path. Every review leaves a note that later explains why something was accepted or changed.

n8n fits here not as "compliance automation", but as orchestration for recurring work. A workflow can ask for missing evidence each month, create review tickets, escalate overdue entries, route supplier-incident notices to the right roles, and prepare status lists for Anna, Markus, and Lena. The decision remains human. Automation makes sure the decision happens on time, with context, and with a trail.

The incident runbook connects supplier risk with response capability. Germany's BSI incident reporting guidance describes, for affected entities, early reporting, follow-up information, continued responsibility even when a service provider reports, and suitable contacts. An SME should not turn that into its own legal diagnosis. It should know operationally which supplier notice is assessed internally, who checks data or workflow impact, when a process is paused, who prepares customer communication, and where legal counsel or data-protection roles take over.

How Planfold turns supplier risk into operational capability

Planfold treats supplier risk as an operating layer, not as a folder of forms. Plan means auditing dependencies, data flows, privileged access, contracts, incident contacts, restore evidence, and existing questionnaire answers. The result is not a broad compliance claim. It is a prioritized supplier map: what is critical, what is unclear, who decides, and where evidence is missing.

Unfold means building the workflow. That can include a Git- or table-backed register, n8n reminders, technical review checklists, access-control routines, restore-evidence storage, supplier-incident runbooks, and management review notes. Infrastructure standardization helps where supplier risk touches hosting, backups, access, deployment, or recovery. Kubernetes operations and cloud-native delivery are relevant only where the workload justifies them. CKA, CKAD, and LFCS are capability signals for critical operations work, not compliance badges.

Resonate means keeping the evidence current. Monthly or quarterly reviews, overdue evidence, supplier changes, new automations, incident learnings, and restore tests flow back into the register. The system stays small enough for a team without a platform department and robust enough that customer questions are not rebuilt from memory every time. That is the difference between a questionnaire project and a digital machine that understands its dependencies.

The boundary remains clear: Planfold does not provide legal advice, certify NIS2 compliance, perform formal penetration tests as a compliance substitute, or decide whether your company is essential or important. Planfold can build the architecture, routines, and evidence layer that gives qualified legal, data-protection, and management decisions reliable facts.

A 30-day start plan for supplier risk

A useful start has to be small enough to actually happen. In week 1, list the most important digital suppliers: SaaS, cloud, hosting, MSP, automation, backup, monitoring, payment, logistics, support, and development partners. Do not treat all of them equally. Mark suppliers with customer data, privileged access, critical workflow impact, recovery role, or incident relevance. That is your first risk selection.

In week 2, classify the top 10. Define owner, data class, access type, affected workflows, incident contact, and current evidence for each supplier. Absent evidence becomes an open action instead of a green check.

In week 3, collect documents and contacts: SLA, security contact, certificate, restore test, backup note, questionnaire answer, access review, patch procedure, or incident procedure. Do not expect complete coverage immediately. A visible gap list beats false completeness.

In week 4, define the review rhythm. Critical suppliers are reviewed at renewal, after significant change, or when evidence is missing. Lena sees due reviews monthly. Markus reviews technical evidence for customer data, privileged access, or recovery impact. Anna decides critical exceptions. A short supplier-incident path lists notification recipients, checked workflows, and the point where qualified legal or data-protection roles take over.

If your company cannot answer a customer questionnaire with confidence today, that is not a reason for theatre. It is a useful starting point. Which vendors are critical? Who owns the relationship? Which evidence exists? Which gap is accepted, and which one must be closed? And which workflow keeps those answers from disappearing again in three months?

Supplier security does not become easier when it waits until the next questionnaire. It becomes easier when it becomes part of operations: visible, owned, repeatable, and honest about open gaps.