Skip to content
Governance

Audit trail, privacy, retention and regulator access

Answer who changed what, handle a data-subject request, set retention, and give a regulator read-only evidence.

DPP Shield editorial team · Updated:

Answer who changed what, handle a data-subject request, set retention, and give a regulator read-only evidence.

The admin overview

The admin dashboard summarizes the organization - profile, people and permissions, plan capacity and recent audit activity - and links onward to the management pages. It is visible to owners and admins only.

The audit log

The audit log records who did what, to which record, and when: creations, updates, publications, validation runs, supplier responses, credential and session changes, and platform-level provisioning. It can be filtered by entity, action and date range, and exported as CSV for an auditor.

The log is treated as immutable evidence. It is never swept by retention, and there is no interface that edits or deletes an entry - which is the point. A machine change is attributed as such rather than being given a fictitious human actor.

Streaming the audit log to a SIEM

Under Settings, Audit streams, an owner or administrator can send every audit entry to a SIEM as it is recorded: an HTTPS collector (each request signed with HMAC-SHA256 in x-dpp-signature, like webhooks), a Splunk HTTP Event Collector, or Datadog logs. A stream starts from now or from the beginning of the trail; the collector secret is stored encrypted and never shown again, and a test button proves the endpoint before you rely on it.

Entries go out in chain order and at least once: each carries its sequence number and SHA-256 chain hash, so the SIEM can drop a duplicate and verify its copy against the trail. A collector that fails is retried with backoff from exactly where it stopped. For an archive, the whole chain can also be downloaded as NDJSON, 50,000 entries per file.

Privacy requests

A subject export assembles the personal data held about a supplier contact, custodian, lessee or member, so you can answer a request without hunting through tables.

Erasure anonymises personal fields rather than deleting rows: the record stays, because audit entries, evidence and recall traceability have to survive. It requires an explicit confirmation because it cannot be undone, and every request is logged with its outcome so you can show what you did.

Retention

Retention settings set how long operational telemetry is kept - carrier scan events, webhook delivery attempts, privacy-request hints - with platform defaults and per-tenant overrides. The preview shows what a sweep would remove before you run it, and a scheduled sweep applies the windows daily.

The audit log is explicitly excluded, and evidence documents are yours to keep. Retention is about operational noise, not about the record of what you declared.

Regulator and third-party access

Rather than exporting a spreadsheet to everyone who asks, issue a grant: a purpose, the markets and categories it covers, and an expiry date, with owner or admin approval. The token is shown once and stored hashed, and it can be revoked at any time.

The holder gets a scoped compliance registry and an evidence register - document metadata, never file contents - and can be refused for asking outside their scope. Every read is audited as a regulator access, so you can see exactly what was looked at and when. A pending, unknown, expired or revoked token is refused without explanation.

Lifecycle reports from repairers and recyclers

A partner holding an approved access grant can also report what it did to a product: a repairer (service grant) reports repairs, inspections and remanufacturing; a recycler reports recycling and inspections; an operator with a legitimate interest reports inspections - such as a battery's state of health - and returns. It sends POST /regulator/passports/{id}/reports with its x-regulator-token, optionally naming a serialized item and adding measurements.

A lifecycle report changes nothing on its own. It waits under Lifecycle reports and in the action inbox until an owner or administrator accepts it, which records the event on the passport (with EPCIS and webhooks) and moves the item's status, or rejects it with a reason the partner can read. Accepting a recycler's report for a battery closes the passport as a recycled battery does.

How does a grant holder read restricted data?

Each public passport has an authorized view, linked from its access section. The holder of an access grant pastes the token there; it is sent in a request header, never in the address, and the page shows the restricted fields of the grant's tier - state of health for a legitimate-interest grant, dismantling information for a repairer or recycler - with the same labels and units as the public page. Every read is recorded in the audit log as a regulator access.

The public page itself lists the fields withheld from it and which tiers may read each, so a reader knows whom to ask.

Screen-by-screen reference

These pages were checked in the organization console on 8 October 2026 using an isolated sample organization. Controls can differ by role, plan, record state and configured providers. Each page below explains its purpose, a practical workflow, the visible controls and what to verify afterward.

Organization overview (/admin)

Owners and administrators see team size, subscription capacity, recent organization audit events and shortcuts to the settings they control.

Use the overview to identify which administrative area needs attention: member capacity, subscription capacity, or a recent audit event. Follow its shortcut into the corresponding settings page for the actual change. The summary is a starting point; the detailed page shows the permissions, limits, and confirmation controls for that operation.

