The Supply Chain Clause: How NIS2 Enforcement Turned Your Development Partner Into a Compliance Dependency

Why Is a Directive You Are Not Subject To Landing in Your Sprint?

Most engineering leaders filed NIS2 under things the CISO deals with, and for a couple of years that was the correct filing. It stopped being correct somewhere in the last twelve months, and the way most teams found out was not a regulator's letter. It was a redline in a master services agreement, or a security schedule attached to a renewal, or a procurement questionnaire arriving from a client who had never asked about branch protection before.

The mechanism is worth understanding precisely, because it is different from how the EU regulations you already track reach you. The NIS2 Directive applies to essential and important entities across eighteen sectors, an expansion that takes the population from roughly 10,000 to 15,000 entities under the original NIS regime to an estimated 160,000 across the Union. Energy, transport, banking, health, water, digital infrastructure, ICT service management, manufacturing, postal services, waste, chemicals, food, research. If you build software for European industry, a meaningful share of your client list is in that number whether or not anyone has mentioned it to you.

What makes this an engineering problem rather than a legal one is Article 21(2)(d). Among the minimum risk-management measures that in-scope entities must adopt is supply chain security, which DLA Piper's analysis describes as covering the security-related aspects of the relationship between each entity and its direct suppliers or service providers, taking into account each supplier's specific vulnerabilities and the overall quality of their cybersecurity practices.

In practice that unpacks into four things your client has to do, and therefore four things that land on you. A supply chain security policy with minimum requirements communicated to suppliers and built into procurement criteria. A risk assessment identifying which suppliers matter, based on the nature of the service and their incident history. Contractual flow-downs covering cybersecurity obligations, employee skills and awareness, incident reporting and audit rights. And a supplier register with ongoing monitoring rather than a point-in-time check at signature. The same analysis notes that flow-downs are expected to extend to the subcontractors of direct suppliers, which means your own subprocessors are in the chain too.

So the asymmetry is this. A national authority cannot fine a software development company that is not itself an in-scope entity. What it can do is fine the hospital group, the grid operator or the logistics platform that failed to manage the risk of that supplier. Your exposure is not regulatory. It is commercial, and it is decided at renewal by a procurement function that now has a reason to be difficult.

Has Anyone Actually Been Fined Yet?

For most of 2024 and 2025 the honest answer to that question was no, and it did a lot of damage to the credibility of the whole regime. Suppliers learned to treat NIS2 questionnaires as theatre because nothing appeared to be happening behind them. That is no longer the situation.

Enforcement trackers compiling actions by national competent authorities now record a first wave of NIS2 penalties across several member states. One such tracker lists a Belgian healthcare provider fined 185,000 euros for a missed 24-hour early warning, an Italian cloud provider fined 450,000 euros for having no risk management programme, a Hungarian water utility fined 78,000 euros for inadequate incident response, a French DNS provider fined 120,000 euros for late incident notification, and, most relevant to anyone reading this as a supplier, a Lithuanian energy operator fined 52,000 euros for missing supply chain controls. The first-wave total sits below a million euros.

Two readings of those numbers are available and only one of them is useful. The unhelpful reading is that the amounts are small relative to the ceilings, which for essential entities reach 10 million euros or 2% of worldwide annual turnover, and for important entities 7 million euros or 1.4%. That is true and it is the sort of thing that gets a supplier comfortable.

The useful reading is what the fines were for. Not breaches. Governance failures, missed clocks and absent controls, which are exactly the findings an inspection produces when nobody was attacked at all. The Lithuanian case in particular establishes that supply chain controls are not a paper obligation waiting for a test case. They have already been the sole basis of a penalty.

The same trackers put supervisory activity at roughly 1,500 essential entities audited across the larger member states, with Germany's BSI, Italy's ACN, France's ANSSI, the Dutch NCSC and Belgium's CCB all running programmes. Meanwhile transposition remains uneven, with 23 of 27 member states having fully transposed and the Commission having pressed the remaining laggards through infringement proceedings, escalating in mid-2026 to referrals to the Court of Justice.

It is tempting for a supplier to read the transposition gaps as breathing room. It is not, and the reason is structural: the obligation reaches you through your client's contract, not through your national statute. A multinational client with operations in a transposed member state applies the same supplier standard across its whole vendor base, because maintaining two tiers of supplier security is more expensive than maintaining one.

What Article 21 Actually Asks Your Development Partner to Prove

