Skip to content
clinvaleBack to site

Security

What protects your patients' records — and, just as usefully, what does not yet.

Last updated 2026-09-10.

Separation between clinics

Every record belongs to exactly one clinic, and that ownership is enforced in the data layer rather than remembered by each screen. Queries are scoped automatically, and the scope fails closed: code that forgets to say which clinic it means returns nothing, rather than everything.

Staff accounts are bound to their own clinic's address. Credentials offered on the wrong one are refused as if they were wrong, so an outsider cannot use the login page to discover which clinics exist.

Access control

  • Roles are defined by the clinic itself, from a catalogue of over a hundred individual permissions. A receptionist need never see revenue; a practitioner need never see payroll.
  • Two-factor authentication (authenticator app) and passkeys are available on every account.
  • Sign-in attempts are rate limited, as are password resets and the public booking form.
  • Significant actions are written to an audit log the clinic can read.

Data handling

  • All traffic is served over HTTPS.
  • Passwords are hashed with bcrypt. We cannot read them, and neither can anyone with database access.
  • Third-party credentials a clinic stores with us — such as a WhatsApp access token — are encrypted before being written, kept out of audit entries, and never sent back to the browser once saved.
  • Clinical photographs are stored separately from the main application files, and served only to authenticated staff of the owning clinic.
  • Outbound webhooks are checked against internal network addresses before each call, so a webhook cannot be pointed at our own infrastructure.

If you stop paying

Your workspace becomes read-only. It is not locked, and your records are not withheld. You can still read and export everything. Holding a clinic's patient history hostage over a failed card is both a poor way to treat a customer and a bad position to be in under data protection rules.

What is not in place yet

Stated plainly, because assuming these exist would be worse than knowing they do not:

  • No independent certification. We are not SOC 2 audited, not ISO 27001 certified, and not HIPAA attested. If your obligations require any of those, this is not yet the right software for you and we will say so rather than sell to you.
  • No national health-record integration. We do not connect to NPHIES, NABIDH, Malaffi or Riayati. Clinics required to exchange data with those systems cannot use this as their system of record.
  • No contractual uptime guarantee. See our terms.
  • Encryption at rest is provided at the infrastructure level by our hosting provider rather than applied per field within the database, other than for the credentials noted above.

This list is kept current deliberately. When one of these changes it will move up the page, not quietly disappear from it.

Reporting a problem

If you believe you have found a security issue, email hello@clinvale.com with enough detail to reproduce it. We will acknowledge within two working days.

Good-faith reports are welcome and will never be met with legal threats. Please do not access, alter or retain anyone else's data while investigating — describing the weakness is enough.