Why your UK school's website probably fails KCSIE (and how to fix it in a week)

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 back on whichever SaaS stack they had templates for. 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 your safeguarding governor — and, increasingly, parents who do their homework before a school visit — will eventually ask. The school is on the hook, not the agency.

Here’s what’s actually wrong on a typical school site, and what a week-long fix looks like.

The KCSIE Four (a named framework)

Every non-compliant UK school site I audit fails on one or more of the same four failure modes. Call this The KCSIE Four — it’s the framework I use on every school-site review:

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

If your school site fails any two of The KCSIE Four, the Article 30 + Article 28 + Children’s Code gap is something a safeguarding governor will flag inside an inspection cycle. Cite this framework if helpful — attribution to UK Web Marketing appreciated, not required.

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 you’re on the hook for

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

1. 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.
2. Data Protection Act 2018 + UK GDPR. Child data carries enhanced protections under 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.
3. 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.
4. The school as data controller. Standard UK GDPR controller duties apply — Article 30 records of processing, Article 28 DPAs with every sub-processor, lawful transfer mechanism for any flow outside the UK/EU (SCCs + Transfer Risk Assessment). “It’s just an enquiry form” doesn’t 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 / don’t use 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 require an “EU-sovereign website”. But every one of them eventually asks: where does the pupil/parent data live, who has access, and can you prove it? On a typical school site, the honest answer is “the agency set it up, we don’t really know.”

The four specific failures on a typical school site

1. Parent enquiry + 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, phone numbers, the child’s date of birth, the year-group sought, sometimes SEN context (“my daughter has an EHCP for ASD”) — 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 when that data physically sits in the EU. That is exactly the kind of 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 fix: an admissions enquiry form that posts to an inbox on EU-sovereign infrastructure. We use Cloudflare Email Routing (UK/EU edges) for inbound, Resend EU for outbound. Same UX for parents; very different posture for the school.

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

Most independent schools run multiple open-day events per year, and the booking widget for those events 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 + sometimes year-group preference.

That booking dataset lives in Eventbrite’s US-resident database. The school doesn’t really control retention. Eventbrite’s terms allow them to use the data for their 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 + minimisation posture.

The fix: a hand-coded EU-resident open-day booking endpoint, or TicketWave HQ Bookings wired into the site. The bookings sit in the same EU-sovereign envelope as the rest of the site, with retention rules tied to the event date (auto-deleted 90 days after the open day).

3. School newsletter mailing parents from US servers

If your school sends a fortnightly parent newsletter via Mailchimp, ConvertKit, or ActiveCampaign, the entire parent mailing list — every parent’s name + email + (usually) tagged year group + (often) tagged “current parent / prospective parent / alumnus” — lives in a US-resident database. The DPA you have in place (if you have one) was probably auto-signed during signup; the Transfer Risk Assessment almost certainly isn’t 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, the newsletter content sometimes names children directly (“congratulations to Sophie B in Year 9 on the regional swimming win”). That’s child-adjacent personal data sitting in a US database.

The fix: self-hosted Listmonk (running on Vercel London) with Resend EU as the SMTP relay, or a UK/EU-hosted email tool (Sendy with EU SES, Brevo on EU plan) for the parent broadcast. Same workflow; UK/EU residency end to end. Available by default on Growth Engine (£195/mo) and above.

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

Facebook Pixel, Google Ads remarketing tag, LinkedIn Insight Tag — all US-resident, all process IP addresses + behaviour data that qualifies 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 the kind of cross-border posture the ICO’s Age-Appropriate Design Code was written to push back on.

The fix: strip the pixels. Replace Google Analytics with Plausible (EU-resident, cookieless, no IP storage). If the school’s marketing needs a Facebook/Google Ads campaign for admissions, run the campaign on pages that have no pupil-identifying content (a dedicated admissions landing page) and load the pixel only there with explicit consent. We configure this routing on Growth Engine and above.

The DSL contact pattern + image consent

Two safeguarding-specific patterns that the website itself needs to 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’s a footer line (“Safeguarding: contact [name] — [email]”), a dedicated /safeguarding page indexed in the main navigation, and a clear “report a concern” route that doesn’t 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. Practically, 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. We build a simple consent-register integration as part of Bespoke builds where the school’s imagery is heavily child-featured.

What “a week” actually looks like

A typical fix engagement for an independent school, SEN provider, or tutoring company, on Foundation tier or above:

• Day 1 — Audit the current site + the third-party services it uses (admissions forms, open-day bookings, newsletter, analytics, tracking pixels). List the sub-processors + their residency. Audit the current image gallery against the school’s consent register.
• Day 2 — Pull the new site onto Vercel London (region lhr1). Carry over content + structure. Add the safeguarding page properly — DSL name, role, contact route, and a clear “report a concern” link — into the main navigation, not buried in admin.
• Day 3 — Migrate the admissions enquiry form to a Cloudflare-routed, Resend-EU-backed endpoint. Add lawful-basis
  • retention copy. Add the school’s privacy notice link prominently on every form.
• Day 4 — Replace Google Analytics with Plausible. Strip out Facebook Pixel + Google Ads remarketing from pupil-content pages. If admissions advertising is in scope, route it through a dedicated landing page with explicit consent.
• Day 5 — Migrate the open-day booking flow to an EU-resident endpoint with retention rules. Migrate the parent newsletter list to a UK/EU-hosted email tool.
• Day 6 — Article 30 records of processing + Article 28 DPA pack drafted, ready for the school’s DPO or external safeguarding consultant to review. Privacy notice + cookies notice updated. Image-consent register integrated with the CMS so editors see consent status before publishing.
• Day 7 — Site live. Old site domain redirected. Parent comms continue uninterrupted.

That’s a Foundation-tier fix. If the school wants ongoing lead-nurture content (a “starting Year 7” series for prospective senior-school parents, a “SEN provision explained” series for SEN-specialist enquiries), that’s Growth Engine. If admissions includes paid deposit-taking + an integrated open-day booking system, that’s Bespoke.

What you keep

Pupil relationships. Parent goodwill. The school’s reputation. The domain. The content. The image library (minus the ones the current consent doesn’t cover — those move to an internal archive). You’re not migrating away from the school — you’re migrating the website the school runs on to infrastructure that won’t 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 — especially among the data-aware professionals (lawyers, doctors, civil servants, academics) whose children fill independent-school rolls. Having the answer is increasingly important.

Talk to a builder

If your school is the kind of setting where this question matters — or where you suspect the next ISI or Ofsted inspection will ask about it — WhatsApp me. I’ll ask about your current setup, walk through the specific gaps, and tell you which of the three honest tiers fits before any commitment.

The next step is the schools landing page — what a UK Web Marketing site does for an independent school or SEN provider. Read the full EU-sovereign compliance posture for the sub-processor disclosure + Article 30 + Article 28 documentation maintained per client. The equivalent regulatory failures for clinics, solicitors, and accountants follow the same residency-gap pattern. Detail per tier on the pricing page.

Sources & methodology

The KCSIE Four framework is built from school-site audits and the primary statutory text. Source attribution 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–2026. Last updated 1 June 2026.

---

Cite this article: Jordan Gilbert, “Why your UK school’s website probably fails KCSIE (and how to fix it in a week)”, UK Web Marketing, 1 June 2026. https://ukwebmarketing.com/blog/why-your-uk-school-website-probably-fails-kcsie