Data Retention Policy

1. Purpose

This policy sets out the categories of personal data processed by Halved Limited (“Halved”) in respect of the Halved platform, and the retention periods that apply to each category or type of personal data, and the procedures by which data is deleted and/or anonymised at the end of each retention period. It supports Halved’s compliance with UK data protection legislation and helps demonstrate how we meet our legal and regulatory obligations.

2. Scope

This policy applies to all personal data collected, stored, or processed by Halved in respect of the Halved platform in connection with the delivery of AI-assisted learning support to UK schools. It covers data held in all storage systems operated on behalf of Halved, including by such of our sub-processors Azure PostgreSQL, MongoDB Atlas, Azure Blob Storage, and Azure Cache for Redis. For more details about the use by any of the aforementioned sub-processor, please see our Privacy Policy.

This Policy does not cover Halved’s retention of its own internal controller records such as human resources and benefits records, legal and accounting records, and sales and marketing records, which are maintained as internal confidential documents.

3. Data Controller and Processor

Where Halved provides the platform to a school, the school is controller for student personal data and school staff platform data processed in the school tenant, and Halved acts as processor under the school DPA. Halved acts as controller only for its own business administration, website enquiries, sales/contract records, support records, security/compliance records, complaints records and legal/accounting records.

4. Retention Schedule

The table below sets out the retention period for each category of personal data.

5. Post-Contract Deletion

Upon termination or expiry of the school’s contract with Halved, all personal data subject to the “Duration of school contract + 90 days” retention period, together with all personal data that any other row of the retention schedule states is in any event deleted on contract end plus 90 days, will be permanently deleted within 90 calendar days of the contract end date. Where a category also carries a shorter cap of its own, such as the 12-month cap on activity records or the 24-month cap on student-authored content, that cap applies during the contract and the contract-end deletion applies in addition to it. The 90-day window allows for:

Resolution of any outstanding data subject access requests or complaints;

Transition assistance to the school or its successor provider;

Final invoicing and contractual close-out.

Deletion will be performed by permanently removing the relevant records from MongoDB Atlas, Azure PostgreSQL, and Azure Blob Storage.

6. Safeguarding Data

Safeguarding flags are retained in accordance with the relevant UK school instructions provided to Halved as set out within the data processing agreement (‘DPA’) agreed between Halved and the school, or otherwise in accordance with the relevant UK school’s documented lawful instructions. The specific retention periods for safeguarding flags are as set out within the relevant DPA or are otherwise aligned to the relevant school’s safeguarding retention policy and/or documented instructions. In the event of any conflict between the retention periods set out within the DPA between Halved and the relevant school, the DPA shall prevail, unless and to the extent that Halved and the school agree otherwise.

Access to safeguarding records after contract termination will be restricted to the designated safeguarding leads of the contracting school and to Halved’s designated safeguarding officer.

7. Deletion Verification

Halved maintains a deletion log recording each erasure carried out in response to an erasure request or a school instruction. The deletion log contains personal data. Each entry holds the identifier of the student whose data was erased, the email address of the member of staff who requested the erasure, the school identifier, the date and time the erasure was recorded and the time it completed, each category of data acted on with what was done to it and how many records were affected, and whether written confirmation was sent. It holds no content from the student’s records. The deletion log is also the only record that links an erased student to their staff access records (section 4), in which the student identifier is replaced on erasure by a reference to that student’s first deletion log entry.

At the end of its retention period the deletion log stops naming the child, and the entry itself is kept. A scheduled job runs nightly and, on each completed entry that has reached the retention period, replaces the identifier of the student and the email address of the member of staff who requested the erasure. The date, the school, the categories acted on, the counts, the completion time and the confirmation flag are all kept, because the entry is the record that the erasure was carried out and a school must still be able to show that erasures are performed. An entry for an erasure that never completed is not touched, because the identifier in it is the only record of which student a school asked to have erased on a run that did not finish; such an entry is reported for human attention instead. The retention period in operation is 3 years, measured from the time the erasure completed.

Deletions carried out automatically by a scheduled retention purge, such as the 12-month cap on activity records, are not recorded in the deletion log. That log is keyed to one student and to the person who requested the deletion, and a scheduled purge has neither. Each purge run that ends writes one record to a separate purge log, which is retained for 3 years. The record holds the date and time of the run, the table it acted on, the retention window applied, the cut-off date resolved for that run, the outcome of the run, the reason where a run ended without deleting, the total number of records deleted, the number of batches used, and a census by school of the records that were in scope. The purge log contains no personal data: it holds school identifiers, counts and timestamps only, and carries no student identifier.

What the per-school figures are, stated precisely, because the distinction matters to a school checking its own record. The census is a count of records per school taken immediately before the deletion, which is the only point at which those records can be counted. It therefore records what was in scope for that run rather than confirming what was removed. The number of records deleted is held as a single total for the run and is not broken down by school. On a run that completes normally the two agree, and a run that does not complete normally is recorded as such with its reason. Each purge run also writes a line to the application logs as an operational signal, carrying the same figures on the same basis, and that line is held for 30 days under the Application logs row of section 4.

Where a school or data subject requests confirmation of deletion, Halved will provide written confirmation within 30 days following the date of deletion.

8. Sub-processor Retention and Deletion

