Safety requirements inform the safety assessment
Relevant product-safety requirements, including safety-relevant cybersecurity requirements, are expressly included in Article 7(2)(f) of Directive (EU) 2024/2853. They can help identify the protection a product should provide. The inquiry starts by identifying the actual requirement and its relationship to the product and risk. A reference to regulations generally is insufficient because different instruments address different products, activities and hazards.
The defectiveness test considers all circumstances, including both expected safety and safety required under Union or national law. Compliance evidence is therefore important but has a defined scope. A passing test does not automatically establish safety in every situation, and a document irregularity does not automatically establish an unsafe defect causing harm. Explain what the evidence proves before drawing wider conclusions.
Distinguish legal rules from technical documents
A binding legal requirement is not the same as a voluntary standard, internal specification, test method or certification scheme. Some standards can support a legally recognised presumption of conformity within a particular regulatory regime, but the basis and limits of that effect must be checked. Do not describe every technical recommendation as mandatory law or every certificate as a government determination of safety.
Record the instrument, provision, version and relevant dates. Then establish why the requirement applies to the product category and activity. A rule addressed to placing a product on the market may raise different questions from one concerning continued operation or workplace use. National provisions can also matter, but their current status should be verified rather than inferred from a general EU summary.
Match the rule to the alleged hazard
The strongest analysis explains what risk the requirement is intended to prevent. A protective-temperature requirement may be relevant to burns or fire, while a traceability provision serves a different immediate function. Both can be important, but they should not be treated as evidentially interchangeable. Identify the required safety outcome and the product characteristic alleged to fall short.
This relationship is especially important for regulatory non-compliance and defectiveness. Article 10(2)(b) requires demonstrated non-compliance with mandatory product-safety requirements intended to protect against the risk of the damage suffered. The provision does not refer to every legal obligation imposed on a manufacturer. Its safety and damage-risk conditions should be stated expressly when the presumption is discussed.
Read test evidence within its limits
A test report should identify the sample, configuration, method, acceptance criterion and conditions. Ask whether those conditions correspond to the alleged risk. A product may pass a test directed at ordinary operation while the incident concerns a foreseeable fault condition not examined by that method. Conversely, a test conducted outside relevant conditions may not justify a broad allegation of non-compliance.
Dates and revisions matter. A certificate for one hardware revision may not describe another, and a laboratory report concerning an exemplar may not establish the state of a damaged unit. Preserve the underlying report rather than relying only on a logo or a summary sentence. If the evidence is incomplete, record what is missing and how that affects the conclusion.
Cybersecurity must be safety relevant
Article 7 explicitly includes safety-relevant cybersecurity requirements. That wording does not turn every security incident into a product liability defect. Identify how the vulnerability could affect product safety and how the relevant rule addresses that risk. For a connected physical device, an unauthorised command might affect a protective function. For another product, a security concern might relate only to confidentiality and require a different legal analysis.
The claim also needs covered damage and causation under the applicable framework. A vulnerability report can establish a technical weakness without proving that it was exploited or caused the incident. Preserve incident-time versions, configuration, access records and the proposed mechanism. Distinguish the possibility of unsafe behaviour from evidence that the behaviour occurred in the relevant event.
Compliance does not close the inquiry
Article 7 requires all circumstances to be assessed. A product's satisfaction of one mandatory requirement does not necessarily answer an allegation involving another hazard, misleading presentation or foreseeable interaction. The absence of a specific regulation addressing a risk does not by itself establish that the product provided the safety people were entitled to expect. The broader safety test still requires an explanation grounded in the product and context.
Article 11(1)(d) contains a distinct exemption concerning defectiveness due to compliance with legal requirements. That is not a blanket exemption for any product carrying compliance documentation. The operator must establish the relevant statutory condition. Keep the proposition that compliance evidence is relevant separate from the more specific proposition that compliance itself caused the defectiveness.
Build a requirement-to-evidence record
A useful record identifies the legal requirement, its product scope, protected risk, relevant date and evidence of conformity or non-conformity. It should also state what remains disputed. This structure allows another reviewer to see whether a report addresses the precise allegation rather than an unrelated compliance topic. Preserve original documents and distinguish a regulator's finding from a manufacturer's declaration or a consultant's opinion.
The result supports a reasoned safety analysis without deciding every compensation question. Defectiveness, damage and causal connection remain separate under Article 10, subject to specified presumptions and rebuttal. Applicable national implementing legislation and procedure must also be checked before assessing an individual dispute. Legal requirements provide an important benchmark, but their significance depends on the exact rule and facts.
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 product identity and configuration
- Source documents and dated safety analysis
- Separate defect, damage and causation records
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.
- Directive (EU) 2024/2853, consolidated text: Articles 7, 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.