Access Control
Users authenticate through Klara's application authentication backed by PostgreSQL. Passwords are stored as salted scrypt hashes; signed sessions are validated server-side and expire after the configured session period.
Server-side authorization scopes database reads and writes to the authenticated user. Administrative database operations are available only through server-side code paths.
Database credentials, authentication secrets, calendar-encryption keys, OAuth client secrets, webhook secrets, API keys, and deployment credentials are server-only environment variables and are not exposed to browser code or committed to source control.
Internal Access Control
Production system access is restricted to authorized Klara and Levo Studio administrators who need access for operation, security, support, or incident response and are bound by confidentiality obligations.
Klara and Levo Studio apply least privilege, need-to-know access, strong passwords or SSH keys, access revocation, and MFA where available for Dokploy, Docker Swarm, servers, databases, backups, logs, and provider accounts.
Production secrets are stored in the deployment environment separately from source code. Access can be revoked and affected credentials can be rotated.
Encryption
Klara encrypts the following content fields in the browser before storing them in the application database: project names, task titles, task descriptions, event titles, event locations, event notes, event attendee placeholders, calendar day highlight labels, calendar template names, calendar template item titles, locations, notes, and attendee placeholders, goal titles and descriptions, and key result titles and descriptions.
The following metadata remains unencrypted because it is needed to operate the product: account identifiers, row IDs, timestamps, calendar start and end times, due dates, recurrence settings, record relationships such as project_id and task_id, task status, priorities, calendar day highlight dates and colors, calendar template item timing, project/task relations, recurring-source metadata, and focus preference structure.
Klara stores encrypted content as ciphertext and does not store the user account encryption key in the application database as plaintext. Without the user account encryption key, Klara cannot read encrypted content from the server-side database values alone. This protection depends on the security of the user device, browser storage, user credentials, and recovery-key handling.
Account encryption keys are generated in the browser and can be synced using a password-wrapped backup. Users can export a recovery key. Transport encryption is provided by HTTPS/TLS in production.
Data Minimization and Transparency
Klara keeps the listed content fields encrypted while leaving necessary scheduling and relationship metadata plaintext for functionality.
The data export includes an operator-visible section showing stored server data and a user-readable section decrypted locally when the account encryption key is available on the device.
Export, Deletion, Retention, and Backups
Klara provides a self-service data export in Settings and a self-service account deletion flow. The export contains an operator-visible view of stored server data and, when the account encryption key is available on the device, a user-readable view decrypted locally in the browser. Account deletion deletes the application account and associated app data, including projects, tasks, events, calendar day highlights, calendar templates, objectives, key results, focus preferences, and encryption-key backup metadata.
Active account data is retained while the account exists. Deleted tasks are retained for up to 30 days for recovery and system consistency and are then purged during normal cleanup. Infrastructure backups follow the documented Levo Studio backup cycle and are used only for continuity, recovery, and security. The signed infrastructure DPA requires protected EU/EEA backups, restore testing, and deletion or return after the service ends, but does not state a fixed retention period; Klara will publish the specific production period once it is operationally confirmed.
Backup access is restricted to authorized operational access and is used for continuity, recovery, and security purposes.
Availability and Resilience
Levo Studio, operated by Julius Grimm in Germany, processes data for Klara under a signed Article 28 GDPR agreement and provides deployment, Docker Swarm and Dokploy administration, server and PostgreSQL operation, backups, monitoring, maintenance, security support, and technical troubleshooting.
The documented production infrastructure uses four EU/EEA nodes: one Hetzner Online GmbH node in Falkenstein, Germany; one DataLix node in Frankfurt am Main, Germany; and two Wordbase / SkyLink Data Center nodes in the Netherlands. The application runs as a containerized Next.js service with a PostgreSQL database. Vercel and Supabase are not part of the current production runtime.
Dokploy is the management layer for the Docker Swarm deployment. Stacks, services, environment secrets, databases, and access rights are separated according to the available infrastructure controls. Container images are built through GitHub Actions and stored in GitHub Container Registry before deployment.
Klara keeps the application deployable from source control and database migrations so service can be restored after infrastructure incidents.
Restore Capability
Klara relies on the Levo Studio infrastructure backup process to support restoration. The signed DPA requires regular protected backups in the EU/EEA and restore tests by agreed plan or sample, but the concrete production frequency and retention duration still require operational confirmation.
Restore procedures cover application redeployment, database recovery from available backups, and reapplication of database migrations where needed.
Restoration does not bypass client-side encryption; encrypted content remains dependent on the user account encryption key.
Testing and Evaluation
Klara reviews authentication, user-scoped database authorization, encryption behavior, data export, account deletion, Google Calendar synchronization, and database migrations before privacy-sensitive releases.
GitHub Actions runs type checks, scoped linting, calendar-sync regression tests, a production container build, and deployment steps. Security regression tests cover password hashing capacity, database TLS verification, request-size limits, rate limiting, and dependency versions.
Encryption, export, deletion, and key-recovery behavior are re-tested after changes to auth, storage, or database schema.
Environment Separation
Development and production environments use separate configuration and secrets.
Production database credentials, auth secrets, OAuth credentials, API keys, webhook URLs, and encryption secrets are not used in browser code and are not shared with frontend bundles.
Docker Swarm stacks, services, secrets, databases, and access rights are separated where supported. Any staging environment must use separate credentials and must not reuse production personal data unless expressly authorized and protected.
Logging and Monitoring
Application errors, deployment logs, sync-health information, and security events are used for debugging, reliability, abuse prevention, and incident response. Klara avoids logging decrypted user content, raw encryption keys, recovery keys, passwords, session tokens, refresh tokens, or API and deployment secrets.
Klara does not currently load a third-party web analytics or performance-measurement provider.
Configured Discord operational webhooks receive only the information required for the relevant feedback, launch-list, aggregate usage, sync-health, or security workflow. Access to the receiving Discord channels must be restricted to authorized personnel.
Incident and Breach Process
Security events are triaged by severity, contained, investigated, and documented.
For personal-data breaches, Klara assesses risk to users, determines notification duties, and keeps an incident record.
Klara targets initial internal assessment within 24 hours and provides required supervisory authority notification within 72 hours after becoming aware of a notifiable personal-data breach.
Development and Change Management
Privacy-sensitive changes are reviewed before release, especially encryption, export, deletion, authentication, authorization, external integrations, infrastructure, and subprocessor changes.
Database migrations, application code, Docker build configuration, and deployment workflows are version-controlled and tested before deployment. Dependency and container updates are included in patch management.
Levo Studio must notify Klara before material changes to subprocessors, data locations, security, or infrastructure access as required by the signed DPA. Access is revoked and credentials are rotated when no longer required.