A UK code can make an edtech vendor a controller, not just a processor

The classroom note

A secondary school signs up for a free revision app a teacher found online. The company's marketing calls it just a study tool for pupils, and the school assumes that because the app is used in class, the school's own data-protection arrangements cover it. The UK's children's code says that assumption can be wrong. The Age Appropriate Design Code was issued on 12 August 2020 and came into force on 2 September 2020, with a twelve-month transition; the Information Commissioner's Office states it began taking the code fully into account from 2 September 2021, the date by which online services were expected to conform.

What the evidence says

Schools themselves are not an information society service under the code, but the regulator's edtech-specific guidance, current as retrieved 16 September 2026, is explicit that an app used through a school can still be covered where the provider shapes how children's data is processed beyond the school's own instructions: setting its own processing parameters, running research the school did not commission, or serving its own marketing or product-development purposes. In the guidance's own worked example, a provider that labels itself a processor but in fact processes data outside the school's instructions is, regardless of that label, acting as a controller, and the code applies in full. Whether a company is a controller, joint controller or processor turns on what it does with the data, not on the contract's label.

The implementation question

The practical task is naming who decides what happens to a pupil's data, and setting that decision down in writing. A school and a vendor must consider their respective roles and work out that allocation before rollout, not after a complaint. Where the vendor determines the purpose of any part of the processing, for research, marketing or building its own product, the code's standards on defaults, profiling and use of data beyond the service apply directly, and no procurement paperwork can substitute for the vendor's own compliance.

What holds and what fails

The assumption that use in school equals coverage by the school's own arrangements holds only where a vendor processes data solely on the school's instructions, for the school's stated educational purpose. It fails wherever the vendor's own commercial interest, in data for model training, analytics products or advertising, sits inside the same tool. Treating every classroom app as automatically shielded by the school's own data-protection position is, editorially, precisely the gap this guidance was written to close.

• Does the vendor determine any part of how children's data is used, beyond following the school's instructions?
• Is the contract's description of the vendor as a processor consistent with what the tool actually does with data?
• Have the school and vendor agreed, in writing, who is responsible for which data-protection obligation?

The code does not ask a school to become a data-protection regulator; it asks the school to stop assuming a label in a contract settles the question.