90 Day Registry Risk: Evidence Audit Trail Checklist for EU Brands

An evidence audit trail is the tamper-evident, timestamped record linking every supplier document, certificate, and approval to a specific product model, batch, or item inside a Digital Product Passport. It matters because Regulation (EU) 2024/1781 puts the burden of proof on the brand, not the registry. The one action to take now: build a version-linked, brand-held evidence store that survives an audit on its own, independent of whatever the EU registry shows.

TL;DR:

• Brands must link each supplier document to specific product versions, batches, or SKUs with detailed metadata, including issuer, scope, and validity dates.
• Evidence ownership involves clear roles for suppliers, data stewards, and compliance reviewers, with enforceable SLAs and access policies to prevent data rot.
• Technical controls like immutable logs, cryptographic signatures, and structured exports are essential for defending evidence integrity during audits.
• Registry proof of registration alone is insufficient; brands need to maintain their own comprehensive, versioned evidence stores that exceed the registry's short retention window.
• Ensuring evidence survives business exit requires contractual backup and transfer clauses, regular testing, and independent export rights embedded in vendor agreements.

• What an Audit Trail Must Actually Record
• Who Owns the Evidence Trail: Governance and Roles
• Building Technical Controls That Hold Up in an Audit
• What ESPR, EN 18221, and the Registry Actually Require
• Making Evidence Survive a Business Exit
• A Checklist You Can Run This Quarter
• How DPP Grid Structures Evidence Behind the Scenes
• Turn This Checklist Into a Working System
• Sources
• FAQ

A folder of PDFs is not an audit trail. Auditors need to see, at a glance, which certificate applies to which product version, who issued it, and whether it is still valid today. That means every piece of evidence needs specific metadata attached, not just a filename.

The minimum fields auditors expect:

• Issuer and issuing body, so the certificate's authority can be verified independently
• Certificate ID, unique and searchable, not a generic "cert.pdf"
• Scope, stating exactly what the document covers (a material, a process, a facility)
• Validity window and expiry date, since an expired certificate is functionally no evidence at all
• Explicit SKU, batch, or version linkage, tying the document to the exact product it supports

The ESPR text also requires four identifiers to sit behind every DPP: a product identifier, an economic operator identifier, a facility identifier, and a registration identifier (this last one usually hidden from public view but visible to authorities). Evidence has to map cleanly onto these four anchors.

Statistic Callout: Under Implementing Regulation (EU) 2026/1778, proof of registration in the EU registry stays available for only 90 days. Beyond that window, the registry entry alone tells an auditor nothing. Brands have to hold the substantive evidence themselves.

Generic certificates dumped into a shared drive fail this test almost immediately. Without field-level linkage to a version or batch, an auditor cannot confirm the document applies to the product in front of them. That gap is where most audit findings originate.

Evidence rots without an owner. The most workable structure splits responsibility three ways, and each role needs a name attached to it, not a department.

1. Supplier owner manages the relationship with a given factory or material supplier and chases missing documents before they become a gap.
2. Data steward (often in IT or product operations) enforces version control, checks that uploads carry the right metadata, and keeps the master product record consistent.
3. Compliance reviewer signs off before anything publishes, checking that scope, validity, and linkage actually match the claim being made.

Supplier SLAs need teeth. Set a submission deadline tied to onboarding or renewal (30 days is common), define what counts as an acceptable document (readable, signed, scoped correctly, not expired), and specify what happens when a supplier misses the window. Operational guidance on evidence intake recommends building this SLA into the supplier contract itself, not treating it as a soft ask.

Access policy matters just as much as intake. Some evidence, like a safety test summary, might be appropriate for public passport pages. Other documents, like a supplier's cost breakdown embedded in a manufacturing agreement, need to stay restricted to the compliance reviewer and data steward only.

Pro Tip: Write your versioning policy before you onboard your first supplier, not after. Retrofitting version control onto six months of unstructured uploads costs far more time than defining the rule up front.

Governance defines who is responsible. Technical controls prove it happened. The two layers work together, and skipping the second one leaves even a well-run evidence program vulnerable to a simple challenge: "how do we know this wasn't changed after the fact?"

At minimum, log four types of events:

• Uploads, including who submitted the file and when
• Modifications, including what field changed and the previous value
• Approvals, including who signed off and under what policy version
• Access attempts, including failed ones, especially for restricted documents

Retention needs a policy of its own. Master data changes (a product attribute being edited) and event data (a supplier uploading a new test result) often warrant different retention windows and access rules, since one tracks the product's current state and the other tracks history.

Immutability is where a lot of programs fall short. Append-only logs, write-once-read-many (WORM) storage, and cryptographic hashing or digital signatures all give an auditor something concrete to check against. A supply-chain audit-trail framework recommends chronological, tamper-proof event logs tied to batch or unit identifiers specifically so recalls and regulator requests can be answered without ambiguity.

An audit trail that cannot prove it wasn't edited after the fact is not an audit trail. It's a claim.

Export format deserves attention too. An auditor working through dozens of SKUs does not want to open twenty different file types. A consistent, structured export, keyed to the same product identifier across evidence, metadata, and log extracts, saves everyone time and reduces the chance of a mismatch. A structured-data audit tool can help confirm your exports are machine-readable in the format authorities and downstream systems expect.

The registry and your own evidence store do two different jobs, and confusing them is the single most common mistake teams make. The registry, governed by Implementing Regulation (EU) 2026/1778, logs access and modifications and issues proof of registration. That proof is useful, but it is not proof of substantive compliance. It confirms a passport exists and was registered correctly, not that the underlying claims are true.

