Security · v2026-05-v1.0

How we protect your learning data.

What we encrypt, who can read what, when we restore from backup, how we respond to incidents \u2014 the controls that actually run today, with no aspirational fluff.

Last updated: Effective 2026-05-05 · Version 2026-05-v1.0\u2713 Aligned with GDPR Art. 32
Decorative illustration

TLS 1.3 in transit

Every request encrypted, modern ciphers only

AES-256 at rest

Provider-managed keys, rotation by Base44

Per-user row-level RLS

Your data isolated from every other account

72h breach SLA

GDPR Art. 33 · you and the regulator notified

In plain English

Plain-English summary.

The full text below is precise, but the headlines are simple.

What we promise

  • Every byte travels over TLS 1.3 — same crypto your bank uses.
  • At-rest data is encrypted on the storage layer with AES-256 (provider-managed keys).
  • Each user sees only their own rows — enforced server-side by row-level security, not by the UI.
  • Backups are taken at least daily and kept off-site for disaster recovery.
  • If we ever have a notifiable breach, we will tell affected users and the regulator within 72 hours.

What we never do

  • We never email or chat-message your password — nobody on staff sees it.
  • We never store payment-card or wallet credentials — NOWPayments handles all crypto checkout.
  • We never use your private uploads to train a third-party model without your explicit opt-in.
  • We never share access logs with marketers or data brokers.

1. Overview

This Security Policy describes the technical and organisational measures LinguaDig uses to keep your learning data confidential, available, and intact. It complements our Privacy Policy (which is the legal commitment) by describing the actual controls (the engineering reality).

This page is version-stamped (2026-05-v1.0, effective 2026-05-05). Substantive changes are published as a new version. We only describe controls that are in place today \u2014 we deliberately do not list aspirational measures.

2. Encryption

In transit

  • All connections to LinguaDig use TLS 1.3 (with TLS 1.2 fallback for legacy clients) and modern AEAD cipher suites only (e.g. TLS_AES_256_GCM_SHA384).
  • HTTP Strict Transport Security (HSTS) is enabled with a preload-eligible policy, so a downgrade to plaintext is impossible after first visit.
  • Calls from the LinguaDig backend to sub-processors (OpenAI, Supadata, NOWPayments) are equally TLS-protected; we pin to vendor-published certificate authorities.

At rest

  • Data is stored on the Base44 platform, which encrypts at rest using AES-256 on the storage layer with provider-managed keys.
  • Uploaded files in private storage (audio, voice clones, support attachments) inherit the same at-rest encryption and additionally require server-signed time-limited URLs to access.
  • Database backups (see §6) are encrypted with the same algorithm and stored off-site.

3. Access control & audit

  • Role-based access on the application layer: regular users see only their own data; admins have elevated permissions only on entities flagged as admin-readable (e.g. moderation queues), and only when serving an admin route.
  • Service-role isolation: backend functions that need elevated database access run as a separate service role. Service-role calls are scoped (e.g. webhooks, scheduled jobs) and never invoked from end-user paths without explicit authentication.
  • Audit logging: sensitive admin actions (subscription overrides, takedown decisions, voice-clone deletions, role changes) write append-only rows on dedicated audit entities (e.g. SubscriptionAuditLog, SourceAbuseReport). These entities are admin-readable only and used to reconstruct any incident.
  • Least privilege for staff: the LinguaDig team uses platform admin tooling that requires individual sign-in; there is no shared admin password.

4. Data isolation (per-user RLS)

Every entity that holds user content carries a row-level security (RLS) rule enforced server-side by Base44 \u2014 not by the UI. The rule is, in plain English:

read = (created_by == user.email) OR (user.role == 'admin')

and analogous rules for create, update, and delete. This means:

  • Even if a bug in our frontend tried to fetch another user's row, the platform would refuse the request.
  • Even a service-role function that mishandles a query is bounded by the schema's RLS expression for non-service calls.
  • Public sharing surfaces (e.g. shared writing/reading links) carry their own narrow RLS exceptions tied to a token \u2014 they do not relax the per-user default.

The full per-entity isolation matrix used for review is documented in docs/F-SourcePrivacy-isolation-matrix.md in our codebase, kept up to date as new entities ship.

