Retention schedule
Version: draft v1.3, 12 October 2026
UK GDPR requires that personal data is kept no longer than necessary (the storage limitation principle: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/). This schedule sets out how long Benchmark.Pulse keeps each type of data, why, and whether deletion is automatic yet.
Honest status: four deletions run automatically today. Invitation email addresses are deleted as soon as the link is used, 30 days after the link was sent, or when the survey closes, whichever comes first, and surveys close automatically at their closing time. Safeguarding comment text is deleted 30 days after a safeguarding lead reviews it. Prospect contacts we have not heard from are deleted 18 months after they were found, and those who replied 24 months after their last reply. Every other deletion below is planned and will be built before launch. Until then, deletion is done on request. There is no in-product way to delete a survey or close an account: schools ask us by email.
Schedule
| Data | What it contains | Controller | Retention | How it is deleted | Status |
|---|---|---|---|---|---|
| School account data | School name, URN, phase, FSM band (all public data from GIAS), verification status, benchmarking opt-in | Benchmark.Pulse (customer record) | While the school has an account, then [12] months after the last activity or on written request | Deleting the organisation cascades to its members, pending team invitations, surveys, invitations, responses, safeguarding alerts, reports, plans and audit log. Purchases, credit records, invoices and credit notes are deliberately protected: the database refuses to delete a school that still has them, so financial records are kept for 6 years (see below). A school with purchases is therefore closed by deleting its survey data and user accounts and keeping a minimal organisation record until the financial records expire [check: closure procedure not yet written] | Cascade and the financial-record protection are in place; the closure procedure and inactivity trigger are planned |
| Staff user accounts | Email address used to sign in, sign-in records held by Supabase Auth, role in the school account, whether the person is a safeguarding lead | Benchmark.Pulse (customer record) | While the person has access to a school account; deleted within [30] days of removal or account closure | Deleting the sign-in account removes their membership. Records that name them as creator or reviewer (surveys, purchases, invoices, plans, refund requests, safeguarding reviews) are kept but lose the reference | The database side is in place; the deletion process is planned |
| Pending team invitations | The email address and role of a colleague an owner has added who has not yet signed in | Benchmark.Pulse (customer record) | Until the person signs in or the owner cancels the invitation | Deleted automatically when claimed at first sign-in, or when cancelled. An invitation never claimed is kept until the school is deleted | Claim and cancel are in place; deleting unclaimed invitations after a period is planned |
| Invitation email addresses | The staff, or parent and carer, email addresses a school uploads to send personal links | School (Benchmark.Pulse as processor) | Until the link is used, 30 days after it was sent, or the survey closes, whichever comes first | The address is deleted as soon as its link is used, in the same database update that marks it used. A nightly job deletes any address 30 days after its link was sent. Any left are deleted for the whole survey when it closes. Surveys close automatically at their closing time (a job runs every 15 minutes), or earlier if a school user closes them | In place. A survey with no closing time, such as a staff exit survey run all year, still loses each address 30 days after it was sent at the latest |
| Invitation token hashes | SHA-256 hash of each personal link token, whether it was used (a flag only, no date), and the days the link was sent and reminded | School (processor) | Kept with the survey after emails are deleted, so used links still show as used and response-rate figures stay correct | Deleted with the survey | Deleted with the survey (cascade). After emails are deleted these rows no longer identify anyone |
| Survey responses | Answers, free text, the respondent's chosen group, channel, submission date (day only), and a list of any answers withheld for safeguarding | School (processor) | 3 years from the survey closing date by default, then deleted. The school can choose a shorter or longer period (the setting is not yet built) or delete earlier at any time. Three years allows comparison with the previous two annual surveys | Scheduled deletion job | Planned. No automatic deletion and no school-facing retention setting exist yet |
| Staff exit responses | As above | School (processor) | Reports use a rolling 12-month window; raw responses kept for 3 years from submission by default | Scheduled deletion job | Planned |
| Safeguarding alerts | The original, unredacted text of a flagged comment, the question it answered, the words that matched, when it arrived (to the second), who reviewed it, when, and the outcome | School (processor) | Comment text: 30 days after a safeguarding lead reviews the alert. The rest of the record: with the survey, as a record that the alert was handled | A nightly job deletes the comment text 30 days after review. The rest is deleted with the survey | In place for the comment text. Limit: an alert nobody has reviewed keeps its text, and the arrival time is kept after the text is deleted |
| Reports | Computed statistics, redacted free-text answers, AI commentary, the identifiers of comments the school has removed (their text is deleted from the report when removed), when the full report was first opened | School (processor) | Same period as the survey's responses, because reports contain redacted free text | Deleted with the responses | Planned. Proposed: keep a version with no free text for trend comparisons for as long as the account is open [decision needed] |
| Downloaded results and printed reports | The results CSV (suppressed figures and redacted comments, no individual rows) and reports printed or saved as PDF from the browser | School | The school's own retention policy | Not held by Benchmark.Pulse: the CSV is built on request and PDFs are made by the school's browser. Nothing is written to file storage | Not applicable |
| Purchases and invoices | Amount, method, status, purchaser user ID, Stripe session ID; invoices and credit notes, with the bill-to name, email, postal address and purchase order number, issued and held by Benchmark.Pulse, not Stripe; refund requests, with any note the owner added | Benchmark.Pulse | 6 years from the end of the financial year they relate to, to meet HMRC record-keeping rules (https://www.gov.uk/running-a-limited-company/company-and-accounting-records) | Kept when a school is deleted (the database refuses to delete purchases, invoices and credit notes with the school). Deleted by an annual review after 6 years [planned] | Protection in place; the 6-year deletion is planned |
| Credit ledger | Report credits granted and spent (prepaid credits are not currently sold) | Benchmark.Pulse | 6 years, as for purchases | As for purchases | Protection in place; the 6-year deletion is planned |
| Audit log | Who did what and when: account, survey, invitation (counts only), team, safeguarding review, report, download, billing and refund actions, as listed in the security overview. Actor is a user ID | Benchmark.Pulse (security record) and the school (account activity) | [2] years, then deleted [proposal] | Scheduled deletion job. Deleted with the school if the school is deleted | Planned |
| Platform logs | Request logs held by Supabase and Netlify, which include IP addresses. Personal link tokens are not in Netlify's logs, because the token sits after "#" in the link and browsers do not send that part to the web host | Benchmark.Pulse via sub-processors | The supplier's default log retention [check: confirm for each plan] | Supplier controlled | To confirm |
| Backups | Copies of the database | Benchmark.Pulse | [7] days [check: depends on Supabase plan] | Overwritten on the backup cycle. Deleted data remains in backups until the cycle completes and is never restored except to recover from an incident | To confirm |
| Prospect contacts (people at schools we have not yet worked with) | Work email address and role, where and when it was found, Apollo's reference number for the person, enrolments, emails sent and delivery events | Benchmark.Pulse (controller) | 18 months from when the contact was found, if they never replied. 24 months from their last reply, if they did, unless the school has since signed up (the account rules then apply) | Deleted automatically every night, with the enrolments, messages and events for the address unless another contact holds it (crm.delete_unengaged_contacts, crm.delete_replied_contacts). A contact who replied also loses their messages to us, except data protection requests, complaints, safeguarding and legal matters, which are kept as the record of how they were handled and deleted automatically 6 years after they arrived. Apollo reference numbers: 18 months from the lookup, unless a kept contact holds them. The do-not-contact list (crm.suppression) is permanent by design | |
| Sales pipeline notes | The owner's next action, expected value and dated notes for a school or trust, about the school and not a person (the page says so) | Benchmark.Pulse (controller) | For a school that has not signed up, 24 months from when they were last changed; for a school with an account, as for school account data | Deleted automatically every night (crm.delete_old_pipeline_notes) | In place |
| Product usage events | Counts, statuses, products and prices for account and survey activity (for example survey opened, report generated). Never survey content | Benchmark.Pulse | [check: retention period for usage events not yet set] | Not yet deleted. When a school is deleted its events are kept without the link to the school, but may still hold its URN | Planned |
| Benchmarking aggregates (only if the school opted in) | Aggregated, thresholded figures, with no response-level data | Benchmark.Pulse | For as long as they are used as a comparison line | Not personal data once aggregated and thresholded [check with the benchmarking DPIA] | Not yet built |
Notes for school DPOs
- Raw response rows. The school's download contains only suppressed figures and redacted comments. Raw rows are never released, to the school or anyone else, because one row per person would defeat the anonymity rules that respondents were promised.
- Anonymous data and rights requests. Responses cannot be linked to the person who gave them, so an individual's response usually cannot be found, corrected or deleted on request. The privacy notice tells staff this before they answer.
- Data sent for AI summarising is not kept by the AI provider beyond the request, if zero data retention is confirmed with Anthropic [check]. See sub-processors.md.
- Changing the default. If your school's own retention policy for staff survey data is shorter than 3 years, set it in the survey settings [planned] or ask us to delete the survey.