Data protection impact assessment: staff surveys with Benchmark.Pulse
Template version: draft v1.3, 12 October 2026, pre-filled by Benchmark.Pulse For: [School name], [URN] Completed by: [name, role] DPO: [name] Date: [date]
This template follows the structure of the ICO's DPIA guidance (https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/). Benchmark.Pulse has filled in what it knows about its own product. The school must complete every [placeholder], challenge anything it disagrees with, and own the final assessment. Statements marked [check] are Benchmark.Pulse's understanding and are still being confirmed.
Step 1: Why a DPIA is needed
This template is written for staff surveys. The school plans to run [staff wellbeing and workload / staff exit / other staff] surveys with Benchmark.Pulse, starting [date].
A DPIA is recommended because the processing:
- concerns employees, where the power imbalance with the employer means staff may not feel free to say no or to speak openly;
- may capture special category data in free text (for example about health, stress or wellbeing), which staff choose to write;
- uses AI to summarise free text, which the ICO treats as innovative technology; and
- relies on anonymity that staff need to trust before they will answer honestly.
The DfE expects schools to assess new technology that processes personal data (Data protection in schools: https://www.gov.uk/guidance/data-protection-in-schools).
Step 2: Description of the processing
Nature
- A school user with the owner or editor role creates a survey from a fixed set of questions, and may add up to 20 questions from the question bank and up to 5 custom questions.
- The school uploads staff email addresses (up to 3,000 per survey) and/or enables an open link or QR code.
- Benchmark.Pulse emails each person a single-use personal link through its email provider (Resend). The link goes only to that person; the school never sees it. Only a SHA-256 hash of each link is stored. A reminder issues a fresh link and the old one stops working. The school must state how many people it will ask before the survey opens, and the invitation list is capped at 1.2 times that number.
- Staff answer on a web page with no sign-in. The response is stored with no name, email, link token, user ID, IP address or device information, and with the date only (no time). It also records whether it came through a personal link or the open link.
- While the survey is open, the school sees only the number of responses and the number of links used, not who responded.
- 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. Surveys close automatically at their closing time (checked every 15 minutes), or earlier if a school user closes them.
- The school sees a free headline summary. If at least the minimum number have responded, it may buy the full report.
- The report is computed by fixed statistical code. AI commentary is a per-survey setting, on by default except for pupil surveys, where it is off by default. The school can change it until the report is written. If it is on, when the full report is unlocked, free text is automatically redacted and then sent to Anthropic's Claude model, which groups comments into themes and writes commentary. Nothing is sent to Anthropic when the setting is off or before a full report is unlocked, and comments flagged for safeguarding are never sent. Every figure in the commentary is checked against the computed statistics.
- Leaders can remove any comment or quote. Removal deletes it from the stored report and the results download and cannot be undone. The report says how many were removed. The results download is free once a survey closes. It holds the suppressed figures and every comment after automatic redaction only; the AI's extra redaction applies only to quotes in the paid report. Removed comments are left out. The school cannot download one row per person.
Scope
| Item | Detail |
|---|---|
| Data subjects | Staff invited to respond: about [number] people. School users of Benchmark.Pulse: [number]. People mentioned in free text |
| Personal data | Staff email addresses (until the link is used, 30 days after it was sent, or the survey closes); anonymous answers; free text; self-selected role group; day of submission; whether the answer came by personal link or open link |
| Special category data | Not asked for. May appear in free text |
| Frequency | [Termly / annually / exit survey all year] |
| Retention | Emails: deleted as soon as the link is used, 30 days after the link was sent, or when the survey closes, whichever comes first. Responses and reports: 3 years from close by default, then deleted (automatic deletion is planned, not yet built). See retention-schedule.md |
| Geography | Database in the UK (London) [check]. AI processing location to be confirmed. See sub-processors.md |
Context
- The relationship is employer and employee. [Describe any current staff relations context: workload concerns, restructuring, union activity, recent leadership change.]
- Staff would reasonably expect an anonymous staff survey to be anonymous from the school. They may not expect AI to read their comments, so the privacy notice says so plainly.
- Small schools and small teams raise re-identification risk. The school has about [number] staff, and its largest role group is about [number].
Purpose
To understand staff views on [workload, wellbeing, leadership, development / reasons for leaving] so the school can act on them and meet its duties as an employer.
Step 3: Consultation
| Who | How | When | Outcome |
|---|---|---|---|
| DPO | Review of this DPIA | [date] | [ ] |
| Staff, or staff representatives and recognised unions | Share the privacy notice and anonymity explanation before launch | [date] | [ ] |
| Governors or trust | [Report to committee] | [date] | [ ] |
| Benchmark.Pulse | Pre-filled this template; answers questions | [date] | [ ] |
Step 4: Necessity and proportionality
| Question | Answer |
|---|---|
| Lawful basis (Article 6) | [School to decide.] State-funded schools usually rely on public task (Article 6(1)(e)), as gathering staff views supports their functions as an employer and their duty to manage workload and wellbeing. Independent schools may rely on legitimate interests (Article 6(1)(f)) with a balancing test. Consent is not recommended as the basis, because of the employment relationship |
| Special category condition (Article 9) | [School to decide.] Not sought, but free text may contain health data. A likely condition is Article 9(2)(b) (employment) with Schedule 1, Part 1, paragraph 1 of the Data Protection Act 2018, which requires an appropriate policy document |
| Is it necessary? | Anonymous surveys are the established way to hear honest staff views at scale. Named surveys or interviews would gather less honest data and more identifiable data |
| Data minimisation | Emails are used only to send links. They are deleted as soon as the link is used, 30 days after the link was sent, or when the survey closes, whichever comes first. Responses store no identifier. Role is the only group question. Time of submission is not stored, and the day a link was used is not recorded. The download holds aggregates, not individual rows |
| Accuracy | Single-use links prevent duplicate answers. The open link cannot prevent duplicates. If responses exceed the number of people asked, role results are withheld and the report says so |
| Retention | Defaults to 3 years for trend comparison. There is no in-product way to delete a survey; the school can ask Benchmark.Pulse by email to delete one earlier |
| Transparency | Privacy notice for staff (privacy-notice-staff.md), issued before the survey opens |
| Rights | Staff can decline to take part. Most rights cannot apply to an individual response because it cannot be traced back to them; the notice explains this |
| Processor | Article 28 agreement in place (data-processing-agreement.md). Sub-processors published (sub-processors.md) |
| International transfers | AI processing may happen outside the UK [check]. Transfer mechanism to be confirmed before launch |
Step 5: Risks
Likelihood: remote, possible, probable. Severity: minimal, significant, severe.
| # | Risk to individuals | Likelihood | Severity | Overall |
|---|---|---|---|---|
| R1 | A respondent is identified from results for a small group (for example the only senior leader who answered in a certain way), including where someone adds responses to push a small group over the threshold | Possible | Significant | Medium |
| R2 | Free text identifies the writer (writing style, a unique role, a specific incident) or names a colleague, and is seen by leaders | Probable | Significant | High |
| R3 | Benchmark.Pulse staff or an attacker with database access link an invitation (email) to a response while the survey is open | Remote | Severe | Medium |
| R4 | The school learns who has or has not responded, or a school user answers with someone else's link | Remote | Significant | Low |
| R5 | The results download lets a leader identify someone | Remote | Significant | Low |
| R6 | Free text sent to the AI provider is retained, used for training, or accessed abroad | Remote | Significant | Low to medium |
| R7 | The AI commentary misstates a figure or describes an individual, leading to unfair conclusions | Remote | Significant | Low |
| R8 | A school account is taken over, exposing reports and the results download | Possible | Significant | Medium |
| R9 | A security breach at Benchmark.Pulse or a supplier exposes emails or responses | Remote | Significant | Low to medium |
| R10 | Data is kept longer than needed | Probable (until automatic deletion is built) | Minimal to significant | Medium |
| R11 | Staff feel pressured to respond, or fear that leaders are watching who responds | Possible | Significant | Medium |
| R12 | Special category data in free text is processed without the school planning for it | Probable | Significant | Medium |
Step 6: Measures to reduce risk
| # | Measures | Effect | Residual risk |
|---|---|---|---|
| R1 | Suppression. No results at all below the minimum response count: 10 for every staff survey except the staff exit survey, which uses 5 (it combines leavers over a rolling 12 months). The same applies to each question: a question answered by fewer than the minimum shows no figures. No result for any role group under 10, applied per question using the number who answered it. Secondary suppression: while the hidden groups together hold fewer than 10 people, the next smallest visible group is hidden too, so hidden groups cannot be worked out by subtracting the visible ones from the total. Small cells: any answer option chosen by fewer than 5 people is shown as "fewer than 5", with secondary suppression for scale and single-choice questions, whose options add up to the total. A role group's figures are hidden when everyone in it gave the same answer, and its positive share is hidden when fewer than 5 people are on either side of it. Custom questions are limited to scale, single choice with 2 to 6 options, or free text, so a school cannot build a fine-grained demographic question. Thresholds are fixed per application and cannot be lowered by the school. Padding: the school must state how many people it will ask before opening a survey; invitation lists are capped at 1.2 times that number; if responses exceed it, all role results are withheld and the report says why. Limit: anyone with the open link can submit, and a determined school leader could still add responses (for example by overstating the headcount and using the open link) to try to isolate a small group. These measures reduce that risk; they do not remove it. [School: if you have fewer than about 20 staff in total, discuss whether role breakdowns will ever show; give the open link only to the intended group.] | Reduced | Low to medium |
| R2 | Free text hidden below the free-text minimum (10 for every staff survey except staff exit, which uses 5), and comments on any single question withheld unless at least 5 people commented on it, because a lone comment is easy to attribute. Automatic redaction of names with titles (Mr, Mrs, Dr and so on), email addresses, phone numbers, links and initials used as names, before display, download or AI processing. A second redaction pass by the AI in the paid report, which flags responses that still identify a person and replaces the detail with "[removed]". Comments are shown in a scrambled order, not submission order, and are never shown alongside the same person's other answers. Leader review: owners and editors can remove any comment or quote before sharing the report. The privacy notice warns staff that what they write may identify them. First names and class codes are also removed, using a list of about 6,400 first names from ONS birth registrations. Leader removal of a comment deletes it from the stored report and the results download, cannot be undone, is logged, and the report says how many comments were removed. The results download holds every comment after automatic redaction only: the AI's extra redaction applies only to quotes in the paid report, so a comment the AI judged identifying stays in the download unless a leader removes it. Safeguarding: every survey checks comments for safeguarding concerns and cannot open without a named safeguarding lead. A flagged comment's original text is shown only to named safeguarding leads and kept out of reports, AI and downloads. Its text is deleted 30 days after review, and the alert records when it arrived (see safeguarding-protocol.md). Limit: the name list misses rare names and nicknames, and removal is optional, not a required step before sharing | Reduced | Medium. Redaction is pattern-based and cannot catch every identifying detail. The school should brief readers not to speculate about authorship |
| R3 | Blind tokens: the invitations table has no link to the responses table. A response stores no token, user ID, IP address, device information or time, only the day. An invitation keeps only a used flag, not the day it was used. Neither table can be read by school users or the public; only Benchmark.Pulse's server functions can read them. 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. Known limitation: marking a link as used and storing the response happen in the same database transaction, and the email address is deleted in that same step, so no stored record links a response to a person. Someone with direct database access watching transactions as they happen could still in principle connect the two. Benchmark.Pulse does not attempt this and is contractually barred from it (DPA clause 6.9(c)). The personal link token sits after "#" in the link, so it is never sent to the web host and does not appear in its logs. Supabase request logs record the IP address of requests, including survey submissions, for a limited period [check: log retention for our plan] | Reduced | Low |
| R4 | School users never see the invitation list after upload, only counts. Personal links are only ever emailed by Benchmark.Pulse direct to the person; they are never shown to a school user (the only exception is a developer's own machine, where no real email is sent). Without an email provider the service refuses to send, and a school account must be verified before email is sent on its behalf. Reminders go automatically only to people who have not responded, so the school does not choose who is chased | Reduced | Low |
| R5 | The download holds the same suppressed figures as the report, not one row per person: counts and percentages per question and per visible role group, with small cells shown as "fewer than 5". Comments are redacted, in random order, and listed separately from all other answers, so a comment cannot be matched to a role or to other answers. It is available only after the survey closes, only to owners and editors, and only if the minimum response count was reached. Each download is recorded in the audit log. Raw response rows are never released, to the school or anyone else | Reduced | Low |
| R6 | Only redacted free text and computed statistics are sent; no emails, names of respondents, tokens or IP addresses. Benchmark.Pulse does not use responses for training and requires the same of its AI provider. Zero data retention with Anthropic, the processing region and the transfer mechanism are to be confirmed before launch. See ai-statement.md and sub-processors.md | Reduced | Low once confirmed |
| R7 | All statistics are computed by fixed code, not by AI. The AI is told to use only the given figures. A validator rejects any commentary that contains a percentage or count not in the statistics (whole numbers up to 5 and years are allowed as ordinary words), and the AI gets one retry. If the commentary still fails, or the AI declines or errors, the report ships with the statistics and redacted comments only, never with unchecked AI text. Theme counts and quotes are assigned by our code from the AI's grouping, not written by the AI. The AI is told never to describe or speculate about an individual | Reduced | Low |
| R8 | Row Level Security limits each user to their own school. Roles separate owners, editors, viewers and DSLs. Sign-in is by a one-time code sent by email; Microsoft and Google sign-in are planned. MFA is not yet enforced (planned). [School: remove leavers' accounts promptly; give owner and editor roles only to those who need them.] | Partly reduced | Medium until MFA is enforced |
| R9 | UK hosting, encryption in transit and at rest [check], no direct access to responses, hashed tokens, invitation emails deleted when the link is used, after 30 days or at close, audit log, breach notice to the school within 24 hours. Cyber Essentials planned before launch. See security-overview.md | Reduced | Low |
| R10 | 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, so a survey with no closing time, such as a staff exit survey run all year, no longer keeps them indefinitely. Surveys close automatically at their closing time (checked every 15 minutes). There is no in-product way to delete a survey; schools ask us by email. Automatic deletion of responses after the retention period is planned. | Partly reduced | Medium until built |
| R11 | Wording to staff stresses that the survey is voluntary and anonymous. The school sees counts, not names. [School: do not chase individuals; do not announce response counts by team if teams are small; consider a staff briefing on how anonymity works.] | Reduced | Low to medium (cultural, depends on the school) |
| R12 | The privacy notice asks staff not to include health details about themselves or others unless they want to. Redaction and leader review apply. [School: record the Article 9 condition and appropriate policy document.] | Reduced | Medium |
Step 7: Sign-off
| Item | Name and date | Notes |
|---|---|---|
| Measures approved by | [ ] | Integrate actions into the survey plan |
| Residual risks approved by | [ ] | If any high residual risk remains, consult the ICO before going ahead (Article 36) |
| DPO advice provided | [ ] | DPO to advise on compliance, whether the measures are enough, and whether the processing can proceed |
| Summary of DPO advice | [ ] | |
| DPO advice accepted or overruled by | [ ] | If overruled, give reasons |
| Consultation responses reviewed by | [ ] | If the school departs from staff views, give reasons |
| This DPIA will be kept under review by | [ ] | Review before each new survey type, and at least annually |
Actions for the school
- Confirm the lawful basis and the Article 9 condition.
- Sign the data processing agreement.
- Issue the staff privacy notice before the survey opens.
- Decide who holds owner and editor roles.
- Set a closing date on every survey, so it closes automatically.
- Brief anyone who reads free text not to speculate about authorship.
- Decide on benchmarking opt-in (off by default).
Actions for Benchmark.Pulse before launch
- Decide whether to separate marking a link as used from storing the response (R3).
- Enforce MFA for school accounts.
- Build automatic deletion and a retention setting.
- Confirm Anthropic zero data retention, region and transfer mechanism.
- Obtain Cyber Essentials.