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.

01

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 AI assist 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, then purged automatically.
One-click GDPR export
A manager can fulfil a Subject Access Request themselves — a full JSON export of one child's profile, guardians, attendance history, care records, documents and financials. No ticket to support, no waiting on us.
02

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.
Six built-in roles, plus your own
Manager, admin, teacher, parent, the door kiosk and ParentLink support — plus custom roles you define with feature-level permissions (e.g. 'can see medical info but not billing'). Every read and write is checked against your role in the database, and money actions against the Finance permission.
Multi-factor authentication
Two-step verification for every member of staff and every parent (works with Google Authenticator, 1Password, Authy, any standard app). Recovery codes are SHA-256 hashed before storage so a database leak can't reuse them. Constant-time comparison defeats timing attacks. 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 teacher 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 never to your children's care records — attendance, medication, incidents and safeguarding entries are out of bounds at every level. 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 grants no access without your say-so, and that you get a complete record of every visit — 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 instantly cuts off API access AND removes them from rota / key-person assignments — no orphaned authorisations. Re-activation is reversible without data loss.
03

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 dropped with a 400 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. Multiple signing secrets supported for safe key rotation.
Per-nursery webhook secrets
Each nursery has its own webhook secret in nursery_payment_config. 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.
04

How we treat parents' data

Parents only see their own child
Enforced at the database via the is_guardian_of() helper, not the UI. 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 MFA for parent accounts
Parents can enable TOTP-based 2FA on 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. Erasing a child's record is handled on request, so the records the law requires you to keep are kept (UK GDPR Article 17).
05

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 edge 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 support tools, 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.

06

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 available on request.

07

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.