Editor and viewer roles do not get this administrative page.

Controls and options

  • Manage team opens invitations and membership controls.
  • Plan capacity compares current use with limits; open Billing to see subscription details.
  • Recent audit activity links to the searchable audit log.
  • Admin shortcuts open billing, webhooks, custom rules and privacy settings.

Audit log (/admin/audit)

The audit table records an action, entity, actor and time for organization changes. It is a trace of events, not an editable record.

Set a narrow date range and entity type before exporting when you need to investigate one change. Match the event time, actor, action, and entity identifier against the record's own version or review history. This view is an organization change trace, so it is useful for reconstruction and accountability rather than editing the recorded event.

Audit entries are retained separately from operational retention windows.

Controls and options

  • Filter by action and entity type or restrict From and To dates, then Apply filters.
  • Clear returns to the full recent list; pagination continues through the log.
  • Export CSV downloads the current audit data for offline review.
  • Use the entity identifier and timestamp together when reconciling a change with a passport version or document review.

Lifecycle reports (/lifecycle-reports)

Approved external partners can submit repair, inspection, return or recycling reports, but each report waits for an organization decision.

Open a pending partner report and compare its item, event, and evidence with the organization's record. Acceptance records the lifecycle event and may update the item state; rejection sends a reason back to the reporter. Leave the report pending when the evidence is incomplete, because pending submissions do not change the passport.

A pending report changes no passport state.

Controls and options

  • Filter reports by status and open one to inspect source, event, item and evidence.
  • Accept records the lifecycle event on the passport and updates the reported item where applicable.
  • Reject requires a reason visible to the reporting partner.
  • Manage access grants controls who may submit in the first place.

Audit log streaming (/settings/audit-streams)

Audit streams forward signed, chained organization events to an HTTPS collector, Splunk HEC or Datadog.

Choose the destination type and HTTPS collector, then configure the receiver to verify signed, chained events before relying on the stream. Starting from now avoids a historical replay; choose backfill only when the collector is ready for the full chain. Watch delivery and sequence status after creation, and deduplicate by event identity or sequence on the receiver.

The collector credential is stored sealed and is not shown again.

Controls and options

  • Name a stream, choose collector type and HTTPS endpoint, and provide its signing secret or token.
  • Start from now or request the whole chain when an authorized backfill is needed.
  • Create stream, then inspect delivery status and retry information.
  • Use sequence numbers and hashes to deduplicate and verify the receiver's copy.

Regulator access (/settings/regulators)

A grant limits an external authority to an approved purpose, market, category, access tier and expiry.

Define a grant by authority, purpose, market, product category, tier, and expiry before sharing a token. Copy the one-time token through an approved channel and verify the recipient can see only the intended registry or evidence metadata. Revoke the grant when its purpose ends rather than relying solely on a distant expiry date.

Read-only registry and evidence metadata remain bounded by the grant; file contents are not automatically exposed.

Controls and options

  • Enter authority, contact reference and purpose; choose markets and product categories.
  • Set expiry and the appropriate access tier before Create grant.
  • Copy the one-time token securely to the authorized recipient.
  • Review grant status and revoke access when the purpose ends.

Privacy requests (/settings/privacy)

Privacy tools find a subject's organization data and record export or anonymization outcomes.

Identify the subject with the exact reference used in the organization, then inspect the proposed export before responding to a request. Erasure anonymizes eligible personal fields only after confirmation and records the action; it must preserve necessary product and audit trace. Use the request log to reconcile the requested action, actor, time, and outcome.

Anonymization preserves necessary audit and product trace while removing personal fields.

Controls and options

  • Choose subject type and supply the exact email or tenant reference.
  • Export data produces a reviewable subject package and logs the request.
  • Erase (anonymise) requires explicit confirmation and records the reason and result.
  • Check the request log before replying to the requester.

Data retention (/settings/retention)

Retention windows cover operational telemetry such as scan events and delivery attempts, with preview before cleanup.

Set the window for each operational record class, then preview the number of rows affected before a sweep. A dry run shows the impact without deleting telemetry; use the real sweep only after reviewing those counts and the policy exclusions. Audit history and uploaded evidence follow their own retention rules and are not removed by these windows.

The audit chain and uploaded evidence are not swept by these telemetry settings.

Controls and options

  • Set days per record class within the displayed limits and Save windows.
  • Preview impact counts records that would be removed under current windows.
  • Dry run sweep reports the effect without deletion; Run sweep now applies it after review.
  • Read Policy notes for excluded evidence and audit records.