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.

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 relies on backups managed by the provider.
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 test, with measured recovery time.
4. 6.4External security certification, such as ISO 27001 or SOC 2.
5. 6.5Independent third-party intrusion test.