OMNIA Inclusion Ltd — Data Protection Impact Assessment (DPIA)
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 |
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 summarisation, Specialist Support Prompts; PII scrubbed before egress | Per provider | Inherited |
| 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 |
| 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.
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.