- Useful standards landscape source, but not a substitute for the binding ESPR delegated-act or implementing-act text.
"technical standards"
Use this page to separate harmonised standards, Commission common specifications, delegated-act requirements, and DPP standards context under ESPR.
The page is intentionally conservative: it records what supports conformity, what still depends on product-group delegated acts, and what evidence should show when a standard is used, partly used, unavailable, or replaced.
Structured answer sets in this page tree.
Cited legal and guidance references.
Under ESPR, standards are not a substitute for checking the applicable delegated act. Harmonised standards can support a presumption of conformity only to the extent their references are published in the Official Journal and the relevant requirement is covered. Common specifications are a Commission fallback for products covered by delegated acts when the ESPR conditions for that fallback are met.
ESPR is a framework regulation. The concrete ecodesign requirement, DPP requirement, test method, calculation method, or technical-documentation expectation normally comes from the delegated act adopted for the product group.
A standards register should therefore begin with the product group and delegated-act clause, then map each requirement to the harmonised standard, common specification, other technical specification, or internal method used to demonstrate conformity.
ESPR gives a presumption of conformity for tests, measurement or calculation methods, DPP requirements, and product ecodesign requirements when they conform with harmonised standards or parts of standards whose references have been published in the Official Journal.
That presumption is limited. The evidence file should say whether the standard was applied in full or in part, which clauses were used, which ESPR requirement they cover, and which remaining requirements are met another way.
Map product-group delegated acts to harmonised standards, common specifications, DPP technical requirements, deviations, and conformity evidence before relying on a presumption of conformity.
Common specifications are not a parallel shopping list of preferred standards. ESPR lets the Commission adopt implementing acts establishing common specifications for products covered by delegated acts, but only under conditions tied to requested harmonised standards that are not accepted, not delivered on time, non-compliant with the request, or not expected to be published within a reasonable period.
When a common specification is used, the register should identify the implementing act, the delegated-act requirement it covers, whether it replaces only part of the standards gap, and whether a later harmonised standard has been assessed and published.
DPP standards context matters because ESPR gives DPPs their own essential requirements and a separate presumption-of-conformity route when harmonised standards cover those requirements. CEN-CENELEC identifies DPP framework and system work, and ETSI ES 204 082 gives a useful evidence pattern for expressing a standard or regulation, criteria reference, claimed value, benchmark, conformance indicator, and evidence URI.
Use that pattern as an evidence design aid, not as a claim that final ESPR DPP fields are already fixed for every product group. Product-specific DPP content still depends on the relevant ESPR delegated act and any published technical specifications that apply.
The strongest standards file is a traceability table, not a narrative memo. It should let a reviewer move from the delegated-act requirement to the selected harmonised standard or common specification, then to the exact test, measurement, calculation, DPP technical control, and conformity declaration reference.
Deviations need the same discipline. If the team does not apply a harmonised standard or common specification, applies only part of one, or uses another reliable method, the file should describe the alternative solution and why it still satisfies the applicable requirement.
This artifact should not be used to announce final standard mandates, product-specific DPP fields, penalties, launch dates, or market restrictions. Those claims need their own source support from a final delegated act, implementing act, Official Journal standard reference, or other authoritative public source.
When source support is incomplete, publish the uncertainty instead of filling the gap. The useful output is a standards-dependency register that shows what is binding, what is a harmonised-standard presumption, what is a common-specification fallback, what is technical guidance, and what remains open.
"technical standards"
"information model"
"applicable delegated acts"