Trust centre

Most products ask you to take a privacy claim on faith. This page is the evidence instead: where encryption happens, who holds each key, what our servers can still see, and what we cannot do even if we wanted to.

The short version

Your vault is encrypted in your browser before it reaches us. We store ciphertext.
Your master key is derived from your password on your device. It is never sent to us, so we cannot decrypt your vault, and neither can anyone who reaches our database.
Some vault metadata is stored unencrypted so your entries can be listed and filtered. That list is below. Do not put sensitive content in those fields.
Two kinds of key are held on our servers, and both are for signing statements rather than reading your data. They are named below.

Key custody

Every piece of key material in the product, where it comes from, and who can use it.

Key custody for every cryptographic module in LucidData
Key material	Held by	Where it comes from	What it protects
Master key lib/crypto/key-derivation.ts	You, in your browser	Derived in your browser from your password and your key salt with PBKDF2-SHA256, 600,000 iterations	Every per-entry data key in your vault It is never sent to the server and is held only in memory, so it is lost when the tab closes.
Per-entry data key (DEK) lib/crypto/client-crypto.ts	You, in your browser	Generated fresh in your browser for each vault entry (AES-GCM 256)	The contents of one vault entry The server stores it only wrapped by your master key, so it cannot be unwrapped server side.
Recovery escrow key lib/crypto/recovery.ts	You, in your browser	Derived in your browser from your one-time recovery code with PBKDF2-SHA256, 600,000 iterations	An escrowed copy of your master key, used after a password reset The server stores the wrapped copy and the salt. It never sees the recovery code.
Vault export key lib/crypto/vault-export.ts	You, in your browser	Your master key, used in the browser during export	The decrypted export you download Decryption happens in your browser. Plaintext never passes through the server.
Contribution anonymization lib/crypto/anonymize.ts	No key involved	No key. Direct identifiers are stripped in your browser	Marketplace contributions before they leave your device You choose which remaining fields to share. Removal happens before upload, not after.
Audit chain hashes lib/crypto/hashing.ts	No key involved	SHA-256 computed on the server over event metadata	The integrity of your audit trail Hashes are not encryption. They make tampering detectable, and they cover metadata only.
Issuer signing key lib/crypto/credential-signing.ts	LucidData servers	Ed25519 keypair generated on the server, private half AES-256-GCM-wrapped with ISSUER_KEY_SECRET	Credentials an organization issues about a person This is server custody by design: an issuer signs a statement, so the signature must not depend on the subject being present.
Credential verification key lib/crypto/credential-verify.ts	LucidData servers	The public half of an issuer key, published for verifiers	Nothing. It only checks signatures Public by design. Anyone can verify a credential without an account.
Consent receipt signing key lib/crypto/consent-receipt.ts	LucidData servers	Ed25519 keypair generated on the server, private half AES-256-GCM-wrapped with ISSUER_KEY_SECRET	The signed statement of what you agreed to Server custody by design: a receipt is LucidData attesting to the terms, and it carries no vault content.
Deletion receipt signing key lib/crypto/deletion-receipt.ts	LucidData servers	Ed25519 keypair generated on the server, private half AES-256-GCM-wrapped with ISSUER_KEY_SECRET	The signed statement of what was erased when you deleted your account The receipt holds counts, table names, and a hash of your email. Your address is not stored, and the hash cannot be reversed to recover it.
Ingestion keypair lib/crypto/ingestion-keys.ts	You, in your browser	ECDH P-256 keypair generated in your browser. The public half is published; the private half is wrapped with your master key	Records a connector fetches from a provider on your behalf A sync runs while you are away, so it gets the public half only. It can write records it cannot read, and they stay sealed until you next unlock.

What our servers can see

Vault contents are ciphertext. These columns are stored unencrypted so the app can list, filter, and scope your entries without decrypting them. Keep sensitive content out of them.

Unencrypted vault metadata columns
Column	Why it is unencrypted
label	The name you give an entry, shown in your vault list
category	Groups entries and drives consent scoping and marketplace eligibility
tags	Your own labels, used for filtering
schema_type	Which structured form the entry uses, so it can be rendered and mapped

Consent terms, audit records, credential claims, and billing details are also stored unencrypted, because both parties and any auditor need to read them.

What revocation cannot do

Revoking consent stops future access immediately. It cannot recall data that was already delivered. If you granted export access, the recipient holds a copy that no revocation can reach.

Retention

Records are destroyed on a schedule rather than kept indefinitely. A job runs every 15 minutes and enforces these windows.

Retention window for each kind of record
Record	Destroyed after
Consent requests, once answered or lapsed	90 days
Credential requests, once answered or lapsed	90 days
Share links, once expired or revoked	30 days
In-app notifications	180 days
Records inside a purchased dataset	When the buyer's download window closes, or when the retention period the buyer declared runs out, whichever comes first

What deletion leaves behind

Deleting your account removes your vault, consents, credentials, contributions, and audit history. Four things survive, and each one is listed on the signed receipt you get when you delete.

Records of payouts already sent to you
Held by Stripe. A payment processor must keep transaction records to meet financial regulation. We delete the connected account; the transaction history is theirs to retain.
Any data they exported while your consent was active
Held by Recipients you granted consent to. An exported copy is already in their hands. Revoking consent ends future access; it cannot recall a delivered copy.
A signed deletion receipt holding a random account id and a hash of your email
Held by LucidData. It is the evidence that your deletion happened. It cannot be used to recover your address.
Counted placeholders in datasets a buyer already purchased
Held by LucidData. The payload is emptied and every link to you is cleared. What remains is a count and a category, which cannot be traced back to you.

Certification status

We publish only what is true. Nothing below is claimed as both achieved and under way.

SOC 2 Type II
No audit has been started. We will publish the report when one exists.
Not started
ISO 27001
No certification has been started.
Not started
Independent penetration test
No third-party test has been commissioned yet.
Not started

Subprocessors

Third parties that process data on our behalf, and what each one handles.

Subprocessors and the data each one handles
Provider	Role	Data handled
Supabase	Database, authentication, and realtime	Account records, encrypted vault entries, consent and audit records, unencrypted vault metadata
Vercel	Application hosting	Request traffic and server logs. No vault plaintext, because none exists server side
Stripe	Payments and contributor payouts	Billing details and payout account details for organizations and contributors
Resend	Notification email, when configured	Email address, notification title, and message text. No vault content

Report a vulnerability

Report a suspected vulnerability to the address above. Tell us what you found and how to reproduce it. We will acknowledge within three working days. Do not access, modify, or exfiltrate other people accounts or data while testing.

security@luciddatabank.com

Threat model

What each design decision protects against, and what it leaves exposed.

Read the threat model

Assurance and procurement

Processing terms, support commitments, data residency, recovery objectives, the incident runbook, and answers to the standard security questionnaire. Including where we do not yet meet a requirement.

Read the assurance pack

Accessibility

How the product conforms to WCAG 2.2 Level AA, how that was evaluated, and every limitation we know about. The product handles health, financial, and legal records, which is exactly the data the people most likely to be excluded depend on.

Read the accessibility statement

Browser extension

Every permission the extension holds, what each is for, and which capabilities stay off until you grant them. The browsing permissions are optional, so your browser withholds them rather than us promising not to use them.

Read the extension permissions