UK GDPR edtech checklist for schools and trusts: 10 questions before you sign up a typing platform
Before a school or trust puts pupil data into any edtech platform, including a typing programme, it should confirm who is the controller and who is the processor, sign a written contract that meets Article 28 of the UK GDPR, decide whether a data protection impact assessment (DPIA) is needed, and check what data is collected, where it is stored, who the sub-processors are, how long data is kept and how it is secured. Those ten questions, drawn from guidance by the Information Commissioner's Office (ICO) and the Department for Education (DfE), can be put to any provider and recorded in your procurement file.
This is general information for data protection officers, MAT IT leads and computing leads. It is not legal advice; your DPO and your own policies decide what your school or trust needs. The Data (Use and Access) Act 2025, which received Royal Assent in June 2025 and is being brought into force in stages, amended parts of the UK GDPR, so check the ICO's current guidance on any point that matters to your decision.
Who is the controller and who is the processor?
When a school uses an online service to process pupil data for its own educational purposes, the school is normally the controller, because it decides why and how the data is used, and the provider is a processor acting on the school's instructions. In a multi-academy trust, the trust is usually the controller for its academies. Ask the provider to state its role in writing, and check whether that role changes if pupils or families also use the service directly, for example through a home account, because a provider that runs its own consumer service is usually a controller for that part.
What must the Article 28 contract include?
A controller must have a written contract with any processor. The ICO's guidance on what needs to be included in the contract lists the essentials: the subject matter, duration, nature and purpose of the processing, the types of personal data and categories of data subject, and the controller's obligations and rights. The processor must act only on documented instructions, keep data confidential, apply appropriate security, use sub-processors only with authorisation, help with rights requests and DPIAs, and delete or return the data at the end.
In practice, ask whether the provider will share its data processing agreement (DPA) before you commit, and read which law it refers to. Many European providers write their DPAs with reference to the EU GDPR only. That is not automatically a problem, but your DPO should decide whether UK wording or an addendum is needed.
Do you need a DPIA for an edtech platform?
A DPIA is required where processing is likely to result in a high risk to individuals. The ICO's examples of processing likely to result in high risk include using children's data for profiling or automated decision-making, and offering online services directly to children. Many schools complete a DPIA, or at least a documented screening, for every new platform that handles pupil data. Ask the provider for what you need to complete it: data flows, sub-processors, security measures and any use of AI, including whether AI is used to profile or assess pupils.
Does the Children's code apply to edtech?
The ICO's Age appropriate design code, usually called the Children's code, sets 15 standards for online services likely to be accessed by children. It does not apply to schools themselves. The ICO's guidance on the Children's code and edtech explains that a provider may be in scope, for example where its service is offered directly to children or it processes pupils' data for its own purposes beyond the school's instructions. A provider acting purely as the school's processor is generally outside it. So the questions to ask are whether the service has a consumer or home version, and whether pupil data is used for anything the school has not instructed. The 2025 Act also added a duty for online services likely to be accessed by children to take children's "higher protection matters" into account when designing their data protection measures, which points in the same direction.
How much pupil data does a typing platform really need?
Under the data minimisation principle, personal data must be adequate, relevant and limited to what is necessary. A typing platform needs very little: a name or alias, a class and progress data. Ask which fields are mandatory, which are optional and whether you can use initials or aliases. While you are asking, check for advertising, tracking cookies, social or chat features, and whether pupil data or the text pupils type is used to train AI models.
Where is the data stored, and are there international transfers?
Ask exactly where data is hosted and processed, including backups and support access. Sending personal data outside the UK is a restricted transfer that needs a lawful basis: UK adequacy regulations, which currently cover the EEA countries among others; appropriate safeguards such as the International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses; or a limited exception. The 2025 Act revised the framework for approving transfers, so check the ICO's current transfer guidance rather than older summaries. If a provider hosts in the EEA but uses a sub-processor elsewhere, ask how that onward transfer is covered.
Which sub-processors does the provider use?
Ask for the full list of sub-processors, what each one does and where, how you will be told about changes and whether you can object. Typical entries include cloud hosting, email delivery, payments, sign-in providers and any AI service. A provider that cannot produce this list quickly is telling you something about its data protection maturity.
How long is pupil data kept, and how is it deleted?
The storage limitation principle means data should not be kept longer than needed. Ask how long pupil data is kept, what happens when a pupil leaves or a class is archived, how and when data is returned or deleted at the end of the contract, and how long backups and logs persist. Then align the answers with your own retention schedule, so that the platform does not quietly keep data your policy says should be gone.
What security questions should you ask?
Ask about encryption in transit and at rest, role-based access (can a teacher see only their own classes?), how passwords are stored, staff access controls, breach notification timescales and any independent testing. The DfE's cyber security standards for schools and colleges describe what the school's side should have in place, and a provider's answers should fit around them.
How should pupil accounts and sign-in work?
Many primary pupils have no email address, and some schools prefer not to share one. Ask how pupils log in, whether staff can reset passwords themselves, and whether single sign-on or class import with Google Workspace or Microsoft 365 is optional rather than compulsory. Fewer identifiers shared means less data to protect.
Which DfE guidance should you use alongside this checklist?
The DfE's data protection in schools guidance covers the school's own responsibilities, and its section on procuring educational technology sets out what to consider before, during and after buying an edtech tool, including data protection by design and by default. Involve your DPO at the start, not after staff have already signed pupils up. Whatever you decide, keep the evidence together:
| Area | Evidence to keep on file |
|---|---|
| Roles and contract | Signed DPA stating controller and processor roles |
| Risk | DPIA or documented screening, signed off by the DPO |
| Data | List of fields collected and why |
| Location and transfers | Hosting locations and transfer mechanism for each sub-processor |
| Retention | Agreed retention periods and end-of-contract process |
| Security | Provider's security summary and breach contact |
Where Kluppy fits
If you are assessing Kluppy, these are the points it states in its own help centre; verify them against its DPA rather than relying on this summary. When a school registers its pupils, the help centre says the school is the controller and Kluppy acts as processor under a data processing agreement. Kluppy says it signs a DPA with every school, written with reference to Article 28 of the EU GDPR and covering purposes, security, sub-processors, retention and deletion, so a UK school should ask its DPO whether that document meets its UK GDPR needs.
On hosting, the help centre states that data is hosted on Google Cloud in the European multi-region (Belgium and the Netherlands), and it lists its sub-processors and their locations. Kluppy says it collects a name or alias, progress and typing statistics; that children's data is never used for advertising and is not sold; that personal data is not used to train AI models; and that there is no chat between pupils. Teachers can reset pupils' passwords from their panel, and classes can be imported from Google Classroom/Workspace or Microsoft 365 Education.
Beyond data protection, Kluppy runs in the browser, including on Chromebooks, with nothing to install and no ads. School licences include a teacher panel and per-pupil reports on speed, accuracy and practice time; prices are on the UK pricing page. Whatever provider you choose, Kluppy included, ask for the DPA and complete your own checks. Our touch typing rollout guide for UK schools and trusts covers the wider plan.
Frequently asked questions
Do we need a DPIA for a typing platform?
It depends on the processing. Where a typing platform involves children's data and new technology, many DPOs complete at least a documented screening. Profiling, automated decision-making and services offered directly to children are among the indicators of high risk listed by the ICO.
Does the Children's code apply to our school?
No. The ICO says the Children's code does not apply to schools. It may apply to an edtech provider, depending on how the service is offered and whether the provider acts only on the school's instructions.
Is hosting in the EU a problem for a UK school?
Not in itself. UK adequacy regulations currently cover the EEA, so personal data can flow to providers hosted there. Check where any sub-processors outside the EEA sit and how those onward transfers are covered.
Can pupils use an edtech platform without an email address?
Often, yes, but it varies between providers. Ask how pupils sign in, whether teachers can manage passwords and whether email or single sign-on is optional, because sharing fewer identifiers reduces the personal data you hand over.