How Surgerly handles your patients' data.

Where data lives

Patient data is processed and stored in UK-based Microsoft Azure regions. Backups stay in-region; we do not replicate patient data to overseas regions.

Operational telemetry (anonymised performance metrics, error reports) may be processed by a small number of sub-processors — listed below — none of which receive identifiable patient data.

Access control

Every action in Surgerly is authenticated and tied to a named user. Staff users are scoped to a single organisation by default; cross-organisation access requires an explicit organisation switch or engineer permission and is logged.

Role-based permissions control who can view records, edit appointments, manage staff, send correspondence and access reporting. Two-factor authentication is supported for staff accounts.

Encryption

All traffic to Surgerly is served over HTTPS using TLS 1.2 or higher. Patient data is encrypted at rest using AES-256, and database backups are encrypted with separately managed keys.

Patient-facing authentication uses one-time codes and signed session tokens; we never store passwords for patients in our database.

Audit logging

Surgerly maintains an append-only audit trail of reads, writes, logins and administrative actions, retained for the lifetime of the organisation account plus a configurable retention period.

Clinic admins can export their own audit log at any time, and engineering access to customer data is itself logged and reviewable.

Backups & recovery

The database is backed up continuously, with point-in-time recovery available within the previous 30 days. Backups are encrypted and stored in-region.

We run regular restore drills against backups so that "we have backups" never depends on hope.

Data subject rights

Surgerly is built to support GDPR data subject rights — access, rectification, erasure, portability — through the clinic's own portal, without engineering involvement in the standard flow.

We help clinics respond to subject access requests, and we publish standard contractual terms (DPA, sub-processor list) on request.

Incident response

We monitor application errors, infrastructure health and authentication anomalies continuously. Incidents that affect customer data are communicated to affected clinics promptly, with a written summary once root cause is established.

Our breach-notification commitments mirror GDPR Article 33 timelines.

Sub-processors

Surgerly uses a small, deliberate set of sub-processors:

• checkMicrosoft Azure (UK regions) — hosting, database, storage
• checkStripe — payments (where enabled by the clinic)
• checkTwilio / equivalent — SMS delivery (where enabled by the clinic)
• checkEmail delivery provider — transactional email