Security
Audit Trails and Versioning in a DPP
Why a Digital Product Passport must be versioned append-only — audit trail design, version queries, signed update receipts and practical implementation.
A passport's content changes over time. How that change is recorded determines your position in an audit. The rule is simple: passports are versioned append-only, never overwritten.
Why overwriting is not enough
Correcting a field loses two pieces of information: the old value and the moment of change. An audit asks about both:
- What value was declared when the product was placed on the market?
- When was the error noticed, and when was it corrected?
A system that cannot answer cannot evidence good faith.
Version design
| Element | Content |
|---|---|
| Version number | Incrementing, unique |
| Timestamp | Moment of publication |
| Changed fields | Field-level diff |
| Reason for change | Certificate renewal, formulation change, correction |
| Owner | Approving role |
| Signature | A seal over the version content. See eIDAS and signing |
Version versus audit trail
- Versions: the published states of the passport. Externally visible.
- Audit trail: every operation in the system (login, edit, approval, access). Kept internally.
Together they provide full accountability. See DPP access rights.
The API side
EN 18222 lists version queries among its API operations. The concrete question to ask a platform: "can I retrieve the version as of a given date through the API?" See EN 18222 passport APIs.
Practical implementation
- Record every publication as a version; draft edits do not create versions.
- Make the reason for change a mandatory field.
- Make the diff visible so internal users can see what changed.
- Move the archive to separate storage but keep it reachable. See EN 18221 archiving.
Frequently asked questions
Does every small change need a version?
Every publication that changes passport content does. Presentation edits (imagery, layout) can be handled separately.
Can I delete an old version?
No. The persistence obligation covers version history. The exception is personal data erasure requests. See GDPR and DPP data.
Is a large number of versions a problem?
No; passport documents are small. In scenarios writing dynamic data — battery SoH, for instance — keep the update cadence sensible. See battery state of health.
