Proof: Disclosure, Presumptions, and the Complexity Rule

Strict liability removes fault from the case. It does not remove proof.

Under Article 10 the claimant must prove three things: that the product was defective, that damage occurred, and that there is a causal link between the two. Nothing about negligence, intent or reasonable care enters.

For a kettle that caught fire, this is workable. The product is in front of the court, an expert examines it, and the failure mode is legible.

For software it collapses. The claimant does not have the source, the build pipeline, the test results, the threat model, the internal bug tracker, or the decision record explaining why a known issue was deprioritised. All of it sits with the defendant. A regime that says prove the defect while the evidence of the defect is exclusively in the defendant's possession is a regime that does not function.

Articles 9 and 10 exist to fix that asymmetry, and they are the most consequential part of the reform for software vendors.

Article 9 lets a court order a defendant to disclose relevant evidence at its disposal.

The trigger is a plausibility threshold rather than a proven case. The claimant must present facts and evidence sufficient to support the plausibility of the claim for compensation. That is deliberately lower than proving defectiveness, because proving defectiveness is what the disclosure is for.

The court controls scope. Disclosure must be limited to what is necessary and proportionate, and the court assesses that against the legitimate interests of all parties, including third parties.

Trade secrets are protected, not excluded. Where evidence constitutes or may constitute a trade secret, the court takes specific measures to preserve confidentiality: restricting who may access the material, limiting hearings, and producing redacted versions of decisions. Confidentiality is a handling regime, not a ground for withholding.

The power is symmetric. A defendant may likewise seek disclosure of relevant evidence at the claimant's disposal.

Article 10 then presumes defectiveness in three situations, each shifting the argument to the defendant.

First, where the defendant fails to comply with an obligation to disclose relevant evidence at its disposal. Non-disclosure is not a neutral tactical choice. It produces the finding the disclosure was meant to test.

Second, where the claimant demonstrates that the product does not comply with mandatory product safety requirements laid down in Union or national law that are intended to protect against the risk of the damage suffered. Note the fit condition: the requirement breached must target the risk that materialised. Breaching an unrelated labelling rule does not help.

Third, where the claimant demonstrates that the damage was caused by an obvious malfunction of the product during reasonably foreseeable use or under ordinary circumstances. This is the res ipsa route: products that work properly do not do that.

The defendant retains the right to rebut each presumption.

Defectiveness and causation are separate elements, and a claimant can establish the first while failing on the second. Article 10 narrows that gap.

Where it has been established that the product is defective and the damage caused is of a kind typically consistent with the defect in question, causation is presumed.

The phrase doing the work is typically consistent. It asks whether this kind of defect ordinarily produces this kind of harm. A memory corruption flaw in a motor controller is typically consistent with unintended actuation. It is not typically consistent with a data breach three months later on a different system.

So the presumption is a matching rule, not a general bridge. A claimant who proves a defect still has to point to harm of the type that defect characteristically causes.

Where the fit is clear, the defendant now has to prove that something else caused the damage, rather than merely observing that the claimant has not proved it did.

The most far-reaching provision comes last, and it inverts an advantage defendants have always held.

Where a court judges that the claimant faces excessive difficulties, in particular due to technical or scientific complexity, in proving defectiveness or the causal link or both, that element is presumed, provided the claimant has demonstrated that it is likely that the product is defective or that there is a causal link, or both.

Read what this does. Complexity used to be a defence in substance if not in name. The more intricate the system, the harder it was for a claimant to explain what went wrong inside it, and the more likely the claim failed for want of proof.

Now complexity is a trigger. If a system is so intricate that proving the defect is excessively difficult, that difficulty helps the claimant.

Two guards remain. It applies only after disclosure under Article 9, and the claimant must still show likelihood. The defendant may rebut.

The provisions form a sequence, and a claimant only descends as far as needed.

The starting position is the general rule: prove defect, damage and causation. A claimant with a legible failure and access to the product may never move past it.

If the evidence is inside the defendant, the claimant meets the plausibility threshold and seeks disclosure under Article 9. That step either produces the evidence or, on non-compliance, produces a presumption of defectiveness directly.

With evidence in hand, two shortcuts may apply: non-compliance with a safety requirement aimed at the risk that materialised, or an obvious malfunction in ordinary use. Either presumes defectiveness.

Once defectiveness is established, causation is presumed where the damage is of a kind typically consistent with that defect.

And if difficulty persists after all of that, the complexity rule presumes whichever element remains unproved, on a showing of likelihood.

Every presumption in the chain is rebuttable by the defendant.

Put the pieces together and the defensive posture inverts.

Under the old regime a software defendant benefited from three structural advantages: the argument that software might not be a product at all, an evidentiary asymmetry that made defects hard to demonstrate, and complexity that made causation harder still.

All three are now closed. Software is a product. Disclosure is available on a plausibility showing. Complexity triggers a presumption rather than defeating a claim.

What replaces them is the quality of your own record. Every presumption in Article 10 is rebuttable, and the material that rebuts it is the material you generated while building and maintaining the product.

A manufacturer that can show a documented risk assessment, the reasoning behind a design choice, test evidence, and a defensible record of how a known issue was triaged is in a strong position. One that produces nothing, or discloses reluctantly, meets a presumption of defectiveness before the technical argument begins.

Exposure is bounded in time by two independent limits, and they run differently.

Article 16 sets a limitation period of three years for bringing proceedings, running from the day the injured person became aware, or should reasonably have become aware, of three things together: the damage, the defectiveness, and the identity of the liable economic operator. All three must be known, so a claimant who suffers harm without knowing its cause has not started the clock.

Article 17 sets an expiry period that runs regardless of awareness. Rights expire ten years after the actual defective product was placed on the market or put into service, or after it was substantially modified.

One derogation extends that. Where an injured person has been unable to bring proceedings within ten years because of the latency of a personal injury, the expiry period is twenty-five years.

The first is a discovery rule that protects claimants. The second is a long-stop that eventually protects defendants.

A ten-year expiry sounds like a firm horizon. For continuously developed software it is softer than it looks, for two reasons.

The period runs from when the actual defective product was placed on the market, and it restarts on substantial modification. A product that is substantially modified in year eight carries exposure into year eighteen for the modified version. A product under active development can therefore be perpetually within a fresh ten-year window, with different versions expiring on different dates.

And the awareness-based limitation period interacts with this. Software defects can lie dormant for years before anyone connects a harm to its cause, so the three-year clock frequently starts late.

The planning consequence is concrete. Records generated today may be the evidence in a claim brought well over a decade from now, long after the code has been rewritten and the team dispersed.

Retention policies written around ordinary commercial horizons are the wrong length for this.

Since presumptions are rebutted with contemporaneous records, it is worth naming what a defensible file contains. Most of it already exists as a Cyber Resilience Act obligation, which is the practical argument for treating the two regimes as one programme.

The risk assessment, versioned, showing what threats were considered and what was decided. Design rationale for security-relevant choices, including options rejected and why. Test and review evidence, dated. The software bill of materials per release, so you can answer which version contained which component.

The vulnerability record: what was reported, when you became aware, how it was triaged, what was shipped and when. Decisions not to fix, with the reasoning recorded at the time rather than reconstructed. Advisories and customer communications as issued. The support period and the basis for choosing it.

One principle governs all of it. A judgement documented when it was made is evidence. The same judgement explained afterwards is argument.