Software can be a product despite the subscription model
Software supplied through a software-as-a-service model can fall within the product concept in Directive (EU) 2024/2853. Article 4(1) expressly includes software. Recital 13 explains that the means of supply or use should not determine that classification, including network access and SaaS. That does not make every activity performed by a subscription business a product, or every service failure a compensable product defect.
The useful first question is what allegedly failed. It might be executable software, a product-dependent digital service, a human support activity or a communication connection. Each layer needs its own description. The SaaS and cloud software framework connects classification with defectiveness, damage and responsibility. Calling the whole arrangement a service, or calling it software, cannot answer those later questions by itself.
Identify the software, network delivery and execution
Software can be downloaded, accessed over a network or executed on cloud servers while a browser displays the result. A connected appliance may receive remotely calculated instructions without downloading the calculation program. Record where the relevant operation happened, what executable software performed it and who supplied it. The visible screen may only transmit requests; it does not necessarily contain the software alleged to have produced the harmful result.
Distinguish the application from information it displays. Recital 13 separates software from the content of digital files, such as media files and electronic books, and mere source code. A hosted document library and the program managing its storage are different objects of analysis. A wrong statement inside a document should not automatically be reclassified as a defective software product simply because it appeared through a browser.
Classify connected services separately
A digital service integrated into or interconnected with a product can meet the related-service definition where its absence prevents at least one product function. This is not a requirement that the entire device becomes useless. Nor is it satisfied merely because two businesses exchange data. The product, its relevant function and the consequence of the service's absence must be established.
For example, a cloud controller might supply commands needed for a domestic device to regulate temperature. An unrelated subscription newsletter about efficient energy use has a different relationship with that device. The canonical explanation of connected products and related services develops this functional test and its internet-access boundary. Software product classification and related-service classification can coexist within one commercial offering without becoming interchangeable.
Establish safety defectiveness and qualifying damage
Article 7 concerns the safety a person is entitled to expect or that law requires. A slow dashboard, disappointing feature or inaccurate invoice does not establish an unsafe software product on its own. Explain the asserted safety shortfall and the circumstances supporting it. Product presentation, foreseeable use, integration with other products and relevant cybersecurity requirements may matter, depending on the actual system.
Article 6 then requires a covered damage category. These include personal injury, certain property damage and destruction or corruption of data not used for professional purposes. Damage to the defective product itself and exclusively professional property fall within exclusions. The data exclusion is broader than the property exclusion: data used for professional purposes do not qualify simply because they also have a personal use.
Why business interruption is a separate issue
A business might lose substantial revenue when a hosted stock-management tool stops responding. The value of that interruption does not itself establish qualifying damage under the Directive. Pure economic loss is not an additional Article 6 damage category. Material losses resulting from covered damage require a different analysis from loss of revenue standing alone. Contract, negligence and other national remedies remain separate questions.
A consumer photo application presents another possibility. If an alleged software defect destroys non-professional family photographs, the data damage category may warrant assessment. Temporary inability to view intact photographs is different from destruction or corruption. In either situation, software classification is only a first step: defectiveness, causation, the appropriate operator and applicable law still need supporting evidence.
Map responsibility and incident-time operation
Identify the software developer or producer, any own-brand manufacturer and the relevant integrated components. The company collecting subscription payments is not necessarily the only legally relevant operator. Article 8 establishes responsibility routes and conditions. Outsourced hosting does not automatically make the infrastructure provider the software manufacturer, while contractual division of tasks does not replace the statutory role analysis.
A SaaS application may change between the incident and the first complaint. Preserve release identifiers, feature flags, tenant settings and relevant service records. Record who authorised each change and whether the affected customer received it. A public release announcement can conceal a gradual rollout. Testing today's application without documenting the earlier state may answer a different technical question from the one the incident presents.
Apply the correct legal and temporal scope
The corrected Article 2(1) applies the Directive to products placed on the market or put into service after 8 December 2026. The national transposition deadline is 9 December 2026. A later incident date alone does not bring an older product into that scope. Continuous SaaS supply can raise specific product-identification and timing questions that require more analysis than the date printed on a monthly invoice.
This explanation remains at Directive level. It does not assert that a particular Member State has implemented the rules or that a specific subscription dispute succeeds. A reliable assessment ends with separate findings about the software, any related service, product timing, safety issue, covered harm and causal mechanism. Uncertainty about one element should remain visible instead of being hidden behind the general statement that SaaS is a product.
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, 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.