Supplier Evidence Register
Track the supplier-held information a passport depends on: what is required, who is expected to provide it, what evidence supports it, whether that evidence has been accepted and is still current, what remains unresolved and what has to happen next. The output is a working evidence register with an explicit action list.
- Procurement and supplier management teams
- Product data teams assembling passport content
- Sustainability teams sourcing product level environmental values
- Quality teams handling declarations, test reports and certificates
- Compliance and regulatory teams preparing for assurance and review
- SME manufacturers managing supplier evidence by email and spreadsheet
- Enterprise DPP programmes coordinating evidence across many suppliers
- After the Passport Data Origin Worksheet identifies supplier-held information
- Before supplier outreach, so you ask for evidence rather than numbers
- During supplier onboarding, and at each scheduled evidence refresh
- When evidence is rejected, disputed, expired or superseded
- When preparing passport data for assurance or review
This is a practical tool, not a canonical Knowledge article and not a tieback framework. It applies two existing frameworks rather than restating them: the DPP Evidence Lifecycle (TBF-034) for evidence kinds, evidence states and the register field set, and the Supplier DPP Readiness Model (TBF-032) for supplier segmentation. The teaching lives in those articles.
The register is vendor neutral. Nothing you enter leaves your browser, and no tieback product is required. It tracks the evidence, not the file: the document stays wherever you already keep it.
Open register ↓Goes straight to the interactive register. The context below stays here if you want it.
Purpose
Supplier data and supplier evidence are different asks, and they are routinely confused. A request for a recycled content percentage is a request for a value; a request for what stands behind that value is a request for evidence. Programmes that track only the first discover the second late, usually when someone asks which claims are supported, by what, issued by whom, and whether any of it is still valid.
This register is the working list for that second question. It answers, per requirement:
- what supplier-held information the passport depends on,
- who is expected to provide it, and at what supplier segment,
- what evidence is expected, and what has actually arrived,
- who issued it and with what standing,
- whether it has been accepted and is still current,
- who internally owns closing the gap, and what happens next.
It is not a supplier portal, not a procurement system and not a compliance determination. It is a structured evidence-management worksheet.
Who It Is For
Anyone accountable for supplier-held passport content: procurement and supplier management, product data, sustainability, quality, and compliance and regulatory affairs. It is written to be usable by a small manufacturer with a spreadsheet and a folder of supplier emails, and to scale conceptually to an enterprise programme running portals, PLM, ERP, QMS and an evidence repository.
When To Use It
Run it after the Passport Data Origin Worksheet. The worksheet establishes which values are supplier-held and who is authoritative for them; this register is what those rows become once you have to obtain and maintain the evidence behind them.
It is also the right tool before supplier outreach, during onboarding, at each evidence refresh, when evidence is rejected or disputed, and when passport data is being prepared for assurance or review.
Instructions
- Start from the supplier-held rows of your Data Origin Worksheet, or from the values you already know a supplier has to provide. One register row per evidence requirement, not per supplier.
- Write the requirement in the language you will use with the supplier, and set the product or material scope precisely. Most evidence disputes are scope disputes: the certificate is real, it just covers a different variant.
- Record the supplier, and the segment if you use one. Segments are the illustrative TBF-032 tiers, not regulatory classifications. Use "beyond the direct supplier" where the information originates further up the chain.
- State what evidence is expected before you chase it, including what it must cover. "No documentary evidence required" is a legitimate expectation once it has been decided; "not yet decided" is not, and the register treats it as a gap.
- Track the evidence state honestly. Received is not accepted, and the register will not let a row read Ready on arrival alone.
- Record the reference, not the file: document id, certificate or report reference, or where it lives in your repository or shared folder.
- Record the issuer and its standing. A supplier assertion, an authoritative source, independent test or certification evidence and an internal control are different positions and should not be flattened into one.
- Resolve validity. Some evidence expires, some does not, and "no expiry applies" is an answer. Expired, superseded and revoked evidence returns the row to a gap.
- Give every row an internal owner and a next action, then work the Gap and Under review rows. Re-open the register whenever a supplier, product, material or requirement changes.
What The Register Tracks
The supplier-held information the passport relies on.
Who is expected to provide it, and at what segment.
What is expected, what arrived, and its reference.
Whether it is accepted and current, and what happens next.
Evidence States
These are the governed states of the DPP Evidence Lifecycle (TBF-034), not a parallel classification. Acceptance is a decision, not the arrival of a file, which is why receiving something never advances a row past review on its own.
| State | How the register reads it |
|---|---|
| Not requested | Gap |
| Requested | Gap |
| Received | Under review |
| Under review (validation or verification) | Under review |
| Accepted | Ready |
| Rejected or insufficient | Gap |
An accepted row still needs a known issuer authority, a recorded reference and a resolved validity position before it reads as Ready.
The Register
The register tracks the evidence, not the file. Record where the evidence lives and how it is referenced; keep the document itself wherever you already keep it, whether that is an evidence repository or a shared folder of supplier emails.
These counts describe this register, not the product. A row reads Ready only when the expected evidence is identified, accepted, attributed to a known issuer authority, recorded against a reference and resolved for validity. Nothing here is a compliance determination or a verification result.
3 illustrative example row(s) are still present. They are worked examples, not a list of information any instrument requires. Remove them before using the register for real.
How To Interpret The Result
The counts describe the register, not the product and not the passport. Read the shape rather than the total.
Gaps concentrated in one supplier: a supplier engagement problem. Escalate through the commercial relationship rather than by resending the same request.
Gaps concentrated in one requirement across many suppliers: the ask is usually wrong. If nobody can answer it, the expectation, the format or the scope needs rewriting before the next round of outreach.
Many rows received but few accepted: evidence is arriving and nobody is deciding. This is a review capacity problem, and it quietly converts into risk at publication.
Accepted rows with no reference: the acceptance cannot be traced back to anything. This is the condition that fails an assurance review most often.
Supplier assertion behind a regulated claim: not necessarily wrong, but know that it is what you are relying on, and decide whether the claim justifies stronger evidence.
Validity not established: you cannot say whether what you hold still supports the claim. Treat this as a gap in waiting rather than an administrative detail.
A register with no gaps means the evidence position is recorded and current. It does not mean the underlying values are correct, and it does not establish compliance, which is determined against the applicable legal instrument and the product specific measure covering your product.
Using It At SME Scale
Nothing here requires a system. A small manufacturer can run this register with the tool on this page, a shared folder and an email trail: the reference field can be a filename, the issuer can be a person, and the repository can be a folder. What matters is that the expectation is written down, that acceptance is a decision someone makes and records, and that expiry is noticed before a customer or an authority notices it. Do not wait for a portal, a PLM instance or an evidence platform before starting; the register is what tells you whether you would ever need one.
Using It At Enterprise Scale
At enterprise scale the same rows are usually populated from supplier portals, PLM, ERP, QMS, sustainability systems and a document or evidence repository, with segments driving how much control each supplier population gets. The register does not replace those systems; it is the governed index across them, which is exactly the role TBF-034 gives an evidence register. If your systems already hold this, use the register to find where they disagree, and to expose the requirements no system currently owns.
Related Frameworks And Knowledge
Worked example: see this tool used end to end, alongside the other two Templates, in Example 01: From DPP Readiness to Defensible Supplier Evidence.
Limitations And Regulatory Caution
- This register tracks evidence. It does not validate evidence, does not verify a claim and does not establish that any supplier value is correct.
- The register positions Ready, Under review and Gap describe register completeness only. They are not a compliance determination, a verification result or a score.
- The evidence kinds and states are the vocabulary of TBF-034 and the supplier segments are the illustrative tiers of TBF-032. Neither is a regulatory classification.
- The illustrative rows are worked examples, legally neutral and generic. They are not a list of information any instrument requires for any product.
- The register holds references, not documents. Keep the evidence itself under whatever control your organisation already applies to it, including access and confidentiality restrictions.
- Entries are stored in this browser only. Clearing site data, switching browser or switching device loses them; export the register if it matters.
- This is not legal advice. Confirm evidence expectations with qualified regulatory or legal advice for your products and markets.
Related Articles
- Passport Data Origin Worksheet
- DPP Readiness Assessment
- From DPP Readiness to Defensible Supplier Evidence: A Worked Manufacturer Example
- DPP Governance: Who Owns What?
- Product Data
- What Data Goes in a Digital Product Passport, and Where Does It Come From?
- How Will Digital Product Passports Change Product Compliance?
- Sustainability Data
References
- Regulation (EU) 2024/1781 (Ecodesign for Sustainable Products Regulation), Chapter III on the Digital Product Passport: https://eur-lex.europa.eu/eli/reg/2024/1781/oj
- tieback Knowledge, “How to Manage Evidence for Digital Product Passports” (TBF-034, the evidence lifecycle this register applies): https://tieback.io/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports
- tieback Knowledge, “How to Prepare Suppliers for Digital Product Passports” (TBF-032): https://tieback.io/docs/knowledge-base/implementation/how-to-prepare-suppliers-for-digital-product-passports
About This Article
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.