Sign in to FROID
PTENFRES

Security & LGPD

Sensitive data demands serious controls — that's how we treat yours

Encryption, ownership-based access control, and LGPD principles built into the architecture, not bolted on afterward.

Sensitive health data: voice, facial expression, and therapy session content are treated as sensitive data under Brazil's LGPD (Law 13.709/2018). This page describes the applied technical and organizational controls.

Data protection

How session data is protected

Encryption

Data in transit is protected by TLS; data at rest is stored encrypted in the analytics database.

Access control

Each session report is tied to the ownership of the responsible professional — access restricted per account, not freely shared per session.

Analytical anonymization

Aggregated metrics used for internal research rely on session and patient hashes, with no directly identifiable data in the analytics layer.

How it works, without oversimplifying

The real path of a session

We'd rather describe the full operation than summarize it in a way that sounds simpler than it is.

Transmission and processing

Remote sessions use WebRTC; when a direct connection between devices isn't possible, a TURN server acts as a relay. A meaningful share of the metrics is calculated in the professional's browser; audio segments may be sent to FROID's backend and to a specialized transcription provider for voice, image, and text processing.

Hosting and backups

Transcripts, reports, and authorized records are stored on FROID's infrastructure, which may include hosting in Estonia and providers for payments, AI, email, and calendaring — which may involve international data transfer, protected by the applicable contractual and technical mechanisms. Backups are encrypted and periodically verified.

Multitenant isolation

Each organization's data (clinic or independent professional) is segregated via Row-Level Security (RLS) in the database — by construction, one organization cannot access another's records.

Access auditing

Access, changes, exports, and denied access attempts on patient reports and data are logged in an audit trail, tied to the account that performed the action.

Compliance

LGPD and industry best practices

We treat LGPD's principles — purpose, necessity, transparency, and security — as architectural requirements, not a checklist applied afterward. This follows the same rationale applied by international health SaaS standards (HIPAA, GDPR): compliance needs to be built into encryption, audit trails, and role-based access control, not just into a contract.

For clinics and professionals who contract FROID, we make data processing terms available as part of the professional onboarding process.

Current commitments

  • Explicit patient consent before every recorded session
  • Right to data erasure upon request
  • Notification in the event of a security incident

Shared responsibility model

As with any health SaaS, security is split: FROID is responsible for the platform infrastructure (encryption, backups, application access control); the contracting clinic/professional is responsible for managing their team's access and for the consent obtained from the patient.

Relevant technical stack

FastAPI backend with DuckDB persistence for aggregated analytics; report ownership control via _can_access_report() and _report_owner_email(); anonymous session hashing via _anonymous_session_hash() before any statistical aggregation.

Platform and infrastructure hardening

  • Encryption: TLS at the edge; at rest, authenticated Fernet encryption (AES-128-CBC + HMAC-SHA256) with key rotation via MultiFernet; passwords with PBKDF2-HMAC-SHA256 (120,000 iterations + salt).
  • Security headers: HSTS with preload, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy and Permissions-Policy (grants camera/microphone only).
  • Reduced network surface: internal services not published on the public interface; all access goes through Caddy over TLS; firewall allowing only 80/443 and restricted SSH.
  • Unprivileged containers: non-root process, no-new-privileges, dropped Linux capabilities (cap_drop: ALL) and a process limit.
  • Application defense: validation of AI-generated SQL (allowlist SELECT/WITH, read_only connection, restricted tables); rate limiting on authentication and ingestion; body limits and timeouts at the edge.
  • Real-time integrity: signal processing (F0/MFCC/envelope) runs in a thread pool so it never blocks the analysis loop under concurrent sessions.
  • Operations: pinned dependencies for reproducible builds; per-service healthchecks; encrypted off-site backups with restore testing.