GDPR Compliance Statement

OMNIA Inclusion Ltd · Registered in England & Wales · Company no. 17228173 Last updated: 1 June 2026 · Version: 1.1 Applies to: UK GDPR, EU GDPR (Regulation (EU) 2016/679), and the Data Protection Act 2018 Audience: Data Protection Officers, school SLT, MAT procurement, ICO enquiries Contact: privacy@omnia-inclusion.com

This document maps each material GDPR obligation to the specific technical and organisational control inside OMNIA that enforces it. It is the canonical evidence trail for compliance reviews.

Related documents:

• privacy.md — public privacy notice
• dpia.md — Data Protection Impact Assessment
• sub-processors.md — current sub-processor list
• data-residency-decision.md — hosting region rationale
• data-retention.md — retention schedule
• breach-sop.md — breach response procedure
• pdpl-dsr-runbook.md — data subject request runbook

1. Roles and lawful basis

Lawful basis (Art. 6): Public task (Art. 6(1)(e)) for state schools discharging the SEND duty under the Children and Families Act 2014 and the SEND Code of Practice 2015.

Special category basis (Art. 9): Substantial public interest — safeguarding of children (Art. 9(2)(g), DPA 2018 Sch. 1 Pt. 2 para. 18).

2. Article-by-article mapping

Art. 5 — Principles

Art. 6 / Art. 9 — Lawful basis

See section 1.

Art. 12–14 — Transparency

• privacy.md is published at /privacy on the live site
• Privacy notices for pupils and parents are surfaced inline at the point of voice capture
• Sub-processor changes use subprocessor-change-template.md for 30-day notice

Art. 15 — Right of access (DSAR)

