Readiness means being able to explain the product
SaaS product liability readiness means having a usable account of the software, its dependencies, control and safety evidence. It does not mean assuming every outage creates liability or obtaining a universal compliance certificate. Directive (EU) 2024/2853 requires several distinct legal elements, and good records help separate them. This checklist is a practical review structure rather than an assertion that every listed document is legally mandatory.
Use the SaaS and cloud services framework to establish the legal context before collecting records. Apply the review to a defined product and supply arrangement, then identify gaps. A broad company-wide statement that the platform is secure or reliable rarely explains the specific release, integration and safety consequence involved in a later incident.
Identify the product and supply dates
Describe what the software does, who develops or presents it as their product and how it reaches users. Distinguish executable software from displayed information, human support and general infrastructure. Where a connected device is involved, identify the device and its relevant functions. Keep software product classification separate from the question whether an associated digital service meets the related-service definition.
Retain records of first supply and relevant subsequent changes. Corrected Article 2(1) concerns products placed on the market or put into service after 8 December 2026; national transposition is due by 9 December 2026. A later subscription payment or incident does not by itself establish the relevant product date. Continuous supply and substantial changes may require closer analysis rather than an automatic assumption that each release restarts every rule.
Map dependencies and control
Create a functional dependency map showing what happens if each service is absent. Identify local safeguards and recovery behaviour. A backend necessary for remote regulation may require a related-service assessment, while ordinary internet access is distinguished in recital 17. Record what evidence supports each function claim, using product documentation and tested behaviour where appropriate.
Create a separate control map covering development, approval, deployment and integration. Article 4(5) concerns specified manufacturer actions and capabilities; supplier names alone are insufficient. Preserve records of authorised third-party integration and update arrangements. Also note customer-created or unsupported connections, without assuming that mere technical compatibility demonstrates consent. A useful map allows a reviewer to see who could change the relevant behaviour and who authorised it.
Review safety across failure and recovery
Consider foreseeable loss of connectivity, delayed responses, duplicate requests, stale values and mismatched units. These are review prompts, not findings that the product has those faults. Article 7 requires an all-circumstances safety assessment, including relevant interactions, intended users and safety-relevant cybersecurity requirements. Link each identified hazard to evidence about the product's safeguards and remaining uncertainty.
Assess recovery as well as normal operation. Queued instructions may run after connectivity returns, old settings may remain cached and a rollback may affect only part of the system. Record what the product is intended to do safely in those conditions and what testing supports that expectation. A favourable uptime percentage does not establish the safety of every failure mode, just as an outage does not establish a defect by itself.
Make incident-time reconstruction possible
Retain version and deployment identifiers with sufficient context to connect them to the affected account or device. Include configuration, feature flags and relevant dependency versions where they change behaviour. Decide which logs are useful, who holds them and how retention and access work within applicable law. Avoid keeping indiscriminate personal data merely because it might someday be useful.
The cloud-dependent failure evidence guide explains how to assemble a chronology across systems. Plan for clock differences, missing identifiers and provider retention limits. Preserve original evidence with provenance, and use controlled copies for analysis. A current software repository and a public status page rarely provide a complete historical record of the product state that processed a particular request.
Separate damage routes before describing exposure
Article 6 covers personal injury, certain property damage and destruction or corruption of non-professional data, with important exclusions. Temporary loss of access, professional data loss and pure business interruption are not automatically covered categories. Distinguish the defective product itself and certain integrated-product damage from other property. Keep contractual service credits and other national remedies in their own analysis.
This separation helps incident intake. Ask what was harmed, how the alleged damage is evidenced and which product behaviour is said to have caused it. A complaint about a missed invoice deadline needs a different route from an allegation that a remote control fault caused injury. The purpose is accurate classification, not rejecting or accepting a claim before the facts and applicable law have been established.
Define escalation and evidence responsibilities
Identify who can preserve releases, settings, supplier records and relevant physical evidence when a safety allegation arrives. Record mitigation decisions and the technical state before and after changes. Restoration may be urgent, but an undocumented fix can remove the best explanation of the incident. Clear responsibilities reduce the risk that each supplier assumes another is preserving the relevant evidence.
Article 9's disclosure mechanism and Article 10's proof rules require their own procedural assessment. Trade secrets and personal information also need proportionate handling. Review national implementing law and product-specific safety duties through appropriate sources rather than treating this checklist as a legal opinion. Readiness improves when the organisation can provide a coherent, sourced account of its product, its control and the limits of its evidence.
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 2, 4, 6, 7, 8, 9, 10, 11, 21, 22 ↗
- 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.