what-is-dpp

JRC145830 DPP Data Classification: What to Prepare First

How JRC145830 helps prioritise DPP data, and why its research categories do not create legal obligations.

3/26/2026 · 12 min read · InfoDPP

Why Data Classification Matters for DPP

A key question when preparing 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.

The three labels used in this article simplify the JRC’s prioritisation approach. Step B.4 assesses usefulness, effort and feasibility; Table 15 uses six illustrative categories (A–F), not a rigid three-box legal classification.

The Three-Tier Framework

Essential data

The research category concerns data needed for a use case or proposed policy option. It must be distinguished from fields already required by applicable law. Potential themes include:

unique product identification
responsible economic operator information
regulatory compliance declarations
data mandated by the applicable delegated act or standalone regulation

A legal obligation arises from the applicable regulation or delegated act, not from the JRC label. Mandatory fields must be supplied from the relevant application date, taking account of transition rules. Granularity determines 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 applicable product legislation, including any relevant delegated act, determines the required granularity.

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.

Illustrative preparation themes, not field classifications assigned by JRC145830:

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 preparation priority, phased implementation, or more ambitious future policy options as data collection tools mature.

Voluntary data

Voluntary data can have high or low value. Table 15 includes both useful enabling data and lower-priority cases. Possible business examples, subject to the applicable disclosure rules, include:

extended lifecycle analytics
additional explanations of sustainability information for consumers
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 related activities:

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 usefulness, availability, acquisition cost, quality and barriers to sharing.
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

Early preparation remains useful, but the methodology does not guarantee the future field list. Separate existing legal obligations from proposed requirements and internal priorities.

2. Granularity dictates the effort

Greater granularity can increase serialisation and data-management work, while supporting more detailed lifecycle services. Actual costs and benefits depend on the product and use case.

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:

Applicable product law: Battery Regulation Article 77 requires an individual passport for LMT batteries, EV batteries and industrial batteries above 2 kWh. That requirement comes from a standalone regulation, not an ESPR delegated act.
The regulatory objective: where the policy problem clearly depends on traceability of individual units or materials, it can indicate the likely policy direction, 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.

Compare a model-level and an item-level pilot before estimating the additional operational workload.

3. The five data areas offer a practical internal structure

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. Consider them in near-term planning while keeping them distinct from legal obligations.

6. Voluntary does not mean irrelevant

Some voluntary data elements (particularly around lifecycle analytics and circularity evidence) may help distinguish a product or service, support ESG reporting, or satisfy downstream customer requirements even without a legal mandate.

Sector Examples

⚠️ Illustrative only. The tables below anticipate patterns suggested by the JRC methodology and publicly available regulatory signals. They are not statements of legally required fields. Actual minimum datasets are defined by: the Battery Regulation Annex XIII, the Toy Safety Regulation Annex VI Part I, the Detergents Regulation Annex VI Part A, future ESPR delegated acts for the relevant textile and electronic product groups, and the CPR-DPP for construction products.

The JRC methodology applies across sectors, but the weight of each tier shifts depending on the product category:

Sector	Illustrative essential themes	Strongly recommended patterns
Batteries (confirmed: Reg. 2023/1542 Annex XIII)	Unique identification, carbon footprint, recycled content, due diligence, and individual-battery performance, durability and state-of-health data where applicable	Additional cell-level traceability beyond the mandatory passport record
Textiles (indicative, future ESPR act)	Fibre composition, substances of concern, manufacturer identity	Supplier mapping, water/energy footprint, durability metrics
Electronics (indicative, future ESPR act)	Repairability score, spare parts information, material composition	Firmware update history, recyclability assessment
Toys (confirmed: Reg. 2025/2509 Annex VI Part I)	Mandatory passport data per Annex VI Part I (identifier, economic operator, applicable Union law, CE marking, etc.)	Material origin, chemical migration test data
Detergents (confirmed: Reg. 2026/405 Annex VI Part A)	Mandatory passport data per Annex VI Part A (identifier, manufacturer, hazard information, ingredient disclosure, etc.)	Biodegradability evidence, packaging recyclability
Construction products (CPR-DPP under Reg. 2024/3110)	Performance and conformity information and applicable environmental indicators under the CPR	Reuse information beyond the applicable minimum

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: technical standards complement the methodology, which also addresses semantic data organisation. Six horizontal DPP standards were cited by Decision (EU) 2026/1736.
CIRPASS: the earlier CIRPASS project mapped DPP data architecture; JRC145830 extends this by adding the transparent assessment of value and effort and tying it to real-world feasibility.

Official Sources

Start preparing for DPP by organising the data for one product. Try OriginPass.eu to see how you can present it in a digital passport.

Continue Reading

Related guides