Why your UK school's website probably fails KCSIE

Most UK school websites — independent prep and senior schools, SEN providers, alternative-provision settings, tutoring companies working with under-18s — were built by a sector-specialist agency a few years ago on whichever SaaS stack carried a template. WordPress on a US host, an Eventbrite open-day booking widget, a Mailchimp parent-newsletter signup, a Facebook Pixel for the admissions campaign, Google Analytics, and a “contact the Head” form pointing at a US-resident inbox. The site works. Parents find it. Open-day signups come in.

It also quietly fails KCSIE safeguarding expectations and the ICO’s children’s-data agenda. That gap is the question a safeguarding governor — and, increasingly, the data-aware parents who do their homework before a school visit — will eventually ask. The school is accountable, not the agency.

This briefing sets out what is actually wrong on a typical school site, and what a regulated-grade estate puts in its place.

The KCSIE Four

Every non-compliant UK school site fails on one or more of the same four failure modes. We call it The KCSIE Four — the framework Custodiance applies on every school-site review:

Parent and admissions forms processed on US infrastructure — HubSpot, Mailchimp, or Typeform routing to a US inbox, often carrying child-identifying data.
Open-day booking widgets holding pupil-year-group data in US databases — Eventbrite, US-resident calendar plugins.
School newsletters mailing parents from US servers — Mailchimp, ConvertKit, or ActiveCampaign with tagged year-group lists.
Tracking pixels loading on pages where pupil-identifying content sits — Facebook Pixel, Google Ads remarketing, LinkedIn Insight Tag on photo galleries and named-pupil pages.

Where a school site fails any two of The KCSIE Four, the Article 30, Article 28, and Children’s Code gap is something a safeguarding governor will flag inside an inspection cycle.

The statute, in its own words

KCSIE 2024 (Keeping Children Safe in Education, statutory guidance for England), Part 2, paragraph 138 (Online Safety):

“Governing bodies and proprietors should ensure online safety is a running and interrelated theme whilst devising and implementing their whole school approach to safeguarding and related policies and procedures.”

KCSIE 2024, paragraph 141 (filtering and monitoring):

“Governing bodies and proprietors should ensure their school or college has appropriate filters and monitoring systems in place and regularly review their effectiveness.”

The ICO Age-Appropriate Design Code (in force 2 September 2021), Standard 7 (Default settings):

“Settings must be ‘high privacy’ by default (unless you can demonstrate a compelling reason for a different default setting, taking account of the best interests of the child).”

A school website loading Facebook Pixel on a page that names a Year 8 pupil fails Standard 7 silently. The default is data-sharing with a US ad network, with no consent mechanism, on a page likely to be accessed by the child themselves.

What the school is accountable for

As an independent school, SEN provider, or tutoring company working with under-18s in the UK, four overlapping frames apply to the website:

Keeping Children Safe in Education (KCSIE). The statutory safeguarding guidance for schools in England. KCSIE requires the Designated Safeguarding Lead (DSL) contact to be visible, that filtering and monitoring are documented, and that staff and pupils can report concerns easily. The website is the front door — it should not be the place where the DSL information is hardest to find.
Data Protection Act 2018 and UK GDPR. Child data carries enhanced protections under the DPA 2018. The ICO’s Age-Appropriate Design Code (“Children’s Code”, in force since September 2021) applies to online services likely to be accessed by children — and the school’s own website is precisely that. The ICO’s children’s-data agenda has been a stated regulatory priority every year since.
DfE safeguarding expectations. For independent schools, the DfE’s Independent School Standards apply, including welfare and safeguarding. Inspections — ISI for ISC member schools, Ofsted for the rest — will look at the website as public-facing evidence of safeguarding posture.
The school as data controller. Standard UK GDPR controller duties apply — Article 30 records of processing, Article 28 DPAs with every sub-processor, and a lawful transfer mechanism for any flow outside the UK and EU, comprising Standard Contractual Clauses plus a Transfer Risk Assessment. “It is just an enquiry form” does not change the controller posture when the enquirer is identifying a child by year group or name.

The image-consent question runs across all four frames: no identifiable child should appear on the website without explicit parental consent, and that consent should be granular (use this photo, not that one), withdrawable, and recorded. Most school websites carry photos that the original consent — from five years ago, on a paper form, signed by a parent whose child has since left — no longer covers.

