SECURITY & TRUST

Closed at the database, not patched in the interface.

Most data breaches in childcare software come from over-permissive APIs, URLs shared in emails that should never have been sent, or staff accounts left active after they leave. Every one of those is a rule the database enforces here, so no screen, export or API route can talk its way past it.

Below is a plain-English summary of how we protect your families’ data, with each claim mapped to the specific control that backs it. If you want the technical detail behind any of them, email security@parentlinkeducation.co.uk.

How we protect data

Encrypted in transit and at rest

AES-256 at rest (managed by Supabase, our database provider) and TLS 1.2+ in transit on every connection from browser, mobile, and server-to-server. There is no unencrypted path to your data.

UK-hosted, UK GDPR compliant

Your nursery's operational data is hosted on Supabase's UK (London) region — the primary database stays in the UK with no cross-border transfer. Static delivery runs on Vercel's edge network. Email and SMS delivery, push notifications, translation and the AI features (AI writing assist, the opening lines of the morning Today brief email, and Just ask) use named providers in the EU and the US, covered by the UK GDPR's transfer safeguards — each one, where it runs and on what basis, is listed on our Privacy page.

Append-only audit log

Every change to a child, staff, money or consent record — a child profile, a billing rate, a permission grant — is written to an append-only audit_log table with the old value, new value, actor, role, and timestamp. Entries are kept for 24 months and removed automatically by the end of the month in which they turn 24 months old.

One-click GDPR export

A manager can fulfil a Subject Access Request themselves — one zip file of one child's profile, guardians, attendance history, care records and financials as JSON, with the photos, videos and documents themselves. No ticket to support, no waiting on us.

If a tablet is lost

Offline tablets are off unless you switch them on. When they are on, the copy a tablet keeps is encrypted and opens with no connection only with your setting's offline code. It holds names, booked sessions, a yes/no health flag, who may not collect each child, and the staff list with today's sign-ins — no health details or notes — and once it is older than the 3, 7 or 14 days you chose, it won't open at all.

Just ask keeps your records in ParentLink

Before a question goes to the AI provider, the names of your children, families, staff, waiting-list families and booking contacts are swapped for placeholders. The AI only plans which look-ups to run; ParentLink runs them on your own records, under the asker's own permissions, so no record is sent. Off until a manager switches it on.

How we control access

ParentLink’s access controls are enforced at the database, not the UI. That distinction matters: even if a logged-in staff member crafted a direct API request to read another nursery’s children, the database would return zero rows.

200+ Row-Level Security policies

Staff at Nursery A literally cannot query rows belonging to Nursery B — the database enforces tenant isolation on every SELECT, INSERT, UPDATE, and DELETE. UI bugs cannot leak data across nurseries because the UI never sees the data.

Built-in roles, account owners, read-only Auditors and your own

Manager, admin, practitioner, parent, the kiosk tablets and ParentLink support — plus account owners who can hand over control and are never locked out of Roles, read-only Auditors for inspectors, accountants and trustees, and custom roles you define. Each page is Off, See only or See and change for each role, and access can be given an end date. In the database, every read and write is checked against the role's level of access. Money, safeguarding, staff pay and HR records, recruitment, the waiting list and the sensitive Settings sections are checked against their own permissions, and an Auditor can never write anything.

Two-step verification

Two-step verification for every account (works with Google Authenticator, 1Password, Authy, any standard app). It is optional: a setting can require it of managers, admins or practitioners, and the database then refuses anyone in those roles who hasn't set it up. Recovery codes are SHA-256 hashed before storage so a database leak can't reuse them. Codes are checked in the database, and five wrong tries lock the account for 15 minutes. A session that has not passed the code reaches no data at all — the database refuses it.

Brute-force protection

Per-document attempt limits (5 fails = 15 minute lockout) AND a cross-request IP-level lockout (20 fails in an hour from one IP = blocked) so attackers can't rotate request IDs to skirt the per-document limit.

Kiosk credentials isolated

The PIN-based kiosk sign-in flow uses its own table separate from staff accounts, with a tighter RLS policy that only managers and admins can read or modify. A compromised practitioner account can't enumerate kiosk PINs.

Support has no standing access to your setting

