Security

Last updated: 26 September 2026Version 1.0

Customers trust us with conversations, recordings and people's faces and voices. This page describes the security measures we actually use today. It is part of Annex 2 of our Data Processing Addendum, and we update it as our measures change. We have not yet completed an independent security certification or attestation; if we do, we will say so here.

1. Encryption

  • All traffic to our websites, console and API uses HTTPS (TLS). Our sites send HTTP Strict Transport Security headers, so browsers that have visited them refuse to connect without encryption.
  • Live audio and video travel over encrypted real-time connections.
  • Our managed database encrypts stored data at rest.

2. Accounts and access

  • There are no passwords to steal: people sign in with single-use codes and links sent by email, which expire after 15 minutes, or with a third-party account protected by a one-time state check.
  • Session cookies are signed, cannot be read by scripts on the page, are restricted to our own site and are sent only over HTTPS. Sessions end after 30 days, or after 12 hours for learner, class-code and embedded sign-ins.
  • Each customer account has role-based permissions, such as owners, administrators, leaders and observers. Sensitive actions, such as withdrawing consent for a face or voice and managing billing, are limited to owners.
  • Access by Zentiq staff is limited to authorised staff who need it. Opening a transcript from a school or family account requires an extra confirmation.
  • Disabled and suspended accounts cannot sign in.

3. Application and infrastructure

  • Requests that change data are checked for their origin, to block cross-site attacks.
  • Public endpoints and the API are rate-limited.
  • Security headers protect against content-type confusion, and the console and sign-in pages cannot be framed by other websites.
  • Our internal services for conversations, voice and images accept requests only from our own systems, authenticated with secret keys.
  • Database tables are protected from direct public access.
  • Automated tests cover security-relevant features such as sign-in and access control.

4. Recordings, faces and voices

  • Job interview recordings are kept in private storage and can be played only through links that expire after 15 minutes. Every viewing is logged.
  • A recorded consent confirmation is required before a face or voice is used. When consent is withdrawn, new sessions with that avatar or voice are refused and the working copies are deleted.
  • Video from the camera, used for on-device features, is analysed in the browser and not sent to us.

5. Collecting less

  • IP addresses in consent, usage and early-access records are stored only in salted, hashed form.
  • Card, bank and national identity numbers that visitors type into a conversation are masked before storage.
  • Connection statistics and error reports leave out what was said and the content of requests.
  • Payment card details are handled by our payment provider and never reach our servers.
  • Job interview data is deleted automatically at the end of each role's retention period, and recordings of interviews that never reached the hiring team are deleted the next day.

6. Incidents

If we suspect a security incident, we investigate, contain and fix it. If personal data we process for a customer is affected, we notify the customer without undue delay, as our Data Processing Addendum sets out, and we help it meet its own obligations.

Our status page shows whether each part of the service is working, from automatic checks, together with the incidents and planned maintenance we post and a history of what our checks recorded over the last 90 days.

7. Your part

  • Protect the email account you use to sign in, because a sign-in code is sent there.
  • Give people only the roles they need, and remove people who leave.
  • Keep API keys secret, store them on your servers only, and replace any key you think has been exposed.

8. Reporting a security issue

If you think you have found a vulnerability, email privacy@zentiqai.com with the subject line "Security". Please give us enough detail to reproduce it and a reasonable time to fix it before telling anyone else. Our Acceptable Use Policy explains the rules for good-faith security research.

Version history

  • Version 1.0 (26 September 2026): First published version.