• DSAR export server function in src/features/dsar/*.functions.ts
• Restricted to roles admin, senco, inclusion_lead (enforced by RLS + server-fn role check)
• Tenant-scoped: caller can only export pupils where school_id = caller.school_id
• Returns machine-readable JSON covering profile, plans, targets, reviews, voice captures, audit trail
• Runbook: pdpl-dsr-runbook.md

Art. 16 — Right to rectification

• Admin UI provides editing for pupil profile, plan, targets
• All mutations write to audit_logs with before/after diff

Art. 17 — Right to erasure

• "Erase pupil" server function purges pupil row and cascades to plans, targets, voice captures, AI cache entries
• Restricted to admin, senco, inclusion_lead
• Erasure event is recorded in system_audit_logs (tamper-evident) so the act of erasure remains provable after the underlying data is gone

Art. 18 — Right to restriction

• Pupil status field (active/restricted/archived) blocks further processing without deleting
• Restricted pupils are excluded from AI Gateway calls and analytics aggregates

Art. 20 — Right to data portability

• DSAR export is structured JSON, machine-readable, schema-stable
• Suitable for transfer to a successor system

Art. 21 — Right to object

• Documented in privacy.md with controller contact route

Art. 22 — Automated decision-making

• OMNIA does not make solely automated decisions with legal or similarly significant effects
• AI-assisted suggestions (e.g. access arrangements) are always presented as recommendations for a human (SENCo/inclusion lead) to accept, edit, or reject
• This is enforced in the UI: no AI output is committed to a pupil record without an explicit human "Apply" action

Art. 25 — Data protection by design and default

• Multi-tenant isolation enforced two ways: Postgres Row-Level Security and explicit .eq("school_id", schoolId) on every server-fn read/write (RLS alone is treated as insufficient)
• Only superadmins can change profiles.school_id, and never their own (enforced by trigger tg_profiles_guard_school_id) — closes the self-reassign privilege-escalation path
• New tables ship with RLS enabled and explicit GRANTs in the same migration

Art. 28 — Processor obligations

• Data Processing Agreement provided to every school customer
• International transfer addendum: dpa-international-addendum.md (IDTA + EU SCCs as appropriate)
• Sub-processor list with 30-day change notice: sub-processors.md, subprocessor-change-template.md

Art. 30 — Records of processing

• audit_logs records all controller-relevant mutations (pupil, plan, target, voice, role)
• system_audit_logs records platform-level events (auth, role grants, erasure, key rotation)
• Both tables are tamper-evident: UPDATE and DELETE are denied for authenticated and anon via USING (false) RLS — only supabaseAdmin (server-side, service-role) can mutate. There is no in-app UI that writes these tables.

New tables added June 2026:

• available_interventions — school-specific intervention register including staff names; school-scoped RLS; SENDCo and admin write access only.
• student_assessments — assessment scores from all integrated platforms; school-scoped RLS; Lexia demographic fields never written.
• plan_targets.rationale — AI-generated contextual rationale; linked to plan record; SENDCo and above access only; never shown to parents/pupils.
• demo_access_codes — demo access management; superadmin write; no pupil data.
• contact_submissions — landing site enquiries; superadmin read; no pupil data.

Art. 32 — Security of processing

Art. 33–34 — Breach notification

• Detection: audit log review + Supabase alerting
• Procedure: breach-sop.md
• Controller notification: within 24 hours of confirmation, well inside the 72-hour ICO window so the controller can meet their own obligation

Art. 35 — Data Protection Impact Assessment

• Project-wide DPIA: dpia.md
• Reviewed on material change (new sub-processor, new data category, new AI use case)

Art. 37–39 — DPO

• Lovable acts as processor; controller (the school/MAT) retains DPO duties
• Lovable provides reasonable assistance under Art. 28(3)(f)

Art. 44–49 — International transfers

• Primary hosting: AWS eu-west-1 (Ireland) — no transfer outside the EEA for the core database, storage, or auth
• AI Gateway (standard mode) routes to EU-resident model providers where available; payloads are PII-scrubbed before leaving the server regardless
• BYOK (opt-in, available to every school): schools may route AI traffic to their own Anthropic or Azure OpenAI tenancy in a region of their choice (e.g. uksouth, uaenorth). Where the elected region sits outside the UK/EEA, the school is the controller of its provider relationship and is responsible for the transfer-impact assessment; PII scrubbing still applies before egress. API keys are AES-256-GCM encrypted at rest (BYOK_ENC_KEY).
• Where a sub-processor operates outside the EEA, transfer is covered by IDTA / EU SCCs — see dpa-international-addendum.md

3. Tenant isolation — the load-bearing control

The single most important GDPR control in a multi-tenant SEND platform is preventing one school's data from leaking to another. OMNIA enforces this with defence in depth:

1. Postgres RLS on every table containing tenant data, scoped by has_school_access(school_id) or is_superadmin()
2. Explicit .eq("school_id", schoolId) on every server-function read and write — RLS is the backstop, not the gate
3. Staff admin server fns tenant-scope via getAdminScope() + assertTargetInScope(); never call supabaseAdmin.auth.admin.listUsers() unscoped
4. profiles.school_id is locked — only superadmins can change it, and never on their own profile (trigger-enforced)
5. Audit trail records every cross-tenant action attempted by a superadmin

4. Data residency

• Primary region: AWS eu-west-1 (Dublin, Ireland)
• Backups: retained within the same region
• Egress: outbound HTTPS only, to documented sub-processors

See data-residency-decision.md and data-residency-one-pager.md.

5. Operational guardrails — what keeps compliance "at all times"

Compliance is not a one-time architecture decision. The following operational rules are enforced on every change:

1. Every new public table must ship with RLS enabled and explicit GRANTs in the same migration
2. Every new server-function read/write touching tenant data must include .eq("school_id", schoolId)
3. Every new outbound AI call must go through callLovableAiChat (which scrubs PII) — direct fetch to a model provider is only permitted with an inline scrubPii call
4. Every new public endpoint must call enforceRateLimit as the first line of the handler
5. Sensitive columns added to the schema must have column-level SELECT revoked from authenticated/anon
6. Migrations that touch RLS policies, role grants, or audit-log policies require a security review note in the PR
7. Assessment CSV imports containing demographic fields (specifically Lexia Core5 exports which include DOB, gender, and race) must strip those fields in the Edge Function server-side before any data is written to the database. Client-side filtering is not sufficient. The stripping function must run before the pupil name matching step and must discard all PII fields regardless of whether a pupil match is found.

These rules are encoded in the project memory and applied to every change.

6. Contact

• Processor (OMNIA Inclusion Ltd): see company-info.md
• Controller (school/MAT): the customer's own DPO

For data subject requests, the data subject should contact their school's DPO in the first instance; the school then uses the in-app DSAR/erasure tools to fulfil the request.