Software Update Evidence Checklist | ProductLiability.help

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

What the checklist is designed to establish

A software update evidence review should reconstruct the product's actual state and connect it to the alleged safety failure. An update being announced, downloaded and installed are separate facts. So are manufacturer control, defectiveness, covered damage and causation. Organising records around those questions produces a more useful account than collecting every available technical document without explaining its relevance.

The updates and post-sale liability framework explains their legal relationship under Directive (EU) 2024/2853. The corrected scope covers products placed on the market or put into service after 8 December 2026. National transposition is due by 9 December 2026. Start by identifying the relevant product and applicable national rules, rather than assuming that any incident involving an update falls within this Directive.

Identify the product and incident period

Record the device, application, model or relevant component, together with identifiers sufficient to distinguish the affected unit. Include the relevant market or first-use information needed for scope analysis. A product-family name may cover different hardware revisions or software branches. The evidence should make clear which one is being discussed and why it matches the incident.

Identify the reported incident time and the period over which the product state needs reconstruction. Distinguish confirmed dates from estimates and identify time zones where they affect the sequence. A general month of failure may be inadequate where a rollout changed the product during that month. Conversely, a precisely displayed timestamp should not be treated as accurate without understanding what event the system recorded.

Reconstruct the release and configuration state

Preserve relevant release identifiers before and after the update, along with configuration, dependency and service information. The displayed application version may not capture a separate firmware change or remote feature activation. Record enough context to explain the safety function at issue without assuming that every technical detail is relevant to the legal inquiry.

Distinguish contemporaneous records from later inspection. A device may have received further corrections, been restored or been replaced before examination. Those later states can provide evidence but should not silently substitute for the incident state. Where a version cannot be confirmed, explain the basis for any inference and the material that could resolve the uncertainty rather than presenting a likely release as established fact.

Map approval and manufacturer control

Identify who developed the change, approved it, supplied it and operated the delivery channel. Article 4(5) addresses specified manufacturer actions, authorisation or consent and the ability to supply updates directly or through a third party. Contracts, release approvals and practical permissions can each help answer different aspects of that definition.

Preserve the arrangement applicable during the relevant period, including changes to providers or support status. A current contract may not explain an earlier release, and technical access is not automatically authorisation of every action. Mere compatibility with third-party software is also different from consent to its integration. Connect each control record to the particular component or change being examined rather than relying only on broad supplier labels.

Trace delivery, installation and later reversal

Record the update's creation, release, offer, download, installation and activation where those stages matter. Identify product eligibility and any compatibility restrictions. A campaign-level success report may need to be compared with the affected device's records. State what an error message or status actually means before using it as evidence of installation, refusal or completion.

Include retries, pauses, withdrawals and rollbacks with their dates and observed results. A rollback may reverse only part of a change, while a later correction may alter the evidence available for inspection. Preserve the distinction between intended target state and confirmed outcome. An incomplete delivery history should remain incomplete in the account, with the missing question identified, rather than be filled by assumptions about normal operation.

Explain safety significance and causal connection

Identify the alleged unsafe condition and how the update introduced it, failed to correct it or affected a protective function. Article 7 considers safety in all circumstances, including presentation, foreseeable use, relevant interconnections and safety-relevant cybersecurity requirements. A newer or more convenient release alone does not establish that an earlier product was defective.

Connect the technical account to the reported harm and consider credible alternative explanations. The cybersecurity incident evidence assessment helps distinguish alerts, successful actions and safety effects. Article 10 starts with defectiveness, damage and causation, then provides specific rebuttable presumptions. A checklist cannot itself establish those conditions or convert an uncertain technical sequence into a legal finding.

Preserve the harm category and evidence limits

Record the actual injury, property damage or data destruction or corruption alleged, including relevant use of property and data. Article 6 contains specific categories and exclusions. Repair costs, inconvenience, professional downtime and loss of confidentiality should not automatically be grouped together as covered damage under this Directive. Other recovery routes can require a separate analysis.

For each important factual point, identify the supporting record, its source, any later interpretation and the remaining uncertainty. Article 9 disclosure is court-controlled, relevant and proportionate, with confidentiality safeguards. A focused account identifies missing material and why it matters without prescribing intrusive access or destructive testing. The completed checklist should show what the update evidence establishes and the precise issues it leaves open.

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 scope dates
Release, authority, delivery and reversal records
Evidence sources, covered harm and unresolved factual points

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.