That distinction shows up clearly in the standards landscape:

• Regulation (EU) 2024/1781 requires explicit linkage between evidence and the DPP record, with the brand holding responsibility for the complete trail
• EN 18221:2026 governs data storage, archiving, and persistence, including replication to backup operators
• Harmonised standards published in July 2026 grant presumption of conformity for container and interoperability aspects, but not for data authentication

Statistic Callout: Six harmonised standards received presumption of conformity in that July 2026 publication round, according to a legal analysis of the DPP standards landscape. None of them cover data authentication or access management. That gap means brands still have to document and justify their own technical security choices, since no published standard yet does it for them.

Retention windows compound this. The registry's 90-day proof-of-registration availability is far shorter than the multi-year retention most product categories will need for warranty, recall, or resale claims. Plan your own retention schedule independently of what the registry promises.

A Digital Product Passport is only as durable as the infrastructure behind it. If the operator managing your product data shuts down, gets acquired, or simply stops paying its hosting bill, the passport needs to keep working. EN 18221 addresses this directly through backup-operator replication requirements.

Build these expectations into vendor contracts, not just technical architecture:

• Backup operator clauses requiring continuous replication to a second, independent operator
• Export rights guaranteeing you can pull evidence and metadata in an open, non-proprietary format at any time
• Handover procedures specifying how registry proof and archived evidence transfer if the primary operator exits

Contractual guarantees matter more here than technical promises, since a vendor's uptime claims mean little if the underlying contract lets them walk away without a handover plan. Running a quarterly persistence exercise, simulating an operator exit and confirming a backup can restore the passport with matching hashes intact, catches gaps before a regulator does.

Turning all of this into action does not require a year-long program. Five steps, done in order, cover most of the exposure.

1. Map evidence to identifiers. For your highest-risk product lines, confirm every certificate links to a specific SKU, batch, or version, not just a product category.
2. Enforce supplier SLAs. Set submission deadlines and validation rules, and track compliance by supplier, not just by document.
3. Enable immutable logging. Turn on append-only or hashed logging for uploads, edits, and approvals before you scale evidence volume further.
4. Run a persistence test. Simulate a backup-operator failover and confirm exported evidence opens and verifies correctly.
5. Prepare an audit package. Bundle evidence, metadata, and a log extract keyed to the same product identifier, following the trace-request structure in the GS1 Global Traceability Standard.

Start with regulated product groups and high-risk materials, textiles with restricted substance declarations, electronics with safety certifications, since those are where market surveillance authorities look first.

Pro Tip: Don't wait for a real audit request to test your export package. Generate one internally every quarter and hand it to someone outside the compliance team to see if they can follow it without help.

DPP Grid links every supplier document to a product at model, batch, or item level, the same granularity ESPR itself demands. When a brand imports products through Shopify, CSV, or an API, each supplier submission gets tied to that specific record rather than sitting in a generic file library.

AI-assisted extraction pulls structured fields, issuer, scope, expiry, from uploaded documents, but nothing publishes automatically. A human reviewer checks and approves each item before it goes live, so an AI suggestion never gets treated as a verified fact. Every edit after that point keeps a permanent version history, and published passports get QR codes and machine-readable exports for anyone who needs to check the record later.

DPP Grid organizes and preserves this evidence infrastructure. It does not issue legal certification, and using the platform does not by itself make a product compliant with any regulation.

Building the checklist above by hand, spreadsheets for supplier tracking, a shared drive for evidence, a separate log for versioning, works for a handful of SKUs. It falls apart fast once you're managing evidence across dozens of suppliers and product lines with regulatory deadlines attached.

DPP Grid maps directly onto each step: product imports from Shopify, CSV, or API give you the identifier structure from step one, supplier upload workflows with SLA tracking cover step two, and permanent version history with immutable logs handles steps three and four automatically rather than through a manual quarterly exercise. Evidence and metadata publish together as QR-linked passport pages, so the audit package in step five is already assembled rather than pulled together under deadline pressure.

Read the practical guide to compliance evidence management to see how the workflow maps to your specific product categories, or start a trial on the DPP Grid platform to test it against your own supplier data. DPP Grid provides the infrastructure and workflow; it does not certify compliance or replace your own regulatory judgment.

• Regulation (EU) 2024/1781 (ESPR) — digital product passport obligations
• Implementing Regulation (EU) 2026/1778 — registry log system and proof of registration
• SIST EN 18221:2026 — Digital product passport: Data storage, archiving and persistence
• GS1 Global Traceability Standard

It is a tamper-evident, timestamped record connecting every supplier document, verification, and approval to a specific product model, batch, or item, distinct from the EU registry's own access logs.

No. Under Implementing Regulation (EU) 2026/1778, proof of registration is available for only 90 days and confirms registration, not substantive compliance evidence.

Issuer, issuing body, certificate ID, scope, validity and expiry dates, and explicit linkage to the correct product identifier, batch, or version.

Retention needs to exceed the registry's 90-day proof window; EN 18221:2026 covers archiving and persistence but leaves exact retention periods to the brand's own policy and product category.

Yes, if the contract includes backup-operator replication and export rights, both of which EN 18221 addresses directly.

No. DPP Grid organizes, links, and preserves supplier evidence and version history, but it does not issue legal certification or guarantee compliance with ESPR or GPSR.

• DPP Grid solutions
• Real Product Passport Examples: Fashion and Consumer Goods
• Compliance Evidence Management for Digital Product Passports
• GPSR product-safety readiness