> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # How Should Organisations Prepare for Digital Product Passports? > A vendor neutral guide to organisational readiness for Digital Product Passports, covering products, data, systems, governance, suppliers, teams and roadmap, before product-specific requirements apply. ## Executive Summary By the time an organisation asks how to prepare for the [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport), it has usually already accepted that the requirement is coming. The obstacle is no longer understanding. It is that the specification for its product category does not exist yet, and waiting feels prudent while acting feels speculative. That instinct is wrong, and the reason is structural rather than motivational. The work that takes longest in a passport programme is almost entirely independent of the specification. Establishing a stable identifier for every product model, batch and item takes months and does not change based on which fields a [delegated act](/docs/knowledge-base/glossary/delegated-act) eventually names. Assigning a named owner to every product attribute is an organisational decision, not a technical one. Obtaining composition and provenance data from suppliers happens over contract renewal cycles, which are measured in years. None of that work is wasted if the requirements land differently than expected, and none of it can be compressed once a date is published. Conversely, the work that genuinely depends on the specification, mapping fields, choosing a data carrier format, building a public view, is comparatively fast, and is the part organisations instinctively worry about first. This article is about organisational readiness rather than implementation. It does not recommend software, does not describe a product, and does not assume any particular architecture. It introduces the Digital Product Passport Readiness Model, an original tieback framework describing seven stages of maturity, and then works through each dimension of preparation in turn: products, data, systems, governance, suppliers, people and sequencing. Five kinds of readiness recur throughout and are labelled consistently, because organisations routinely achieve one and assume they have achieved the rest. * The slowest preparation work, identifiers, ownership and supplier data, is independent of any delegated act. Start it before you know your requirements. - Readiness is sequential. Attempting governance before you know what products and data you have produces a policy nobody can apply. - Data readiness is almost always worse than believed. Assume the audit will find contradictions between systems, because it usually does. - Supplier engagement is the longest lead time item and the most commonly under-resourced. It is a commercial exercise, not an integration. - Technology readiness comes sixth, not first. Selecting tooling before understanding your data is how organisations buy the wrong thing confidently. - Preparation without an owner is a study. Name a single accountable person before anything else, or the work will stall at the first cross-functional disagreement. This article follows [What Are the Benefits of a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-are-the-benefits-of-a-digital-product-passport), which establishes why organisations invest, and is the tenth article in the tieback Knowledge learning path. It is the point at which the learning path turns from understanding to action. Framework TBF-011 The Digital Product Passport Readiness Model Sequences preparation work that holds its value under any delegated act, from identification to governance and publication. ## Table of Contents * [Definition](#definition) * [Why Organisations Should Start Early](#why-organisations-should-start-early) * [The Digital Product Passport Readiness Model](#the-digital-product-passport-readiness-model) * [Understanding Your Products](#understanding-your-products) * [Understanding Your Data](#understanding-your-data) * [Assessing Existing Systems](#assessing-existing-systems) * [Preparing Product Governance](#preparing-product-governance) * [Preparing Supplier Collaboration](#preparing-supplier-collaboration) * [Preparing Internal Teams](#preparing-internal-teams) * [Building a Roadmap](#building-a-roadmap) * [Common Mistakes Organisations Make](#common-mistakes-organisations-make) * [Frequently Asked Questions](#frequently-asked-questions) * [Key Takeaways](#key-takeaways) * [Related Articles](#related-articles) * [Related Glossary Terms](#related-glossary-terms) * [References](#references) * [About This Article](#about-this-article) ## Definition The state in which an organisation could satisfy a Digital Product Passport requirement for its products without a discovery phase: it knows which products are in scope, where each required attribute originates, who owns it, how accurate it is, and how it would be maintained after the product ships. Readiness is a property of the organisation and its data, not of any system it has purchased. An organisation can be fully ready without having selected any technology, and can own sophisticated technology while remaining entirely unready. The five dimensions of readiness used throughout this article are distinct, and progress in one does not imply progress in another. | Dimension | The question it answers | Typical owner | | ------------------------ | ---------------------------------------------------------------------------------- | ---------------------------------- | | Regulatory readiness | Which requirements apply to which of our products, and from when? | Regulatory affairs, compliance | | Data readiness | Do the required attributes exist, in one place, accurately, with known provenance? | Product data, engineering, quality | | Process readiness | Is there a defined way information is created, approved, changed and retired? | Operations, quality | | Technology readiness | Can our systems produce and maintain structured, identified, accessible data? | IT, digital | | Organisational readiness | Is anyone accountable, resourced and empowered to make decisions across functions? | Executive sponsor | Most stalled programmes have high technology readiness and low organisational readiness. Very few fail for the opposite reason. ## Why Organisations Should Start Early There are four arguments for starting before a specification exists, and only the fourth is about compliance. **Lead times are structural, not effort dependent.** Identifier reconciliation, attribute ownership and supplier data collection are constrained by contract cycles, system release schedules and the availability of people who know how products are actually made. Doubling the budget in the final six months does not halve those durations. **The discovery is the value.** Organisations consistently find, during assessment, problems that were already costing money: duplicate part numbers, unmapped identifiers across systems, attributes maintained in three places with different values. Fixing these has a return whether or not a passport is ever required. **Late programmes make permanent architectural mistakes.** Under deadline pressure, the fastest path is to maintain passport data separately from source systems. That produces a compliant output and a new silo, and reversing it later costs close to the original programme. **Some obligations already have dates.** The battery passport under Regulation (EU) 2023/1542 applies from 18 February 2027 and is the only firmly fixed Digital Product Passport date at present. Other categories depend on delegated acts still to be adopted, with a preparation period after adoption. See [When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory) and [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport). ESPR establishes the passport as a framework capability rather than a single obligation. It requires that passport data be accessible through a [data carrier](/docs/knowledge-base/glossary/data-carrier) linked to a unique [product identifier](/docs/knowledge-base/glossary/product-identifier), that access be differentiated between the general public, authorities and actors with a legitimate interest, that the data be based on open standards and be interoperable, machine readable, structured and searchable, and that it remain available for a defined period. Which products carry a passport, which fields it contains and when it applies are set per product group in each delegated act. Nothing in ESPR displaces existing conformity, safety or documentation duties. See [What is ESPR?](/docs/knowledge-base/regulations/what-is-the-ecodesign-for-sustainable-products-regulation-espr) and [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts). > **What to do while the specification is unknown** > > Prepare for the attributes that recur across every published and draft requirement rather than for > a specific field list: unique identification, the responsible [economic operator](/docs/knowledge-base/glossary/economic-operator), material composition, substances of > concern, [conformity assessment](/docs/knowledge-base/glossary/conformity-assessment) evidence, > and repair, spare part and [end of life](/docs/knowledge-base/glossary/circular-economy) > information. These appear in essentially every proposal because they are what the policy is for. > Building the capacity to produce them accurately is not speculative work. ## The Digital Product Passport Readiness Model The framework below is an original tieback model. It describes seven stages of readiness. Its purpose is diagnostic and sequencing: it tells an organisation where it currently is, and it argues that the stages are ordered for a reason. Organisations frequently attempt several stages at once, usually by launching a technology evaluation while the product scope is still unclear. The model's central claim is that each stage consumes the output of the one before it. Governance written before the data assessment governs imagined data. Technology chosen before governance encodes decisions nobody has made. Understanding Structure Execution 01 Awareness Organisational readiness The organisation knows the requirement exists, that it is not solely an IT matter, and that it will affect product, compliance, procurement and commercial functions. A named owner exists. Exit test One person is accountable, and the executive sponsor can state why this matters without reading a slide. 02 Regulatory Understanding Regulatory readiness The relationship between the framework regulation, delegated acts and existing product legislation is understood, along with which of the organisation's roles apply: manufacturer, importer, distributor, or several at once. Exit test You can explain which legal instrument would impose a passport on your products, and what is still undecided. 03 Product Assessment Regulatory readiness The portfolio is segmented by likely product group, market, role and lifecycle stage. Products are counted and prioritised. The unit of identification, model, batch or item, is decided per category. Exit test A defensible number exists for how many products are in likely scope, and why. 04 Data Assessment Data readiness For each likely attribute: does it exist, where does it originate, how accurate is it, who maintains it, and does it agree with itself across systems? Gaps are recorded as gaps rather than as assumptions. Exit test An attribute inventory exists with a source, an owner and a confidence rating for every entry. 05 Governance Process readiness Ownership, approval, change control, versioning and retention are defined for product information. Someone can say who is permitted to change a value, and what happens to products already in the field when it changes. Exit test A change to a published attribute has a defined path, not an improvised one. 06 Technology Readiness Technology readiness Systems can hold structured attributes against a stable identifier, expose them for machine consumption, and support differentiated access. Capability is assessed against the governance model, not against a feature list. Exit test You could produce a structured record for one real product end to end, from source system to resolvable output. 07 Operational Readiness Organisational readiness The capability runs as business as usual: new products acquire passports through the normal launch process, changes propagate, suppliers deliver data contractually, and staff are trained. It is nobody's project any more. Exit test A new product launched next quarter would be covered without anyone convening a working group. Stages 1 to 3 establish what is true. Stages 4 and 5 establish control. Stages 6 and 7 deliver and sustain. Stages can overlap at their boundaries, but they cannot be reordered: each consumes the output of the one before it. Organisations that begin at stage 6 are not accelerating, they are deferring stages 3 to 5 until the point where they are most expensive to perform. ## Understanding Your Products Product assessment sounds trivial and is routinely the first place a programme discovers it has a problem. The question "how many products do we sell" typically produces several different answers depending on who is asked, because sales counts sellable items, engineering counts designs, and the catalogue counts listings. Work through the portfolio along five axes. **Category.** Which product groups do your items plausibly fall into under the working plan, and are any already covered by existing sector legislation such as batteries? Products can fall into more than one, and combination products, an appliance containing a battery, are the ambiguous cases worth identifying early. **Market.** Which products are placed on the EU market, by whom, and under whose name? An organisation that manufactures for a private label customer may not be the responsible economic operator for that product. **Role.** Manufacturer, importer, distributor or [authorised representative](/docs/knowledge-base/glossary/authorised-representative), per product and per market. Many organisations hold different roles for different lines and have never written this down in one place. **Unit of identification.** Whether the passport attaches to a model, a batch or an individual item is a defining decision. It drives volume, cost and system design more than any other choice, and it differs legitimately between categories. **Volume and variation.** Ten thousand SKUs that are configuration variants of forty designs is a completely different problem from ten thousand distinct products, and the two are frequently conflated in early estimates. #### Where the product count goes wrong A lighting manufacturer began with an estimate of 2,400 products in scope, taken from the sales catalogue. Product assessment reduced the engineering-distinct count to 310 base designs, since most catalogue entries were colour, voltage and fitting variants sharing identical composition and compliance evidence. It also raised the identification count, because one line required batch level identification for a component subject to a substance restriction. The programme's shape changed entirely: far less attribute work than feared, considerably more identification work. #### Decide the unit of identification per category, deliberately Model level identification is cheapest and sufficient where products are homogeneous and the required information does not vary between production runs. Batch level is necessary where composition, supplier or process varies between runs, and it is what makes precise [recall](/docs/knowledge-base/glossary/recall) possible. Item level is required where individual history matters, such as service records or ownership transfer. Choosing item level uniformly because it seems safest multiplies cost across the whole programme for benefit that only a minority of categories need. Write the reasoning down; it will be questioned repeatedly. ## Understanding Your Data Data assessment is where optimistic programme plans meet reality. The output should be an attribute inventory, and it should be honest to the point of being uncomfortable. For each attribute likely to be required, record six things. #### Existence Does the value exist anywhere in the organisation today, in any form, including a supplier document nobody has structured? Record "no" where the answer is no. A programme that records optimistic placeholders in the assessment phase will discover the truth during delivery. #### Location and system of record Where does it live, and if it lives in more than one place, which one is authoritative? If no system is authoritative, that is the finding, and it is a common one. #### Provenance Where did the value originate: measured, calculated, supplied by a supplier, or estimated by someone at some point? Estimated values that have hardened into apparent facts are the most dangerous category, because they look identical to measured ones. #### Owner Which named role is accountable for its accuracy? Not which department. Departments do not approve values; people do. #### Accuracy and currency How confident are you, and when was it last verified? A three level rating, verified, plausible, unknown, is sufficient and far more useful than a percentage nobody can defend. #### Maintenance What triggers an update, and does that trigger currently reach this value? An attribute with no maintenance trigger will be correct at launch and wrong within two years. Two findings appear in nearly every assessment. The first is contradiction: the same attribute holds different values in ERP, PLM and the customer facing catalogue, and no rule exists for which wins. The second is orphaned data: attributes maintained by a person rather than a process, usually in a spreadsheet, usually by someone who has been doing it for years and has never been asked to document it. > **Sample deeply rather than surveying broadly** > > A full attribute inventory across the whole portfolio takes months and is usually obsolete in > parts before it is finished. Instead, take three products that genuinely differ, ideally a simple > one, a complex one and one with a difficult supply chain, and inventory them completely to item > level detail. The pattern of problems found in three deep samples predicts the portfolio far > better than a shallow survey of three hundred, and it produces findings in weeks rather than > quarters. ## Assessing Existing Systems This section is deliberately capability based. It describes what needs to be possible, not what category of software provides it, and it assumes nothing about your current architecture. Assess whether your existing systems, collectively, can do the following. * **Hold a stable unique identifier** for the chosen unit of identification, which persists across the product's life and is not reused when a product is discontinued. * **Store structured attribute values** with defined types and units, rather than free text notes attached to a product record. * **Record provenance and version history**, so that it is possible to state what a value was at a given date and where it came from. * **Expose data for machine consumption** by another system, without a person exporting a file. * **Support differentiated visibility**, so that the same underlying record can serve public, authority and legitimate interest audiences with different content. * **Maintain data after shipment**, rather than treating product data as complete at launch. * **Link to a data carrier**, such as a [QR code](/docs/knowledge-base/glossary/qr-code) or a [GS1 Digital Link](/docs/knowledge-base/glossary/gs1-digital-link) URI, associating the physical product with the resolvable record. Most organisations find that several systems each satisfy part of this and none satisfies all of it. That is a normal finding and does not automatically imply new software. The important output of this stage is a clear statement of which capability is missing and where the [authoritative source](/docs/knowledge-base/glossary/authoritative-source) for each attribute will be, because that determines what any future decision has to accommodate. #### Selecting technology before completing stages 3 to 5 Evaluating tooling before the product scope, attribute inventory and governance model exist is the most common sequencing error, and it is attractive precisely because it feels like progress. The evaluation criteria end up being derived from vendor feature lists rather than from your own requirements, and the resulting decision encodes assumptions nobody has validated, most often about the unit of identification and about who is permitted to change a value. Requirements written after stages 3 to 5 are dramatically better, and the delay is shorter than the rework it prevents. ## Preparing Product Governance Governance is where readiness stops being an assessment exercise and starts constraining how people work. It is also the dimension most often skipped, because it produces no visible artefact and requires decisions that cross functional boundaries. Six things need defining. **Ownership.** Every attribute has one accountable role. Where two functions both believe they own a value, that disagreement must be resolved before publication, not after a contradiction is noticed externally. **Approval.** Which values require review before they become visible, and by whom. Not every attribute needs the same rigour: a care instruction and a substance declaration should not follow the same path. **Change control.** What happens when a value changes. Specifically, what happens to products already sold, whose passport described the earlier state. This is the question that most often has no answer. **Versioning and history.** The ability to state what the record said at a point in time, which matters for any dispute, [market surveillance](/docs/knowledge-base/glossary/market-surveillance) query, audit or field action. **Retention.** How long the record is maintained across the [product lifecycle](/docs/knowledge-base/glossary/product-lifecycle) and by whom, including the case where the responsible operator ceases trading or the product is discontinued. **Accuracy standard.** What "correct" means for estimated or calculated values, and how the basis of an estimate is recorded alongside it. #### The change control question in practice A component supplier reformulated a plastic housing, changing the recycled content percentage from the value published against forty thousand units already in the field. The technical work of updating the record took an afternoon. Determining whether the earlier units' records should be corrected, superseded or left as an accurate description of what was actually shipped took six weeks, and involved legal, quality and commercial. Organisations that decide this rule during governance design decide it calmly. Organisations that meet it live decide it under pressure. ## Preparing Supplier Collaboration For most manufacturers, the majority of required information originates outside the organisation. This is consistently the longest lead time element of preparation, and it is a commercial exercise before it is a technical one. **Map the dependency first.** For each attribute in the inventory, record whether the source is internal or a named supplier, and how many tiers away it sits. Tier two and beyond, where your supplier's supplier holds the answer, is where [product traceability](/docs/knowledge-base/glossary/product-traceability) work discovers that no direct relationship exists with the party holding the data. **Establish the contractual basis.** A supplier's obligation to provide accurate product data, notify you of changes, and support your compliance obligations belongs in the contract. Since contracts renew on their own cycle, this determines the realistic timeline more than anything else, and it is why supplier work must begin early even though it produces nothing visible for months. **Ask for what you need, in a stable format.** Asking each supplier for a bespoke spreadsheet recreates the fragmentation problem one tier upstream. Requesting the same structured set from every supplier, aligned to recognised identification and classification standards such as those maintained by [GS1](/docs/knowledge-base/glossary/gs1), makes the responses comparable and reusable. **Accept a maturity gradient.** Some suppliers will hold the data in good shape. Many will hold it in no better shape than you do. Some will regard composition data as commercially sensitive and will need either a confidentiality arrangement or a differentiated disclosure route. Plan for three tiers of supplier capability rather than one. **Do not transfer responsibility by receiving data.** Information supplied by a supplier does not move legal responsibility away from the operator placing the product on the market. Accuracy commitments and remedies belong in the contract, not in the assumption that the supplier will be liable. #### Start with the twenty suppliers that matter Attempting to engage the entire supply base simultaneously guarantees a slow, shallow response. Rank suppliers by the number of in-scope products they touch and by the criticality of the attributes they hold, then engage the top group properly: an explanation of what is coming, a specific data request, a contractual conversation and a named contact on both sides. A small number of suppliers usually account for the large majority of required attributes, and the process you refine with them becomes the template for everyone else. ## Preparing Internal Teams Passport readiness fails at organisational boundaries more often than at technical ones, because the required information is distributed across functions that do not routinely coordinate. | Function | What they contribute | What they need to understand | | ---------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------- | | Regulatory, compliance | Scope interpretation, evidence, conformity records | That accessibility and structure are now part of the obligation | | Product, engineering | Composition, design, durability, repair and spare part information | That design decisions now become externally visible | | Procurement | Supplier data, contractual terms, supplier capability | That data provision is a contractual requirement, not a favour | | Quality | Accuracy standards, verification, change control | That product data now needs the discipline applied to physical quality | | IT, digital | Identifiers, structure, interfaces, access control | That they are enabling a business capability, not owning it | | Commercial, marketing | Public facing content, claims | That published claims now sit next to verifiable data | | Customer service | Use of the record when answering customers | That the passport is a support tool as well as a compliance artefact | Three organisational conditions matter more than any training plan. **A single accountable owner.** Not a steering committee. Someone whose objectives include this outcome, with enough seniority to resolve a disagreement between compliance and procurement without escalation taking a month. **Decision rights that are written down.** The most common cause of delay is not disagreement about the answer but ambiguity about who gets to decide. **Realistic capacity.** Preparation work is almost always assigned to people who already have full roles. A programme resourced entirely from spare capacity moves at the speed of spare capacity, which in most organisations is zero. ## Building a Roadmap A readiness roadmap should be organised around the model's stages rather than around calendar quarters, because the durations are uncertain while the sequence is not. The following shape is deliberately generic and should be adapted to portfolio size and role. #### Establish accountability and scope of intent Name the accountable owner and the executive sponsor. Agree what the organisation is trying to achieve: minimum compliance when required, or a reusable product data capability. This single decision determines almost every subsequent trade-off, and leaving it implicit is why programmes later disagree about whether they are on track. #### Complete the regulatory picture Determine which instruments could apply, which roles the organisation holds per product and market, and what remains genuinely undecided. Distinguish firmly between what is law, what is proposed and what is speculation, and keep that distinction visible in every subsequent document. #### Segment and prioritise the portfolio Complete the product assessment. Choose a first cohort: ideally a category with a known or likely early requirement, moderate complexity and an engaged internal team. Avoid choosing the hardest product to prove the concept, and avoid choosing the easiest to prove nothing. #### Run a deep data assessment on the first cohort Produce the attribute inventory with source, owner, provenance and confidence. Publish the gaps honestly. This is the deliverable that makes every later estimate credible. #### Fix identity before anything else Establish stable unique identification at the chosen level, and reconcile the identifier schemes that already exist across systems. Nothing else in the programme becomes reliable until this is done, and it is invariably slower than planned. #### Define governance and begin supplier engagement in parallel These two run concurrently because both are slow and neither blocks the other. Governance defines ownership, approval, change control, versioning and retention. Supplier engagement begins with the highest impact suppliers and the contractual conversation. #### Assess system capability against the governance model Now, with scope, attributes and governance defined, evaluate what existing systems can and cannot do. Any requirement written at this point is derived from your own findings rather than from someone else's feature list. #### Produce one complete record end to end Take a single real product and carry it from source systems to a structured, identified, resolvable record with differentiated access. A working end to end example surfaces more genuine problems than any amount of further analysis, and it converts the programme from theory to evidence. #### Industrialise and transfer to business as usual Extend from the first cohort outward, embed passport creation into the normal product launch process, train the functions that will operate it, and define how the record is maintained after shipment. The programme is finished when new products are covered without a project. > **Sequence by lead time, not by visibility** > > Order the work by how long it takes rather than by how quickly it demonstrates progress. Identity > reconciliation, supplier contracts and governance decisions are slow and invisible. Interfaces and > public views are fast and highly visible. Programmes that sequence by visibility present well for > two quarters and then stall for a year on precisely the items that should have started first. ## Common Mistakes Organisations Make * **Waiting for the delegated act.** The slow work is specification independent. Waiting converts a manageable multi-year effort into a compressed one. * **Treating it as an IT project.** Technology is the least uncertain component. Ownership, supplier data and governance are where programmes actually fail. * **Selecting tooling first.** Requirements derived from feature lists rather than from your own attribute inventory encode decisions nobody has made. * **Recording optimistic assessments.** Marking an attribute as available because someone believes it exists somewhere produces a plan that fails in delivery rather than in planning, which is far more expensive. * **Under-resourcing supplier engagement.** It is the longest lead time item and it is commercial work, not integration work. * **Skipping governance because it produces no artefact.** The first uncontrolled change to a published value demonstrates why it was needed, at the worst possible moment. * **Building the passport as a separate store.** If the passport becomes the only place a value lives, you have rebuilt the fragmentation problem with a public interface. * **Boiling the ocean.** A full inventory across the entire portfolio before any end to end proof produces a document, not a capability. * **Assuming supplier data transfers responsibility.** It does not. It transfers effort. * **No single owner.** Programmes run by committee stall at the first genuine cross-functional disagreement, and there is always one. ## Frequently Asked Questions #### How early should we start if no delegated act covers our products? Begin stages 1 to 4 now: awareness, regulatory understanding, product assessment and data assessment. These are specification independent, they surface problems that already cost money, and they take longer than expected. Defer detailed field mapping and interface work until the requirement is clearer. The distinction is between building the foundation and building to a specification. #### How long does readiness take? It depends almost entirely on portfolio complexity and supply chain depth rather than on organisation size. As a rough shape, product and data assessment on a first cohort takes weeks to a few months, identity reconciliation and governance take several months, and supplier data collection runs across contract renewal cycles, which is typically the constraint. Anyone quoting a duration without knowing your identifier situation is guessing. #### Do we need to buy software to be ready? No. Readiness is a property of the organisation and its data. Stages 1 to 5 involve no purchase at all, and they are where most of the difficulty lies. Whether existing systems can satisfy the capability list in stage 6 is a question that can only be answered sensibly after those stages, which is precisely why the model places technology sixth. #### Where should a small organisation start? With one product. Take a single representative item and work it completely through the attribute inventory: what is required, where each value comes from, who owns it, how confident you are. A small organisation's advantage is that this can be done in days rather than quarters, and the findings generalise across a smaller portfolio far more reliably. #### Who should own passport readiness internally? A single accountable person with cross-functional authority. The function matters less than the authority: it works from regulatory affairs, from product management or from operations, and it consistently fails when owned by IT alone, because the hardest decisions are about ownership of information rather than about systems. #### What if our suppliers will not provide the data? Then it becomes a contractual and sourcing question rather than a data question. Establish which attributes you cannot obtain, from which suppliers, and what the commercial options are: contractual amendment at renewal, confidentiality arrangements for sensitive composition data, testing or analysis as a substitute, or eventually resourcing elsewhere. Discovering this two years before a deadline leaves options. Discovering it two months before leaves one. #### Should we prepare for one regulation or several? Prepare the underlying capability rather than the specific output. The same identified, governed, structured product data serves ESPR, sector legislation such as the batteries regulation, corporate [sustainability data](/docs/knowledge-base/glossary/sustainability-data) reporting and customer data requests. Building separately for each is the fragmentation problem repeating itself with better intentions. #### How do we know when we are actually ready? Apply the exit test for stage 7: a product launching next quarter would be covered through the normal launch process, without convening anyone. Until that is true, the capability is still a project, and projects end. A useful interim test is whether you could produce a complete, accurate structured record for any randomly chosen in-scope product within a day. ## Key Takeaways * Readiness is organisational, not technological. An organisation can be entirely ready before selecting any system, and entirely unready while owning several. - The seven stages are ordered because each consumes the output of the one before. Starting at technology defers the hard stages until they are most expensive. - Identity is the first hard dependency. Stable unique identification, reconciled across existing systems, blocks everything downstream and always takes longer than planned. - Record the data assessment honestly. Optimistic placeholders move failure from the planning phase to the delivery phase. - Supplier engagement runs on contract cycles. Begin with the twenty suppliers that hold most of the attributes, and treat it as commercial work. * Governance produces no visible artefact and prevents the most expensive category of problem. Decide the change control rule before you need it. - Sequence by lead time rather than by visibility. Slow and invisible work must start first. - Name one accountable owner with cross-functional authority. Committees stall at the first real disagreement, and there is always one. ## Related Articles * [How to Validate Digital Product Passport Data](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data) * [What Are the Benefits of a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-are-the-benefits-of-a-digital-product-passport) * [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture) * [Product Data](/docs/knowledge-base/glossary/product-data) * [How to Build a Trusted Product Data Foundation](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation) * [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap) * [How to Manage Evidence for Digital Product Passports](/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports) * [How to Operate a Digital Product Passport Programme](/docs/knowledge-base/implementation/how-to-operate-a-digital-product-passport-programme) ## Related Glossary Terms Definitions of record for the terms used above live in the [glossary](/docs/knowledge-base/glossary/overview). * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [ESPR](/docs/knowledge-base/glossary/espr) * [Delegated Act](/docs/knowledge-base/glossary/delegated-act) * [Economic Operator](/docs/knowledge-base/glossary/economic-operator) * [Market Surveillance](/docs/knowledge-base/glossary/market-surveillance) * [Conformity Assessment](/docs/knowledge-base/glossary/conformity-assessment) * [Product Data](/docs/knowledge-base/glossary/product-data) * [Product Identifier](/docs/knowledge-base/glossary/product-identifier) * [Product Traceability](/docs/knowledge-base/glossary/product-traceability) * [Product Lifecycle](/docs/knowledge-base/glossary/product-lifecycle) * [Sustainability Data](/docs/knowledge-base/glossary/sustainability-data) * [Circular Economy](/docs/knowledge-base/glossary/circular-economy) * [Data Carrier](/docs/knowledge-base/glossary/data-carrier) * [QR Code](/docs/knowledge-base/glossary/qr-code) * [GS1](/docs/knowledge-base/glossary/gs1) * [GS1 Digital Link](/docs/knowledge-base/glossary/gs1-digital-link) ## References * Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, including the Digital Product Passport provisions, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) * Regulation (EU) 2023/1542 concerning batteries and waste batteries, including the battery passport, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2023/1542/oj](https://eur-lex.europa.eu/eli/reg/2023/1542/oj) * Regulation (EU) 2019/1020 on market surveillance and compliance of products, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2019/1020/oj](https://eur-lex.europa.eu/eli/reg/2019/1020/oj) * Decision No 768/2008/EC on a common framework for the marketing of products, setting out the obligations of manufacturers, importers and distributors: [https://eur-lex.europa.eu/eli/dec/2008/768(1)/oj](https://eur-lex.europa.eu/eli/dec/2008/768\(1\)/oj) * European Commission, ESPR working plan 2025 to 2030, COM(2025) 187: [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025DC0187](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025DC0187) * European Commission, The Blue Guide on the implementation of EU product rules: [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0629%2804%29](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0629%2804%29) * European Commission, Ecodesign and energy labelling policy pages: [https://energy.ec.europa.eu/topics/energy-efficiency\_en](https://energy.ec.europa.eu/topics/energy-efficiency_en) * EUR-Lex, official portal for European Union law: [https://eur-lex.europa.eu](https://eur-lex.europa.eu) ## About This Article About This Article
Last Reviewed
2026-08-07
Next Scheduled Review
2027-08-07
Article Version
1.0
tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve. ## Related Docs * [Implementation](/docs/knowledge-base/implementation/overview) * [What Are the Benefits of a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-are-the-benefits-of-a-digital-product-passport) * [What is the Ecodesign for Sustainable Products Regulation (ESPR)?](/docs/knowledge-base/regulations/what-is-the-ecodesign-for-sustainable-products-regulation-espr) * [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts) * [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport) * [When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory)