Set up ESPR work as a governed product-release system: monitor product groups, map delegated acts, collect engineering and supplier evidence, govern DPP data, and prepare authority responses.
This page avoids product-group deadlines or DPP field claims unless the cited ESPR sources support them. It is most relevant for manufacturers, importers, distributors, dealers, and fulfilment service providers handling products covered by a delegated act under ESPR.
Structured answer sets in this page tree.
Cited legal and guidance references.
An ESPR compliance program should not start as a static policy. It is most relevant for manufacturers, importers, distributors, dealers, and fulfilment service providers handling products covered by a delegated act under ESPR. The practical model is a standing product-law workflow that watches the Commission working plan, converts each applicable delegated act into engineering and information requirements, assigns evidence owners, controls Digital Product Passport data, blocks releases when conformity evidence is missing, and prepares fast responses to market surveillance authorities.
Create an intake record for every product family, intermediate product, private-label product, imported product, online offer, and material change that may be placed on the EU market or put into service. The intake should identify the product group, economic-operator role, EU market route, supplier chain, and whether the product appears in the Commission working plan or a delegated act.
The intake team should not invent future dates or requirements. It should classify the product against the current working plan, then flag what must wait for a product-specific delegated act.
When a delegated act applies to a product group, the operating model should open an implementation record before design freeze. That record should translate performance requirements, information requirements, conformity assessment, test methods, and documentation obligations into engineering tasks with named approvers.
Engineering release gates should require a completed requirement traceability matrix, test or calculation evidence, technical documentation, and a conformity decision before the product is placed on the market or put into service.
Supplier data should be requested through a governed ESPR evidence process, not through informal spreadsheets after launch. For each delegated act, procurement should identify which suppliers, service providers, component owners, and contract manufacturers hold data needed for ecodesign requirements, information requirements, DPP records, or conformity assessment.
The supplier workflow should capture the source, version, test basis, facility or product scope, responsible contact, confidentiality status, and whether the data can be shared with notified bodies or competent national authorities when required.
Use this operating model to assign ESPR owners, connect delegated acts to evidence, and block product releases when conformity, supplier, DPP, or market-surveillance records are incomplete.
The DPP workstream should sit inside product governance, not beside it. Each product group needs a DPP data owner, data dictionary, source-system map, access model, backup-hosting decision, publication approval, and change-control process before DPP content is exposed to customers, businesses, authorities, or other permitted users.
Do not hard-code DPP fields before the applicable delegated act defines them. Use the ESPR list of possible DPP data elements as the planning envelope, then lock the actual field set only when the product-specific rule supports it.
A useful ESPR program has gates before design freeze, supplier nomination, production release, EU market launch, marketplace publication, and material product changes. Each gate should answer a narrow question: is the product covered by a delegated act, are the applicable requirements mapped, is the evidence complete, is the DPP ready if required, and can the company answer an authority request on time?
The gate should fail closed when evidence is missing. A release exception should name the missing source, the product models affected, the responsible executive, the customer or authority impact, and the date for re-review.
Market surveillance support should be a named response playbook. The company should know who receives requests, who can provide technical documentation, who can explain the DPP and product identifiers, who contacts suppliers, who approves corrective action, and who communicates with distributors, marketplaces, notified bodies, the Commission, or Member State authorities when escalation is required.
The response record should be product-specific. It should preserve the authority request, product identification, origin, model, quantities, alleged non-compliance, evidence supplied, corrective action, timelines, customer or channel actions, and final closure decision.
The operating model should publish a simple RACI so ESPR work does not disappear between sustainability, product compliance, engineering, procurement, IT, and legal. One accountable program owner should maintain the control calendar, but each evidence stream needs an operational owner with authority to stop a release or reopen a decision.
Review cadence should follow legal and product events: working-plan updates, new or amended delegated acts, product changes, supplier changes, DPP service-provider changes, authority requests, and recurring evidence refreshes required by the applicable rule.
"how data should be stored and managed"
"market surveillance"
"economic operators shall"
"technical documentation is not available"