DPP Data Requirements: Mandatory, Conditional and Voluntary Information

Learn how to distinguish mandatory, conditional and voluntary Digital Product Passport data without turning guidance or future policy work into a universal field checklist.

Last verified: 3 September 2026

LinkedIn X Email

Navigate this page

Overview
The short answer
Mandatory always needs a scope
Conditional means “required when true”
Voluntary data is allowed, but it is not invisible
Preparatory classifications are not a current business manda
Batteries are the clearest adopted example
Textiles are the opposite case
The six columns every DPP requirement row should have
Common misreadings
What is settled and what remains product-specific
What a business can prepare now
What would change this page
Sources and legal basis
Keep exploring

There is no universal list of DPP fields that every product must populate. The applicable product rule decides the required data. A field can be mandatory for every product in scope, mandatory only when a condition is met, or voluntary. Commission guidance also permits additional voluntary data where it is clearly distinguished from mandatory data and does not undermine the passport’s accuracy, interoperability or functionality.

The short answer

The safest way to read a DPP field list is to separate four things that are often collapsed into “required”:

Label	Meaning	Business treatment
Mandatory	The applicable law requires the information for this product/actor/case	Build and evidence it before the relevant application date
Conditional	The law requires the information if a stated condition is true	Store the condition and test it; do not treat the field as optional
Voluntary	The operator may include the information even though the applicable mandatory set does not require it	Keep it visibly separate from mandatory data and govern accuracy
Preparatory / policy priority	An official study or methodology proposes or prioritises information for future rulemaking	Useful for readiness, not a current universal duty

The word that causes the most trouble is conditional. Conditional does not mean “nice to have”. If the legal condition applies, the requirement follows.

Mandatory always needs a scope

A field is not meaningfully “mandatory” until you can answer:

mandatory under which instrument;
for which product category;
for which actor;
at which level: model, batch or item;
from which date; and
under which condition, if the requirement is conditional.

ESPR Article 9 assigns the product-specific delegated act the job of specifying the DPP data for the product group. The Commission’s FAQ makes the same point in plainer language: the specific data a DPP must contain is determined by delegated acts under ESPR or by separate product-specific legislation.

That means Annexes, guidance tables, vendor templates and preparatory studies must be read through the applicable product law rather than treated as one horizontal field checklist.

Conditional means “required when true”

A conditional requirement has two parts:

the field or action; and
the condition that activates it.

The mistake is to keep the first and lose the second.

A good product-data model therefore does not store only:

field = substance information

It stores something closer to:

field = substance information obligation_strength = conditional applicability_test = condition from the applicable act source = legal provision effective_from = date scope = model/batch/item evidence = source record

That structure matters because “not applicable” and “missing” are different outcomes. A field that is not triggered by its condition should not be treated as a data-quality failure.

Voluntary data is allowed, but it is not invisible

The Commission’s DPP FAQ says additional voluntary data points may be included if they do not compromise accuracy, interoperability or functionality, and if they are clearly distinguished from mandatory data points.

That creates a practical governance rule: voluntary data should carry its own status in the published data model.

Do not mix voluntary marketing claims into the mandatory layer and then rely on the reader to work out which is which.

A voluntary field still needs to be accurate. “Voluntary” describes why the field is present, not whether you can publish an unsupported claim.

For the evidence question, use what a passport field can and cannot prove.

Preparatory classifications are not a current business mandate

The JRC methodology for future DPP data design distinguishes essential, strongly recommended and voluntary elements as part of a policy-design and feasibility method. It is designed to support delegated acts and impact assessments.

Those labels are useful to policymakers and useful to businesses trying to anticipate data pressure. They are not a replacement for the product-specific act.

So if a research paper calls a data point “essential”, the implementation system should not silently convert that into mandatory = true.

A better representation is:

policy_priority = essential legal_status = in_official_development mandatory = not_established

until the applicable law settles it.

Batteries are the clearest adopted example

The battery passport is useful because the product rule is adopted and the Commission has published a detailed implementation view of the data points. The live 71 battery data points guide already owns that regime in detail.

The important lesson to carry horizontally is not “there are 71 DPP fields”. It is that one adopted regime can contain data with different applicability conditions, levels and timing. That makes a flat required/not required spreadsheet too crude.

Batteries are evidence that conditionality is real. They are not a universal template for textiles or other ESPR product groups.

Textiles are the opposite case

For textiles, the Commission says the exact information requirements will be defined through the relevant delegated act and supporting technical specifications. That act has not yet been adopted.

So a textile business can structure likely product facts now, but it should not label its own readiness field set “the mandatory textile DPP fields”.

This estate already makes that distinction on the 22 fields we track for a textile passport: tracked and governed data is not the same thing as a current statutory textile passport checklist.

The six columns every DPP requirement row should have

If you want a field register that survives future acts, add at least these six columns:

Column	Question it answers
`legal_source`	Which instrument creates or supports this requirement?
`requirement_status`	Which current estate proposition status applies: applicable now, adopted-later, proposed, in official development, indicative, pending measure, transposition/national implementation or not established? Keep any duty arising under other law in a separate requirement-basis field.
`obligation_strength`	Mandatory, conditional or voluntary?
`applicability_condition`	What must be true for this requirement to activate?
`granularity`	Model, batch or item?
`evidence_owner`	What source substantiates the published value and who owns the decision?

Access rights and freshness belong alongside those columns when they matter.

The point is not database neatness. It is being able to change the rule without losing the evidence or rebuilding the product record.

Common misreadings

“It is on an EU list, so it is mandatory”

Not necessarily. First establish whether the list is binding product law, Commission guidance or preparatory methodology.

“Conditional means optional”

No. A conditional requirement can be mandatory where its condition is satisfied.

“Voluntary means we can publish it without evidence”

No. Voluntary describes obligation strength, not truthfulness.

“If batteries need it, every DPP will need it”

No. Batteries are a product-specific adopted regime.

“The JRC calls it essential, so the EU requires it today”

No. The JRC methodology supports policy design and impact assessment. The product rule is what settles the legal requirement.

What is settled and what remains product-specific

Settled horizontally

ESPR product-specific delegated acts can specify the data included in a DPP.
DPP information must be accurate, complete and up to date where the ESPR requirement applies.
Commission guidance permits clearly distinguished voluntary additions under stated system-quality conditions.

Product-specific or not yet established

the final field set for future textile DPPs;
which fields are conditional for a future textile act;
final textile access classes;
final textile granularity; and
whether future product groups will require third-party assessment for particular data points.

What a business can prepare now

Prepare

map every field to its source;
store obligation strength separately from field name;
encode conditions explicitly;
keep model/batch/item scope separate;
preserve the evidence behind each value;
distinguish mandatory publication from voluntary publication;
re-verify the applicable act before a product is launched under a new regime.

Do not hard-code

one universal DPP checklist;
“JRC essential” as “legally mandatory”;
battery access or granularity as the default for another category;
a blank conditional field as a failure without first testing the condition.

What would change this page

Re-verify when:

a new product-specific DPP act is adopted;
the Commission changes FAQ question 22;
the JRC methodology is materially revised; or
a new adopted sector regime introduces a requirement type that does not fit the current model.