The UK’s independent authority set up to uphold information rights in the public interest, promoting openness by public bodies and data privacy for individuals.

Does the Children’s code apply to schools?

The Children’s code does not apply to schools.

To be defined as an Information Society Service (ISS), organisations must meet several qualifying conditions which are set out in services covered by the code. Schools do not meet the definition of an ISS.

However, the code’s vision – to ensure that the best interests of children are a primary concern when using their data – also closely aligns with schools’ own educational mission. Schools are also required to comply with UK GDPR and the Data Protection Act 2018, and the code sets out what good practice compliance looks like in the areas it covers. We therefore encourage schools to aspire to meet the code’s 15 standards as a matter of general good practice.

What are school’s responsibilities when procuring edtech solutions?

Whilst the code does not apply to schools, wider UK data protection law does.

Schools have a range of important responsibilities under the UK GDPR and the DPA 2018 when procuring edtech services. These include due diligence, safeguarding and oversight. The UK GDPR states that of data protection by design should be taken into consideration for public tenders, and encourages organisations including schools to make sure that controllers and processors are able to fulfil their data protection obligations’ when selecting services. 

Schools must think carefully about the responsibilities they and the edtech provider will hold under a specific contractual agreement. More specifically, the degree to which the edtech provider will be able to influence how children’s data is used. Schools need to consider who is acting as a sole data controller, or whether they are joint controllers and processors. Our Controllers and processors guidance gives more information to assist organisations to make this assessment.

If edtech providers fulfil controller responsibilities, schools must make sure that edtech providers are not defined as processors. Controller responsibilities include determining the means and purposes of data processing,

Where an edtech provider and a school are acting as joint controllers, the contract will define who is responsible for complying with different data protection requirements, although both are ultimately accountable for meeting them.

Even where an edtech provider is acting as a processor, they still have legal obligations to assist the school as the controller. Schools should remind edtech processors of these obligations, which include:

  • Maintaining a record of their children’s data processing activities, and ensuring they have not processed children’s data in any way beyond the school’s instruction
  • Proactively notifying a school without undue delay if there has been a personal data breach
  • Implementing appropriate security measures and safeguards to protect children’s data
  • Assisting the school with their obligation to undertake a Data Protection Impact Assessment

An edtech provider acting as the sole data controller with the school as a data processor is rare – the edtech provider would be accountable for complying with all data protection requirements, if this was the case.

When does the code apply to edtech services, and what are their responsibilities?

The code applies to edtech services that are likely to be accessed by children on a direct-to-consumer basis These are services which are freely and directly available to users on open platforms such as the web or via an app store.

This is because edtech providers meet all the criteria that define a relevant ISS in-scope of the code.

The code applies even where the organisation providing the direct-to-consumer edtech service operates on a non-profit basis.

This is because most similar services are normally provided on a for-profit basis in the direct-to-consumer edtech market, meaning non-profit edtech are still considered “normally provided for remuneration” - part of the definition of being a relevant ISS.

The code also applies to edtech services in another scenario. This is where an edtech service is provided to children through a school, and the edtech provider influences the nature and purpose of children’s data processing.

Examples of where this is likely to apply include:

  • schools procuring “off-the-shelf”, pre-defined, edtechproducts,
  • edtech providers processing children’s data for product development or research - where the research isn’t the core service procured by a school,
  • edtech providers processing children’s data marketing and advertising, or their own commercial purposes.

The school and edtech provider should consider their respective roles and responsibilities in order to determine whether the edtech provider is acting as a joint controller or independent controller – our guidance on Controllers and processors can support them to do so.

The Children’s code applies here as the edtech service meets all three criteria of the ISS definition.

The edtech provider cannot rely upon their service being considered an extension of the offline activities of a school. Case law indicates this excludes them from being defined as an ISS (more detail on this is given in the following "When doesn’t the code apply to edtech services, and what are their responsibilities?" question).

This is because the edtech provider’s influence, as a data controller, on the nature and purpose of children’s data processing means the service has digital elements that are distinct from the school’s offline activities. These service features would likely not be provided by the school without the influence or support of the edtech provider.

When doesn’t the code apply to edtech services, and what are their responsibilities?

The code does not apply to edtech providers where all the following criteria are met:

  • The edtech service is provided to children via an intermediary such as a school
  • The service only processes children’s data to fulfil the school’s public tasks and educational functions
  • The edtech provider acts solely on the instruction of the school, and does not process children’s data in any other form beyond these instructions

The school and edtech provider should consider their respective roles and responsibilities in order to determine whether the edtech provider is acting as a controller or processor (it is most likely they will be acting as a processor). Our guidance on Controllers and processors can support them to do so.

The code does not apply because where the edtech services are procured by schools to support the school to fulfil its educational functions, the edtech provider will be acting solely on the instruction of the school.

The edtech service is a digital extension of the school’s offline activities. Case law indicates they should not be considered an ISS (which defines an organisation in-scope of the code) in this scenario.

In these circumstances the service’s core use of children’s data must be limited to school’s educational purposes.

Edtech providers acting as processors still have a range of obligations and responsibilities under the UK GDPR and DPA 2018. Our current intelligence and engagement with the schools ecosystem suggests Edtech providers should take particular care to ensure they comply with the following data protection principles:

  • Necessity and proportionality. Edtech providers should be able to evidence that their use of children’s data is effective in delivering the stated educational benefit
  • Purpose limitation. Data gathered and processed by edtech providers to fulfil the educational functions of the school must not be used for any other purpose. This includes re-using children’s data for commercial gain, for example through advertising, research for commercial strategy, or new product development.
  • Lawful bases. The “public task” lawful basis must not be used for data processing that doesn’t relate to schools’ public tasks, as defined by law (for example within the Education Act 2002). Where edtech providers are processing for broader purposes, it is likely that legitimate interest legal basis is more appropriate.
  • Data minimisation. Only gather or process children’s data that is needed to perform the given educational function.
  • Data protection impact assessments. Any processing likely to result in a high risk requires a DPIA – we consider any online service likely-to-be -accessed by children high risk, so edtech services will need to work in partnership with schools to complete and regularly review a DPIA in respect of service being provided.