PillarClinic Trust & Security

Access & authentication

Every user signs in with an individual account — email and password, with self-service password reset.
Roles are held separately from user profiles: clinic admin, practitioner, prescriber, receptionist and client. Permissions follow the role, not the person's own profile record.
Clinical records, diaries, inventory and reporting are scoped to a single clinic. A clinic account cannot read another clinic's data.
Clients only ever see their own appointments, consent forms, invoices and photographs.

Access to every table is enforced in the database itself with row-level security, not only in the app screens.
Traffic between browsers and PillarClinic is encrypted in transit over HTTPS; the managed database and file storage are encrypted at rest by the hosting provider.
Clinical photographs and uploaded documents are held in private storage and served only through short-lived, authenticated links.
Shared skin-analysis reports use expiring, revocable links with a view count, rather than public URLs.

Consent forms are immutable once signed; withdrawal is recorded rather than deleting the original.
Completed treatment sessions can be sealed with a cryptographic fingerprint covering the consent version, treatment map, products and batch numbers used.
Prescriptions cannot be edited after issue — changes are made by cancelling and re-issuing.
An append-only audit log records who changed which record, when, and which fields changed.

Clinic data: staff accounts, services, pricing, stock and batch records.
Client data: contact details, date of birth, medical history and allergies captured on intake forms, consent forms, treatment notes, clinical photographs, prescriptions and invoices.
Operational data: appointment history, notifications sent, and audit entries.
Data is processed on behalf of the clinic. The clinic is the data controller for its client records; PillarClinic processes it to provide the service.

Each clinic sets its own retention periods for records, clinical photographs and audit history in Clinic settings.
Removing a client archives their record rather than silently deleting it, so clinical and medico-legal obligations can be met; a full clinical record can be exported as a PDF first.
Permanent deletion and anonymisation are available to clinic admins from the compliance area, and are themselves recorded in the audit log.
A retention worklist flags records that have passed the clinic's own retention window.

Managed application hosting, database, authentication and file storage are provided by the platform PillarClinic is built and deployed on.
Skin analysis and the AI clinical scribe send the relevant images or dictated text to a large-language-model provider through a managed AI gateway to produce the draft output. Drafts are always reviewed by a clinician before they are saved.
Email and SMS reminders are delivered through the clinic's configured messaging provider.
Clinics can connect their own payment gateway; card details are handled by that provider and are never stored by PillarClinic.

PillarClinic is a single application with a managed Postgres database; there is no separate clinic-run infrastructure to patch.
Server-side logic runs in an isolated runtime with secrets held outside the codebase and never sent to browsers.
Authorisation is enforced in the database rather than only in the interface, so an API call cannot bypass a screen-level check.
This describes the controls in place today. PillarClinic has not been independently audited or certified against ISO 27001, SOC 2, Cyber Essentials or any comparable scheme, and makes no such claim.

Staff can enable two-factor authentication with an authenticator app from Account security, with one-time recovery codes stored only as hashes.
Roles are least-privilege: prescribing is limited to prescriber accounts, clinic configuration and user management to clinic admins, and clinical records to the treating clinic's staff.
Passwords are managed by the authentication service; PillarClinic never sees or stores them.
Sessions are per-device and can be ended by signing out; password resets are self-service by email.

Record-level changes are written to an append-only audit log with the actor, time and fields changed.
Account-level security events — sign-ins, two-factor changes, role changes, exports, prescription and consent actions — are recorded separately and are visible to the account holder and their clinic admins.
Credentials, tokens, recovery codes and secrets are deliberately excluded from both logs.
One clinic cannot see another clinic's audit trail or security events.

The database and file storage are managed services; backup, replication and restore are provided by the hosting platform under its own operational controls.
Clinics can export their own clinical records, invoices and reports as PDFs or data files at any time, so a usable copy can be kept outside the platform.
PillarClinic does not publish a contractual recovery time or recovery point objective, and none should be inferred.

Suspected security issues should be reported to the PillarClinic team with enough detail to reproduce them, before any public disclosure.
Reports are triaged, and clinics affected by a confirmed incident involving their data are contacted directly.
As a processor, PillarClinic supports the clinic's own regulatory notification duties; the clinic, as controller, decides on and makes any notification to the ICO or to data subjects.

Clinic admins can produce a complete export of an individual client's record, including consent forms, notes, photographs, prescriptions and invoices.
A clinic can export its own operational and financial data from the reporting and insights areas.
Account closure and permanent deletion or anonymisation are carried out on request by the clinic and are recorded in the audit log.
Clients should direct subject access, correction and erasure requests to their clinic, which is the data controller for their record.