Data controller / processor: OMNIA Inclusion Ltd (registered in England & Wales, company no. 17228173). Registered office: 169 High Street, Marske-by-the-Sea, Redcar & Cleveland, TS11 7LN, United Kingdom.
Version: 1.4 Last reviewed: 2026-06-01 Owner: Data Protection Officer (school-side) + OMNIA Inclusion Ltd platform team
1. Purpose of processing
OMNIA helps schools document Special Educational Needs and Disability (SEND) provision: inclusion plans, behaviour plans, EAA arrangements, Personal Emergency Evacuation Plans, parent voice, referrals, JCQ access arrangements (including Form 8 and parental consent), annual / statutory review records, and supporting evidence.
Lawful bases relied on:
- GDPR / UK GDPR Art. 6(1)(e) + Art. 9(2)(g) — public interest task (statutory SEND duties, JCQ regulations for exam access arrangements).
- UAE PDPL Art. 5(d) + Art. 6 — necessity for performance of a contract with the parent and compliance with KHDA / ADEK regulatory obligations.
2. Data categories processed
| Category | Examples | Sensitivity |
|---|---|---|
| Pupil identity | Name, DOB, photo, year group, national ID | Personal |
| SEND data | Primary need, plans, targets, specialist reports | Special category |
| Parent voice | Free-text responses about the child | Personal + special category |
| Staff identity | Staff name, email, role | Personal |
| Audit metadata | IPs, user agents, timestamps | Personal |
| Staff timetable assignments | Staff↔pupil↔provision links, period times, location | Personal (staff) + linked to special-category pupil data |
| Access-arrangement evidence | JCQ Form 8, normal way of working, assessor reports, parental consent | Special category |
| Review records | Annual / statutory review attendees, decisions, sign-off | Personal + special category |
| Available Interventions Register | School's deliverable intervention programmes; staff names as trained-to-deliver | Personal (staff) |
| Assessment platform import data | Scores and progress data from Lexia Core5, Nessy, Sparx Maths, DoodleLearning, TTRS, Emile, GL Assessment, PUMA, MAP, and others | Personal + linked to special-category SEND data |
| AI plan generation rationale | Per-target contextual rationale in plan_targets.rationale; references assessment scores, voice entries, strategy history | Special category (linked to SEND data) |
3. Data flows
Parent ─┐ ┌─► Inclusion team (browser, RLS-scoped)
├─► OMNIA web app ─┤
Staff ──┘ ├─► Lovable Cloud (Postgres, encrypted at rest)
├─► Microsoft Graph (optional: SharePoint discovery,
│ shared mailbox for parent links)
├─► Lovable AI Gateway (specialist-summary OCR/LLM,
│ Specialist Support Prompts) — standard mode
└─► School's own AI provider (BYOK opt-in) —
Anthropic or Azure OpenAI, in the school's
chosen region (e.g. UAE North, UK South)
The Staff Timetabling tool reads and writes the same Lovable Cloud (Postgres)
tables as the Resource Optimiser (staff_allocations, plus its own
timetable_periods and staff_timetable_slots). It introduces no new
processors and no new data egress.
Specialist Support Prompts read already-documented provision data and
surface professionally-framed prompts to qualified staff. They are never
visible to parents or pupils, never make clinical claims, and every prompt
acceptance / rejection is written to audit_logs.
4. Processors
| Processor | Role | Region | DPA |
|---|---|---|---|
| Lovable / Supabase | Hosting, database, storage | EU (AWS eu-west-1, Ireland) | Yes |
| Microsoft Graph | Optional SharePoint + email for parent links | School's tenant | School's existing M365 DPA |
| Lovable AI Gateway (standard mode) | LLM request brokerage routing to Anthropic Claude (plan generation and contextual AI) and Google Gemini (natural language query parsing only). PII scrubbed before all egress. | Per provider | Inherited |
| Anthropic PBC | LLM inference for plan generation, contextual AI, Specialist Support Prompts | US (via Lovable AI Gateway); PII-scrubbed prompts only | Anthropic DPA; no training on school data |
| School's own AI provider (BYOK opt-in, Connected tier) | Replaces the Lovable AI Gateway for that school's traffic; Anthropic or Azure OpenAI under the school's own contract | School-elected region (UAE North, UK South, etc.) — may be outside the UK/EEA; the school is responsible for residency assessment | School's direct DPA with the provider |
5. Risks & mitigations
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Cross-tenant data leak | Low | High | Row-Level Security on every domain table; explicit .eq("school_id", schoolId) filter on every server-fn read/write as defence-in-depth; nightly schema linter. Tenant guard on supabaseAdmin writes (e.g. mergeIntoPlan); staff admin server fns tenant-scope via getAdminScope() + assertTargetInScope(). Only superadmins can change profiles.school_id, and never their own (trigger-enforced). |
| Parent voice link interception | Medium | Medium | 4-digit PIN gate, scrypt-hashed PINs, rate-limit (per-IP + per-token via enforceRateLimit) + 15 min lockout after 5 attempts, single-use tokens, 30-day expiry |
| Inappropriate staff access | Low | Medium | Role-based access (superadmin / admin / inclusion_lead / SENCo / teacher / peep_only / read_only); Teaching Assistant view sees least; External Professional view scoped to plan summaries only; per-pupil audit trail visible to SENCo; MFA (TOTP, AAL2) required for admin and superadmin |
| LLM data exposure (standard mode) | Low | Medium | Single chokepoint (callLovableAiChat); server-side PII scrubber (scrubPii/scrubMessages — names, emails, phone, UPN/ULN, NI, postcode, DOB) runs on every outbound prompt — including BYOK; not opted in to provider training; upstream retention governed by AI Gateway and its providers |
| LLM data exposure (BYOK mode) | Low | Medium | School elects provider (Anthropic / Azure OpenAI) and region under its own DPA. API key AES-256-GCM encrypted at rest (BYOK_ENC_KEY); plaintext never returned to client (only provider, endpoint, last4, active, verified_at exposed). PII scrubbing still applied. No silent fallback to OMNIA's shared key — failures surface to the school admin. Region may sit outside UK/EEA (e.g. UAE North) — residency is the school's controller decision. |
| SharePoint over-discovery | Medium | Medium | Drive allow-list, GDPR acknowledgement gate, manual confirm before file binds to pupil |
| Stale data retention | Medium | Low | Daily retention sweep (see /docs/data-retention.md) |
| Inappropriate visibility of staff schedules | Low | Low | Premium feature flag (off by default); RLS-scoped per school; teachers see only their own + their year groups; SENCo/admin see all within school |
| Access-arrangement evidence mis-handling | Low | High | JCQ Form 8 authored via Zod-validated structured form; parental consent captured per arrangement with timestamp and route; audit-timeline export logged in audit_logs; retention aligned to on-roll + 7 years |
| Audit-log tampering | Low | High | RLS denies UPDATE/DELETE on audit_logs and system_audit_logs for authenticated/anon via USING (false); only supabaseAdmin (server-side service-role) can mutate |
| Specialist Support Prompts misuse | Low | Medium | Reads only documented provision data; presented as professional prompts (not clinical claims); never visible to parents/pupils; accept/reject logged in audit_logs |
| Assessment import PII exposure (Lexia) | Low | High | Lexia Core5 CSV exports contain DOB, gender, and race. Server-side PII stripping function removes these fields immediately on import before any database write. Fields are never stored. Stripping enforced in Edge Function, not client-side. |
| Available Interventions Register access | Low | Low | Staff names in trained_staff field are staff personal data. Read restricted to school members by RLS; write restricted to admin and SENCo roles. Programme names and delivery formats only included in AI context — staff names never transmitted to AI. |
| Contextual AI rationale retention | Low | Medium | plan_targets.rationale references specific assessment scores and voice content. Mitigated by: SENDCo and above role access only; never shown to parents, pupils, or teachers; parent-facing plan view excludes rationale entirely. |
| Edge runtime exposure | Low | Medium | Server-side logic runs on Cloudflare Workers; no pupil data persisted at the edge; secrets injected per request, never logged |
6. Data subject rights
- Access (PDPL Art. 13 / GDPR Art. 15): DSAR pack generated from the pupil page. Restricted to admin, SENCo and inclusion-lead roles. Includes all rows + redacted security tokens + audit log.
- Erasure (PDPL Art. 14 / GDPR Art. 17): "Erase pupil record" admin action with two-step confirmation. Cascade-deletes across plans, PEEPs, referrals, parent voice, share links, discovered files, staff allocations, timetable slots, access-arrangement records, consent rows and Form 8 JSON; storage folder cleared. Audit row written before deletion.
- Rectification: SENCos can edit any pupil record directly.
- Restriction / objection: raise with school DPO; OMNIA exposes per-pupil "mark as left" plus per-record edit/delete.
Erasure cascade also includes: available_interventions rows linked to the school on school deletion; student_assessments rows linked to the pupil; plan_targets.rationale for all plans linked to the pupil.
7. Children's data
OMNIA processes data about children only on the school's lawful basis as
above. Parents are informed via the privacy notice surfaced on every
parent-voice form before submission, and consent to that submission is
captured as consent_given_at on each request.
8. Review cadence
This DPIA is reviewed:
- annually by the school DPO,
- on any change to processors,
- on any change to the data categories above,
- after any security incident,
- on enabling the Staff Timetabling premium feature for a school.
- On enabling or populating the Available Interventions Register for a school for the first time.
- On adding a new assessment platform integration that introduces new data categories or demographic fields requiring PII stripping.