NIS2 Applies to Your Company: What to Demand From the Developers Who Maintain Your Software

A manufacturing company outside Stuttgart found out it was in scope for NIS2 the way most German Mittelstand companies do: a customer's procurement department sent over a supplier questionnaire. The managing director knew the law existed. She did not know it also reached the freelance developer who built and still runs the company's order management system, or that the obligation to answer for that system now sits with her, not with him. Working out the NIS2 software supplier requirements that apply to a custom application built by an outside developer, rather than to a product you sell, is a different problem than the one most NIS2 coverage addresses, and it is the one a growing number of German companies are facing first.

Most writing about NIS2 is aimed at the companies that have to register directly: SaaS vendors, managed service providers, cloud platforms. If you run one of those, our breakdown of NIS2 for SaaS companies covers the registration thresholds and the reporting clock in detail. This post is for the other case: a manufacturer, logistics firm, healthcare provider, or any other mid-size company that is not itself a software business but depends on one, either because NIS2 covers your sector directly or because a customer that is already in scope is pushing its own supply chain obligations down into your contract.

Why NIS2 software supplier requirements land on you, not the developer

Germany's implementing law, the NIS2UmsuCG, took effect in late 2025, and the BSI registration deadline for already-affected organizations fell on 31 July 2026. If your company meets the size thresholds, roughly 50 employees or 10 million euros in annual turnover, and operates in one of the eighteen sectors the directive covers, from manufacturing of certain goods to healthcare to digital infrastructure, you are likely in scope as an important entity even if nobody on your payroll writes a line of code. The directive's risk management measures, laid out in Article 21, cover risk analysis, incident handling, business continuity, supply chain security, basic cyber hygiene, access control, multi-factor authentication, and cryptography, among others, and they apply to the organization as a whole, not to whichever vendor happens to be running your systems. Fines for non-compliance can reach 10 million euros or 2 percent of global annual turnover for essential entities, and 7 million euros or 1.4 percent for important entities, whichever figure is higher, and management can be held personally liable for failing to oversee the required measures. Your freelancer or agency is, in effect, your IT service provider under NIS2's supply chain lens, even if their invoice never uses that language. That detail gets lost when a company assumes NIS2 is an IT problem and hands the whole thing to whoever maintains the software, because the law does not let the delegation go that far. You can hire someone to patch the server. You cannot hire someone to take the fine.

What NIS2 supply chain security actually asks you to check

Article 21 treats supply chain security as one of the required measures, which means your obligations extend to the vendors, freelancers, and agencies who touch your systems, not just to your own staff. In practice this comes down to a short list of questions, and the honest answer to most of them, for a company that outsourced its software years ago and never revisited the arrangement, is "I don't know."

Start with patching. Ask how often the developer or agency checks for security updates on the frameworks, libraries, and server software your application depends on, and how quickly a critical vulnerability gets fixed once it is known. "We fix it when something breaks" is not a patch process. A dependency scan running on a regular schedule, with a defined window for critical fixes, is. If nobody can describe that process to you in two sentences, it probably does not exist, and that is worth reading alongside our post on what happens when no developer is responsible for a system anymore, which is a more common situation than most owners expect.

Access management is the second thing to check, and the question is simple: who can reach your production server and admin panel, and does that list still match who is actually working on the project today. Contractor access that was never revoked after a project ended shows up constantly in code audits, and it is exactly the kind of gap a NIS2 supply chain review is designed to surface. Multi-factor authentication on anything that touches production should not be optional, and if it is not already enforced, that is a cheap fix worth asking for immediately.

Third, ask how vulnerabilities get found in the first place, not just how they get fixed once a client complains. A developer who waits for someone to report a problem is running a help desk, not a vulnerability management process. Ask whether dependencies are scanned automatically, whether the results go anywhere, and who decides what counts as urgent.

A fourth question covers logging: does the application keep access and error logs, and for how long. Without them, there is no way to reconstruct what happened during an incident, which matters both for your own investigation and for the reporting windows NIS2 sets once a significant incident is confirmed.

Last is the incident contact itself. If your server goes down at two in the morning, or a vendor discloses a vulnerability in a library you depend on, is there a named person who will actually answer, and do they know the clock NIS2 puts on reporting. A Slack handle for a freelancer who stopped billing you eighteen months ago is not an incident contact.

Putting the answers into the contract, not just a conversation

Asking these questions once and getting a verbal answer solves nothing if the next person to look at the relationship, an auditor, an insurer, a customer's procurement team, has nothing in writing to check against. The NIS2 requirements for external developers that actually hold up are the ones built into the agreement itself: a defined patching service level, a named point of contact for incidents with a response time attached, the right for you to request an audit or evidence of the measures in place, and a notification clause that obligates the developer to tell you about a security incident quickly enough that you can still meet your own reporting obligation. None of this needs to be adversarial. Most freelancers and agencies worth keeping are already doing some version of this work; the contract just needs to say so, so the arrangement survives a change of personnel or a change of agency.

If your current agreement is a one-page scope of work from several years ago, this is also the moment to decide whether an ad hoc relationship still fits, or whether a maintenance retainer with defined patching and response commitments is the better structure. We cover what that retainer should actually include in more detail, including the parts most contracts leave out.

The fastest way to find out where your own gaps sit is a short code quality review: a few days spent on the dependency inventory, the access list, and the patch history of whatever your developer currently maintains, before an auditor or a nervous customer asks for it first. Wolf-Tech runs reviews like this as part of our code quality consulting work. If you want a second set of eyes on what your current developer or agency can actually show you, reach out at hello@wolf-tech.io or visit wolf-tech.io.