Chapter 3 — full chapter
| Site: | FashionKIC Learning Platform |
| Course: | Digital Product Passports |
| Book: | Chapter 3 — full chapter |
| Printed by: | Guest user |
| Date: | Sunday, 1 November 2026, 3:19 AM |
Chapter 3 — DPP Data and Traceability
Guiding question : What data must a product carry so that a recycler, a repairer or a second-hand buyer can act on it with confidence — and who owns that data?
This chapter introduces the data foundations that make a Digital Product Passport work in practice: what data it must carry, which supply chain actors create and hold that data, how it accumulates across the product life cycle, and how transparent, well-governed data sharing turns a technical record into a tool for traceability and trust
Learning objective
Learners will be able to understand and apply Digital Product Passport data requirements to improve product traceability, transparency, and supply chain collaboration.
In this chapter:
- 3.1 Data requirements
3.1 Data requirements
Framed at EU level, a DPP is best understood as a data infrastructure rather than a label. The European Parliament’s own research service describes it as a structured collection of product-related data, accessible throughout the value chain, built from three parts: a unique product identifier, a dataset of verified information, and an access point such as a QR code, RFID tag or digital twin. Chapter 2 mapped the roughly fifty data points a textile DPP is expected to carry within that structure, organised by legislative logic; product and producer identity, performance, and after-sale information. This section returns to the same data with a different question: not what a passport must say, but how a business turns a legal list of fields into a working dataset that can actually support traceability.
A field list on its own is not a traceability system. Two businesses can hold identical data points, the same fibre percentages, the same country of origin, the same care instructions, and still produce passports of very different quality, because what separates a usable record from a decorative one is not which fields are present but how reliably each one is captured, updated and trusted. This section works through that gap in four steps: what a data requirement actually consists of, how it connects to the physical carrier that will deliver it, how fields differ in urgency, and who is answerable for each one.
3.1.1 From data field to data requirement
A data requirement is more than a field name. A textile DPP’s identification and performance data spans product identity (GTIN, model/batch IDs, HS/TARIC customs codes), producer and operator identification (manufacturer, importer, facility GLNs, EORI numbers), material composition, environmental indicators, durability, and end-of-life information, roughly 50 data points in the JRC’s preparatory study. For an SME, “material composition” only becomes usable traceability data once it is defined at a specific level of the three-tier model introduced in Chapter 2 (model, batch, or item) and paired with a rule for how it is captured, verified, and refreshed. A requirement therefore has four dimensions: the field itself, the tier at which it is recorded, the level of confidence behind it (declared by a supplier, tested in a lab, or certified by a third party), and the update trigger that tells the business when the value needs to change. A further distinction matters in practice: primary data, collected directly from a business’s own supply chain, carries more weight than generic or industry-average data used as a placeholder where primary data is not yet available. Treating “data requirements” as a static checklist, or leaning permanently on generic data, is one of the most common reasons a DPP looks complete on paper but fails the first time someone actually queries it.
3.1.2 Reading the requirement through the data carrier it will need
Chapter 5 examines the specific carriers — GS1 identifiers, QR codes, RFID, and NFC — in detail. What matters here is that a data requirement cannot be finalised without deciding how it will be attached to the physical product. A requirement that changes at batch level, such as a certified recycled-content share, needs a carrier and a registry design that can resolve to the right batch record, not just the right product model. Getting this link wrong is one of the most common integration failures reported in early passport pilots, and it is a data-requirements problem before it is a technology problem.
This is also where the EU’s planned infrastructure becomes relevant to a data-requirements decision rather than a purely technical one. Article 13 of the ESPR requires the Commission to stand up a central digital registry, targeted for July 2026 (Chapter 2, section 2.1), whose job is precisely to let an authorised actor locate where a given product’s passport data actually lives, whichever platform or supplier hosts it. A business that defines its data requirements without deciding, at the same time, how each field will resolve through that kind of registry is building a dataset it will later have to re-engineer.
3.1.3 Mandatory, conditional and voluntary data fields
Not every field carries the same weight. Some are mandatory once a delegated act applies, such as fibre composition at model level. Some are conditional, required only for products that make a specific claim as a recycled-content percentage is only meaningful if the product claims recycled content. Others remain voluntary for now, such as item-level serialisation for resale and repair tracking. For an SME planning its data work, this distinction matters more than the total field count: mandatory and conditional fields set the floor a business must clear, while voluntary fields are where early investment can create competitive differentiation, in the same way Coverguard and Fusion Sportswear used voluntary transparency to win business ahead of any legal requirement (see Chapter 1, section 1.3.1).
Sequencing follows naturally from this distinction. A realistic SME data plan clears the mandatory floor first, closes the conditional fields tied to whatever claims the business actually intends to make, and only then decides, deliberately, which voluntary fields are worth the investment given its market position, rather than treating the full field list as one undifferentiated task to be completed in one pass.
3.1.4 Who is accountable for each field
Every data requirement needs an accountable party, not just a data source. In practice this means naming, for each field, who enters the value, who can amend it, and who is liable if it is wrong. This distinction between accountability, not just custody, is what turns a spreadsheet of data requirements into a functioning system, and it is the bridge into the next section: no single company along the value chain can be accountable for all of a garment’s data on its own. The DPP is a data infrastructure, not just a label: per the EPRS, it is a structured collection of product-related data accessible throughout the value chain. Each passport combines a unique product identifier, a dataset of verified information, and an access point (QR code, RFID or digital twin) — connecting producers, brands, regulators and consumers.
RESOURCE INSIGHT : How Europe’s Data Revolution Will Transform Fashion and Circularity — Sustainable Brand Platform, 2025. The DPP is a data infrastructure, not just a label: per the EPRS, it is a structured collection of product-related data accessible throughout the value chain. Each passport combines a unique product identifier, a dataset of verified information, and an access point (QR code, RFID or digital twin) — connecting producers, brands, regulators and consumers. Source: https://www.sustainablebrandplatform.com/articles/how-europes-data-revolution-will-transform-fashion-and-circularity-through-the-digital-product-passport