To help with a problem, a member of our team has to ask, and a manager at your setting switches access on for a chosen number of hours. You choose whether we can look only, or also make changes; the database holds us to that choice, and we can never change your children's care records — attendance, medication, incidents and safeguarding entries — at any level. With a view grant we can see them, as you can. It expires on its own, you can end it at any moment, and everything done while we are in is written to your own audit log under our name. Being plain about the limit: like any provider that can restore your database, our engineers hold administrative credentials to the underlying infrastructure. What we are telling you is that the support tool opens your setting's records only with your say-so, that the few account fixes we make without it (turning off a locked-out manager's two-step verification, adding a manager, group-wide access, pausing or resuming sending, adding sending credit, and a full copy of your data) are made only after checking it is really you, and that anything ParentLink support does is recorded in your own audit log — not that we have made ourselves technically incapable. Any supplier claiming the latter is describing a system that could never be recovered after a failure.

Off-boarding is a single click

Deactivating a staff member cuts off their sign-in and API access at once, and keeps their records. An Auditor's access can be given an end date, and closes by itself on that day. Re-activation is reversible without data loss. Their key-person children and future rota shifts stay as they were, so reassign those when someone leaves.

How we secure money flows

Payment integrations are the highest-stakes part of any nursery software. Forged webhook calls can mark unpaid invoices as paid, trigger refunds, or push fake bank-mandate confirmations. We’re paranoid about this layer.

Direct Debit via GoCardless

Every webhook from GoCardless is verified with HMAC-SHA256 using a per-nursery shared secret. Constant-time signature comparison. Unsigned or wrongly-signed callbacks are refused before they touch your invoices.

Card payments via Stripe

Webhook signature verified using Stripe's t=&v1= scheme with a 5-minute timestamp tolerance — even a captured signature cannot be replayed an hour later. During a Stripe key roll, either signature on a webhook is accepted.

Per-nursery webhook secrets

Each nursery has its own webhook secret, stored with its payment settings. A compromised secret at one nursery affects no other customer — and rotation is a one-row update with no redeploy.

Tax-Free Childcare reconciliation

When you upload a bank statement to reconcile TFC payments, the import runs through a per-bank parser, idempotent matching by reference number. Only staff at your setting can upload.

How we treat parents' data

Parents only see their own child

Enforced at the database, which checks the parent is linked to that child — not by the screens. Even a parent who guesses another child's UUID and pastes it into a URL gets a clean 'not found' — the database refuses to return the row.

Name and date of birth on every parent form

Forms emailed to parents require the child's first name AND date of birth before they'll accept a submission. Boosts brute-force resistance by ~1,800x vs name-only. The form refuses to leak whether a given URL even exists.

Optional two-step verification for parent accounts

Parents can switch on two-step verification for their own account from the settings page — same standard authenticator-app workflow as the manager flow.

Erasure requests

A child's full record exports in one click, and a parent account can be erased from inside the app, with an audit trail. The setting decides how long each kind of record is kept after a child leaves (safeguarding, accident and medication records never shorter than the usual minimum), and may also choose how long to keep the messages, care logs, registers and gallery photos of children still there. Once a period has passed, someone the setting allows approves the deletion — a manager unless it chooses otherwise; safeguarding records need someone who may also open the safeguarding log — and every deletion is logged.

Infrastructure & shared responsibility

ParentLink is a Supabase + Vercel application. We’re explicit about this because it’s how you should think about our security posture: the platform layer is best-in-class hyperscale infrastructure; the application layer is where our specific controls live.

Platform layer (Supabase + Vercel)

SOC 2 Type II — both providers
ISO 27001 — both providers
GDPR-aligned — both providers
Managed Postgres with provider-side backup and recovery (Supabase)
DDoS mitigation at the edge (Vercel)
TLS termination + automatic certificate rotation

Application layer (ParentLink)

Row-Level Security enabled on every tenant table
Every server function gated — caller permission checks, webhook signature verification, or scoped bearer tokens
Verbose tracing is off in production
Webhook signature verification on every external callback
Brute-force lockout per document AND per IP
Append-only audit log on every child, staff, money and consent record
Payload-size caps on public endpoints
Support access is customer-granted, time-limited and audited — enforced in the database, with the record of every visit in your own audit log

We have rehearsed the hard part

In July 2026 we moved the entire production database from the EU to the UK region — every table, every stored file, every scheduled job — and brought it back up on the other side. The whole exercise took about four hours end to end; the database restore itself took seconds. Most of that time was checking, not waiting. It was a migration rather than a drill, but it is the same work a real recovery would need, and it is the reason we can describe our recovery process from experience instead of from a document.

Compliance

UK GDPR

Data Protection Act 2018

ICO registered — ZC232143

Audit log kept for 24 months

Data minimisation by design

UK-hosted database (London)

ParentLink is operated by ParentLink Education Ltd, a company registered in Scotland under company number SC900539, and registered with the UK Information Commissioner’s Office under reference ZC232143. You can check both on the public registers rather than taking our word for it.

ParentLink Education Ltd acts as a data processor for nurseries that use the platform. Your nursery is the data controller. We do not sell, share, or repurpose customer data for any reason — and we do not train AI models on it. The full list of sub-processors is on our Privacy page; our data processing agreement is published and forms part of our Terms.

Responsible disclosure

Found something? We’d like to hear from you before you tell anyone else.

security@parentlinkeducation.co.uk

We aim to acknowledge within one working day.
We won’t pursue good-faith researchers who follow responsible disclosure.
We’re a small team without a formal bug bounty yet — but we’ll send a thank-you and credit you on this page if you’d like.