Walk through the NIS2 obligations as the person who owns them — the CISO, the Head of IT, the one senior security person in a two-hundred-person regulated company. Most of the list is work, but it's work you know how to plan. One item isn't. This post is about why that one item is structurally different — not harder because you're under-resourced, harder because of where the work lives.
Most of Article 21 is procedural
NIS2 Article 21(2) lists ten areas of risk-management measures every covered entity has to implement. Look at how most of them behave in practice.
Awareness training has a playbook: pick a provider, set a schedule, track completion, report the percentage to the board. Incident handling has a runbook: detection, escalation, roles, and a reporting ladder with fixed clocks. Patch management is procedural: asset inventory, maintenance windows, severity SLAs, a documented exception path. Business continuity is a discipline with forty years of method behind it: impact analysis, recovery objectives, an annual test with findings. Cryptography, access control, MFA — policy, implementation, evidence.
None of that is trivial. But it shares one property that makes it plannable: the work is internal. Your systems, your people, your artefacts. You control the inputs, you control the cadence, and you control the format of the proof. When the auditor asks, the evidence is something your own organisation produced, in a shape you chose, on a schedule you set.
Then there's 21(2)(d)
The supply chain clause reads: "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." One line. It behaves differently from every other item on the list, for four structural reasons.
The evidence sits with external parties. You cannot generate a supplier's ISO certificate, their sub-processor list, or their incident history. You can only request it, chase it, and judge what arrives. Every other obligation lets you produce your own proof; this one makes you a collector of other people's.
It arrives in a dozen formats. A SOC 2 report here, a certificate PDF there, a security policy exported from someone's wiki, a cyber-insurance letter, a screenshot, an email that says "we're working on it." There is no native format for supplier assurance, because each supplier answers in whatever form their own tooling produces.
It expires unevenly. ISO 27001 certificates run a three-year cycle. A SOC 2 Type II covers a twelve-month period and goes stale after it. A sub-processor list can be out of date a quarter after it was sent. Contracts renew on their own calendar. There is no single review date that keeps a supplier record current — every artefact ages at its own speed.
Someone has to defend the decisions later. Approving a supplier is easy. Showing — three years later, after the reviewer has left, possibly under regulator scrutiny — how you approved them, on what evidence current at the time, and who signed: that's the part that takes infrastructure, not effort.
And underneath all four: your suppliers have suppliers. The directive scopes the obligation to your direct suppliers and service providers, but the risk that reaches you often starts further down, and what you can see of it depends entirely on what your direct suppliers disclose.
Effort doesn't fix a structural problem
The natural response is the one every mid-market security lead has already built: a supplier spreadsheet, a review-dates calendar, a shared folder of evidence, and a mailbox full of questionnaire threads. At ten suppliers it works. At thirty it wobbles. At the first audit it breaks — not because anyone was careless, but because the picture was never in one place to begin with.
During audit time, everything else gets dropped. The work isn't proving you're compliant — the work is finding everything you already have, in the right form, before the auditor's next question. Spreadsheets are practical, but they aren't sufficient in isolation. Not when the real picture lives across emails, contracts, screenshots, SharePoint folders, and three different versions of the same file.
This is why "try harder with the spreadsheet" is not a playbook. The other obligations reward process discipline. This one punishes it with entropy: external parties, mixed formats, uneven expiry, and a burden of proof that lands years after the decision.
What a playbook would have to look like
The closest thing 21(2)(d) has to a procedure is a set of artefacts a supervisory authority or auditor will actually ask for: a maintained supplier inventory, a documented risk classification, per-supplier assessment evidence on a known cadence, a defensible decision trail, and a reaction plan for material change. We've unpacked each of them in the Article 21(2)(d) deep dive.
Notice what that list is, though. It isn't a sequence of steps your team runs internally — it's a filing discipline imposed on a coordination problem with dozens of external parties. Each artefact is easy to describe and miserable to keep current by hand. That gap, between "easy to describe" and "miserable to maintain," is exactly where the spreadsheet era ends.
The obligation deserves its own tool
This is the argument for why Vittnor — Supply Chain Assurance for the mid-market — exists as its own product rather than a module in something bigger. Article 21(2)(d) asks you to manage the security of your direct supplier relationships. Operationally, that means one record per supplier: current evidence with reviewer attribution, the questionnaire answers and what they were based on, the decision — approve, reject, accept-with-risk — with a timestamp and a name on it. The output is a queryable, exportable supplier register an auditor can actually ingest.
The honest boundaries: it doesn't write your supply chain security policy, and it doesn't make you compliant — no tool does; compliance is a judgment your regulator makes. What it does is give the obligation the operational backbone the other nine areas already have. Awareness training has its platform. Patching has its tooling. Supply chain security deserves the same.
If you're mapping your own gap
Two useful next steps, depending on how you like to work. The NIS2 readiness check is self-serve and takes about five minutes — it scores your supplier-assurance setup across four NIS2 categories, including the supplier-risk and evidence ground this post covers. Or read the full Article 21(2)(d) breakdown first and come back with sharper questions. Either way: most of your NIS2 list has a playbook. This is the part that needs a system.