Trust & Safety

Security practices

What Kleveroo actually does to protect your account and your content today — and, just as plainly, what we haven't done yet.

Last updated: August 30, 2026

Kleveroo is a small product, so our approach to security is to keep it boring: use well-supported infrastructure, keep access rules as close to the data as possible, and avoid handling anything we don't need to handle. Everything below is in place right now.

How the site is served

  • Every page loads over HTTPS, and the main domain tells browsers to refuse an insecure connection in future.
  • Security response headers are configured, including a content security policy that limits what code and content a page is allowed to load, plus clickjacking protection, MIME-type protection, and a strict referrer policy.
  • Fonts and site assets are served from our own domain. We removed Google Fonts entirely, so loading a Kleveroo page no longer makes a request to a third-party font CDN.

How your data is protected

  • Database tables use Row Level Security. The rules live in the database itself, so a signed-in account can only reach its own records even if application code has a bug.
  • Data request records are readable only by an administrator. Anyone can submit a request, but the public cannot read stored request records — not their own, not anyone else's.
  • When a data request is submitted, a notification goes to support@kleveroo.com so a person sees it promptly.
  • Passwords are handled by our authentication provider and are never stored by Kleveroo in a form we can read.

Payments

  • Card entry happens on Stripe's hosted checkout. Card numbers are never typed into a Kleveroo form and are not stored by Kleveroo.
  • We keep only the Stripe identifiers and purchase records needed to reconcile a payment with an account, issue receipts, and handle tax.

Tracking and third parties

  • First-party analytics only. Product telemetry runs on our own infrastructure.
  • No third-party advertising trackers, no Meta Pixel, no Google Analytics, and no session replay tools are installed.
  • The third-party services we do rely on are listed openly on our subprocessors page.

What we ask of you

  • Do not upload sensitive student data — rosters, IEPs, medical or disciplinary records — into board text, AI prompts, uploaded files, or clue images.
  • Use a strong, unique password on your account.
  • If you spot something that looks like a security problem, email support@kleveroo.com and we'll look at it. We don't run a paid bug bounty, but we do read every report.

Current limitations

We'd rather you learn these from us than discover them later.

  • Kleveroo is not currently SOC 2 or ISO certified, and we do not describe ourselves as compliant with any framework.
  • No public penetration test report is available.
  • There is no public uptime or status page yet.
  • The storage bucket holding clue images is currently public, meaning an image's web address can be opened by anyone who has it. Don't upload anything sensitive as a clue image.
  • Automated deletion is not enabled. Deletion requests are reviewed and carried out manually by an administrator, which is slower but avoids irreversible mistakes.

These are on our list. As the product grows we expect to close several of them, and this page will change when we do rather than staying quietly out of date.

Questions or paperwork

Reviewing Kleveroo for a school, district, or company? Email support@kleveroo.com. We don't have a pre-signed data protection agreement or a security questionnaire on file yet, but we'll answer honestly and work through whatever your process needs. Privacy and data requests can also be submitted through /data-requests.

Related: Trust Center, Subprocessors, Privacy Notice, Data Requests.