5. Retention & deletion

The authoritative retention table is in the Privacy Policy §10. From a security viewpoint:

  • Uploaded content (Source Studio sources, audio recordings, support attachments, voice clones) lives on private storage and is deleted within 30 days of account or row deletion.
  • Database deletions cascade to backups via the next backup-pruning cycle (we do not restore-and-replay deleted rows under any circumstance).
  • Cryptographic erasure: voice-clone provider keys are revoked at deletion time so even cached provider data is unrecoverable.
  • Hashes of removed content (DMCA / DSA takedowns) are retained indefinitely to prevent re-upload \u2014 the original content itself is purged.

6. Backups & disaster recovery

  • Daily off-site backups of all production databases, encrypted with AES-256. Backup keys are rotated by the storage provider on a vendor-defined cadence.
  • Recovery point objective (RPO): ≤ 24 hours. Recovery time objective (RTO): ≤ 8 hours for the core platform.
  • Backups are kept for 30 days on a rolling window. Older snapshots are securely destroyed.
  • We exercise restore drills periodically against a non-production environment to verify backup integrity.

7. Incident response (GDPR Art. 33 / CCPA)

  • If we become aware of a personal-data breach, we notify the relevant supervisory authority within 72 hours in line with GDPR Art. 33, and CCPA / state-level analogues for affected California residents.
  • If the breach is likely to result in a high risk to your rights and freedoms, we additionally notify affected users without undue delay (GDPR Art. 34) by email and an in-app banner.
  • The notification will describe: the nature of the breach, the categories and approximate number of records affected, the likely consequences, and the measures taken or proposed to address it.
  • Internal runbook: detection \u2192 contain \u2192 eradicate \u2192 recover \u2192 lessons learned. Every step is recorded on the security audit log so the response is reconstructable.
  • Report a suspected security incident to security@linguadig.app (please don't disclose technical details on a public channel before we've had a chance to remediate).

8. Sub-processor security review

Before a new sub-processor is added, it must satisfy:

  • A written Data Processing Agreement (DPA) committing to confidentiality, security, and breach notification.
  • EU-aligned transfer mechanism (Standard Contractual Clauses, where the sub-processor is outside the EEA / UK).
  • A current public security posture (e.g. SOC 2 Type II, ISO 27001) or, where unavailable, a documented controls review by our team.
  • A scoped purpose: each sub-processor receives only the data necessary for the service it provides.

The current sub-processor list with role, location, transfer mechanism, and privacy URL is published in the Privacy Policy §8. Adding or removing a sub-processor is a substantive policy change that triggers a privacy-policy version bump and a re-agreement prompt.

9. Vulnerability disclosure

We welcome reports from independent security researchers. To submit a finding:

  • Email security@linguadig.app with steps to reproduce.
  • Please give us reasonable time to remediate before public disclosure (we target 90 days from acknowledgement, less for trivially reproducible issues).
  • Don't access or modify another user's data, run automated scans against production, or exfiltrate data \u2014 a proof-of-concept against your own account is sufficient.
  • Acting in good faith under these guidelines, you will not be subject to legal action by LinguaDig for the disclosure.

We currently run a self-managed disclosure program; we will publish a HackerOne-style bounty surface only when we can fund it consistently \u2014 we do not list one we cannot maintain.

10. Penetration testing

  • The LinguaDig codebase is subjected to an internal red-team review on a quarterly cadence covering authentication, RLS bypass, payment flows, voice-clone abuse, and prompt-injection on AI surfaces.
  • Findings are tracked as roadmap items with severity ratings; criticals are remediated before any new feature ships on the affected surface.
  • Once we cross 10,000 active monthly users, we will commission an annual external penetration test from a CREST-accredited firm and publish a redacted attestation.

11. Changes

We may update this Security Policy as the platform evolves. Each version is immutable once published; substantive changes ship as a new version with a new effective date. Subscribe to What's new to see version bumps as they happen.

12. Contact

Effective date: 2026-05-05 \u00b7 Version: 2026-05-v1.0

Your data, your decision

Ready to start learning?

5-day free trial · no credit card · cancel anytime · delete your data with one click whenever you want.

Have a question? Reach our support team

© 2026 LinguaDig · All rights reserved