Cloud supply does not identify a single legal role
A third-party cloud provider is not automatically liable for every product failure involving its infrastructure. Under Directive (EU) 2024/2853, the analysis turns on what the provider supplied, its relationship with the product and the alleged defect and harm. Hosting, software development and providing a product-dependent digital service can be different activities, even where one business performs several of them.
The SaaS and related-services framework explains the wider product and service distinctions. Begin with a supply map rather than the names on invoices. The visible application brand, software producer, connected-device manufacturer and infrastructure operator can each occupy different roles. A contract describing one party as a processor or subcontractor is useful evidence of the arrangement but does not conclusively determine statutory responsibility.
Identify the allegedly defective supplied element
Article 4 includes software as a product and defines components and related services. A provider that develops the relevant software may therefore require a different analysis from one renting generic computing capacity. Where a digital service is essential to a product function, examine the related-service definition and connected-system relationship. The term cloud should not substitute for that functional and supply analysis.
Record whether the provider supplied application logic, a device-specific backend, storage, network connectivity or another service. Identify the particular element alleged to have made the finished product defective. A platform-wide interruption might affect several elements simultaneously, but that does not establish the causal role of each. The same cloud business may be relevant in one capacity and irrelevant in another for the incident under investigation.
Establish integration within manufacturer control
Article 8(1) addresses defective component responsibility where the component was integrated into or interconnected with the product within manufacturer control and caused that product to be defective. It also addresses the finished-product manufacturer's liability. Article 4(5) and recital 18 explain important control concepts, including authorisation or consent to third-party integration or supply. Outsourcing therefore does not automatically end the final manufacturer's potential responsibility.
Evidence can include integration agreements, product specifications, release approvals and the way the service was presented to users. Mere technical compatibility does not by itself establish consent. Nor does a provider's ability to change infrastructure demonstrate that the final product manufacturer authorised every resulting change. Separate technical capabilities, contractual powers and actual approvals so that the control finding rests on conduct rather than assumptions about the cloud model.
Apply Article 8 rather than generic blame
Identify the manufacturer of the allegedly defective product and any relevant defective component. Article 8 also contains routes involving importers, authorised representatives, fulfilment providers, distributors and certain platforms, with specific conditions. A cloud supplier's presence in the commercial chain does not make every route applicable. The location of a business and the nature of what it supplied both need evidence.
If a product manufacturer and component manufacturer are liable for the same damage, Article 12 addresses joint and several liability. Article 14 deals separately with recourse between operators, subject to national law. Those rules should not be collapsed into an assertion that the injured person must first solve the suppliers' contract dispute. Conversely, the existence of a subcontract does not establish that both parties are liable without satisfying the underlying conditions.
Read contractual allocations within their proper scope
Service-level commitments, warranties and indemnities can explain agreed tasks and allocation of costs. They can also identify who was expected to retain logs or approve a deployment. Article 15 prevents liability towards the injured person under the Directive being excluded or limited by contractual terms or national law. A liability cap in a business contract therefore should not be presented as settling that person's statutory rights.
This does not make the contract irrelevant or remove other legal limits. A contractual claim may address downtime or business loss outside Article 6, while the product liability analysis requires qualifying harm. Separate the claimant, defendant and remedy for each route. A provider could meet an availability promise yet supply defective software, or breach an availability promise without causing covered product liability damage.
Connect the provider's conduct or supplied defect with harm
Preserve evidence identifying the incident-time product state, relevant provider service and failure sequence. A customer's device may fail unsafely during a cloud outage because of its local fallback design. Alternatively, a defective remote instruction may cause the unsafe response. Those are different causal theories. The fact that the cloud provider experienced an incident does not establish which explanation applies.
Article 10 starts from proof of defectiveness, damage and causation, with conditional presumptions. Article 6 excludes pure economic loss as a standalone category, professional data and specified property interests. Severe commercial disruption is therefore not enough by itself. Identify the actual injured person, damaged interest and causal mechanism before describing the provider as liable, and preserve evidence supporting competing explanations as well as the initial allegation.
Preserve a role map that can be reviewed
For each relevant business, record the legal name, supplied object, product relationship, control evidence and source of those findings. Include effective dates because providers and subcontractors can change during a product's life. Distinguish observed facts from contractual statements and unresolved identity questions. The investigation should make it possible to see why a particular legal role is proposed.
National implementing law and procedure determine important aspects of pursuing or allocating claims. Corrected temporal scope also remains separate from the cloud provider's current service terms. A useful conclusion identifies potentially relevant operators and the conditions still needing proof. It does not treat the nearest visible cloud brand as universally responsible or assume that outsourcing removes the product manufacturer's responsibility.
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, 10, 11, 12, 14, 15 ↗
- 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.