The PLD Disclosure-of-Evidence Duty: Why Your Logs and Design Docs Are Now Litigation Discovery

Under the revised Product Liability Directive, a claimant can ask a court to order you to hand over your logs, your design documents and your test records — and if you cannot produce them, the court may presume your product was defective. Your evidence hygiene has quietly become a litigation strategy.

Most commentary on Directive (EU) 2024/2853 fixes on the headline: software is now a product, and a missing security update can be a defect. That is real, and I have written about it elsewhere. But the provision that will actually decide cases is quieter and more procedural. It is the disclosure-of-evidence duty in Article 9, read together with the presumptions in Article 10. Between them, they turn your internal technical record into discoverable material and make an inability to produce it work against you. For a CTO, this is not a legal footnote. It is a records-engineering problem with a deadline.

What Article 9 actually lets a claimant do

The old regime put the evidential burden squarely on the injured party. If you were hurt by a product, you had to prove the defect, the damage and the causal link — often without any visibility into how the thing was built. For software, embedded systems and connected devices, that was frequently impossible. The claimant simply could not see inside the box.

Article 9 rebalances that. Where a claimant presents facts and evidence sufficient to support the plausibility of a claim, a national court can order the defendant to disclose relevant evidence at its disposal. Disclosure is bounded — it must be necessary and proportionate, and the directive requires courts to protect confidential information and trade secrets with specific measures. But the boundary is proportionality, not the mere fact that the material is internal, sensitive or commercially awkward. “We would rather not” is not a defence. The duty runs both ways, so a claimant can be ordered to disclose too, but the practical weight falls on the party that holds the technical record: you.

And “evidence” here is broad. It is not just the formal design dossier. It reaches emails and messages, test results, change logs, incident records and machine data — including metadata that never appears on anyone’s screen. If it exists and it is relevant, it is potentially disclosable.

The penalty for not having it

Here is the part that changes the engineering calculus. Article 10 sets out a series of rebuttable presumptions, and the first of them bites directly on disclosure. Where a defendant fails to comply with an order to disclose relevant evidence under Article 9, the court may presume the product defective. Not “may draw an adverse inference” in some vague sense — the defect itself is presumed, and the burden flips to you to rebut it.

Read that against how technology organisations actually keep records and the exposure becomes obvious. Logs rotated out after thirty days. Design decisions that live in a Slack thread and a departed engineer’s memory. A CI pipeline that overwrites build artefacts. A threat model last updated two products ago. None of that is unusual. Under the old law it was invisible. Under the new law, an inability to reconstruct what you knew and did, when a court asks, is no longer a neutral gap. It is a fact the claimant can convert into a presumption of defectiveness. Poor record-keeping stops being your problem and becomes their argument.

The record you should be able to produce

The goal is not to keep everything forever — that is its own liability and its own cost. The goal is to hold, in a retrievable and trustworthy form, the specific artefacts that answer the questions a defect claim turns on: what the product was supposed to do, what you knew about its risks, what you tested, and what you changed and when. In practice that means being able to produce:

• Design and risk documentation, versioned. The requirements, the architecture decisions, the threat models and the risk assessments — tied to the specific product version that was on the market, not a rolling document that has since moved on.
• Test and validation records. What was tested, against what criteria, with what result, for the release that shipped. “We test thoroughly” is not evidence; a retained test report for build 4.2.1 is.
• A defensible change and build history. An immutable, timestamped record of what changed, who approved it and when it reached the field — including the security updates you did and did not ship.
• Operational and incident logs with real retention. Runtime logs and incident records held long enough to reconstruct behaviour after a claim surfaces, which can be years, not the ninety days your logging bill defaults to.
• Integrity you can attest to. Evidence is only useful if you can show it was not edited after the fact. Write-once storage, hashing or signed logs turn “here is a document” into “here is a document a court can trust.”

This is the same instinct that runs through the Cyber Resilience Act’s product duties: the regulator, and now the claimant, expects you to be able to demonstrate what you did, not merely assert it. The artefacts overlap heavily. A firm building a defensible technical file for the CRA is most of the way to building one for the PLD.

Why this is a retention-design decision, not a legal one

The temptation is to hand this to legal and let them draft a policy. That produces a document, not a capability. Whether you can actually satisfy an Article 9 order is decided by architecture: what your systems log, how long they keep it, whether the design record is bound to the shipped version, and whether any of it can be trusted six years later. Those are choices made in the platform, the CI/CD pipeline and the data-retention configuration — by engineers, long before a claim exists.

It is also a decision with a firm date attached. Member States must transpose the directive by 9 December 2026, and it applies to products placed on the market after that point. Anything you ship from then carries the disclosure exposure for as long as the liability window runs. The record has to exist from the moment the product ships, because you cannot retrospectively generate a log you never kept. The work of deciding what to retain, and building the systems that retain it, has to happen now — which is exactly why the 9 December 2026 transposition deadline is an engineering milestone, not just a legal one.

The firms that will struggle are not the ones with defective products. They are the ones with defensible products and no way to prove it — who did the right engineering and cannot reconstruct the record, and so watch a presumption of defect fill the space where their evidence should have been. Treating a missing update as a defect is one exposure I have covered before. This is the other side of it: even when you were right, the burden is now on you to show it, on demand, from records you decided to keep long before anyone asked.