Article 21(2) sets out ten minimum risk-management measures, and read in the abstract they are unremarkable: risk analysis and information system security policies, incident handling, business continuity and crisis management, supply chain security, security in acquisition, development and maintenance, policies to assess the effectiveness of the measures, cyber hygiene and training, cryptography, access control and asset management, and multi-factor authentication and secured communications.

What turns that list from a policy exercise into engineering work is the layer built on top of it. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 lays down technical and methodological requirements at EU level for the digital infrastructure and ICT service management sectors, covering DNS providers, TLD registries, cloud computing providers, data centre operators, CDN providers, managed service providers, managed security service providers, online marketplaces, search engines, social platforms and trust service providers. ENISA followed with technical implementation guidance published on 26 June 2025, breaking the requirements into thirteen cybersecurity parameters with practical advice, evidence examples and mappings to existing standards.

The managed service provider category deserves a second look from anyone running a development partnership, because it is closer than most teams assume. If your development partner operates your CI/CD pipelines, administers your cloud environments, holds production credentials, runs your on-call rotation or manages your observability stack, the relationship has drifted past writing code and into managing services. Whether that crosses a legal definition is a question for counsel. Whether your client's third-party risk team will treat it that way is considerably less ambiguous.

Translated into artefacts an engineering organisation can actually produce, the ten measures come down to a fairly short list. An asset and dependency inventory, which in 2026 means a current SBOM per delivered artefact rather than a spreadsheet. Access control with named individual accounts, enforced multi-factor authentication and a joiners-movers-leavers log that can be shown rather than described. A cryptography policy that says what is used where. A vulnerability handling process with published remediation targets and twelve months of actual times against them. Backups with a documented, dated restore test. Logging with retention long enough to reconstruct an incident after the fact. A secure development standard that is enforced in CI, covering mandatory review, branch protection, secret scanning and dependency pinning. Training records with completion dates. And a periodic assessment of whether any of it is working.

None of that is new to a competent team. What is new is the evidentiary burden. Under this regime it is not sufficient to do these things well; you have to be able to show, on a few days' notice, that you were doing them on a specific date eight months ago, and name the person who owned each one.

The 24-Hour Clock Does Not Stop at Your Vendor's Front Door

Article 23 imposes a staged reporting obligation that is tighter than most suppliers realise. An early warning within 24 hours of becoming aware of a significant incident. A fuller notification within 72 hours including an initial severity assessment and indicators of compromise. An intermediate report if the authority asks for one. And a final report within one month covering a complete description, root cause, mitigations applied and lessons learned.

Note again what the Belgian fine was for. Not a breach, and not an inadequate response: a missed 24-hour early warning. The expensive failure in this regime is frequently not the security event. It is the clock.

Now put a development partner in the middle of that chain. If an incident is discovered in infrastructure your partner operates, or by an engineer on your partner's team, your client's 24-hour window opens when your client becomes aware, and their awareness is entirely downstream of yours. Every hour your team spends deciding internally whether something qualifies as an incident, or waiting for a lead to come online, or routing the question to an account manager who will pick it up tomorrow, is an hour subtracted from a regulatory deadline that belongs to someone else.

This is where the shape of the delivery relationship stops being a preference and starts being a control. A named contact who is reachable outside business hours. An escalation threshold agreed in writing before anything happens, so nobody is improvising a severity judgement at 23:00. A pre-written early warning template, because the 24-hour submission is deliberately allowed to be thin and teams waste hours trying to make it complete. A shared channel that does not depend on one person's inbox. And, the part almost nobody does, a rehearsal in which the clock starts at supplier awareness rather than client awareness.

Time zones stop being a comfort argument here and become arithmetic. A 24-hour window with a partner nine or ten hours away means the first handoff consumes a meaningful fraction of the budget before anyone has assessed anything. With a partner working European hours, the assessment call happens the same morning. That difference is the sort of thing nobody weighs during vendor selection and everybody weighs during the incident review afterwards.

It is also worth mapping this against the other clock you may already be running. If you ship a product with digital elements into the EU, the Cyber Resilience Act's reporting obligations impose their own early-warning window, which we covered in the CRA's 24-hour clock. The triggers differ, the recipients differ, and a single event can start both. The Digital Omnibus proposal would route NIS2 notifications through a single Union-level reporting portal while leaving the Article 23 triggers, content requirements and timelines intact. That is a genuine administrative simplification and it changes nothing whatsoever about the engineering obligation, which is to detect, classify and escalate fast enough to feed it.

Why Your Client's Board Suddenly Cares About Your Branch Protection Rules

There is a governance provision in NIS2 that explains almost all of the behavioural change suppliers are experiencing, and it is not the fine ceiling.

Article 20 puts the management body of an essential or important entity personally in the frame. Management bodies must approve the cybersecurity risk-management measures and oversee their implementation, and the directive requires them to follow training sufficient to identify and assess cybersecurity risks, with entities obliged to offer comparable training to staff on a regular basis. Member states may attach personal liability, including temporary bans from holding management functions at essential entities, and some national transpositions add individual financial exposure on top of the corporate penalty.

Read that from the other side of the table. The person who signs your contract, or the person whose director signs it, now has a personal interest in being able to demonstrate that they oversaw supplier risk rather than delegated it into a folder. That is a different motivation from the one that produced a decade of perfunctory vendor reviews, and it produces different behaviour: more questions, more technical questions, more insistence on audit rights actually being exercisable, and more resistance to the interchangeable-resource-pool staffing model.

That last point catches a lot of outsourcing arrangements off guard. Article 21's cyber hygiene and training measure, and the employee skills and awareness provisions that flow down through supplier contracts, are straightforward to evidence for a stable team of named engineers with training records and access histories. They are genuinely awkward to evidence for a rotating bench where the people who touched the codebase in March are on a different account by September and nobody kept the access log. The compliance regime did not set out to have an opinion about staffing models, but it has ended up with one.

The same dynamic explains why subprocessor disclosure has become a sticking point. Your client's management body is being asked to attest to a supply chain they can describe. A partner who cannot produce a current list of which third parties touch the work, including the AI tooling now embedded in most development pipelines, is asking them to attest to something they cannot see.

The Questionnaire Economy Is a Bad Proxy for Security

The default institutional response to a supply chain obligation is to send a questionnaire, and the volume of that response has become its own problem for everyone involved.

The figures are unflattering in both directions. Third-party risk data compiled for 2026 shows enterprise security teams receiving roughly 23% more vendor security questionnaires per quarter than in early 2025, with about 35% of third-party risk programmes running questionnaires of 100 questions or more, and the large majority of organisations taking more than two weeks to complete a vendor assessment by hand. From the supplier side, a substantial share of vendors either never return questionnaires or return them late, and 54% of companies report losing deals because they could not complete a security questionnaire in time.

Both halves of that are bad. Buyers are spending analyst weeks on documents whose accuracy nobody can verify, and suppliers are losing work on administrative throughput rather than security posture. The questionnaire is measuring one thing reliably, which is the supplier's capacity to answer questionnaires, and that is correlated with size far more than with control quality.

The alternative is cheaper for both sides and it is not complicated: a standing evidence pack, maintained as a by-product of how the team already works rather than assembled per request. In practice that is a location, not a document, containing a current SBOM for each delivered artefact, an access register with named engineers and a joiners-movers-leavers log, the vulnerability handling policy alongside twelve months of real remediation times against its targets, the date and outcome of the last restore test, the secure development standard with evidence that its checks are enforced in CI rather than aspirational, the incident runbook with a named contact and the date of the last rehearsal, a current subprocessor and tooling list including AI coding assistants and any MCP servers in the pipeline, and training completion records.

Every item on that list has a date and an owner, and every item is something a good team produces anyway. The difference between a supplier who can hand that over in an afternoon and one who needs three weeks and a consultant is not a difference in security. It is a difference in whether the evidence was a by-product or an event, and it is visible to a buyer within about ten minutes.

If you are on the buying side, the highest-leverage change you can make to your vendor review is to stop scoring prose. Ask for three artefacts with dates on them and a thirty-minute call with the engineers who maintain them. You will learn more than a hundred-question questionnaire will tell you, and you will learn it in a week rather than a quarter. We walk through the rest of that evaluation in our guide to vetting a development partner.

January 2026 Changed the Trajectory: High-Risk Suppliers and Certified Posture

If the current state of NIS2 were the end of the story, this would be a manageable procurement nuisance. The proposals published on 20 January 2026 suggest it is not.