None of those frames explicitly requires an “EU-sovereign website”. But every one of them eventually asks the same question: where does the pupil and parent data live, who has access, and can the school prove it? On a typical school site, the honest answer is “the agency set it up; we do not really know.”

The four specific failures on a typical school site

1. Parent enquiry and admissions forms processed on US infrastructure

The “Enquire about admissions” form on most school websites is a HubSpot embed, a Mailchimp form, a Typeform widget, or a WordPress plugin sending to a US-resident inbox. Parent names, telephone numbers, the child’s date of birth, the year-group sought, and sometimes SEN context (“my daughter has an EHCP for ASD”) are all processed and stored on US servers.

US-resident SaaS is subject to the US CLOUD Act (2018), which allows US authorities to compel disclosure of stored data even where that data physically sits in the EU. That is exactly the cross-border posture the ICO has, in multiple public statements, said it expects organisations to avoid when processing children’s personal data. A school sending a Year 7 admissions enquiry through a US pipeline cannot easily justify that under the Children’s Code’s “best interests of the child” principle.

The standard: an admissions enquiry form that posts to an inbox on EU-sovereign infrastructure — Cloudflare Email Routing on UK and EU edges for inbound, an EU-resident relay for outbound. The same experience for parents; a very different posture for the school.

2. Open-day booking widgets holding pupil-year-group data in US databases

Most independent schools run several open-day events per year, and the booking widget is almost always Eventbrite, sometimes a WordPress event plugin backed by a US database, occasionally a Calendly link. The booking form typically collects parent name, parent email, parent phone, and — critically — the child’s name, year group, and sometimes year-group preference.

That booking dataset lives in Eventbrite’s US-resident database. The school does not really control retention. Eventbrite’s terms permit use of the data for its own marketing in some configurations. A list of “every Year 6 family looking at independent senior schools in Yorkshire in autumn 2026” is exactly the kind of dataset the ICO has flagged as needing strong residency and minimisation posture.

The standard: an EU-resident open-day booking endpoint, sitting in the same EU-sovereign envelope as the rest of the estate, with retention rules tied to the event date (auto-deleted 90 days after the open day).

Where a school sends a fortnightly parent newsletter via Mailchimp, ConvertKit, or ActiveCampaign, the entire parent mailing list — every parent’s name and email, the (usually) tagged year group, and the (often) tagged “current parent / prospective parent / alumnus” — lives in a US-resident database. The DPA in place (if any) was probably auto-signed during signup; the Transfer Risk Assessment almost certainly is not on file.

The list is also, functionally, a list of children’s family relationships. The parent’s email tells you the child exists, the year-group tag tells you their age, and the newsletter content sometimes names children directly (“congratulations to Sophie B in Year 9 on the regional swimming win”). That is child-adjacent personal data sitting in a US database.

The standard: a self-hosted sender on a London-region container with an EU-resident SMTP relay, or a UK and EU-hosted email tool for the parent broadcast. The same workflow, with UK and EU residency end to end.

4. Tracking pixels loading on pages where pupil-identifying content sits

Facebook Pixel, the Google Ads remarketing tag, and the LinkedIn Insight Tag are all US-resident, and all process IP addresses and behaviour data that qualify as personal data under UK GDPR. On a school website they typically load on every page, including pages where pupil-identifying content sits — the gallery of last term’s production, the head’s blog post about a Year 11 mock-results celebration, the SEN provision detail page.

The CJEU’s Schrems II ruling (2020) made bulk transfer of EU personal data to US infrastructure legally precarious; for child personal data the bar is higher again. Loading a Facebook Pixel on a page that shows a Year 8 pupil’s name and photo is precisely the cross-border posture the ICO’s Age-Appropriate Design Code was written to push back on.

The standard: strip the pixels. Replace Google Analytics with Plausible (EU-resident, cookieless, no IP storage). Where the school’s marketing genuinely needs a paid admissions campaign, run it on a dedicated landing page with no pupil-identifying content, and load the pixel only there with explicit consent.

Two safeguarding-specific patterns the website itself must handle correctly, separately from the residency question:

