Legal documents and company details
The company
Delta Academics is run by Delta Research Group Ltd, registered in England and Wales, company number 17324839, registered office 127a Westbury Road, Bristol, England, BS9 3AP.
- Company
- Delta Research Group Ltd
- Registered in
- England and Wales
- Company number
- 17324839
- Registered office
- 127a Westbury Road, Bristol, England, BS9 3AP
- Incorporated
- 7 July 2026
- ICO registration number
- ZC270883
- Privacy contact
- privacy@deltaconsole.com
The school data processing agreement
The agreement between a school and Delta Research Group Ltd under Article 28 of the UK GDPR, as the company's solicitor approved it.
Terms and acceptable use
Privacy notices
Personal data breach procedure
Approved by the company's solicitor, 28 September 2026; party details updated 28 September 2026; the changes of 22 October 2026 published on the founder's own approval and sent to the company's solicitor for review. Prepared 28 September 2026 from the code and docs/DATA_PROCESSING_RECORD.md; [Assumption] marks anything not established from them; and on 22 October 2026 for pupils' names, sign-in, comments, messages, kept drafts and questions made from a pupil's own work.
From the approved document 06, Personal data breach procedure. Left out here: the paragraph "What this is", which points to Delta's internal records; section 5, the incident lead's own log of incidents; section 6, questions for the solicitor.
Delta, operated by Delta Research Group Ltd (company number 17324839, registered office 127a Westbury Road, Bristol, England, BS9 3AP)
1. Roles
| Role | Who | What they do |
|---|---|---|
| Incident lead | The person named as watching Delta. Until a school joins this is the founder; the role, not a personal address, is written into the records | Decides that an incident exists, runs every step below, keeps the log, and speaks to schools and the ICO |
| Deputy | [Assumption] None yet. Name one before a second school joins | Takes over if the lead cannot be reached for 12 hours |
| School contact | The school's data protection officer, named in the school's data processing agreement (schedule 1) | Receives the notice; the school decides whether to tell the ICO and pupils |
| Sub-processors | Render, Resend, Sentry, Mistral and the transcription provider | Tell us of a breach on their side under their own terms |
2. How an incident is noticed
- Sentry emails the incident lead about every new error (docs/RENDER_SETTINGS_CHECKLIST.md, "Who watches Delta").
- The daily operations email arrives every morning; a missing email is itself a warning. It lists failed safeguarding emails, stuck checks, workers not seen, AI spend and whether retention is stale.
- The uptime monitor alerts when /healthz fails or retention is stale.
- Render emails a failed deploy or a failed scheduled job.
- A school, adviser or pupil reports something. Every report is treated as a possible incident until the lead has ruled it out.
3. The steps, in order
| Step | What | Within |
|---|---|---|
| 1. Contain | Stop the harm first. Options, from least to most disruptive: revoke one adviser's sessions (remove the adviser); switch a school's AI features off on /admin (always allowed, needs no confirmation); rotate a leaked key in Render (ADMIN_TOKEN, OXCAM_SECRET_KEY, which signs every session out, RESEND_API_KEY, MISTRAL_API_KEY, the transcription key, and the database credentials); take the web service offline by suspending it in Render. | At once |
| 2. Record | Open an entry in the breach log (section 5): time noticed, by whom, what is known. Keep adding to it. | Within 1 hour |
| 3. Assess | Which data, which schools, how many places, whether free text (statements, transcripts, notes, comments, messages) is involved, whether it left Delta, whether it held pupils' names (they are encrypted: say whether the key could also have been reached) or only place labels and usernames, and whether it included an adviser's or safeguarding lead's address. Use the audit log and Render's logs; never copy pupil text or a pupil's name into the breach log. | Within 12 hours |
| 4. Tell each affected school | Email the school's named contact: what happened, the data and places involved (by label), what has been done, what the school may need to do, and who to call. A processor must notify the controller without undue delay (UK GDPR Article 33(2)). [Assumption] Delta's own target is within 24 hours of becoming aware, so that the school can meet its 72-hour deadline. | Within 24 hours |
| 5. Tell the ICO, where Delta Research Group is controller | For adviser account data only. If a risk to people is likely, report to the ICO as soon as possible and where feasible within 72 hours; if the risk is high, tell the people affected without undue delay (ico.org.uk/for-organisations/report-a-breach, read 28 September 2026). For pupil data the school decides and reports; Delta supplies what it needs. | Within 72 hours |
| 6. Recover | Fix the cause. If the database must be restored, follow docs/RESTORE_RUNBOOK.md, which locks the service until every erasure has been re-applied. | As needed |
| 7. Review | Within two weeks: what happened, why, what changes, and a ledger entry in the repository. Close the log entry. | Within 14 days |
4. What never goes into a notice or the log
- A pupil's name, statement, transcript or the flagged passage. Place labels, usernames and counts are enough.
- The value of any key, token or password.
Retention schedule
Approved by the company's solicitor, 28 September 2026; party details updated 28 September 2026; the changes of 22 October 2026 published on the founder's own approval and sent to the company's solicitor for review. Prepared 28 September 2026 from the code and docs/DATA_PROCESSING_RECORD.md; [Assumption] marks anything not established from them; and on 22 October 2026 for pupils' names, sign-in, comments, messages, kept drafts and questions made from a pupil's own work.
From the approved document 07, Retention schedule. Left out here: the section "Questions for the solicitor".
Delta, operated by Delta Research Group Ltd (company number 17324839, registered office 127a Westbury Road, Bristol, England, BS9 3AP)
What this is. How long each kind of record is kept, how it ends, and where the rule is enforced. Built from docs/DATA_PROCESSING_RECORD.md sections 2, 5 and 6 and the code they cite. A school sets its own retention period for its pupils' data; everything else is fixed by Delta.
| Record | How long | How it ends | Source |
|---|---|---|---|
| Everything about a pupil's place (their name if the school gave it, profile, results, statements and kept drafts, interviews, test practice, reading log, tasks, the adviser's note, comments, messages, outcomes) | 12 calendar months from the cohort's creation by default; each school sets its own period | Nightly purge at 03:15 UTC through the audited deletion machinery; an adviser can delete a place, a statement or an interview attempt at any time | record s.5; scripts/retention_job.py |
| An unaccepted adviser invitation | 7 days | Purged at expiry | record s.2.1; INVITE_TTL |
| A sign-in link | 15 minutes, single use | Deleted on use or expiry | record s.7 |
| A signed-in session | An adviser's: 2 hours without use, 7 days at most. A pupil's: 1 hour without use, 12 hours at most, or until the browser closes | Deleted when it ends, or at once when revoked or signed out | api/main.py ADVISER_IDLE, PUPIL_IDLE, SESSION_TTL, PUPIL_SESSION_TTL |
| An adviser account | While the school uses Delta | Removal disables it at once; the address stays on the disabled row so that notes keep an accountable author, until the school's account is erased | record s.2.1 |
| The safeguarding lead's name and address | While recorded | Cleared by an administrator, or erased with the school | record s.2.1 |
| The school's safeguarding record | While the school uses Delta | Kept when a pupil's place is deleted, so that every concern Delta raised stays with the school; deleted with the school's account | record s.2.25 |
| The key that unscrambles pupils' names | For as long as Delta holds any name | Held only in the hosting service's settings, never in the database or a backup; changed by moving every name to a new key, and never removed while a name depends on it | record s.2.19 |
| Audit log | No automatic limit in the code today [Gap] | Survives erasure by design and holds identifiers only; a limit (the security document proposes 24 months) is not yet enforced | record s.6; api/store.py AUDIT_KEYS |
| Deletion requests | Kept, by design | Needed to re-apply every erasure after a restore; identifiers only | record s.6 |
| AI usage counters | Kept | Counts and pence per school per day; no text or audio | record s.2.5 |
| Hosting backups | Point-in-time recovery 3 or 7 days (workspace plan); logical exports 7 days | Expire at Render; erasures are re-applied after any restore | render.com/docs/postgresql-backups |
| Founder-held exports (scripts/db_tool.py) | Until a newer one exists | Operational rule: encrypted disk only, deleted when superseded [Assumption: rule not yet written into the runbook] | EVIDENCE_FOR_LEGAL_REVIEW s.6 |
| Copies at Mistral | None retained (zero data retention) | Founder's arrangement confirmed 27 September 2026 | founder's statement |
| Copies at the transcription provider | Seconds | Delta deletes the job before the request returns; AssemblyAI's own time limit can be set to 1 day as a backstop; Speechmatics keeps an undeleted job 7 days | api/transcription.py; providers' pages |
| The admin page's email status list | Last 20 attempts, in memory | Emptied on every restart or deploy; addresses masked | record s.2.5 |
Months are calendar months
Both stores compute a purge date as the cohort's creation time plus N calendar months, with PostgreSQL's end-of-month rule (31 January plus one month is 28 February). "12 months" is twelve real months (record, section 5, corrected 14 August 2026).
Erasure survives a restore
Every executed deletion request is kept so that scripts/replay_deletions.py can re-apply it after any restore, and the web service refuses to serve until it has (docs/RESTORE_RUNBOOK.md). A restore to a point before a deletion was requested cannot know about it; the runbook says to restore to the most recent safe point and re-apply any such deletion by hand from the audit log.
Gaps to close
- The audit log has no automatic limit. Proposal: delete audit rows older than 24 months in the nightly job, keeping deletion requests.
- The rule for founder-held exports (encrypted disk, deleted when a newer one exists) is not yet written into the restore runbook.
- [Assumption] Resend's and Sentry's own retention of emails and error events has not been checked against their current terms.