Security you can verify from the architecture
Every claim on this page names its mechanism. The short version: records encrypted on your machine, AI that never leaves it, and servers that only ever see ciphertext.
Encryption at rest
The clinical database is encrypted on disk with SQLCipher (AES-256). Master keys live in hardware-backed custody on your machine, and sensitive fields carry their own envelope encryption inside the database — raw key material never appears in the interface, in logs or in error messages.
AI without a cloud
All AI features run on a local model on your own hardware. There is no cloud-inference path in the product, so there is no AI vendor receiving session content, no transcript retention question, and no new disclosure surface to assess.
Zero-knowledge sync and portal
Multi-device sync and the patient portal ride a relay that stores ciphertext only. Encryption keys exist exclusively on devices the practice enrolls; devices are trusted explicitly and revocable individually. The operator cannot read patient data — by construction, not by promise.
Access control and audit
Role-based access separates practitioner, admin, front-desk and auditor duties, and a tamper-evident audit trail records reads and writes across the clinical record. 'Who accessed this record and when' is a query the software answers.
Backups, updates and the supply chain
Backups (.cfbak) are encrypted archives; restore and secure wipe are built in. Application updates are cryptographically signed and verified on your machine before installing, and the macOS release is notarized. The storefront and app bundles are self-contained — no third-party scripts, fonts or trackers.
Compliance posture, in plain words
The architecture is designed to support practices' obligations under HIPAA, GDPR and comparable frameworks — encryption at rest, access control, audit trails, consent tracking, subject-access export, breach-resistant key custody. We state it exactly that way because compliance is a property of a practice and its processes; software is the part we can build, and this page is the honest inventory of it.
Reporting a vulnerability
Security reports go to support@sideclick.io and are handled as a priority. Include enough detail to reproduce; please don't test against machines holding real patient data. We credit reporters who want credit.
Security questions, answered
Who holds the encryption keys to my records?
Your practice, exclusively. Master keys live in hardware-backed custody on your machines; SideClick has no copy and no recovery backdoor, which is why practice-held backups matter.
Can SideClick staff access my data for support?
No. Support works from symptoms, logs you choose to share (which never contain record content), and reproduction — not from looking at your records, which we structurally cannot do.
Is SideClick HIPAA or GDPR certified?
We deliberately don't claim that. The architecture is designed to support those obligations — encryption at rest, audit trails, consent tracking, subject-access export — and this page inventories the mechanisms so you and your advisors can verify the fit.
How do I report a security vulnerability?
Email with enough detail to reproduce; reports are handled as a priority and reporters credited if they wish. Please never test against machines holding real patient data.
Try SideClick free for 30 days
Full capability, no card required. Your data stays on your machine either way.
Start a 30-day trial