Is Your Catalog Passport-Ready? The 5-Area Audit

Before any DPP software decision, audit five areas: identity, required fields, evidence, freshness, write-back. Here's the operational check, area by area.

Digital Product Passport requirements arrive category by category — batteries first, February 2027, others behind them. Before evaluating any passport software, there’s a cheaper and more revealing exercise: audit whether your catalog data could support a defensible passport today. For most multi-supplier catalogs the honest answer is no, and the audit tells you precisely where and how much — which is the real scope of your readiness project, independent of which passport tool eventually sits on top.

Five areas. For each: what to check, and what “ready” looks like.

Area 1 — Identity

The check: For your regulated (or soon-regulated) product category, does every physical product exist as exactly one record? Sample the category and count: how many products appear under multiple part numbers, supplier codes, or manual entries?

Ready looks like: One canonical record per real product, with duplicates resolved and merges traceable. A passport attaches to a product identity — two records for one battery means either two conflicting passports or an unanswerable question about which record is the truth.

Common finding: Distributors sampling honestly typically find duplication concentrated exactly where it hurts — products onboarded from multiple suppliers over years, which for battery-containing industrial products is most of the category.

Area 2 — Required fields

The check: Take the mandatory field set for your category’s passport and measure completeness against it, per SKU. Not “do we roughly have specs” — field by field: category, model, chemistry, capacity, technical characteristics. What percentage of SKUs have every mandatory field populated as a structured value?

Ready looks like: Mandatory fields exist as queryable, normalized fields — not embedded in a description string, not “it’s in the datasheet somewhere.” A value trapped in a PDF is, for passport purposes, a missing value with extra steps.

Area 3 — Evidence

The check: For each populated claim — a certification, a recycled-content figure, a compliance status — is there a source document on file that supports it? Pick twenty claims at random and try to produce the document for each.

Ready looks like: Every claim links to a supporting document. Under a regime where the operator placing the product on the market is liable for passport accuracy, a value with no evidence behind it isn’t data — it’s exposure. This is the area where “we have the data” and “we can defend the data” turn out to be different statements.

Area 4 — Freshness

The check: For the documents behind your claims — when were they issued, and are any certificates expired or superseded? Does anything in your process notice when a supplier revises a datasheet or a certificate lapses, or is freshness assumed until someone stumbles on a problem?

Ready looks like: Issue dates and validity tracked per document, expiries surfaced automatically, and supplier revisions detected rather than discovered. A passport describes the product as placed on the market now; four-year-old evidence with unknown status doesn’t meet that bar.

Area 5 — Write-back

The check: Where would passport-ready data actually live and flow? If the answer is “a new spreadsheet / a standalone compliance tool,” you’re about to create a parallel copy of product data that drifts from your ERP and PIM the week after it’s built.

Ready looks like: The cleaned, evidenced record lives in your canonical layer and is written back into the systems you already run — so the passport, the ERP, the PIM, and the storefront all draw on the same truth, and an update propagates everywhere instead of into one silo.

Scoring it honestly

Area	Failing looks like	Ready looks like
Identity	Same product under multiple records	One canonical record per product
Required fields	Specs in descriptions and PDFs	Structured, normalized mandatory fields
Evidence	Claims with no document behind them	Every claim traceable to a source
Freshness	Expiry discovered by accident	Validity tracked, revisions detected
Write-back	A new standalone data silo	Trusted record flowing into existing systems

The output of the audit shouldn’t be a green/red compliance score — it should be a work queue: these SKUs have unresolved identities, these fields are blank, these claims lack evidence, these certificates are expired. That queue is your actual readiness project, and its size is knowable this week, not in 2027. The seven data gaps guide covers why each area breaks the way it does.

Want to run the audit on a real category together? Book a 30-minute call — bring one supplier feed from a battery-related category and we’ll score the five areas against it.

FAQ

How do you assess whether a catalog is ready for Digital Product Passport requirements?

Audit five areas: identity (one record per real product), required fields (mandatory passport fields as structured values), evidence (a source document behind every claim), freshness (validity and revisions tracked), and write-back (data flowing into existing systems rather than a new silo).

What should a DPP readiness assessment produce?

An actionable work queue — which SKUs have unresolved identities, which mandatory fields are blank, which claims lack evidence, which certificates are expired — rather than a generic red/green compliance score.