Core claim: On 9 December 2026 the revised EU Product Liability Directive starts applying to software newly placed on the market — and because the directive rewards manufacturers who can evidence how their product was built, readiness is not a paperwork exercise you can do in the last week of November: the record you will need is the one you start keeping now.

What actually happens on 9 December

Directive (EU) 2024/2853 makes software — standalone, embedded, or delivered as SaaS — a “product” under EU product liability law. Member states must transpose it by 9 December 2026, and it applies to products placed on the market or put into service from that date; products already on the market stay under the old 1985 regime. In Denmark the implementation is underway: the Ministry of Justice consulted on a new product liability act in January 2026, and the bill now sits with the Parliament’s Legal Affairs Committee.

One boundary first, because it decides how the directive reaches you. The PLD compensates natural persons: death, personal injury, damage to property used for private purposes, and destruction or corruption of data not used exclusively professionally. It is not a general B2B damages regime — a business customer does not gain a new PLD claim against its software vendor. For B2B software makers the directive arrives indirectly but concretely: through products that do face consumer claims, with recourse flowing back up the supply chain to component and software suppliers, and through the evidentiary standard it sets for what a documented development process looks like once any court starts asking.

Two properties of the new regime matter for anyone shipping software. First, liability is strict — no negligence needs to be shown for a defective product that causes damage within that scope, and “damage” now includes destruction or corruption of (non-professional) data. Second, the evidentiary mechanics changed: a national court can order the manufacturer to disclose “necessary and proportionate” evidence about the product, and if the manufacturer fails to comply, the product’s defectiveness is presumed. Our pillar article on the directive walks through the mechanism in detail; the short version is that from December, the team that cannot show its work argues from the losing position.

The checklist

Ninety days is enough time to be ready — if the time is spent creating evidence rather than formatting documents. What follows is an engineering-readiness list, not legal advice; the legal review of your exposure belongs with counsel.

  1. Inventory what you place on the market. Every product with software in it, including SaaS and software delivered as updates to products already shipped. The 9 December line runs product by product, not company by company.
  2. Know your AI share. Which components, features and changes were authored or co-authored by AI tooling, and under whose review? “We don’t know” is the weakest possible answer to a disclosure order — and it is the honest answer in most codebases today.
  3. Start a contemporaneous development record. Who changed what, what review it passed, what tests it ran against — recorded at the time of change, append-only, verifiable by a third party. This is the single item on this list that cannot be done retroactively.
  4. Make your review process real and visible. A review that happened but left no evidence behaves, in a disclosure situation, like a review that did not happen. Coverage matters less than record-keeping discipline.
  5. Tie test evidence to releases. For each version you place on the market, be able to say which tests ran, when, and with what result — not as a CI dashboard that expires, but as a record that survives the tooling.
  6. Keep technical documentation per release. The Cyber Resilience Act’s reporting obligations begin 11 September 2026 and its documentation expectations point the same direction as the PLD: an SBOM, a described and evidenced development process, and a vulnerability-handling trail.
  7. Check your component provenance. Third-party and open-source components have their own liability story under the directive; free and open-source software supplied outside a commercial activity sits outside its scope, but the moment you ship it inside your product, its provenance is your problem.
  8. Rehearse the disclosure question. Give an engineer one hour and the question “show me how release X was built, reviewed and tested.” If the answer is a shrug, a wiki page from 2024 and three Slack threads, you have found your gap while it is still cheap.

Why September beats November

The items above split cleanly in two. Formatting exercises — the inventory, the documentation structure — compress fine; you can do them in a sprint whenever you like. Evidence does not compress. A development record started in September proves three months of real history by the deadline; one started the week before proves a week — and a record reconstructed after the fact proves nothing at all, because provenance is the one thing in software you cannot fix retroactively. The directive’s own defenses point the same way: the development-risk defense turns on what was known and checked at the time the product shipped, which is precisely the thing only a contemporaneous record can establish.

Ninety days out, the question is not whether you can write the documents in time. It is whether, on 9 December, your codebase has a history — or just a story.

This builds on article 1, “Who wrote your code? The provenance gap in AI-built software”, and on our pillar walkthrough of the directive, “Software is now a product”.

Sources