The goal is not to finish everything at once. The goal is to know which product line you start with, and which data gaps block a credible product passport.
1. Scope and requirements
- List product groups / categories you sell in the EU
- Mark which have early DPP pressure (see the timeline)
- Pick 1–2 product lines to start with (representative enough, but manageable)
- Document which identifiers you use today (SKU, GTIN, internal article code)
2. Map where the data sits
- ERP / business systems: article master, suppliers, purchasing data
- PLM / engineering: BOM, materials, revisions
- Quality / compliance: certificates, test reports, DoP, declarations
- Sustainability: EPD, climate data, chemical lists
- “Shadow systems”: spreadsheets, shared folders, email attachments, supplier portals
For each field, note: source · owner · update frequency · reliability.
3. Supplier and chain data
- Which data must come from tier-1 (and further)?
- Do you have templates / questionnaires for supplier replies?
- Is there a contract or process to request updates when materials change?
- Who quality-assures incoming evidence before it is used in the passport?
4. Documentation and evidence
- Collect critical documents per first product (certificates, declarations, technical files)
- Check validity and version control
- Link documents to the right product/batch level – avoid “one PDF for the whole range” with no clear link
5. Organisation and maintenance
- Appoint an owner for the DPP programme (often sustainability, quality or product ops)
- Define RACI between purchasing, engineering, production, quality and sustainability
- Decide how changes (new supplier, new material, new variant) trigger a passport update
- Set a rhythm: monthly gap status until the first line is stable
6. From data to passport
- Normalise fields and units
- Fill gaps in priority order (requirement-critical first)
- Create and review a first passport for the first product
- Connect publishing / QR or another carrier where required
- Establish ongoing maintenance – not a one-off export
Common pitfalls
- Starting with the label/QR before the data model is ready
- Assuming “we have an EPD” covers the whole DPP requirement set
- Having no owner when supplier replies do not arrive
- Building a one-off export that cannot be updated
Related: A DPP is not a QR code · What is a DPP?