A contract between the wrong people
The contract had been signed at the end of 2023, and from the prime vendor’s standpoint it was a clean, well-structured contract, with all the safeguard clauses the legal department had insisted on over the years. It clearly specified the subject matter of the supply, set out service levels, fixed penalties for non-compliance, defined the perimeter of vendor liability with standard caps at the contract’s annual value, excluded indirect damages, and governed subcontracting through a clause that required the client to approve the main subcontractors and that placed on the client the burden of verifying their adequacy. It had been negotiated for four months, gone through three rounds of legal review on both sides, signed by executives with the necessary powers. The prime vendor, a software house of fifty people, considered it a good contract. The client, a private healthcare company with a million enrolled patients, considered it a balanced contract. For two years the relationship went well.
At the end of 2025 a patient suffered harm from something the clinical system should have done and didn’t do. The technical cause was traced to a risk-evaluation library the system used to classify intervention priorities. The library had been supplied by a subcontractor approved by the client four years earlier, had been silently updated by the subcontractor itself eighty days before the incident with an algorithm change that no one had communicated to the prime vendor, and no one had requested a documentation update because the subcontractor considered its update routine maintenance. The subcontractor was based in a third country, had no legal representative in the Union, and in the months that followed the lawsuit turned out to be effectively unreachable for judicial notices.
The prime vendor reacted to the patient’s lawyer’s damages request by showing the contract. They argued that the subcontractor had been approved by the client, that the change had been introduced unilaterally by the subcontractor without any communication, that the contract excluded indirect damages and capped liability at the annual value, and that in any case material liability fell on the client as the entity that directly managed the relationship with the patient. The patient’s lawyer did not contest any of these contractual points. He simply noted that the contract between vendor and client did not concern him, because he had not signed it, and that his action was based on the new European product-liability regime, under which the prime vendor qualified as the producer of the defective product and was strictly liable toward the final injured party regardless of the clauses agreed with the client. Those clauses, he added, governed recourse between the signing parties, not exposure toward third parties. The contract, in other words, was a good contract between the wrong people.
The traditional objection
The objection I want to address right away, because it is the most rooted and the most sincere, is the one that comes from traditional lawyers I have worked with over the years. It goes like this: this is all a problem of contract drafting. If the clauses are well-written, if the indemnities are complete, if the subcontracting procedures are rigorous, the prime vendor is protected. It is an objection formally consistent with how contract law has functioned for forty years in software. Until a few years ago it was also substantially true, because the software-producer liability regime was weak, third-party injured-party actions almost always passed through the direct client, and the prime vendor could reasonably expect its exposure to be exhausted within the agreed contractual limits.
That era is over. The legal regime now consolidating in Europe between 2024 and 2027, which I have already written about in this series with respect to software-as-written-promise and the specification as the legally relevant asset, introduces a level of liability that operates outside the contract and that the contract can only partly govern. The revised Product Liability Directive, applicable from 9 December 2026, explicitly qualifies software as a product and applies a regime of strict liability to the software producer toward final injured parties. The Cyber Resilience Act, fully applicable from 11 December 2027, introduces digital-product security obligations that bear on the producer along the entire lifecycle and extend to integrated components. The AI Act distributes obligations along the chain of AI-system providers so that the provider of the final system has to ensure that integrated components are compliant. The Digital Operational Resilience Act, applicable from 17 January 2025, imposes on financial entities and their critical ICT vendors supply-chain risk-management obligations that cross contractual boundaries. NIS2, applicable from 18 October 2024, makes the same move for the expanded critical sectors. Each of these acts, taken individually, would be manageable with some contractual adjustment. Taken together, and at their intersections, they define a structure of liability that the supply contract is no longer able to contain.
The four collapsed assumptions
The traditional contractual model of software grew up in an era in which certain implicit assumptions held, and it has become inadequate because all those assumptions collapsed in the same decade. There was, first, the idea that the vendor’s liability toward the client exhausted the vendor’s exposure, because the intermediate client absorbed and managed any liability toward third parties. There was then the conviction that software was an object delimited at the moment of delivery, assessable on the basis of a static specification at release. It was assumed, third, that the supply chain was essentially bilateral from a legal standpoint — that each link could be governed by a contract between two parties without having to worry about the chain’s overall dynamics. And it was assumed, finally, that the liability regime would remain stable over time, enough to make it reasonable to sign multi-year contracts under the legal framework in force at signing. These were assumptions that looked like laws of nature of software contracting until around 2020, and that in retrospect turn out to be merely the characteristics of a specific legal era.
The first assumption was eroded by the broadening of the active legitimacy of third-party injured parties under the new PLD. Under the old product-liability regime, the final injured party could act against the producer, but in practice actions mostly went through the reseller or commercial integrator, and the software producer, until 2024, enjoyed interpretive uncertainty about whether it even fell within the definition of producer. The new Directive, by including software explicitly in the definition of product and introducing defect presumptions that lighten the injured party’s burden of proof, makes the software producer’s position much more exposed. It also adds a documentary disclosure mechanism allowing the judge to order the vendor to produce the technical documentation of the product, and to presume defect in case of non-disclosure. From that moment the injured party’s lawyer no longer needs to go through the intermediate client, and can act directly against the prime vendor of the software that caused the harm, ignoring entirely the contractual clauses between vendor and client, because those clauses govern a relationship to which the injured party is a third party. The point is written explicitly into Article 15 of the Directive, titled “Exclusion or limitation of liability”, which requires Member States to ensure that the liability of the economic operator toward the injured party cannot be limited or excluded either by contractual clauses or by national-law provisions. It is a short, technical article, but it is the keystone of the entire structure, because it transforms what looked like contractual room for manoeuvre into a zone of legal indisposability.
The second assumption was eroded by the Cyber Resilience Act and the AI Act, both of which introduce security and risk-management obligations bearing on the producer along the entire product lifecycle, not only at the moment of delivery. Software has stopped being an object delimited at the time of delivery and now stands as an object continuously exposed to the regulatory regime. Every update, every modification, every integration of new components can be requalified as a substantial modification that brings the product back within the regime, even if the product was placed on the market in an earlier era. The prime vendor that delivered the system in 2023 did not unload its liability in 2026 when a third-party library integrated into that system stopped being maintained and developed security vulnerabilities. Liability simply shifted to the maintenance plane, and the vendor that did not update is a vendor that has failed a continuing obligation, not an obligation limited to the moment of original delivery.
The third assumption, the bilateral nature of the supply chain, was also eroded by the introduction of liability chains that cross bilateral contracting. Under the DORA regime, the financial entity must map and manage its ICT third-party risk along the whole chain, and when a vendor is qualified as critical the obligations extend so that the contractual clauses between the financial entity and the critical vendor must contain specific elements imposed by the Regulation, regardless of the parties’ will. The CRA, for its part, requires the producer of a digital product to guarantee the security of the integrated product, and that guarantee is not exhausted in contractual relationships with its subcontractors, because the regulator assesses the product as a unitary whole regardless of the internal composition of the supply chain. The revised PLD adds a further complication, providing that the substantial modifier of a product can themselves become liable as the producer, and this opens a circular liability dynamic in which the prime vendor, the intermediate integrator, the subcontractor and the final user can be sued under different titles for the same harm. NIS2 and the AI Act complete the picture, extending analogous obligations to expanded critical sectors and to high-risk AI systems respectively, with the result that every chain segment is today crossed by at least two or three overlapping regimes that bilateral contractual clauses cannot reconcile.
The fourth assumption, regulatory stability, is the one whose erosion produces the most insidious effects, because multi-year contracts signed today under the current framework will be applied tomorrow under a framework that will have evolved. The vendor signing a six- or seven-year contract in 2026 will find itself executing it in 2032 or 2033 under regimes that may have changed significantly by then, because the PLD provides for a revision clause, because the CRA will be the subject of guidelines that will modify the interpretation of entire sections, because the AI Act has already been described as an open construction site by the Commission itself. The multi-year contract under the traditional model presupposed a regulatory inertia that no longer exists.
Four phenomena the contract cannot address
Each of these four phenomena has practical consequences the traditional contract cannot address. Joint liability of critical-component suppliers, introduced in different forms by the PLD and the CRA, means the prime vendor answers for defects of integrated components even when subcontractors are non-compliant or unreachable. The contractual clauses that govern recourse against subcontractors remain valid between the signing parties, but do not shift liability toward the final injured party, who can always act against the prime vendor as the accessible and patrimonially most solid link of the chain. The prime vendor that wanted to shift the risk onto the subcontractor through contractual clauses ends up having to absorb it, and can only later try to recover by way of recourse — assuming the subcontractor is still in existence, solvent and reachable.
Documentary disclosure obligations introduced by the new PLD are the second phenomenon, and they are particularly insidious because they turn the vendor into a subject who must show the judge their own technical documentation, even when that documentation includes design choices, security configurations, training datasets, architectural decisions the company would consider trade secrets. The judge must balance the right to disclosure with the protection of trade secrets, but in practice the vendor finds itself exposed to documentary requests the contract with the client cannot limit, because the contract does not bind the judge or the injured party. The vendor may have agreed with the client on the inaccessibility of the documentation, but if the injured party requests production, the vendor must produce, and refusal to disclose generates a presumption of defect under Article 10 of the Directive.
Defect presumptions, which the individual vendor cannot rebut alone, are the third phenomenon, and the subtlest of the four. The new PLD provides that the judge may presume the defectiveness of the product when the product is technically or scientifically complex and proof of the defect would be excessively difficult for the injured party. For complex software systems, especially those integrating AI components, this presumption activates almost automatically, and the burden of rebutting it falls on the vendor. Rebutting the presumption requires demonstrating that the product at delivery did not present the defect, or that the defect was introduced later by modifications outside the vendor’s control. Both demonstrations require detailed historical documentation of the system, and the vendor that did not maintain such documentation finds itself unable to prove anything, and therefore succumbs to the presumption.
Substantial-modifier accountability is the fourth phenomenon, and the one that most radically breaks the bilateral contract structure. When a client or intermediate integrator substantially modifies a software product supplied by a third party, they can themselves become liable as the producer of the modified product, and this opens a dynamic in which the original vendor may no longer be liable for the product as modified, but the modifier may not have the competence, documentation and structure to assume the liability they have materially assumed. The result is a grey zone of liability where the injured party chooses whom to sue based on patrimonial and procedural accessibility, and where the parties involved volley liability among themselves with often paradoxical outcomes.
The settlement that doesn’t arrive soon
One could object, and someone will, that all this is exaggerated and that judicial practice will find a way to bring order back to the system. It is an objection that deserves respect, because judicial practice has always had this stabilising function, and because European regulations, once translated into national case law, often lose the rigidity they have on paper. The answer I am willing to give, after observing how practice is moving in the European jurisdictions where the first cases are emerging, is that the settlement will come, but it will come in five or seven years, and in the meantime the exposure window for vendors operating under traditional contracts is very wide. The first relevant rulings on software-producer liability under the new PLD will not arrive before 2028, because the regime applies to products placed on the market after 9 December 2026 and cases have minimum lead times of a year and a half. From then it will take another three or four years for consolidated case law to form. Meanwhile, every vendor operating with old-model contracts is accumulating retroactive exposure, because many of the systems being delivered today will still be in production when the case law has settled, and they will be assessed against the criteria that have consolidated by then.
The sectors that came before us
It would be dishonest not to recognise that there are sectors where these dynamics have existed for decades, and where supply contracts have a structure that recognises the inadequacy of the traditional bilateral model. They are sectors that have lived under tight product-liability regimes long before general-purpose software, and they have developed contractual practices worth studying. Civil aviation is one, and aircraft-component supply contracts have always incorporated obligations of documentary traceability, third-party certification, coordinated handling of non-conformities, joint liability toward regulatory authorities. Medical devices are another, and supply contracts for medical-device components include quality-framework agreements that go beyond the single commercial contract and govern the relationship between the parties as a regulatory relationship as well as a commercial one. Automotive is the third, especially after the introduction of the ISO 26262 functional-safety standards for vehicle electronic systems, and software supply contracts for automotive have for about a decade incorporated chain-of-liability clauses that recognise the impossibility of confining exposure within bilateral relationships.
What is happening in general-purpose software is convergence — accelerated by the European regulatory package — toward the model these sectors already practise. The difference is that aviation, medical devices and automotive have had thirty years to build their contractual practices, internal competencies, sector standards and structured supply relationships. General-purpose software has five or seven years to do the same thing, and must do it while continuing to operate in markets where most competitors still reason within the old model. It is an asymmetric transition, in which whoever moves first pays a positioning cost that whoever moves later does not pay — but whoever moves first also builds capacity to absorb the subsequent regulatory evolutions that whoever moves later will have to acquire at consolidated-market prices.
Five operational dimensions
On an operational plane, the transformation of the software supply contract has five dimensions to be managed simultaneously. The first is the move from contract-as-document to contractual documents as ecosystem. A software supply contract under the new regime is not exhausted in a single document valid until renewal, but constitutes a system of related documents including the master contract, service-level annexes, security annexes, quality agreements similar to those of medical devices, personal-data processing agreements under GDPR Article 28, coordinated vulnerability-handling agreements, mutual supply-chain disclosure agreements. Each of these documents lives with its own update cycle, and the master contract becomes the framework that holds them together, not the container of all clauses.
The second dimension is the transformation of the limitation-of-liability clause. Traditional clauses that cap vendor liability at the contract’s annual value, or that exclude indirect damages, remain valid between signing parties but produce no effects toward third-party injured parties. For the vendor this means actual exposure is exposure toward the final injured party, not the one agreed with the client, and insurance policies must be sized on that actual exposure, not on contractual caps. Insurance practice in the sector is currently confused, because companies are redefining product-liability products for software producers in light of the new regime, and premiums are rising non-linearly. For mid-size Italian software houses, the insurance cost of product liability is becoming a significant balance-sheet item, where until a few years ago it was a negligible one.
The third dimension is the rewriting of subcontracting clauses, which must move from a model in which the client approves the main subcontractors at signing to a model in which there is a continuous procedure of evaluation, monitoring and disclosure of subcontractors throughout the contract’s duration. The prime vendor must be able to demonstrate at any moment the composition of its supply chain, must be able to produce the SBOM under the CRA, must be able to respond to audit requests from the client or the regulator, must manage situations in which a subcontractor exits the market or ceases maintenance of a component. All this requires supply-chain management tools that the traditional contractual model took for granted and that today become continuous operational activity.
The fourth dimension is the introduction of clauses on coordinated handling of vulnerabilities and security incidents. Under the CRA, under NIS2 and under DORA for the financial sector, vendor and client both have reporting obligations within tight time windows, and meeting these windows requires coordination that the contract must govern operationally, not just formally. A clause that says “the parties shall cooperate in incident handling” is useless if it does not specify who notifies, within what time, through which channels, with what severity thresholds. The clause must be almost a contractual mini-runbook, and its quality is measured in its ability to function during an actual incident, not in its legal elegance.
The fifth dimension is the subtlest, and concerns product-lifecycle management. Under the CRA the producer must declare the product’s support period and maintain it for that period, and must manage the product’s exit from the market so that users are informed and have transition paths. The software supply contract must govern this aspect, because the prime vendor is exposed toward the final injured party even after the end of the contractual relationship with the client, and because end-of-support management becomes a critical moment when residual liabilities can materialise. The traditional clauses of “perpetual licence” or “no warranty after termination” produce no effects toward third-party injured parties, which means the vendor must manage the product lifecycle as a function exceeding the duration of the contract.
Disclosure: eighteen months of rewriting
I have to be transparent on one point, because on this subject I am describing transformations I am living through first-hand. The revision of our supply contracts, inside the company where I work, is an activity that has been underway for eighteen months and has not yet arrived at a stable form. We are working with our reference law firm to rewrite the master contract for software services, and what is coming out is far from the clean, elegant contract we hoped to produce — it has the form of a more articulated system of documents than its predecessor, with annexes that exist for different reasons and that cannot be reduced to a single template. Some clients accept the new structure; others find it needlessly complex and ask to go back to the old model. Market pressure toward contractual simplicity is still strong, and in some cases we ourselves accept to sign old-model contracts when the client imposes it, knowing we are accumulating retroactive exposure. It is a choice we make for immediate commercial reasons, and that I have called compounded exposure in our internal conversations, because it accumulates non-linearly as the client portfolio grows.
An opportunity, not just a burden
I also want to say, because otherwise the piece would sound like a pessimistic forecast about the Italian software industry, that the transformation I am describing is an opportunity before it is a burden. Mid-size Italian software houses that decide to build contractual competencies coherent with the new regime, to pair delivery work with continuous documentary maintenance and supply-chain management, to train internally the hybrid figures I described in the previous piece of this series, will have, in five years, a competitive position hard to erode. Software houses that keep signing traditional contracts in the hope that the regulatory framework won’t really apply, or that national case law will soften it, will find themselves exposed and will have to close the gap at far higher costs than today’s sustainable ones. It is one of those situations in which the decision not to decide is the most expensive of all, because time works against those who do not move, and because every contract signed today under the old model is a liability that will reveal itself in a few years, when the cases that the PLD has designed as standard scenario start appearing in the news sections of specialised media.
The centrality that dies
Putting the four pieces of this series together, the general argument I am trying to build is the following. Software, as an industrial and as a legal object, is changing nature before our eyes, and the engineering and commercial culture of the sector is not adapting at the speed the moment requires. The first piece, Cruft, Not Patina, argued that software does not know how to age the way material objects do. The next, The Specification Debt, shifted attention to the fact that the written specification has become the legally relevant asset of the product and that our industry lacks the tools to keep it alive. Then came The Rise of the Compliance Engineer, devoted to the hybrid professional figure emerging to oversee the gap between engineering and regulation. In this fourth piece the argument shifts from the plane of product and labour to the plane of the relationship between organisations, and the thesis is that the supply contract — the classic legal instrument of that relationship — is becoming one instrument among others within a wider, more structured relationship that traditional contract law can only partly govern.
The software supply contract is not dead, and nothing of what I have written should be read as a forecast of its disappearance. What is dead is its centrality, the idea that the relationship between vendor and client can be exhaustively described by a bilateral document negotiated at the start and updated at renewals. The contemporary relationship is multilateral, regulatorily loaded, dynamically exposed to third parties the contract does not bind, and crossed by continuous documentary obligations the contract can only summarise. Thinking that better-written clauses are enough is an understandable, human nostalgia — and also the fastest way to accumulate exposure while believing oneself protected. Clauses still matter, and matter more than before, but they matter as elements of a wider device that contains and exceeds them.
The contract, as we have known it, has become the gentle deception that lets software vendors believe they know what they are exposed to. Traditional contracts will keep being signed for some years more, because the market moves more slowly than the law, and because the old model is familiar and the new ones are still forming. But whoever keeps signing traditional contracts in the next five years is signing, alongside the contract, a quiet bet that things will not really change. It is a bet that my generation of those who make software in Europe will probably lose, because things are already changing — and what today looks like an excess of caution from the few who are moving will turn out, in a few years, to be the prudential minimum that was required from the start.
Key takeaways
Article 15 of the revised PLD is the keystone of the new regime: liability toward the injured party cannot be limited or excluded by contractual clauses or by national-law provisions. What looked like contractual room for manoeuvre becomes a zone of legal indisposability.
Four implicit assumptions of the traditional contractual model collapsed in the same decade: vendor exposure exhausted in the client relationship, software as a delivery-bounded object, supply chain as a sum of bilateral relationships, regulatory stability that made multi-year contracts under a fixed framework reasonable.
Four phenomena the traditional contract cannot address: joint liability for critical components, documentary disclosure to the judge (with presumption of defect for non-disclosure), defect presumptions for technically complex systems, accountability of the substantial modifier — which most radically breaks the bilateral structure.
Sectors that have lived under this regime for decades — civil aviation, medical devices, automotive — have had thirty years to build the practices. General-purpose software has five to seven years to do the same thing, while most competitors still reason within the old model.
The contract is not dead — its centrality is. The contemporary relationship is multilateral, regulatorily loaded, dynamically exposed to third parties the contract does not bind, and crossed by continuous documentary obligations the contract can only summarise. Clauses still matter — more than before — but as elements of a larger device that contains and exceeds them.
Questions & answers
Why has the software supply contract «stopped being central»?
Because the legal regime now consolidating in Europe between 2024 and 2027 introduces a level of liability that operates outside the contract and that the contract can only partly govern. The revised PLD, the CRA, the AI Act, NIS2 and DORA converge in making the vendor liable toward the final injured party regardless of the clauses agreed with the intermediate client, and in imposing documentary, security and supply-chain obligations that cross bilateral contracting. The clauses still govern recourse between signatories, but they do not shift liability toward third parties. The contract is not dead — its centrality is.
What changes with Article 15 of the revised PLD?
Article 15, titled «Exclusion or limitation of liability», requires Member States to ensure that the liability of the economic operator toward the injured party cannot be limited or excluded either by contractual clauses or by national-law provisions. It is a short, technical article, but it is the keystone of the entire structure: it transforms what looked like contractual room for manoeuvre into a zone of legal indisposability. The vendor who protects itself with cap clauses or indirect-damage exclusions discovers that those clauses govern recourse with the signing client, not exposure toward the third-party injured.
What are the four operational phenomena the traditional contract cannot address?
First, joint liability for critical-component suppliers: the prime vendor answers for the defects of subcontractors even when these are non-compliant or unreachable. Second, documentary disclosure obligations to the judge, with presumption of defect for non-disclosure (Article 10 PLD). Third, defect presumptions for technically complex systems, which kick in almost automatically for software integrating AI components. Fourth, accountability of the substantial modifier: the client or intermediate integrator who substantially modifies a product can become the producer themselves, breaking the bilateral structure.
Which sectors already operate under a similar regime, and what can we learn?
Civil aviation, medical devices and automotive have lived under tight product-liability regimes for decades and have developed useful contractual practices. Aviation contracts incorporate documentary traceability and third-party certification obligations. Medical devices use quality-framework agreements that go beyond the single commercial contract. Automotive, especially after ISO 26262, embeds chain-of-liability clauses. The difference is that these sectors have had thirty years to build the practices; general-purpose software has five to seven years to do the same thing.
What are the five operational dimensions of the contractual transformation?
First, from contract-as-document to contractual documents as a related ecosystem (master contract, SLAs, security annexes, quality agreements, GDPR Article 28 data-processing agreements, coordinated vulnerability handling, supply-chain disclosure). Second, the limitation-of-liability clause, which remains valid between parties but produces no effects toward third parties (and forces a re-sizing of insurance policies). Third, rewriting subcontracting from initial approval to a continuous evaluation-and-disclosure procedure. Fourth, operational vulnerability- and incident-handling clauses, almost like contractual mini-runbooks. Fifth, product-lifecycle and end-of-support management, which exceed the duration of the contractual relationship.
Is there a connection between this piece and the three previous essays in the series?
Yes, this is the fourth and final piece of the series. Cruft, Not Patina argued that software does not know how to age. The Specification Debt shifted attention to the fact that the written specification has become the legally relevant asset of the product and that the industry lacks the tools to keep it alive. The Rise of the Compliance Engineer described the hybrid figure emerging to oversee the gap between engineering and regulation. This piece moves the argument to the plane of the relationship between organisations: the contract — the classic legal instrument of that relationship — is becoming one instrument among others within a wider device. The unifying thesis is that software, as an industrial and as a legal object, is changing nature before our eyes, and the engineering and commercial culture of the sector is not adapting at the speed the moment requires.
The author