DSL contact details must be visible. KCSIE expects the Designated Safeguarding Lead’s name, role, and contact route to be findable easily. On a properly built school website that means a footer line (“Safeguarding: contact [name] — [email]”), a dedicated /safeguarding page indexed in the main navigation, and a clear “report a concern” route that does not require a parent or pupil to dig through admin pages.
Image consent on every identifiable child. No identifiable child should appear on the website without recorded parental consent. In practice that means a consent register the marketing team can check before publishing, photos tagged with the consent status, and a clear withdrawal route for parents. A consent-register integration belongs in the estate where the school’s imagery is heavily child-featured.

How a regulated-grade estate handles this

Custodiance runs this as a managed estate, in-jurisdiction, to your regulator’s standard. The work that puts a school’s site right is the work the estate carries continuously, not a one-off remediation:

Audit. The current site and every third-party service it uses — admissions forms, open-day bookings, newsletter, analytics, tracking pixels. Each sub-processor and its residency, set against the school’s current Article 30 records (or built from scratch where none exist). The current image gallery audited against the school’s consent register.
Hosting. The site pinned to a London region (lhr1), content and structure carried over, with the safeguarding page built properly — DSL name, role, contact route, and a clear “report a concern” link — into the main navigation, not buried in admin.
Admissions intake. The enquiry form migrated to a Cloudflare-routed, EU-relay-backed endpoint, with lawful-basis and retention copy, and the school’s privacy notice linked prominently on every form.
Analytics. Google Analytics replaced with Plausible (EU-resident, cookieless). Facebook Pixel and Google Ads remarketing stripped from pupil-content pages. Where admissions advertising is in scope, it is routed through a dedicated landing page with explicit consent.
Bookings and contacts. The open-day booking flow moved to an EU-resident endpoint with date-tied retention rules. The parent newsletter list migrated to a UK and EU-hosted email tool. An image-consent register integrated with the CMS so editors see consent status before publishing.
Documentation. Article 30 records of processing and an Article 28 DPA pack ready for the school’s DPO or external safeguarding consultant to review. Privacy and cookies notices updated to reflect the sub-processor list.

This is the floor of a Growth engagement (£1,495/mo). Where admissions includes deposit-taking, an integrated open-day booking system, and a child-featured image library across several sites — or where a school wants a fractional CTO owning the roadmap and compliance posture — that is an Embedded engagement (from £6,000/mo, bespoke).

What the school keeps

Pupil relationships. Parent goodwill. The school’s reputation. The domain. The content. The image library (minus the images the current consent does not cover — those move to an internal archive). The school is not migrating away from anything — it is moving the website it runs on to infrastructure that will not make the safeguarding governor nervous, and that holds up when a prospective parent asks “where does the admissions form data go?”

That parent is increasingly common — particularly among the data-aware professionals (lawyers, doctors, civil servants, academics) whose children fill independent-school rolls. Having the answer is increasingly the price of keeping them.

Where this fits

The equivalent regulatory failures for clinics, solicitors, accountancy practices, and estate agencies follow the same residency-gap pattern. The practical KCSIE checklist sits in the school website audit checklist. The published posture behind all of this is the Custodiance framework. When a school is ready, the next step is to request a scoping call.

Sources & methodology

The KCSIE Four framework is built from school-site audits and the primary statutory text. Source attribution is given where rules or paragraphs are quoted.

Keeping Children Safe in Education 2024 (statutory guidance) — UK Department for Education — https://www.gov.uk/government/publications/keeping-children-safe-in-education—2
ICO Age-Appropriate Design Code (“Children’s Code”) — Information Commissioner’s Office — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-the-code-in-full/
Independent School Standards (DfE) — Department for Education, regulatory framework — https://www.gov.uk/government/publications/regulating-independent-schools
CJEU Schrems II ruling — Case C-311/18, 16 July 2020 — https://curia.europa.eu/juris/liste.jsf?num=C-311/18
US CLOUD Act (2018) — Pub. L. 115-141 — https://www.congress.gov/bill/115th-congress/house-bill/4943
Methodology: framework derived from independent prep and senior school, SEN provider, and tutoring company site audits, 2025 to 2026. Last updated 1 June 2026.