Skip to content
Churnora

Security

How we protect your data

Written plainly, because this is the page that decides whether you trust a product with your customers' information.
01

Encryption in transit and at rest

All data travels over TLS 1.2 or better. Data stored in the database is encrypted at rest with AES-256 by the database provider. The encryption is on by default and applies to every row in every table.

Your import file is processed in memory and not written to disk in unencrypted form at any stage.

02

Database and row scoping

Churnora runs on Postgres. Every query that reads customer data checks that the data belongs to the workspace making the request, in the query itself. One workspace cannot read another's imports, scores, or drafted plays.

Database access from the application uses a connection-pooled role with the minimum permissions needed. Administrative access is limited to two engineers and reviewed quarterly.

03

Passwords and sessions

  • Passwords are hashed with scrypt and a per-user salt. Churnora never stores or logs a password in any form, and nobody at Churnora can see one.
  • Sessions are httpOnly, sameSite cookies signed with a server-side secret. They expire after 30 days of inactivity.
  • Every request that reads workspace data checks session ownership. There is no admin override path that bypasses this check.
04

Payments

Payments are handled by Stripe. Card numbers, CVVs and bank account details never reach Churnora's servers. What Churnora receives from Stripe is a token identifying a payment method and a record of whether a charge succeeded.

Billing records are stored by Stripe under their PCI-DSS certification. Churnora keeps only the minimum needed to associate a Stripe customer with a workspace.

05

Language providers and training

When a language model writes the explanation for one account's factors and drafts its save play, it receives only that account's behavioral fields: the eight feature values the model scored it on. It does not receive the account name, contacts, or any information that could identify the customer to a third party without context.

Churnora uses language providers under business API agreements that prohibit training on API traffic. Your data is never used to fine-tune a shared model. It is not used to improve prompts without asking. It is not licensed or sold to anyone for any purpose.

The risk score itself is computed by Churnora's own behavioral model, which runs in process and never leaves Churnora's servers. The language provider is only involved in writing the explanation afterward.

06

Export and delete

You can export your scored book as CSV, including scores, bands and factors, from the risk table or from Settings on Growth and Scale plans. On any plan, you can export your raw imported data from Settings at any time.

Delete your workspace from Settings to remove your account, every import, every set of scores, and every drafted play from the database. Delete means delete, not archive. Backups roll off within 30 days, after which deleted data is gone from backups too.

07

Our own posture

  • Two-factor authentication is required on every service Churnora uses, with no exceptions and no shared logins.
  • Production access is limited to two engineers and reviewed quarterly.
  • Dependencies are updated on a weekly cadence and security advisories are addressed within 72 hours for anything reachable from production.
  • SOC 2 Type I is in progress. We do not hold a completed report yet and would rather say so plainly than imply otherwise. A report will be made available under NDA when complete.
08

Responsible disclosure

Email security@churnora.com. We acknowledge within two business days, we will not threaten you for reporting in good faith, and we will tell you when the issue is fixed. If you would like to be credited, say so and we will.

This page describes what Churnora does today. The privacy policy is the legal version of the same thing. The your data page has the export and delete controls. Last reviewed August 2026.