Retention Policy

Ephemera's core promise: we never keep your cluster data longer than the current audit session requires. This document states exactly what we retain, for how long, and how we enforce it.

What 'job completion' means

Throughout this policy, 'job completion' means the moment the rendered PDF audit report is made available to the Customer. All auto-wipe commitments in this document and in our Terms & Conditions are triggered by this single event.

What we retain during an audit

• The cluster dump - the ZIP or YAML you upload, after client-side secret-stripping and server-side redaction. Stored in your chosen region's object storage.
• Derived findings - structured records extracted from the dump (finding IDs, severities, namespace names, control IDs). No raw manifests, no secret values.
• The rendered PDF - the audit report, stored in your region's object storage.

All three are deleted within 24 hours of job completion (as defined above).

The deletion mechanism - belt and suspenders

• Bucket lifecycle rule - your region's object storage bucket has a 24-hour expiry rule applied at the storage layer. Even if our application layer fails completely, this hard floor kicks in.
• Per-minute wipe cron - a background job runs every minute, identifies jobs whose delete_at timestamp has passed, and explicitly deletes every associated object from object storage.
• Append-only retention log - every deletion event is written to an append-only, hash-chained log. Each entry lists the deleted objects — normally each as key:SHA-256, i.e. the object's storage path plus a fingerprint of its exact contents. (The scheduled cleanup that removes anything older than its 24-hour limit records just the path, without the content fingerprint.) Each entry also carries a timestamp, the chain fields, and one ed25519 signature over the whole entry. You can download your signed log and verify each entry against our public key - if any entry has been edited, deleted, or reordered, the hash chain breaks and the signature will not verify.

What we retain longer

• Retention log entries - kept indefinitely as an immutable audit trail. Each entry contains only object storage keys and their SHA-256 hashes, a timestamp, internal identifiers (job and tenant UUIDs, region), the hash-chain fields, and an ed25519 signature. These entries do not contain personal data or any artifact contents, and their retention is justified under GDPR Art. 5(1)(e) by the minimal scope and the integrity-of-processing purpose they serve.
• Workspace metadata - your email, organization name, role, region preference, billing status. Stored in the control-plane database in your region. Retained for the duration of your subscription plus 30 days.
• Audit metadata - job IDs, finding counts, scores, timestamps. Retained for 90 days on a rolling basis for dashboard trend charts. No finding titles, no evidence snippets, no remediation text after the 24-hour auto-wipe.

What we never retain

• Your kubeconfig or raw cluster credentials - Ephemera only receives the exported dump, not live cluster access.
• The values of any Kubernetes Secret (stripped at the browser before upload).
• Raw container environment variable values that match secret patterns.
• JWT tokens, API keys, or private keys found in your dump.

Region pinning

Your cluster dump, derived findings, and PDF are written only to the region you selected at signup. They do not cross region boundaries. The control-plane metadata (your account, billing) lives in a control-plane database replicated within the same continent.

Cron last-run status

The deletion cron publishes its last-run timestamp publicly so you can verify it is running. This is a machine-readable liveness probe — it surfaces only the timestamp, not how much was processed.

Verifying the policy

The retention log for your workspace is visible in the dashboard under Trust → Retention log. Use Download signed log (JSON) there to export the whole signed entries — including the hash-chain fields and the full list of deleted objects — then verify them offline against our public key published at https://ephemera.sh/status. Recompute each entry's hash, confirm the chain is unbroken, and check each ed25519 signature; if the log has not been tampered with, the chain holds and every signature verifies. The exact construction is documented on the Trust page. (A human-readable CSV is also available, but it omits the chain fields and is not the artifact you verify against.)

Changes to this policy

If we ever loosen this policy (retain things longer, retain more things), we will notify all active users by email at least 30 days in advance, and publish a changelog at ephemera.sh/changelog. Tightening the policy (keeping less) can happen at any time.

Questions? Email privacy@ephemera.sh.