Security, Residency, Retention, and Incident Response

All traffic between the browser and LAP servers is protected by TLS 1.2+ via Caddy automatic HTTPS. Data at rest in PostgreSQL is stored on encrypted volumes. Backups are encrypted with AES-256.

• Passwords: Argon2id (time cost 3, memory 64 KiB, parallelism 1)
• Authentication tokens: JWT signed with HS256, short-lived access tokens (15 min)
• Refresh tokens: httpOnly Secure SameSite=Lax cookies with single-use rotation
• API transport: HTTPS-only with HSTS headers

LAP uses PostgreSQL Row-Level Security (RLS) for workspace-level data isolation. Every workspace-scoped table (44 tables) has RLS policies that automatically filter rows based on the authenticated workspace context, set via SET LOCAL at the start of each request transaction.

This means one workspace can never query, modify, or delete data belonging to another — even if application-layer code has a bug. The database enforces the boundary.

Primary data processing and storage is located in the EU: Hetzner cloud, Falkenstein, Germany (EU). Redis and PostgreSQL run on the same EU infrastructure. The frontend is served globally via Cloudflare Workers edge locations, but no user data is stored at the edge.

Third-party sub-processors and their data locations are documented on the subprocessors page. Enterprise customers may request region-locked processing.

Data retention is configurable at the workspace level. Default retention windows apply:

• Telemetry session data: retained for the lifetime of the workspace
• Account data: retained while the account is active, deleted on erasure request
• Backups: 7-day rolling retention, daily snapshots at 03:00 UTC
• Rate limit and idempotency cache: 24-hour TTL in Redis

Self-service data export and account erasure are available through the application settings. GDPR erasure requests are processed via Celery background tasks to ensure complete removal across all storage systems.

Incidents are triaged by severity with accountable ownership:

• P1 (Critical): Service down or data breach — 4-hour response target, continuous updates until resolved
• P2 (High): Degraded service or security vulnerability — 1 business day response target
• P3 (Medium): Non-critical issues — 3 business day response target

Data breaches are reported to affected controllers within 72 hours of confirmed detection, per GDPR Article 33. Post-incident reviews are conducted and documented for all P1 and P2 incidents.

If you discover a security vulnerability, please report it responsibly by emailing security@lap-coach.racing. We commit to acknowledging reports within 48 hours and providing an initial assessment within 5 business days.

We do not pursue legal action against researchers who act in good faith and follow responsible disclosure practices.