Security & compliance
Last updated: October 2026
You are handing us the rota, the care notes and the staff records for people who depend on you. This page says plainly how that data is kept apart, who can reach it, and what we record. Where something is not built yet, it says that too.
Tenant isolation
Every table that holds customer data carries an organisation id and is protected by PostgreSQL row-level security. Isolation is enforced by the database itself against the signed-in user's token, not by a filter in application code that a bug could omit. A query that forgets its organisation returns nothing rather than everything.
Sensitive records (pay details, restricted client notes, safeguarding information) sit behind further permission checks on top of that, so a colleague with ordinary rota access cannot read them.
Access control
Access is by role: owner, admin, manager, team leader, team member. Team leaders see their own team. Carers see their own shifts, their own records and the clients they are rostered to. Being on call widens what a person can see for the duration of their on-call session and then narrows it again.
The mobile app requires a PIN in addition to sign-in, and the PIN is stored only as a bcrypt hash. Sign-in is by email and password. We do not yet offer two-step verification (an authenticator code or a passkey) for any account, and we will not describe it here until it exists.
What we record
Changes to rota shifts, cover requests and replies, on-call events, handovers, staff skills, restrictions on which staff may attend a client, roles and rule overrides are written to an audit log with the actor, the time and the before-and-after values. No user of the product can edit or delete an entry. The log does not yet cover changes to staff or client profile records, the sensitive pay and restricted-note records described above, leave or documents, and we do not record who reads or views a record. Two things in particular are recorded because they are the ones an inspector asks about:
- Every cover decision. When a shift is offered, who it went to, the ranked reasoning they were picked on at that moment, who replied and what they said.
- Every rule override. If a manager assigns someone past a working-time limit, a training requirement or a client restriction, that is recorded against their name with the reason they gave and the numbers as they stood, and the carer is told and asked to confirm they were told.
Overrides are off by default, per category, and an organisation switches on only the ones it is prepared to allow. Two things have no override switch and no code path at all: immigration hour caps, and the special-hazards eight-hours-in-any-24 limit under regulation 6(7) of the Working Time Regulations. Breaching those is not a risk a provider is entitled to accept, so the product will not help them do it.
Hosting and sub-processors
The application and database run on Supabase, in the United Kingdom (the London region). Your staff records, client records, rota, care notes and documents are held there. The websites and apps are served from Cloudflare.
Some supporting services that receive data about your staff or the people you support operate outside the UK, and we would rather name what reaches them than claim more than we can. Transactional email goes through Postmark; crash reports go to Sentry; push notifications are delivered through Expo and then through Apple's push network (APNs) and Google's push network (FCM), which carry the same notification Expo does; and the map on a client or staff record comes from OpenStreetMap. None of them holds your records. Every one of them, and what it receives, is on the sub-processor page, which we keep current.
The map deserves a sentence of its own. When a manager presses “Find their address on the map” on a client or staff record, the browser sends the address as typed to OpenStreetMap's Nominatim search service to place the pin. It sends the address only, with no name attached, but an address is still personal data and you should know it travels.
A push notification concerns a person you support too, so it is worth being exact. It carries their initials, never their name: a carer reads “J.B. · 31 Aug 18:00” and knows whether it is their round without unlocking the phone, and nobody outside the UK is told who that is. The name is shown once the carer opens the app, which is a request to our own database in London. If a coordinator types a name into the free-text note attached to a cover request, that note is part of the notification and does travel: it is the one route we have left open, because a note nobody can read until they unlock is most of the reason for sending one.
Backups and recovery
The database is backed up daily by our hosting provider, and the backups are held in the same United Kingdom region as the database itself. Point-in-time recovery is available on our platform and we have not enabled it, so a restore could lose up to 24 hours of changes. We would rather tell you that number than let you assume a smaller one.
We have not yet published a tested recovery time objective. The verification steps a restore is checked against are written down and have been run; the restore itself has not been timed, and we will not quote a figure we have not measured. If a guaranteed recovery point matters to your organisation, ask us before you rely on it: it is a cost we can cover for a customer who needs it, and we would rather have that conversation than surprise you.
Reporting a vulnerability
Email hello@oncallcare.co.uk. Tell us what you found and how to reproduce it. We will acknowledge within two working days. We will not take legal action against anyone acting in good faith who gives us reasonable time to fix an issue before going public, and who does not access or alter other people's data while investigating.
What we do not claim
We are not ISO 27001 or Cyber Essentials certified and we do not describe ourselves as either. We have no SOC 2 report. We are a small company and we would rather you know that than find out later. On the ICO register: Registration applied for; number not yet issued.
Where the law is going, and where we already are
Holiday records are a criminal matter
Since 6 April 2026, under section 35 of the Employment Rights Act 2025, failing to keep adequate holiday pay records for six years is a criminal offence, not a civil one. Most providers we talk to are still keeping this in a spreadsheet that is rewritten each year.
OnCall Care keeps a running accrual ledger per carer (hours worked, entitlement accrued, leave taken, balance carried), and it does not get overwritten. That ledger is the record the section asks for.
It handles all three lawful accrual methods, including the one most systems get wrong: a zero-hours carer whose hours are stable in practice is not an irregular-hours worker, because the statutory test is contractual variability. Applying 12.07% to them is unlawful, and pro-rating their contracted hours gives zero. Following Harpur Trust v Brazel, we average their paid weeks over 52 instead.
The zero-hours package
The Act's guaranteed-hours, reasonable-notice and short-notice cancellation payment duties are law but are not expected to be in force before 2027, and the numbers inside them (the reference period, what counts as reasonable notice, what a cancellation is worth) were still out to consultation, which closed on 25 August 2026.
So nobody can be compliant with them yet, ourselves included, and any supplier telling you their product is "ERA 2025 compliant" today is selling you something that cannot exist.
What is true is duller and more useful. When the reference period does start, it will look backwards at hours already worked, offers already made and shifts already cancelled. Providers who only start recording that when the duty commences will begin with an empty history. We record it now: rolling hours per carer, every shift offer and who it went to, every cancellation and when, so that on day one you have the history rather than a blank page.
When the regulations land with their final numbers, the calculations become a per-organisation setting with a documented default, the way every contested rule in this product already is. We do not bake a disputed interpretation of the law into code and present it as fact.
Questions
Security and data protection questions go to hello@oncallcare.co.uk. If you are running a supplier assessment, ask. We would rather answer a questionnaire than have you guess.