DPP Data Classification: Essential, Recommended, Voluntary
JRC methodology for classifying DPP data into essential, strongly recommended and voluntary tiers under the ESPR framework.
Why Data Classification Matters for DPP
One of the most common questions companies ask when preparing for a Digital Product Passport is: which data points are actually required, and which are optional?
Until recently, the answer depended largely on reading between the lines of the ESPR framework and waiting for sector-specific delegated acts. However, on 19 March 2026, the European Commission’s Joint Research Centre (JRC) published a methodology that addresses this exact question directly: JRC145830 — Methodology for defining data requirements for the Digital Product Passport under the ESPR framework.
This report introduces a transparent, repeatable approach to classifying DPP data into three tiers: essential, strongly recommended, and voluntary. It focuses on the semantic definition and prioritisation of information requirements, systematically investigating current industry data collection and data-sharing practices across complex product value chains. The framework is designed to support the drafting of ESPR delegated acts and impact assessments, but its practical value extends to any company trying to prioritise its product-data preparation work today.
The Three-Tier Framework
Essential data
Essential data elements are those directly required by regulation or strictly necessary for the DPP to fulfil its core legal purpose. They typically include:
- unique product identification
- responsible economic operator information
- regulatory compliance declarations
- data mandated by the applicable delegated act or standalone regulation
If an essential data point is missing, the DPP is fundamentally incomplete. These elements are non-negotiable once a delegated act enters into force. The JRC methodology emphasises that essential data must be tightly coupled with the appropriate level of product passport granularity. In practice, this refers to how precisely the passport identifies the product:
- Model level — a single passport covers all units of a given product model (e.g. “washing machine Model X”). The data is identical for every manufactured unit.
- Batch level — the passport covers a specific production batch (e.g. “batch 2026-03-A of washing machine Model X”). Data may vary between batches, for instance raw-material composition.
- Item level — every individual unit has its own passport with a unique identifier (e.g. a serial number). This enables full lifecycle tracking of each specific unit.
The required granularity level is set by the delegated act for each product category and directly determines the scope of essential data.
Strongly recommended data
Strongly recommended elements are not strictly mandated in every case, but they score highly on a transparent value–effort and feasibility assessment grounded in real-world practices. The information they provide is of clear, demonstrable use to regulators, consumers or value-chain partners, and the effort to collect it is considered reasonable given existing industry and technological readiness.
Examples that frequently appear in this tier:
- material composition beyond legally required substances
- carbon footprint or environmental performance indicators where calculation methodologies are mature
- repairability or durability information where standardised metrics exist
- supply-chain traceability evidence beyond minimum legal thresholds
In practice, strongly recommended data is best read as an early-priority layer for preparation, phased implementation, or more ambitious future policy options as data collection tools mature.
Voluntary data
Voluntary elements provide additional value in niche contexts but score low in the value–effort assessment — either because the data is difficult to collect reliably at scale, or because its usefulness is limited to narrow downstream scenarios. They may include:
- extended lifecycle analytics
- enhanced consumer-facing sustainability storytelling
- proprietary performance benchmarks
- data relevant only to specific downstream use cases
Voluntary inclusion is not discouraged, but companies should approach it as a strategic choice rather than a compliance requirement.
How the JRC Methodology Works
The JRC report does not simply list data fields. Formally, it sets out four main steps (A-D) with sub-steps; for company teams, the logic can be summarised as the following six connected moves:
- Map policy objectives — identify what the ESPR (or a standalone regulation) aims to achieve for a given product category.
- Define use cases — determine who needs the data (market surveillance, consumers, recyclers, repairers) and for what specific purpose.
- Identify candidate data elements — list all information that could serve the mapped use cases.
- Assess value and effort — evaluate each data element against its practical usefulness, data availability, collection cost, and current industry readiness. This step is where the JRC methodology diverges most from earlier approaches: it introduces a structured scoring framework rather than relying on expert panel consensus alone.
- Classify into tiers — assign each element to essential, strongly recommended, or voluntary based on the feasibility assessment.
- Address data governance — consider access rights, data granularity (model, batch, item level), and update frequency.
While the JRC report leaves detailed system architecture and IT implementation out of scope, its modular structure allows the methodology to be applied beyond the ESPR framework where equivalent contextual and feasibility analyses are carried out. This can also be relevant for standalone DPP mandates such as the Toy Safety Regulation (from 1 August 2030) or Regulation (EU) 2026/405 on detergents (from 23 September 2029).
What This Means for Companies in 2026
1. Priority becomes clearer
Before the JRC methodology, companies had to guess which data to collect based on incomplete signals from ESPR recitals and the working plan. The three-tier framework gives a structured way to separate “must-have now” from “useful but deferrable.”
2. Granularity dictates the effort
The JRC explicitly ties data requirements to the concept of granularity. Opting for an item-level DPP (requiring individual unit serialisation) demands significantly more effort than a model-level DPP (covering general product attributes), but it unlocks advanced tracking and circular services.
How do you estimate which level may matter for your sector before the legal text is final? In practice, companies usually look at three types of signals:
- The delegated act — once adopted, this is decisive for the legally required level (e.g. the Battery Regulation mandates item-level passports for electric-vehicle and industrial batteries above 2 kWh).
- The regulatory objective — where the policy problem clearly depends on traceability of individual units or materials, it can indicate the likely direction of travel, but it is not a substitute for the legal text.
- The ESPR working plan and preparatory studies — these can signal where more detailed traceability may matter, but they do not themselves set the required granularity.
The practical takeaway is straightforward: the more granular the level, the higher the serialisation, IT infrastructure, and data-collection costs — but also the greater the passport’s value for circular services and market surveillance.
3. The five data layers are a practical internal mapping
The DPP data requirements guide describes five core data layers: product identity, responsible operator, composition, sustainability, and traceability. That five-layer model is an InfoDPP planning structure, not a taxonomy defined by JRC145830. It can nevertheless be used as a practical way to map the JRC prioritisation logic onto an internal product-data model.
4. Access control is a separate design dimension
Not all essential or recommended data will be public. The report treats access rights as a separate DPP design and governance question: delegated acts are meant to specify which actors can see which data, while balancing proportionality, data protection and confidential business information. In practice, companies should design DPP infrastructure with differentiated visibility levels from the start, rather than assume every field belongs in the public view.
5. Strongly recommended deserves baseline planning
The strongly recommended tier is not binding law. But it identifies data points that score well on policy value and feasibility, making them sensible candidates for earlier preparation, phased roll-out, or more ambitious future policy options. A prudent approach treats them as a near-term planning priority rather than as a mere extra.
6. Voluntary does not mean irrelevant
Some voluntary data elements — particularly around lifecycle analytics and circularity evidence — may create competitive differentiation, support ESG reporting, or satisfy downstream customer requirements even without a legal mandate.
Sector Examples
The JRC methodology applies across sectors, but the weight of each tier shifts depending on the product category:
| Sector | Essential focus | Strongly recommended patterns |
|---|---|---|
| Batteries | Unique identification, carbon footprint, recycled content, due diligence | Performance degradation data, cell-level traceability |
| Textiles | Fibre composition, substances of concern, manufacturer identity | Supplier mapping, water/energy footprint, durability metrics |
| Electronics | Repairability score, spare parts information, material composition | Firmware update history, recyclability assessment |
| Toys | Safety documentation, conformity assessment, component traceability | Material origin, chemical migration test data |
| Detergents | Ingredient disclosure, classification data, hazard information | Biodegradability evidence, packaging recyclability |
| Building materials | Environmental declarations (EPD), composition, technical performance | Lifecycle carbon data, reuse potential |
These are illustrative based on the methodology’s logic and existing regulatory signals. Final field lists will be confirmed in each product category’s delegated act or standalone regulation.
Relationship to Existing DPP Guidance
The JRC methodology complements, rather than replaces, other guidance:
- ESPR Annex III — still defines the legal scope of possible DPP requirements; the JRC methodology helps prioritise which elements from that scope to implement first.
- CEN/CENELEC standardisation — harmonised standards will define technical formats; the JRC methodology addresses what data to include, not how to encode it.
- CIRPASS — the earlier CIRPASS project mapped DPP data architecture; JRC145830 extends this by adding the transparent value–effort classification layer and tying it to real-world feasibility.
Read Next
- DPP Data Requirements: What Data You Actually Need
- What is a Digital Product Passport (DPP)?
- How to Create a DPP: Step-by-Step Guide
- ESPR vs Battery Regulation vs CBAM: What’s the Difference?
Official Sources
- JRC145830 — Methodology for defining data requirements for the Digital Product Passport under the ESPR framework
- ESPR Regulation (EU) 2024/1781
- European Commission ESPR Working Plan 2025–2030
Need to map your product data against the essential–recommended–voluntary framework? Start free on OriginPass.eu and test a structured product record aligned with emerging DPP data standards.