Security and data handling

This page says what is true today. Where we hold no certification, it says that rather than describing an aspiration in the present tense.

What is deliberately not stored

No patient data. The product schedules staff. There are no patient records, no appointments tied to a named patient, no clinical data. This is an architectural property rather than a policy — there is nowhere to put it.

That matters more than any control would. The strongest protection for data is not holding it.

No financial data. No card number, no last four digits, no brand, no expiry date, no security code, no bank detail, no amount charged — none of it is in our database, in any table. Payment details live with the payment processor and are read from them at the moment of use; what we store is the processor's own identifier for the customer, which is a pointer rather than a copy.

This is enforced rather than intended: a test fails the build if a card-shaped column, migration or API field appears anywhere in the codebase.

No pay rates. Hours and shift classifications are exported for payroll to price. Rates, differentials and contract terms stay in payroll.

What is stored

Names, work email addresses, the staff categories and sites a person belongs to, their shifts, their requests, their professional qualifications where a site tracks those, and an audit record of changes. Contact details where a site enters them for on-call purposes.

Tenant isolation

A site administrator is a customer with a boundary, not a reduced version of the operator. Their access is scoped to the sites they administer, and every list, report and change is filtered to those.

The permission to take an administrative action and the question of which rows that action may touch are separate decisions throughout the codebase. Conflating them — using "is this caller an admin" to decide what data they see — is the defect class this product has been audited for most often, and there is a build-failing test that looks for it specifically.

Row-level security is enabled on every table in the database, with no policies granting access, so the data layer is deny-by-default and reachable only through the application's own authorisation.

Access and sessions

Sessions are signed and time-limited. A password change or a deactivation revokes every live session for that account immediately, rather than waiting for them to expire.

Where a platform administrator needs to act as a user to reproduce a problem, that access is time-boxed and both identities are written to the audit record — the account the action appears under, and the administrator actually driving.

Transport and headers

Everything is served over HTTPS with HSTS. The application sends a Content-Security-Policy that permits no inline or evaluated script, and the API sends a stricter one still. Cookie-authenticated changes are protected against cross-site request forgery by origin enforcement plus a token derived from the session.

What we do not claim

• No SOC 2 report. We do not hold one.
• No ISO 27001 certification. We do not hold one.
• No HIPAA compliance claim. We are not making one, and the design intent is to hold no data that would require it. If your use requires a business associate agreement, raise it with us before assuming.
• No penetration test report to share at present.

If any of these change, this page changes. Until then it is accurate.

Reporting something

If you believe you have found a security problem, contact us and say so in the subject. We would rather hear about it.

Related

• Audit trails
• Multi-site scheduling — how scoping works across a group.