Security

Security & data protection.

A plain-language summary of the controls we build into Nora, and how to report a problem to us.

Last updated August 16, 2026

Access control

  • Every record is scoped by account: a practice sees only its own data, a therapist sees only their own clients and sessions, and a client sees only their own bookings, payments and homework.
  • Access rules are enforced at the database layer, not just in the interface, so a request cannot read data outside its own scope.
  • Roles are stored separately from profiles, so a user cannot change their own permissions.
  • Joining a practice requires approval by a practice owner, and owners control revenue splits and payout settings.

Data in transit and at rest

  • All traffic to Nora is served over HTTPS with modern TLS.
  • Client notes, documents and homework are kept in private storage that is not publicly listable; downloads use short-lived signed links.
  • Passwords are handled by our authentication provider and stored only as salted hashes. Google sign-in is available if you prefer not to manage another password.
  • Databases are hosted on managed cloud infrastructure with automated backups.

Payments

  • Card details are collected and stored by our PCI-compliant payment processor. Nora never sees or stores full card numbers.
  • Charges, refunds and no-show fees require an explicit confirmation step in the interface so money never moves by accident.
  • Payouts and withdrawals also require confirmation, and are limited to funds that have actually settled.
  • Nora takes no percentage of your client payments; our only revenue from you is your subscription.

Telehealth

Video sessions run as encrypted peer-to-peer connections between participants. We do not record video or audio, and session links are tied to a specific session and time window.

Our operational practices

  • Least-privilege administrative access, used only to operate and support the service.
  • Automated security scanning of the database access rules and application dependencies, with issues triaged as they appear.
  • Secrets and API keys are stored in a managed secret store, never in source code.
  • Change history for all application code, so any change can be traced and reverted.

We are a small team and we describe our controls honestly: Nora has not undergone a third-party security certification or audit. If your practice requires formal attestation, tell us what you need and we'll be straight with you about what we can and cannot provide today.

What we ask of you

  • Use a strong, unique password and keep your email account secure.
  • Only invite people into your practice who should see client information, and remove them promptly when they leave.
  • Keep notes proportionate — record what your professional obligations require, not more.
  • Tell clients how their information is used and stored, and get the consent your college requires.

Reporting a vulnerability

If you believe you have found a security issue, please tell us through our contact form with enough detail to reproduce it, and give us a reasonable window to respond before disclosing it publicly. Do not access, modify or download data that is not yours while testing, do not run denial-of-service or spam tests, and do not use automated scanners against live client data. We appreciate good-faith reports and will not pursue action against researchers who follow these guidelines.

Incident response

If we become aware of a security incident affecting personal information, we investigate promptly, contain the issue, and notify affected account holders and, where required, the relevant privacy authorities in line with Canadian law.

Questions about this page?

Reach us through our contact form and we'll get back to you. This page describes Nora's own practices and is not legal advice for your practice.