Healthcare-grade security, engineered from day one.
Patient records are the most sensitive data a clinic holds. Every layer of The Clinic — from the database row up to the copilot prompt — is built on the assumption that a breach is unacceptable.
- HIPAA-aligned
- GDPR
- ISO 27001 Aligned
- Per-tenant isolation
Every framework your compliance team asks for.
We map our controls to the frameworks clinics actually get audited against, not just the ones that look good on a badge.
HIPAA
We act as a business associate and will execute a BAA. Every access to PHI is written to an append-only audit log that the application itself cannot alter, retained for ten years by default and configurable per clinic.
SOC 2 criteria
Controls mapped to the SOC 2 Trust Services Criteria. No third-party audit report is available today, and we do not claim one.
GDPR
Lawful bases documented, DSR tooling in-product, DPA signed with every clinic, production hosted in the EU.
ISO 27001 Aligned
Information Security Management System aligned to Annex A controls. Not certified.
HITRUST
Control alignment mapped to HITRUST CSF v11. No assessment has been performed.
PCI DSS
Card data never touches our infrastructure — it is tokenized by our payment processor. We hold no PCI attestation of our own.
Defense, layered at every level of the stack.
Data encryption
- AES-256 encryption at rest across every Postgres cluster and object store
- TLS 1.3 in transit with HSTS preloading and modern cipher suites only
- Envelope encryption with per-clinic data keys, rotated quarterly
- Patient media served only through short-lived signed URLs — never a public bucket
Access control
- Role-based permissions across 11 roles, enforced in every API route
- Google sign-in or email and password, with two-factor (TOTP) your admins can enforce for every staff account
- Per-user permission overrides that can restrict what a role sees, never widen it
- Session timeout, brute-force lockout and rate limiting enforced server-side, not in the browser
Tenant isolation
- Postgres Row-Level Security policies enforced at the database layer
- Tenant context propagated via AsyncLocalStorage on every request
- Prisma extension blocks any cross-tenant write at the ORM layer
- Continuous tenancy self-tests run in CI and on every deploy
Audit & monitoring
- Every read and write of PHI written to an append-only audit log, enforced by database trigger
- Ten-year default retention, configurable per clinic, with a 90-day floor the application cannot lower
- Update, delete and truncate are rejected for every database role, including the one the application runs as
- PHI reads are logged at the data layer rather than route by route, so coverage cannot drift as routes are added
Multi-tenant isolation, verified three ways.
Every request flows through three independent enforcement layers before it can touch a patient record. A bug in any one of them is caught by the other two.
- Application. JWT claims resolve a tenant ID, stored in an AsyncLocalStorage context for the life of the request.
- ORM. A Prisma extension injects the tenant filter on every read and blocks any cross-tenant write at the ORM layer.
- Database. Postgres Row-Level Security enforces the same boundary at the storage layer — a misbehaving app cannot bypass it.
Resolves tenant, sets AsyncLocalStorage context
Injects WHERE clinicId, blocks cross-tenant writes
Row-level policies gate every SELECT and UPDATE
Incident response
A documented incident-response runbook, uptime and error monitoring, and a root-cause post-mortem shared with any clinic whose data was involved.
Vulnerability disclosure
We run a coordinated disclosure program with safe-harbor language for good-faith researchers, and we credit reporters publicly.
- Published security.txt with escalation path and PGP key
- Public credit for the first report of a valid issue
- Safe-harbor clause for good-faith research
- Acknowledgement within one business day
Everything your compliance team needs, in one place.
Security questions
What compliance teams ask before signing.
Will you sign a BAA?
Yes. The Clinic acts as a business associate and executes a BAA alongside the DPA. HIPAA-aligned controls include role-based access across every API route, two-factor authentication your administrators can enforce, and an append-only audit log that records every read and write of PHI.
Are you SOC 2 or ISO 27001 certified?
No, and we do not claim to be. Controls are mapped to the SOC 2 Trust Services Criteria, and the information security management system is aligned to ISO 27001 Annex A — but no third-party audit report exists today. The mapping is documented, so your compliance team can assess it directly.
How is one clinic's data kept separate from another's?
Per-tenant isolation is enforced three independent ways on every request: the application resolves the tenant from the signed-in user's token, a database access layer injects the tenant filter and blocks cross-tenant writes, and PostgreSQL row-level security enforces the same boundary at the storage layer. Tenancy self-tests also run in CI and on every deploy.
Can the audit log be edited or deleted?
No. The audit log is append-only, enforced by a database trigger — update, delete and truncate are rejected for every database role, including the one the application itself runs as. Retention defaults to ten years, is configurable per clinic, and has a 90-day floor the application cannot lower.
How is patient data encrypted?
AES-256 at rest across every database cluster and object store, and TLS 1.3 in transit. Encryption uses envelope encryption with a data key per clinic, rotated every 90 days, and patient media is served only through short-lived signed URLs — never from a public bucket.
Ready to try The Clinic
See it run your clinic in 30 minutes.
Book a personalized demo. We'll use your clinic's real workflows — not a generic walkthrough.
No credit card. No slides. 30 minutes.