Skip to content
Trust

Security overview

Last updated: October 14, 2026

Kendor runs code written by people you haven’t hired yet, and keeps a record of how they worked. This page describes how we protect that data and the systems around it. For a security questionnaire, a countersigned DPA or anything not covered here, email hello@kendor.io.

Where your data lives

  • The application, its database and our main code-execution servers run in Frankfurt, Germany.
  • Stored files (code snapshots, recordings, uploads) are kept in Amazon S3 in Frankfurt (eu-central-1), and so are database backups.
  • Candidates in the Americas get a nearby code-execution server in the US so their editor stays fast. What they produce is still stored in Frankfurt.
  • Every company that processes data for us is on our sub-processor list. We email organization owners 30 days before adding one.

Encryption

  • All traffic to Kendor is served over HTTPS with TLS 1.3. Older browsers can fall back to TLS 1.2; anything older is refused.
  • Stored files in S3 are encrypted at rest with AES-256.
  • Database backups are encrypted before they leave the server, with a key that is kept offline.
  • Secrets you give us, such as AI provider keys, ATS credentials and SSO settings, are encrypted in the database with AES-256-GCM.

Candidate code runs in isolation

Candidate code runs on dedicated servers, separate from the application and the database. Each session gets its own container:

  • It runs as a non-root user with all Linux capabilities dropped, a read-only root filesystem and no access to the host or the container runtime.
  • Memory, CPU and process limits stop one session from starving another.
  • Sessions cannot reach each other, our private networks or cloud metadata services. They can reach the internet, so candidates can install packages as they would at work.
  • Idle sessions are shut down and their containers removed.

AI agents and your API keys

When you let candidates use Claude Code or Codex, your API key never enters the candidate’s sandbox. The sandbox gets a session-only credential that works only through our gateway, which adds your key on the way out and stops working when the session ends. You can switch AI on or off per interview, and the prompts and responses are kept for your reviewers.

Accounts and access

  • Passwords are hashed with bcrypt. Sessions use secure, httpOnly cookies, and new accounts must verify their email.
  • Single sign-on with SAML 2.0 or OIDC, with verified domains and an option to require SSO for everyone (Enterprise plan).
  • Owner, editor and viewer roles decide who can change screens, see results and manage the organization.
  • Sign-in and email endpoints are rate limited against brute force.
  • Candidates don’t need an account: they join with a private link.

Backups and monitoring

  • The database is backed up every night and backups are kept for 30 days. The server that writes them can add new backups but cannot read or delete old ones.
  • Servers, endpoints, certificates and backups are monitored around the clock, and failures alert us by email. Live status and past incidents are on status.kendor.io.
  • Production configuration and secrets live only on the servers, never in the source repository.

Support and incidents

  • Support is in our Slack community and by email at hello@kendor.io, Monday to Friday, 9:00 to 18:00 Central European Time, except public holidays. Security issues and anything that involves candidate data go by email.
  • We aim to reply within 4 business hours when Kendor is down or a live interview or assessment is blocked, within one business day when a core feature is broken, and within two business days for everything else. Outside business hours, monitoring alerts still reach us and we respond as soon as we can.
  • Our uptime target is 99.5% a month for the app, the API and the code-execution servers in each region, measured from outside on status.kendor.io. Planned maintenance is announced there at least 48 hours ahead. This is a target we publish our record against, not a contractual SLA.
  • During an incident we post updates on the status page until it is resolved, and email your organization’s owners if it interrupts live sessions or could affect your data. Critical incidents get a written explanation of the cause and the fix within five business days.
  • If a breach affects personal data we process for you, we tell you without undue delay, aiming for 72 hours, as set out in section 7 of the DPA.

Privacy and retention

  • We process candidate data on your behalf under our Data Processing Agreement, including the EU Standard Contractual Clauses where they apply.
  • Session recordings and captures are deleted automatically after 12 months.
  • On request we erase a candidate’s data completely, stored files included, not just database rows. Candidates can export their own data.
  • Logs don’t contain candidate code, and email addresses in them are masked.
  • No ads, trackers or analytics run in the product or on candidate pages, and your data is never sold. Read the privacy policy for the details.

Certifications

We don’t hold SOC 2 or ISO 27001 yet. We’re a small team, and we would rather say so than imply otherwise. We answer security questionnaires (including SIG Lite and CAIQ) and review calls directly, usually within two working days.

Reporting a vulnerability

If you find a security issue, email hello@kendor.io with the details and how to reproduce it. We’ll confirm we received it within two working days and keep you updated until it’s fixed. Please don’t access other people’s data or disrupt the service while testing.