Software Product Liability Investigation Checklist

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

Start with safety and a clear account of the event

A software product liability investigation should connect the product state, alleged unsafe behaviour, covered harm and responsible actors. It should also preserve competing explanations. Directive (EU) 2024/2853 does not make a crash report, a known bug or a missing log a complete claim. A checklist helps organise evidence for assessment rather than certify that the legal conditions have been satisfied.

The software product liability framework explains those conditions. Before collecting technical records, address any continuing danger and record immediate protective action. Do not repeatedly operate a potentially unsafe device merely to reproduce the failure. Where a reset, repair or shutdown is necessary, document it and explain which historical information may have been changed or lost as a result.

Identify the product and relevant dates

Record the product name, manufacturer or publisher, serial or account identifier where appropriate, hardware revision and software release. Identify the relevant supply route and evidence of market placement or first use. The corrected Article 2(1) concerns products placed on the market or put into service after 8 December 2026. The national transposition deadline is 9 December 2026 and has a separate legal purpose.

Do not choose the new framework from the accident date alone. Record later software supply, integration or modification without assuming every change creates a new product. If several products are involved, list them separately and explain their functional relationship. National implementation and governing-law questions need their own official-source research instead of an assumption that every Member State has already adopted identical operative rules.

Describe the alleged unsafe mechanism

State what the software received, what it did and what result followed. Identify the safety function allegedly absent or ineffective. A useful description might distinguish an incorrect calculation from an ignored sensor input or a command that was transmitted but not executed. Label untested explanations as hypotheses and retain evidence inconsistent with the preferred account.

Assess Article 7's relevant circumstances, including design, presentation, instructions, foreseeable use, interactions and safety requirements. A failed feature is not automatically a safety defect. A later improved release does not alone prove earlier defectiveness. Identify the safety expectation and the facts supporting it so that the investigation does not substitute a general quality complaint for the legal inquiry.

Classify each alleged harm separately

Article 6 covers death and personal injury, including medically recognised psychological harm, specified property damage and destruction or corruption of data not used professionally. Record the harmed person, the nature and date of harm, supporting medical or technical evidence and restoration or repair facts where relevant. Avoid combining different people's losses before classification.

The defective product itself is excluded from the property category, which also excludes a product damaged by an integrated defective component in the stated circumstances and property used exclusively professionally. Professional data fall outside the stated data category. Business downtime and an unusable product may raise other legal routes, but should not automatically be labelled covered damage under this Directive.

Preserve the actual incident-time software state

Collect the release identifier and the corresponding artefact where available, together with configuration, dependency versions and relevant service state. Record acquisition method and integrity information. A current download or a visible version label may not identify the executable that operated during the incident. Keep original records separately from working copies and record examination steps that could alter them.

The version history evidence guide explains how to link approval, distribution, installation and activation. Keep these events distinct. A release available before an incident might have been activated afterward. Feature flags or rollout groups can also change behaviour without changing the installed version. Document the sources used to reconstruct the active state and their limits.

Identify actors and control without assuming responsibility

List the software developer or producer, branded supplier, component suppliers, integrator and any relevant later modifier. Preserve commercial supply and authorisation records. Article 8 addresses economic operators under particular conditions; a dependency list is not itself a list of liable parties. A component manufacturer's role and the finished-product manufacturer's role need separate assessment.

Map who authorised or consented to integration or modification and who could supply software changes. Article 4's manufacturer-control definition and Article 11(2)'s limits on certain exemptions can make those facts important after supply. Non-commercial free and open-source software has a specific Article 2(2) exclusion. Record upstream and downstream commercial circumstances rather than deciding scope from the licence label or purchase price alone.

Construct and test a common chronology

Combine device logs, application events, deployment records, service reports and witness observations. Record time zones, clock sources and known offsets. Explain whether a timestamp records an action, its completion or later collection. Apparent sequence can be misleading when clocks differ. Preserve uncertainty instead of manufacturing a precise chronology from incompatible records.

Test alternative explanations against the same evidence. Hardware faults, external inputs, network failure and configuration may contribute alongside code. Controlled reproduction should identify the software, hardware, settings and inputs used and any differences from the original event. Keep unsuccessful results. A successful reproduction supports a mechanism under stated conditions but does not independently prove every claimed loss or legal requirement.

Frame missing evidence as focused questions

Article 9 permits relevant court-controlled disclosure under conditions including claim plausibility, necessity, proportionality and confidentiality safeguards. Identify the specific missing release record, configuration value or test result and explain why it matters. The provision does not grant automatic access to every source repository or unrelated customer record. Keep access lawful and information collection relevant to the issue.

Article 10 starts from proof of defectiveness, damage and causation, subject to specified rebuttable presumptions. Excessive technical difficulty has legal conditions rather than acting as a universal presumption for all complex software. The product evidence record mapper can help organise a starting checklist without receiving case documents. Finish the investigation with a record of established facts, supported hypotheses, contrary evidence and unresolved gaps. That reviewable account gives technical and legal advisers a concrete basis for deciding the next evidential or procedural step.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

Product identity and supply-date evidence
Incident release, configuration and dependency state
Separate evidence for each alleged harm
Actor, authorisation and control map

Independent educational information at EU Directive level. National implementing law and procedure require separate review.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.