All sub-processors used by Halved are bound by the Microsoft Customer Agreement and Microsoft Data Protection Addendum, which include obligations to delete personal data in accordance with the controller’s documented instructions. MongoDB Atlas is bound by MongoDB’s Data Processing Agreement.

Halved will issue written deletion instructions to relevant sub-processors within 30 days of a contract end date. Sub-processors are required to confirm deletion within their own documented SLAs.

9. Backup Retention

Automated backups are retained as follows:

MongoDB Atlas: Point-in-time restore enabled with a 7-day restore window. Backups are stored within Azure UK South.

Azure PostgreSQL: Automated backups are retained for 30 days with geo-redundant storage within the UK.

Azure Blob Storage: No automatic backup; data durability provided by Azure ZRS (zone-redundant storage) within UK South.

No backup snapshot will be retained beyond the applicable retention period for the data category it contains.

10. Data Subject Rights and Early Deletion

For further information about the rights of data subjects, please see our Privacy Policy.

In respect of any requests received by Halved from a data subject to exercise their right to erasure (including when such request is received from a student, a parent and/or legal guardian) Halved will comply with all such requests and delete the specific personal data without undue delay and in any event within one month of receipt of the request. This period may be extended by up to two further months where the request is complex or numerous, in which case Halved will inform the data subject within one month of receipt and explain the reasons.

Two records are kept on erasure with the student’s identifier removed from them, and the reasons are stated here because a school will ask. The first is the staff access record (section 4), which shows which member of staff opened a student’s data, on which surface and on which day. Erasure is requested by school staff. If erasure deleted this record, a member of staff who had read a child’s conversations could remove the record that they did so by asking for that child to be erased, and the record would not survive the one action it most needs to survive. So on erasure the student identifier in each of these records is replaced with a reference to the erasure, being the identifier of that student’s first deletion log entry, and the staff account, school, reason, day and count are kept. A record written after the erasure has completed carries the same reference rather than the student identifier. The erasure locks these records against new writes for the moment before it completes, so a record written at the same time cannot be left carrying the student identifier. The system account that performs erasures can amend these records and cannot delete them. The reference can be linked back to the student only through the deletion log (section 7), and once that entry stops naming the student at the end of its retention period the record of the reading cannot be linked back to the child at all, while the record of who read and when survives. The written confirmation of an erasure names this record and states that it was kept.

The second is the record of a student list import. When a school creates student accounts by importing a list, Halved keeps a record of the list and of what happened to each line of it, so that the school can see which accounts were created and which were not. That record also names the school’s other students on the same list, so erasure does not delete it. Instead, on erasure, the student’s line in each import made by any school the student has been at is replaced with the same reference to the erasure, and the rest of the list is kept as it was. A list that has been checked but not yet confirmed is treated differently: the student’s line is removed from it, so that confirming the list later cannot create the erased student’s account again. Import records are short lived in any case. A list that is checked and never confirmed is deleted one day after it was checked, and every import record is deleted 30 days after it was last changed. The written confirmation of an erasure names this record and states that it was kept.

A school’s intake, described in section 4, names students too, but only until Halved imports it, when it is deleted. It can name a student whose data is being erased only if an import created that student’s account and stopped before it finished. In that case the student’s lines are removed from the intake, so that finishing the import cannot create the erased student’s account again. While that intake is being imported, or where a line carries the student’s email address under a school student identifier that does not confirm it is them, the erasure is not completed: the student’s account is kept so that the erasure can be run again once the import has stopped or the intake has been corrected or deleted.

A student may delete their own uploaded content and free-text notes at any time using the in-product delete control, and deletion is actioned immediately. Students can also delete their own working ink at any time before it is submitted, on a lesson slide and in the jotter alike. Ink a student draws on their own uploaded work is never submitted to a teacher, so the student can erase it at any time, and deleting the upload deletes its ink. The exception is an upload withheld by safety screening, which is kept with anything drawn on it when the student deletes it. Once ink is submitted to the teacher as part of a piece of work, it forms part of the assignment record and is retained for marking and review; it cannot be deleted by the student. This applies to a page of jotter working out in the same way as to a marked-up lesson slide. Teacher feedback annotations are authored by staff and retained with the assignment record. Ink flagged by safeguarding screening is retained for staff review.

A profile photograph is different. A student or a member of staff can replace their profile photograph at any time from their profile page, but there is no in-product control to remove one without putting another in its place. Removal is handled as an erasure request to dataprivacy@halved.io or through the school, and is actioned within the periods set out above.

Requests for the erasure of any special category personal data retained by Halved or any of its sub-processors will be complied with without delay (and in any event, within one month of receipt of any request).

There may be circumstances where Halved has a legal obligation to retain information (excluding special category information) which will result in Halved having to refuse to comply with an erasure request. In such circumstances, Halved will inform the data subject without delay and shall set out the reasons for such refusal. The circumstances that may be relied upon for such refusal include (but are not limited to) compliance with applicable laws and/or regulations, or for establishing, exercising or defending legal claims.

The staff access record and the import record kept on erasure, described above, are not refusals of this kind. Wherever such a record exists it is kept in the form set out above, and the confirmation of every erasure names it.

11. Policy Review

This policy is reviewed annually (or upon a material change to the Halved platform’s data processing activities, applicable law, or regulatory guidance). The next scheduled annual review is May 2027.

12. Document Control