Information Security Policy

1. Data protection in transit and at rest

1. 1.1All traffic uses HTTPS. The HSTS header instructs the browser to never attempt an unencrypted connection with the domain.
2. 1.2The database and file storage are encrypted at rest by their respective providers.
3. 1.3Third-party integration tokens are encrypted with AES-256-GCM before being stored.
4. 1.4Screen recordings and audios are kept in a private bucket, without a public URL. Access occurs via a signed link valid for 1 hour, generated only for those with permission in the workspace.

2. Authentication and access control

1. 2.1Passwords are stored only as a cryptographic hash with bcrypt.
2. 2.2The session is maintained by a token signed with the server's secret.
3. 2.3Each workspace has four roles: owner, administrator, editor, and reader. Permission is read from the database with each request, and not just from the token, so that access removal has immediate effect.
4. 2.4All study data queries are isolated by workspace.
5. 2.5The internal administrative panel is restricted to addresses authorized by configuration, and each action is recorded in an audit trail with author, action, target, and date.
6. 2.6Password reset uses a single-use token with an expiration date and a limit on requests per hour.
7. 2.7Sign-in with a corporate identity provider (SSO), when the customer’s organization requires it.
8. 2.8Limit on sign-in attempts per source address, to curb password-guessing attempts.
9. 2.9Application access logs, with date, time and IP address, kept for 6 months.

3. Abuse protection

1. 3.1Public routes, used by participants, have a request limit per address and per session.
2. 3.2Each account has daily limits on the use of artificial intelligence, voice synthesis and transcription, and file uploads.
3. 3.3Collection events are deduplicated by a unique key, so that resubmission due to an unstable network does not generate a duplicate response.
4. 3.4Public report and video snippet links use a long random token and can be revoked by the client.

4. Development and changes

1. 4.1The code is versioned, and each change undergoes automatic type checking, automated tests, and compilation before publication.
2. 4.2Database migrations are additive and manually reviewed before being applied.
3. 4.3Production errors are monitored, with removal of request body and response content before sending to the monitoring provider.
4. 4.4There is automatic accessibility verification of the participant flow with each change.

5. Continuity

1. 5.1The database has backups managed by the provider, deleted within 30 days.
2. 5.2Expired recordings are automatically deleted by a daily routine, according to the plan's term.
3. 5.3There is application health verification and email alert when the service becomes unavailable.

6. What we don't have yet

Transparency here is worth more than appearance. As of the date of this version, the items below are not implemented and should not be affirmed to clients.

1. 6.1Second factor authentication for researchers.
2. 6.2Staging environment separate from production.
3. 6.3Periodic backup restoration testing, with measured recovery time. A rehearsal was carried out on September 4, 2026; the frequency has not yet been established.
4. 6.4External security certification, such as ISO 27001 or SOC 2.
5. 6.5Independent third-party intrusion test.