Security & privacy

Built so that being careful is the default, not the discipline.

Electronic visit verification holds some of the most sensitive information a person has: where they live, who comes into their home, and when they are alone. The protections below are structural — properties of how the system is built, rather than rules staff are asked to remember.

Every tenant is isolated in the database itself

Separation is not a filter the application remembers to apply — it is enforced by Postgres row-level security on every table, evaluated on every query. An organisation cannot read another organisation’s records even if a query is malformed, a filter is dropped, or an interface is used in a way nobody anticipated.

Two independent layers: one keyed to the signed session, and a second that re-checks live membership on every request, so revoking someone’s access takes effect immediately rather than whenever their session happens to expire.

Visit records cannot be quietly altered

Clock-ins and clock-outs are append-only. A correction never overwrites the original — it creates a new record that references it, carrying who asked, who agreed, when, and why.

Both the device time and the server time are stored on every punch, so a shifted device clock is visible rather than authoritative. This is what lets a provider answer an audit years later with evidence instead of assurances.

A location is either verified or it is labelled

Where a modality genuinely proves presence, the visit is recorded as verified. Where it does not — a caregiver reading an address over the phone, a call from a mobile — it is recorded as attested and sent for review.

The distinction is structural, not a convention someone can override under pressure to lift a compliance percentage. The system will not let an assertion be stored as evidence.

Two-step verification, and a trail when it is reset

Time-based one-time codes are supported for every account and can be required across an organisation. Resetting somebody’s second factor is the classic social-engineering route, so it demands a written reason and is recorded against the name of whoever did it.

Sessions are deliberately short-lived, and passwords are chosen by the worker — never generated, seen, or reset by an administrator.

The audit trail is append-only, and permission-gated

Every meaningful action writes an audit record with actor, organisation, before and after values, and reason. Update and delete are revoked from every application role, so the trail cannot be edited by the software that writes it.

Who may read it is a permission an organisation grants deliberately, visible in the portal — not a hidden capability.

The cross-tenant console is not on the public internet

The internal console used to create and manage organisations sits behind Cloudflare Zero Trust. An unauthenticated visitor is stopped at the network edge and never reaches the application at all.

Defence in depth, not the only defence: every privileged operation re-checks authorisation in the database, so bypassing the edge still yields nothing.

Where we are, plainly

Security pages tend to imply more than they say. This one is a status report. If a control is not in place yet, it says so — you should expect the same candour from any vendor holding this data.

Encryption in transit and at rest In place
Row-level tenant isolation, continuously tested In place
Append-only visit records and audit trail In place
Two-step verification (TOTP) In place
Zero Trust on internal administration In place
Automated isolation tests on every change In place
Signed BAA and HIPAA-tier infrastructure Before first production PHI
Independent security assessment Before first production PHI
Field-level encryption for identifying data On the roadmap

We do not describe the product as HIPAA compliant. Compliance is a property of an operating organisation with executed agreements, not of software — and until a Business Associate Agreement is signed and the platform moves to its HIPAA-tier configuration, the honest word is ready, not compliant. We will say so the day it changes, and not before.

What we deliberately do not collect

No background tracking

Location is captured at clock-in and clock-out. Never in between, never while the app is closed. A caregiver’s day is not a route we record.

Almost nothing kept on the phone

Visits captured without a signal are held encrypted on the device using opaque identifiers only — no names, no addresses — and cleared within days once sent.

No verbose query logging

Database auditing is scoped to schema and permission changes. Statement text is deliberately excluded, because logging it would copy personal information into logs that then need protecting too.

Questions from a compliance officer are welcome

We would rather answer a hard question early than discover a mismatch during an audit.