The Commission put forward two instruments that day: a Cybersecurity Act 2 replacing the 2019 Act, and a set of targeted NIS2 amendments motivated explicitly by the geopolitical situation and by supply chain security risk. The amendments are, in aggregate, a simplification, easing compliance for around 28,700 companies including 6,200 micro and small enterprises, clarifying definitions in healthcare, electricity generation, chemicals and DNS, and introducing small mid-cap enterprises as important rather than essential entities. They also expand the perimeter, bringing European Digital Identity Wallet and Business Wallet providers, submarine data transmission infrastructure operators and managers of strategic dual-use infrastructure into scope, and they add mandatory ransomware reporting covering attack vectors, mitigations and, on request, ransom details. A detailed breakdown of the package also flags post-quantum cryptography transition targets of 2030 for critical use cases and 2035 more broadly.

The consequential piece for anyone buying or selling development services is the proposed ICT supply chain security framework. It would establish mechanisms for identifying key ICT assets and designating high-risk suppliers, and enable the Commission to impose binding restrictions on procurement from designated high-risk jurisdictions, with a 36-month phase-out already sketched for mobile network equipment and adoption expected in late 2026 or early 2027. Analysis of the reform places it alongside a broader harmonisation of technical controls across member states.

Two implications follow, and they point in different directions for different suppliers. The first is that jurisdiction stops being a matter of procurement taste. Where your engineers sit, where your build infrastructure runs and where your data comes to rest become attributes a regulator can designate rather than preferences a client can weigh. Organisations that have already done the work of understanding their own geography, a theme we covered in the piece on EU cloud sovereignty requirements, will find this an inventory exercise. Organisations that have not will find it a migration.

The second is more encouraging. Cybersecurity Act 2 extends certification beyond products to organisational cybersecurity posture, and, importantly, would prevent authorities from re-auditing areas already covered by certification, with ENISA's budget rising by more than 75% to support an expanded role covering EU-level risk assessment, the European Vulnerability Database and a central incident reporting platform. For a supplier, that is the first real signal that investment in a demonstrable, certified posture might substitute for questionnaire rounds instead of merely accompanying them. The evidence pack described above is the same artefact either way, which makes it a reasonably safe bet under either outcome.

What Should You Build Before Your Next Procurement Review?

A sequence that fits inside a quarter and leaves you materially harder to fail an audit over, whichever side of the contract you are on.

Weeks one and two: find out who is actually in scope. List your clients, or your suppliers, against the eighteen NIS2 sectors, then go and read the security schedules you have already signed. This step reliably surprises people. Most engineering organisations have already agreed to audit rights, incident-notification windows and subprocessor disclosure obligations that nobody in engineering has ever read, because the schedule was negotiated by legal and filed. Knowing what you promised is prerequisite to knowing whether you are keeping it.

Weeks three and four: build the evidence pack as a location with owners, not a document with a version number. SBOMs, access register, vulnerability handling policy plus twelve months of measured remediation times, last restore test with its date and outcome, secure development standard with proof its checks run in CI, incident runbook, subprocessor and tooling list, training records. If assembling it takes more than two weeks, that duration is itself the finding.

Weeks five and six: agree the incident trigger threshold in writing and rehearse it, with the clock starting at supplier awareness. Run the tabletop at an inconvenient hour, because that is when incidents are discovered. The gaps this exposes are boringly consistent across organisations: log retention shorter than anyone believed, restore procedures never tested end to end, offboarding that revoked the obvious accounts and missed the CI tokens, and no agreed definition of significant.

Weeks seven and eight: close what the rehearsal exposed, and put the subprocessor register on a maintenance cadence rather than a compliance cadence. Pay particular attention to the AI layer of your pipeline, because coding assistants, agent frameworks and MCP servers are now third parties with access to your source, and they are the part of the supply chain that has changed most since your last security schedule was drafted. We wrote about that specific attack surface in the analysis of agent supply chain attacks.

On who does the work: this is the point where the structure of the partnership matters more than its hourly rate. Evidencing named-engineer access histories, training completion and continuity of ownership is straightforward when the team is stable and employed, and genuinely difficult when it is a rotating bench assembled per project. That is the model StepTo is built around: engineers are Serbian employees assigned by name, working as a stable extension of the client's team in overlapping European hours, which is the same property that makes a 24-hour early-warning window survivable. Serbia's own Law on Information Security, in force since 31 October 2025 and modelled on NIS2 as part of the country's accession alignment, means the teams doing the work are operating under a domestic regime built from the same directive rather than translating obligations across an unfamiliar legal frame. For clients evaluating that geography specifically, we set out the trade-offs in our nearshore development overview.