Preserve the system that existed at the incident
Evidence for a cloud-dependent product failure should connect the physical product, software, relevant services and actual harm. A screenshot of an error message rarely establishes that whole sequence. Directive (EU) 2024/2853 requires an assessment of defectiveness, damage and causation, subject to its evidence provisions. The records should explain those elements without assuming that the first visible outage caused the incident.
The SaaS and cloud services framework identifies the legal questions. This article focuses on reconstructing a changing technical environment. Preserve available original evidence lawfully and safely, and record mitigation separately. Continuing a dangerous operation merely to reproduce an error can create further harm. Necessary safety action should proceed with a clear record of what was changed and when.
Establish product identity and historical state
For a device, record model, serial number, firmware and relevant installed components. For software, preserve build identifiers, customer cohort and configuration. For a remote backend, identify the service version or deployment that processed the relevant operation. The incident-time account is more useful than a current inventory if releases or integrations changed after the event.
A repository commit does not establish what was deployed. Compare build records, deployment logs and request-level identifiers. Feature flags, reference tables and tenant settings can alter behaviour without changing the main software version. Record whether evidence establishes a value directly or reconstructs it from a later snapshot. If the historical state cannot be recovered, retain that limitation rather than presenting today's system as an exact substitute.
Connect events across the dependency chain
Create a chronology separating user action, request submission, processing, response, device action and observed harm. Record time zones and clock differences. A status page may use monitoring detection time, while a device records a local time without a reliable clock. Match events using request identifiers and other corroboration where available, rather than treating similar timestamps as conclusive proof of a shared transaction.
Preserve the relevant input, transmitted values and acknowledgements. An acknowledgement might confirm receipt but not execution. A timeout might conceal an action that completed after the caller stopped waiting. The explanation of API failures and product liability shows why those distinctions matter. The chronology should state where the available records stop and where a causal inference begins.
Record functional dependence and manufacturer control
Map what the product could and could not do without each relevant service. Include local fallback behaviour, cached instructions and recovery. A loss of a remote dashboard may differ from loss of actual control. Evidence of product presentation, integration approval and supplier selection helps establish whether the service was part of the relevant product relationship rather than an independent user-added connection.
Control records can include authorised release approvals, commissioning documents and contractual descriptions of update responsibilities. They should be compared with actual conduct. Administrator access alone does not prove legal authority, while outsourcing does not necessarily place a related service outside manufacturer control. Identify the business, action and date supporting each control proposition so later reviewers can assess the proposed role rather than relying on an unexplained supplier list.
Preserve harm evidence independently
Record the damaged interest separately from system logs. Physical inspection, photographs, maintenance records and appropriate medical evidence answer different questions from a cloud error trace. Article 6 covers specified damage and exclusions, so the file should distinguish damage to the defective product from damage to other property and distinguish non-professional data corruption from temporary inaccessibility or professional data loss.
For alleged data damage, identify what changed, relevant backup states and whether the information was used professionally. Preserve provenance and avoid modifying the only surviving copy during recovery attempts. For property damage, record the item's use and relationship to the allegedly defective component. A technical service incident does not prove covered damage merely because a customer attaches a substantial financial estimate to it.
Understand court-controlled disclosure
Article 9 provides for relevant evidence disclosure in national-court proceedings under stated conditions, including facts and evidence supporting the plausibility of the claim. Disclosure is limited by necessity and proportionality, with protection for confidential information and trade secrets. It is not a general right to demand every provider log or access unrelated customers' data outside the applicable procedure.
A focused evidence request identifies the issue, the likely record holder and the time window. A request for the deployment handling a specified device event is more informative than a demand for the provider's entire cloud account. Article 9 also addresses defendant requests for relevant claimant evidence and understandable presentation. National rules govern procedure and may separately address pre-trial evidence mechanisms.
Keep proof and presumptions separate
Article 10 begins with the claimant proving defectiveness, damage and their causal link. Later paragraphs establish conditional, rebuttable presumptions, including specified consequences of failure to disclose relevant evidence. Technical complexity or missing logs do not automatically establish every condition. Record why a proposed presumption is considered relevant instead of using uncertainty as an automatic finding against a supplier.
An organised evidence file should end with a supported account, not merely a large document collection. Separate direct observations, technical interpretations and legal questions. Note gaps, retention limits and plausible alternative causes. Product timing, national implementing law and procedural deadlines require separate assessment. The value of cloud evidence lies in linking the actual product state to the actual harm while making the limits of that link visible.
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.
- Incident-time software, device and deployment identifiers
- Functional dependency and authorisation records
- Original logs with timestamps and recorded limitations
Independent educational information at EU Directive level. National implementing law, product timing 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.
- Directive (EU) 2024/2853, consolidated text: Articles 4, 6, 7, 8, 9, 10, 11 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.