A security page should be checkable. Everything below names the mechanism, and where the evidence is not yet saved, it says so in a comment a reader of the source can see.
How does the connector reach my practice software?
A small Windows service, the agent, runs on the server that holds your database. It reads the database, keeps a short local copy of what it has read, and sends new records to the Calibic cloud every five minutes.
It is read-only by construction, not by promise:
- The code that talks to the database exposes a reader and nothing else. There is no insert, update or delete path to call.
- On Open Dental, the MySQL session is opened with
SET SESSION TRANSACTION READ ONLY, so the server itself refuses a write. - On Dentrix, the ODBC connection is opened in read-only access mode where the driver honours it.
- On Eaglesoft, the connection string ends with
ReadOnly=YES.
This describes our software. It does not describe the database credential. On Open Dental you can and should create a SELECT-only user for the agent; on Dentrix and Eaglesoft the agent uses the vendor’s own access method and we cannot promise the credential is read-only at the database level.
The agent reads only the columns it needs. Free-text clinical notes are not selected.
What is stored on my server?
A local event file, events.db, under C:\ProgramData\TrailVerity\, holding the last 30 days of change events so a lost connection does not lose data. It is a plain file protected by the server’s own permissions and disk encryption, if you use it; the agent does not encrypt it separately. The practice database connection string is in the agent’s settings file on the same machine.
How does data travel?
Over HTTPS to the Calibic cloud, authenticated with a per-agent key sent as a bearer token. The install token that enrols an agent is single-use and stored hashed. The web app sends HSTS headers and secure cookies, and the database connection from the app requires SSL.
Updates are delivered automatically over the same channel. The installer is self-signed and updates are not yet signature-checked; that is on the fix list and we will not call updates “signed” until they are.
Where does it live in the cloud?
On Microsoft Azure: an App Service, a PostgreSQL database and Azure OpenAI for the AI features, stored in the United States. Microsoft publishes its own ISO/IEC 27001, FedRAMP High and SOC attestations for the platform; those are Microsoft’s, not ours, and we do not inherit them.
Encryption at rest is Azure’s platform encryption, which uses AES-256 according to Microsoft. Patient columns are not additionally encrypted at the application layer.
Each practice’s data is logically separated: every query is scoped to the signed-in account and location, and the tests check it. It is one shared database, not a dedicated one per practice.
Backups: point-in-time restore is configured for 35 days, and a real restore was carried out on 2026-09-30.
Who can sign in, and what can owners see?
- Sign-in is passwordless: a one-time code by email, valid for ten minutes, five attempts, with six requests per hour per address and IP address. This is a single factor. Multi-factor authentication is not built yet.
- Sessions sign out after 60 minutes idle and last at most 30 days. Owners can sign out everywhere in one click.
- Team members sign in with their own email. There are owner, admin and staff roles; the roles gate settings, team and messaging configuration. Staff can read and export the same patient views as owners today.
- Owners can see, under Settings and Security, who opened a patient card, exported a list or asked a question. That is the list of logged actions; it is not yet an audit log of every screen.
- If the agent goes quiet for 45 minutes during office hours, the owner and our operations address get an email, and it re-arms on the next heartbeat.
What do we not have?
No SOC 2 report. No independent penetration test. No multi-factor authentication. No SSO. No public status page. No published vulnerability disclosure policy; email hello@calibic.com with “Security” in the subject and it is read first. We will update this page when each of these changes, with a date.
What happens when I leave?
Your data is deleted on request, and backups roll off within the backup window. Export of lists as CSV and reports as PDF is available today; a full account export is not built yet.
Next step: read what the BAA commits to, or see how the read-only model shows up in Coverage as what we can and cannot see.