Assurance and procurement

Where your data is processed

Support commitment

Monday to Friday, 09:00 to 17:00 UK time, excluding public holidays. Severity 1 reports are monitored outside those hours. Reach us at support@luciddatabank.com.

Availability target: 99.5% monthly, excluding planned maintenance. This is our operating target. We do not yet publish measured uptime, and there is no service credit scheme. Both are recorded as planned work rather than described as in place.

Backup and recovery

• Database loss or corruption

  Data loss window 24 hours · Recovery time 8 hours

  Supabase daily automated backups with point-in-time recovery on paid plans.

  Never tested. This is a design target, not a measurement.

• Application hosting failure

  Data loss window None. The application holds no state. · Recovery time 1 hour

  Redeploy from the Git repository. Every environment variable is reproducible.

  Never tested. This is a design target, not a measurement.

• Loss of the issuer signing secret

  Data loss window None for vault data. Issued credentials become unverifiable. · Recovery time Not recoverable. Keys must be rotated and credentials reissued.

  Issuer key rotation under LD-406. Existing credentials signed by the lost key cannot be recovered.

  Never tested. This is a design target, not a measurement.

Incident response

Written to be followed under pressure by someone who did not write it.

• Incident lead

  Declares the incident, owns the timeline, and is the single decision maker. Nobody else may stand the incident down.

• Technical responder

  Investigates, mitigates, and records every action with a timestamp.

• Communications owner

  Writes user and regulator notifications, and is the only person who sends them.

1. 1. Declare

   Anyone may raise a suspected incident to security@luciddatabank.com. The incident lead declares it and starts a timestamped log.

   Immediately on suspicion. Declaring and standing down costs nothing.

2. 2. Contain

   Revoke affected credentials and API keys, and disable the affected path. Containment comes before investigation.

   Within 1 hour of declaration

3. 3. Identify who is affected

   Query the audit chain and the relevant tables to produce the exact list of affected accounts. The chain is per user and tamper evident, so the list is evidence rather than an estimate.

   Within 12 hours of declaration

4. 4. Notify the regulator

   Where a personal data breach is likely to result in a risk to people, notify the lead supervisory authority. Record the decision and its reasoning either way.

   72 hours from becoming aware, per GDPR Article 33

5. 5. Notify affected people

   Where the risk is high, tell affected people directly, in plain language, using the template below. Do not wait for a complete picture if that would delay the warning.

   Without undue delay, per GDPR Article 34

6. 6. Review

   Write up what happened, what we changed, and what we would do differently. Publish the summary unless doing so would put people at further risk.

   Within 10 working days of resolution

We are notifying you of a personal data breach under Article 33.

What happened: [factual description, no speculation]
When we became aware: [date and time, UTC]
Categories of data: [what was affected, and whether it was encrypted]
Approximate number of people affected: [number, and how it was determined]
Likely consequences: [assessment]
Measures taken: [containment and mitigation, with timestamps]
Contact: [name and role of the incident lead]

We need to tell you about a security incident affecting your LucidData account.

What happened: [plain description]
What this means for your data: [state whether vault contents were reachable. Vault entries are encrypted in your browser with a key we never hold, so [state plainly whether that protection held]]
What we have done: [containment]
What you should do: [specific action, or "no action is needed" if that is true]
Where to ask: security@luciddatabank.com

Processing terms

The positions a data processing agreement has to state. For a countersigned agreement, write to legal@luciddatabank.com.

• Roles

  For an organization account, LucidData is the processor and the organization is the controller. For an individual account, LucidData is the controller of the account record and cannot be a processor of vault contents, because it cannot read them.

• Subject matter and duration

  Processing lasts for the term of the account and ends on deletion, subject to the retention windows published on the trust centre.

• Instructions

  We process personal data only on documented instructions, which are the actions taken through the product and its API.

• Confidentiality

  Anyone with access to personal data is bound by confidentiality obligations.

• Security measures

  Client-side encryption of vault contents, row level security on every table, a tamper-evident audit chain, multi-factor authentication, and step-up re-authentication for destructive actions.

• Subprocessors

  The list is published on the trust centre. We give 30 days notice before adding one, and you may object.

• Assistance with data subject rights

  The rights engine handles access, correction, deletion, restriction, and portability requests with jurisdiction-aware deadlines, and records every step.

• Breach notification

  We notify the controller without undue delay after becoming aware of a personal data breach, following the published incident runbook.

• International transfers

  Personal data is processed in the United States. Transfers from the EU or UK rely on Standard Contractual Clauses. There is no in-region processing option today.

• Deletion and return

  On termination, data is deleted through the same explicit deletion path used by account deletion, and a signed receipt is issued.

• Audit

  We answer a security questionnaire and provide the published documentation. We do not currently support on-site audits or bespoke audit rights.

Subprocessors: Supabase, Vercel, Stripe, Resend. Each is listed on the trust centre with the data it handles.

Security questionnaire

The questions every questionnaire asks, answered once so the answers cannot drift.

• Is customer data encrypted at rest?

  Vault entries are encrypted in the browser with AES-256-GCM before they reach us, under a key derived from the user password with PBKDF2-SHA256 at 600,000 iterations. We cannot decrypt them. The database is additionally encrypted at rest by the provider.

• Is customer data encrypted in transit?

  Yes. TLS on every connection, enforced by both the application host and the database provider.

• Who can access production data?

  Vault contents cannot be accessed by anyone but the user, including us. Unencrypted metadata and account records are reachable by the service role, which is used only by server code and never exposed to a browser.

• Do you have multi-factor authentication?

  Yes. Passkeys (WebAuthn) and TOTP, with backup codes. Destructive actions additionally require a password re-entry within the previous two minutes.

• How do you handle access logging?

  Every read, write, grant, and revocation writes to a per-user SHA-256 hash chain. Any modification to a past entry breaks the chain and is detectable. Users can verify their own chain.

• Have you had a penetration test?

  No. No third-party test has been commissioned. We run dependency auditing and publish a vulnerability disclosure address.

• Are you ISO 27001 or SOC 2 certified?

  No. Neither certification has been started.

• Do you use subprocessors?

  Yes: Supabase, Vercel, Stripe, and Resend. Each is listed on the trust centre with the data it handles.

• How long do you keep data?

  Answered requests for 90 days, share links for 30 days after they die, notifications for 180 days, and purchased dataset records until the buyer download window or the declared retention period ends, whichever is first. The windows are published on the trust centre and enforced by a scheduled job.

• How do you handle deletion?

  Deletion is explicit rather than left to database cascades, is verified afterwards, and produces a signed receipt listing what was removed and what a payment provider still has to keep.

If LucidData ends

• What happens to my data if LucidData shuts down?

  We would give at least 90 days notice and keep the export working for the whole of it. Your vault export runs in your browser, so it does not depend on us staying solvent enough to run a server-side job.

• Can I get my data out without your help?

  Yes. Export produces JSON decrypted in your browser. Issued credentials export with their signature and the issuer public key, so a third party can verify them without contacting us.

• What happens to consent grants I have given?

  Grants are enforced by our access checks, so they end when the service does. A recipient who already exported a copy still holds it. That limit is stated on every export order and on the trust centre.

• Is there an escrow arrangement?

  No. There is no source code escrow and no third-party data escrow. We would not want a buyer to assume one exists.