How to do a DPIA for edtech in education: template and steps

Learner support software holds some of the most sensitive information a college or training provider keeps: diagnoses, disabilities, mental health, EHC plans, care history, and notes from conversations with learners at difficult moments. Before you move that information into a new system, you need to understand the risks to learners and how you will reduce them. That is what a data protection impact assessment (DPIA) is for.

Learner support software is edtech that handles special category data, so a DPIA for edtech of this kind deserves care. This guide explains when a DPIA is needed, who owns it, what to cover for learner support software specifically, and what to ask suppliers. It is written for DPOs, inclusion leads and IT teams working together. It is not legal advice. The ICO notes that its DPIA guidance is under review following the Data (Use and Access) Act 2025, so check the current version.

What is a DPIA?

A DPIA is a process for systematically identifying and minimising the data protection risks of a project. Article 35 of the UK GDPR requires one where processing is likely to result in a high risk to people’s rights and freedoms. The ICO says it should begin early, before processing starts, so it can shape the design. It is a living document: review it when the processing or the context changes.

Is there a DPIA template for education?

There is no mandatory DPIA template for education. The ICO publishes an optional one, and many colleges and training providers use their own. Whichever DPIA template you use, the content matters more than the form: it should follow the seven steps below, describe the learner support data and flows specifically, and record your DPO’s advice and the decisions you took. A generic edtech template that only asks yes or no questions will not be enough for special category data. Our DPIA screening checklist can help you decide whether you need a full DPIA and what to gather first.

Do we need a DPIA for learner support software?

Almost certainly. The ICO guidance explains that, in most cases, a combination of two of the European high-risk criteria indicates a DPIA is needed, though this is not a strict rule. Learner support software usually meets several:

The ICO’s own list of processing likely to be high risk includes innovative technology such as AI, and decisions about access to a service that involve special category data. Processing large volumes of special category data is also one of the cases where Article 35 itself requires a DPIA.

Even if you conclude a DPIA is not strictly required, record why. Most DPOs will choose to do one anyway. Our DPIA screening checklist can help you decide.

Who owns the DPIA?

You do, as the controller. A college or training provider using learner support software decides why and how learner data is processed, so it is the controller. The supplier is usually a processor, acting on your instructions.

The ICO is clear on the division of labour:

• You can use the supplier’s work. For new technology, you may be able to use a DPIA prepared by the product developer, and your processor contract should require the processor to help you.
• You remain responsible. You can outsource a DPIA, but the ICO says you remain responsible for it.
• Your DPO must advise. The ICO says that if you have a DPO you must seek their advice, record it, and record your reasons if you do not follow it.

How do you carry out a DPIA for edtech, step by step?

Follow the ICO’s seven steps. Here is what each looks like for learner support software.

1. Identify the need

Record the screening result and the reasons. Name the project owner, usually the inclusion lead, and the DPO.

2. Describe the processing

Describe the nature, scope, context and purpose.

• Data: learner identity details, needs, disability and health information, support plans, delivery records, reviews, uploaded documents, safeguarding flags if any, and staff and employer contact details.
• Sources: learners themselves, staff, MIS imports, schools, local authorities, specialist assessors.
• People with access: inclusion team, tutors and assessors, learners, apprenticeship employer contacts, admins, supplier support staff.
• Locations: where each part of the service stores and processes data, including sign-in, hosting, file storage and any AI provider.
• Retention: how long each type of record is kept and how it is deleted.
• Purpose: to identify, agree, deliver and review support for learners, and to evidence it.

A data flow diagram helps more than paragraphs. The ICO’s 2026 audits of edtech providers found incomplete data flow mapping was a common gap.

3. Consider consultation

The ICO says you should seek and document the views of individuals or their representatives unless there is a good reason not to. Ask a learner panel how they feel about what is recorded, who sees it and what employers see. Their answers often change the design.

4. Assess necessity and proportionality

Set out your lawful basis under Article 6 and your condition under Article 9 for special category data, with any Schedule 1 condition of the Data Protection Act 2018 and an appropriate policy document where needed. Then ask: do we need every field? Could we achieve the purpose with less? Is retention justified? See our guide to special category data in education.

5. Identify and assess risks

Focus on harm to learners, not risk to the organisation. Assess likelihood and severity.

6. Identify measures to reduce the risks

For each risk, record the measure and the remaining risk.

7. Sign off and record outcomes

Record who approved the residual risks, the DPO’s advice, and the review date. If a high risk remains that you cannot reduce, you must consult the ICO before you go ahead.

What risks should a learner support DPIA cover?

These are the risks most specific to learner support. Adapt them to your context.

The ICO’s edtech audit findings are a useful checklist. They included providers not recognising when they acted as controllers for their own purposes, such as product development, analytics or AI training; contracts lacking required processing terms; weak data minimisation and retention; outdated privacy information; and gaps in DPIAs. AI features switched on by default without safeguards also featured. Ask every supplier how they address each point.

What should you ask suppliers?

Use these questions in procurement. Ask for written answers you can quote in the DPIA.

1. Which parts of the service process our data, and where? Name each subprocessor and location.
2. Do you ever act as a controller of our learners’ data, for example for analytics, product improvement or AI training?
3. How are permissions enforced? Can a user reach data through the API that the interface hides?
4. What can an employer contact see?
5. How are uploaded files stored, scanned and released?
6. Which AI features exist, are they optional, and are they off by default? Which provider processes the data, and is it used for training?
7. How do retention and deletion work, including backups?
8. What security assurance can you evidence today, and what is planned?
9. How do you support subject access requests, corrections and erasure?
10. Will you share your own DPIA or data protection documentation?

Be wary of answers that promise compliance in general terms. Good suppliers say exactly what exists and what is still planned. Our guide to choosing learner support software covers wider procurement questions.

How often should the DPIA be reviewed?

Whenever something material changes, and on a regular cycle. Triggers include a new feature such as AI, a new subprocessor, a change in processing location, a new user group such as employers, a security incident, or new ICO guidance. The ICO has said it is discussing a possible edtech code, so watch for developments that affect education technology.

How does Inclusion Studio support this process?

Inclusion Studio is learner support software being built for FE colleges and apprenticeship providers in England. It is pre-pilot: a prototype uses fictional learners and the production application uses synthetic data only, so no real learner data is processed yet. Its primary database is hosted in London; some supporting services may process data elsewhere, and each will be documented and assessed before real learner data is used. AI is optional, human-reviewed and not trained on case records, and Gemini on Google Cloud Vertex AI is the selected AI provider. It has been tested with synthetic data only, the location for real learner data is not decided, and no real learner data has been sent to any AI provider. We aim to give pilot partners the information a DPIA needs, through our data protection, where data is processed and subprocessors pages. Your DPIA, and the decision to proceed, remain yours.