Data and privacy

Understand stored data, product boundaries, exports, retention and erasure.

Copy page

Lepsto stores your team’s accounts, your product’s end-user data and operational records. Product access controls determine which records a request can reach; export and erasure options depend on the data involved.

This page explains those operations and their limits. The Privacy Policy, Terms of Service and sub-processor list describe the applicable agreements and processing disclosures.

What data the platform holds

Lepsto keeps your team accounts separate from the end users of the product you build:

• Team data: accounts, organization and product memberships, roles and sign-in sessions.
• End-user data: product user accounts, identifiers, metadata, waitlist signups, consent decisions, visitor profiles and event history.
• Operational records: request logs, automated runs and audit records of actions.

Data classes

These terms describe the kinds of data involved:

A classification label does not guarantee redaction before AI processing. The current Privacy Policy says natural-language analytics sends unredacted questions and query result rows to Anthropic for inference in the US. Person-level results may contain normalized email addresses or phone numbers. The sub-processor list identifies Standard Contractual Clauses as the transfer safeguard.

Processing depends on the feature. For example, Brain processes connected Drive, ClickUp and GitHub content through Google Vertex AI (Gemini) in the EU to extract facts and support search, as described in the Privacy Policy.

Separation between products

Product-scoped reads, updates and deletes use the product from the validated request context. Supplying a product id alone does not authorize access.

• A resource belonging to another product returns 404, avoiding disclosure of its existence through a different response.
• Analytics queries are constrained server-side to the selected product’s rows.
• Product access requires a concrete product membership; organization ownership or administration does not silently bypass that boundary.

Choose the product’s region at creation. It cannot be changed later; using a different region requires another product. Region selection does not mean every processor runs there: the Privacy Policy describes primary storage on Google Cloud in europe-west4 and identifies US processing for Inngest and certain AI inference. See the current processing locations.

Protection

The platform data-handling documentation describes AES-256 encryption at rest, TLS 1.3 for traffic in transit, database and application access controls, and audit records identifying the actor, action and time.

For connected-account tokens, the Privacy Policy describes AES-256-GCM encryption, keys in Google Secret Manager and HTTPS connections to providers. It also explains which integration data is stored and who can access it.

Retention

The table distinguishes account and workspace data from operational records. See the Privacy Policy’s retention section for additional categories and exceptions, including waitlist emails, connected-account tokens and payment records. Consent records are described below.

The platform data-handling documentation specifies the 30-day period for automated run logs. The Privacy Policy specifies the other periods above. Prompts and responses from model calls are AI request logs. Stored conversation archives also fall in that category. Runs without model calls, such as schedules and automations, are automated run logs.

Audit records remain for their full two-year retention period, including after a deletion request and are not anonymized under the policy’s legal-claims retention rule, GDPR Art. 17(3)(e). They contain a user id, action and timestamp rather than personal content. They support incident investigation and audits and are not currently exposed as a browsable customer surface.

Audit retention is not the only exception. Consult the Privacy Policy for other retained categories, including payment records.

Exporting data

Choose the export for the data you need:

• Organization data: use the self-service export in Settings.
• Product user directory: export paginated profile, identifier and metadata records for migration, backup or access requests. Password hashes, including imported hashes, are excluded. Exports are audited with their filters and row counts.
• One visitor’s journey: export the profile, identity signals and event history as JSON. The history is limited to 50,000 events and marked truncated when it exceeds that limit.
• Consent history: export CSV for the product or filter by the record id in a visitor’s consent cookie to retrieve their decision chain. See Consent records.

A single export covers its own data area. Answering an access request may require records from several areas.

Deleting data

Soft deletion marks a record as deleted and removes it from default lists, while leaving it retrievable by id. It does not purge the record and is not a substitute for erasure.

Erasure is irreversible. Its result depends on the record:

• End user: identifiers and identity rows are deleted, profile fields are cleared and metadata is emptied. A tombstone retains the id and erasure time so existing references still resolve. The operation emits an event for other consumers to purge their copies. The email can be registered again as a new user with a new id. Repeating erasure is safe; this operation retains a pseudonymized audit trail.
• Waitlist signup: the signup, attribution and consent proof are deleted, and the directory entry is erased while its id remains as a tombstone. Erasure by email also deletes invite tokens, replaces the raw email in the consent ledger with a keyed hash and adds the address to the do-not-contact suppression list. A retention sweep handles stale pending entries separately.
• Visitor profile: the person and events are permanently deleted and the request is recorded. Already archived events are reported as a deletion gap.

The Privacy Policy provides for processing personal-data deletion requests within 30 days, with the stated retention exceptions. Do not assume every category is deleted automatically: Lepsto-held published posts and their statistics currently require a request to privacy@lepsto.com and are deleted within 30 days of that request. To remove a published post from an external network, delete it there as well. Disconnecting an integration deletes its stored token but does not remove data already produced from it.

Consent

The consent banner stores each choice as a record and links later changes to earlier decisions. You can export this chain for review or as part of an access request.

Consent records contain no end-user identifier, so end-user erasure cannot select them by identity. Product erasure deletes the product’s Consent tables. Records remain for 1095 days unless the product is erased; the visitor’s cookie lasts twelve months. See Lepsto Consent and Consent records.

Incident response

The documented response process is detection, triage, containment, investigation and resolution, followed by a postmortem within 48 hours. A data breach also requires notification to affected customers.

Next steps

• Lepsto Consent: understand visitor choices and signed records.
• Add a cookie consent banner: install and verify the banner.
• Ask questions about your product’s data: understand the analytics query path.
• Roles and permissions: review product access.