Data retention & deletion
What Lockey keeps, for how long, and what happens when someone asks for it back or asks for it gone.
The governing principle
The document owner controls the lifetime of their data. Lockey does not expire or delete a person's documents on its own schedule — a document lives until its owner deletes it or closes their account. Everything that does expire automatically is a short-lived access artifact, not the data itself.
That split is the whole table below.
Automatic expiry (access artifacts)
These are created to grant access and disappear on their own. None of them contain document contents.
| Artifact | Lifetime | Why this long |
|---|---|---|
| Viewing session | 1 hour | Long enough to read a document, short enough that an abandoned tab stops working. |
| Signed page URL | Expires with its session | Transport auth only — link state is re-checked live on every fetch regardless. |
| Owner preview URL | 10 minutes | A leaked preview URL goes stale fast. |
| Recipient email OTP | 10 minutes, single use | Standard OTP hygiene. |
| Password-lockout counter | 15 minutes | Self-healing, so a locked-out recipient never needs owner intervention. |
| Link-state cache (KV) | 60 seconds | And invalidated immediately on revoke or pause — the cache never delays enforcement. |
| Watermarked page composite | Purged when the session ends | Also purged when watermark config or the mask set changes, so a cached page can never serve an outdated watermark or an unmasked region. |
Retained until deletion
| Data | Retained | Notes |
|---|---|---|
| Original files (R2) | Until the owner deletes the document or the account | Never served to a recipient or partner. |
| Rendered page images | Same as the document | Clean renders are owner-private. |
| Document metadata | Same as the document | Name, type, size, sensitivity, page count. |
| Share links & rules | Until deleted; revoked links are retained as history | A revoked link stops working immediately but stays visible in the owner's records. |
| Audit events | Until the account is deleted | See the open item below. |
| Notifications | Until the account is deleted | Metadata only — never document contents. |
| Consent ledger | Until the account is deleted | Versioned, append-only; it is the proof of what was agreed and when. |
Open item: audit-log retention limits
Audit events are currently retained for the life of the account. There is no automatic age-based purge yet — this is tracked as an open backlog item, not a shipped control. Audit rows carry request metadata (IP address, coarse location, device type, OS, browser), which is personal data under GDPR.
We are stating this rather than implying a limit we do not enforce. If a defined audit-retention window is a hard requirement for you, ask before integrating.
Data minimization
Some things are deliberately never stored, which is stronger than any retention limit:
- Sensitive-field detection stores geometry and field type only — the coordinates of a passport number on a page, and the fact that it is a passport number. The extracted text is never persisted.
- Subject contacts in document requests are stored as a hash, not plaintext. This is also what makes the no-existence-oracle guarantee possible.
- Audit events carry metadata only — who, what, when, from where. Never a document's contents.
- Notifications carry metadata only — enough to tell an owner something happened, never enough to leak what the document says.
Access & portability requests (GDPR Art. 15 / 20)
Account holders export their own data from the Lockey app — Settings → Your data → Export my data — and receive a dated JSON file immediately. No support ticket, no waiting period.
The export covers profile, folders, documents, share links and their rules, viewing sessions, the audit trail, notifications, notification preferences, consents, registered devices, plan and usage, and any document requests addressed to them.
It deliberately excludes:
| Excluded | Why |
|---|---|
| Session and OAuth tokens | Exporting them would turn a downloaded file into an account-takeover kit. A token is not personal data the user provided. |
| Link password hashes | A hash is a credential. Exporting it invites offline cracking of a password the person may reuse elsewhere. |
| Push tokens | A delivery credential someone could abuse. |
| Internal storage keys | They address our infrastructure, not the user. |
| The original files themselves | The export is metadata. See below. |
The export does not contain the original documents
This is a deliberate scope decision, and it is stated inside the export file itself so anyone holding the file knows what they have. Owners access their documents through the app; the export describes the vault rather than duplicating it. If a supervisory authority reads Art. 20 as requiring the files themselves, raise it with us.
Erasure (GDPR Art. 17)
Deleting an account is one irreversible operation that purges every store:
- R2 — original files, rendered pages, and cached watermarked composites, enumerated and deleted explicitly (object storage has no cascade).
- D1 — everything cascades from the account row: sessions, devices, folders, documents, links, audit events, notifications, consents, usage. Deleting sessions also signs the person out everywhere.
- KV — cached link snapshots, so a stale snapshot cannot serve a deleted account's link for the remainder of its TTL.
Deletion is ordered R2 → D1 → KV so that a partial failure leaves the operation retryable rather than stranding unreferenced, undeletable objects.
One record survives: a metadata-only tombstone proving when the erasure happened and how many documents it covered. It carries no personal data, and it exists so the deletion itself is auditable.
What this means for partners
If you integrate against the Partner API, the retention question mostly resolves in your favor: you never take custody of the original. You read grants as hosted, watermarked, view-only sessions.
What you retain is your own: request IDs, grant IDs, statuses, and whatever you record about your decision. What Lockey retains — the documents — is governed by the subject's own account, not by your integration. When a subject deletes their account, the grants you hold stop resolving.
That is the intended trade. You get the review you needed without inheriting a retention obligation over someone else's passport.
Back to: Encryption & data protection ←