To review a DPIA for SEND technology, trace the real processing from purpose to deletion. Identify each data category, system, organisation and user; test necessity, access, retention, AI use and risks to pupils; then record mitigations, residual risk, the DPO's advice, an accountable decision and a review trigger. A supplier questionnaire helps. It cannot complete the school's assessment or approve the processing.
This guide is for SENCos, school leaders, trust leaders and data protection leads in England. It is accurate on 15 August 2026. It supports an organisation's own data protection process and isn't legal advice.
Begin by defining the proposed use
The UK GDPR requires a DPIA before processing that is likely to create a high risk to people's rights and freedoms. The Information Commissioner's Office also recommends considering one for any major project involving personal data. Children, special-category information, dataset matching, profiling and innovative technology all make careful screening important.
A DPIA is a process, not a certificate with a reassuring date in the footer. It should shape the design before processing begins and stay under review when the purpose, scope, context or technology changes. Record who owns each condition and the evidence that will show whether it has been implemented before staff or pupils use the tool.
The Department for Education's school EdTech guidance was updated on 9 July 2026. It tells schools to involve the DPO early, require suppliers to explain the full data flow and revisit the DPIA when processing changes. That matters during summer contract reviews, when a renewal can otherwise acquire a new date while the underlying data route quietly acquires three new destinations.
Follow one made-up SEND tool from question to decision
The example below combines common procurement questions. It does not describe a pupil, school, customer or supplier. A trust is considering a reading-support platform for several schools. Staff will assign activities and review progress for pupils receiving additional support.
The first proposal says the platform needs names, classes, SEND status, assessment scores, attendance, free-text notes and parent contact details. The school's first DPIA question is: what decision or task requires each field? Names, class and selected assessment evidence may support assignment and review. The supplier must explain why the wider SEND label, attendance, parent details or unrestricted notes are necessary. Available data is not automatically proportionate data.
Draw the whole data flow
The supplier explains that a school administrator uploads a roster, pupils use the platform, teachers add comments and a cloud hosting company stores the records. Support staff at the supplier can access selected accounts. Nightly backups sit in a second service, and product analytics are sent elsewhere.
The DPIA should name those flows, storage locations and organisations. It should distinguish the school or trust's controller decisions from processor activity under instruction and any purpose for which the supplier acts independently. If analytics or product development use pupil data for the supplier's own purpose, calling everything “our processor” does not settle the role.
Test access against the job to be done
The trust narrows the import and separates roles. Teachers see assigned pupils. The SENCo can review support evidence for pupils within authorised scope. Technical support access is time-limited, logged and subject to an approved support route. Joiners, movers and leavers are part of the design, along with strong authentication and a way to review access.
A role name is not evidence that every permission beneath it is necessary. The reviewer should test what a user can actually open, export, change and share, including across schools in a trust. Record missing evidence as missing. Do not translate “configurable” into “configured”.
Make retention and exit testable
“Retained for the life of the contract” leaves several practical questions unanswered. The school records a period or event for each data class, who can trigger deletion, what happens to exports, and how backups, logs and caches age out. The contract end needs a return format, deletion timescale and confirmation route.
This is separate from choosing retention periods for the school's underlying SEND records. Use the school's approved schedule and professional advice for that decision. The separate SEND record retention and transfer guide covers the record-level workflow.
Open the AI box before approving it
The supplier then discloses an optional AI summary. The DPIA records whether pupil input or output reaches another provider, where it is processed, how long it is kept, whether it is used for model training, how inaccurate or biased output is handled, and which staff supervise use. The school also checks whether profiling or automated decisions affect access to support.
DfE's generative AI product safety standards were updated on 19 January 2026. They expect clear privacy information, lifecycle DPIAs, proportionate controller and processor responsibilities, and no commercial reuse of personal data for model training without an appropriate lawful basis. An AI label is therefore the start of a data-flow question, not an explanation.
Record the decision in seven lines
The trust's final record states the purpose, minimum data, full flow, controller and processor roles, authorised access, retention and exit route, and any AI processing. It then links each risk to a mitigation, owner, evidence and review trigger. The DPO's advice and any disagreement remain visible. The accountable leader records approve, approve with conditions, pause or do not proceed.
The DPIA does not need to claim that all risk has disappeared. It should show whether remaining risk is justified and controlled. If a high risk cannot be mitigated, the ICO says the controller must consult it before processing starts.
The ICO's Edtech examined statement of 24 June 2026 gives this review fresh weight. Its audits found recurring gaps in controller and processor roles, contracts, data-flow maps, data minimisation, storage limitation, privacy information and DPIAs. A school should test the evidence behind each answer, not count the number of documents in the supplier's folder.
Where Student Radar fits
Student Radar publishes a DPIA Supplier Information and School Template alongside its data processing, sub-processor, retention and AI governance documents. These provide supplier facts and a structure for review. The school or trust remains responsible for its own purpose, lawful basis, necessity, risk assessment, DPO advice and decision.
Where enabled, Account Connections supports authorised staff account operations for pupil and parent connectivity. It does not approve permissions or complete a DPIA. Use the pupil-data checks to verify source quality, and review the current security evidence before a procurement decision. To discuss the school's intended workflow, request a SEND-focused walkthrough.
Sources and further reading
- Information Commissioner's Office, Data protection impact assessments, current guidance accessed 15 August 2026.
- Department for Education, Data protection in schools: procuring educational technology, guidance published 3 February 2023 and updated 9 July 2026.
- Department for Education, Generative artificial intelligence and data protection in schools, guidance published 3 February 2023 and updated 9 July 2026.
- Department for Education, Generative AI: product safety standards, published 22 January 2025 and updated 19 January 2026; applies to England.
- Information Commissioner's Office, ICO statement on Edtech examined, published 24 June 2026.