What’s all the fuss?

A primary source of confusion and conflict between schools, EdTech suppliers, and other agencies often lies in defining their exact relationships with each other, and the subsequent relationships with the students, staff, and families involved. It should be straightforward – schools as data controllers, and suppliers as data processors. However, issues persist due to the varying circumstances, as pointed out by the ICO Helpline.

Before we proceed, it’s important to agree on specific terms and definitions, consider different perspectives, and then formulate what we believe should be the standard procedure. This article isn’t intended to be a basic GDPR course, or a step-by-step guide, but rather aims to provoke thought and provide pertinent questions for self-assessment, regardless of your role in the process.
Let’s take a quick look at what the GDPR says are the definitions of key terms.

These are taken directly from Article 4. These include terms such as:

1. ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

5. ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;

12. ‘personal data breach’ means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed;

There are more, and it is worth going through them all so you have a good baseline to work with.

While some parts of this information are straightforward, others may seem convoluted. We can refer to the UK’s Data Protection Act 2018 for guidance. Part 2 in particular provides ‘essential definitions’. However, this mainly refers back to the GDPR, which can take some time to unpick and understand!

So, What Does This Mean for EdTech?

We need to consider various scenarios that can range from straightforward and idealistic to complicated and frustrating. An important concept to keep in mind is that the Data Controller is the organisation who determines why personal data is being processed – this is referred to as the ‘Purpose’.

1. The Perfect Scenario

The school, or Data Controller (Controller), hires a service from an organisation, like an EdTech supplier, or Data Processor (Processor). This agreement forms the ‘instructions’ for the supplier to handle the personal data of the school’s community, including students, staff, and parents, known as Data Subjects.

This agreement is often referred to as a Data Processing Agreement (DPA), among other names. It likely contains other details about contracts and payments, but the key component for us is the DPA. It may be that there is a separate contract, terms of service or managed service agreement, and that the DPA is incorporated with these as an annex, or it may be referenced as a separate document but it is important to remember that it is still part of the contract and instruction between the Data Controller and the Data Processor (the school and the EdTech supplier, respectively). 

The Data Processor (the EdTech supplier) may have its own Data Processors, known as Sub-Processors, who must handle data as in accordance with the instructions of the Data Controller. The Data Processor and Sub-Processor will also have a DPA which will not be less onerous than the one between the Data Controller and Data Processor while ensuring that the Sub-Processor is at all time acting in a way compatible with the Data Controller’s instructions (even though the Controller doesn’t have a direct relationship with them). The Sub-Processor can be viewed as a sub-contractor, something that schools might be used to.

They are sometimes called Third Parties, a common term in contract law. However, in Data Protection, Third Parties have a separate and distinct meaning, so it’s crucial to clarify this term, which we’ll discuss further later.

2. The School as a Customer/business

Just as schools have a direct relationship with their Data Subjects (staff, children and families), suppliers have a direct relationship with their customers, in this case, the school entity, not the end users. Suppliers must maintain numerous records and need information to sell their services and fulfil contractual obligations. You may hear this described as business-to-business (B2B)

In some contracts, suppliers may refer to themselves as Data Controllers, which is accurate, particularly when they are referring to their processes around managing the account with the school, billing and taxation purposes. In their Privacy Notice, they’ll explain their data processing activities. The Privacy Notice might include what they process as a Data Controller and what they process on behalf of the Data Controller (i.e. when the school is the Data Controller and ‘instructs’ them). While this may seem complicated, it’s perfectly expected that a supplier will need to be a Data Controller for the purposes of managing the account with the school, but then a Data Processor for processing the data provided by the school for the ‘purpose’ discussed previously. 

Ideally, the nature of the relationship should be clear from the beginning.

3. A Mix of Roles?

As the title of this post implies, there is a complexity in roles between schools and suppliers. In our first scenario, the school is the Data Controller and the supplier is the Data Processor. However, it’s not always this clear. There could be instances where a supplier wants to use some personal data for their own objectives, such as product improvement, research, etc.

Some argue this shouldn’t be allowed, while others believe using anonymised data is acceptable. Others advocate for negotiation and transparency. I align with the latter view.

If a supplier needs certain information to maintain and enhance the agreed service they provide, this is generally reasonable. The supplier typically decides which personal data is needed and how it’s processed. This could lead to a situation where you’re Joint Controllers, or where they’re the Data Controller and you’ve merely ‘shared’ data with them. Transparency is crucial in this matter.

4. Confusion with Multiple Parties

There can be situations where many parties are involved in a process, making it unclear who’s responsible for what. Schools frequently exchange data with numerous organisations, creating relationships beyond just Data Controller and Data Processor, often involving Data Controller to Data Controller sharing. Data Sharing Agreements (DSAs) might be established. There may be times when this is required as part of a legally required audit trail, e.g. safeguarding. Nevertheless, due diligence remains essential.

A good example of this is Multi-Agency Safeguarding Hubs, where there are a number of organisations sharing data for a common purpose but all using data for their own reasons. However, it’s crucial to understand what data is being shared and the safeguards other parties have in place.

A potential issue arises when shared data falls under the control of another Data Controller who may then share it with organisations the school might not agree with. Transparency is crucial in these situations, both with you as a Data Controller and with the Data Subjects involved. Data subjects need to be informed about who now holds their data and how their rights are being maintained. Data flow mapping and diagrams that show how it all works can help provide clarity and transparency, ensuring each organisation understands their role and relationship with others and the data subjects.

When we think about sharing with other Data Controllers, it would be correct to refer to them as Third Parties. The confusion about the term can arise when a supplier is talking about a third party, meaning a Sub-Processor and someone reading the DPA takes it to mean an independent Data Controller. It may be that a supplier uses it to refer to both, possibly as they are thinking about terms used within contracts and not data protection. In this scenario it’s extremely difficult for a school to be transparent with their staff, children and families, as required by law. 

5. Security Through Obscurity

In some cases, the situation is not complex but simply chaotic. There might be no clear Data Processing Agreements (DPAs) or Data Sharing Agreements (DSAs). The school and the supplier may disagree on who the controller is, despite anything which is inferred from the nature of the relationship between them. The supplier might also be involved with funded research, or could potentially report directly to the Department for Education (DfE), who may view themselves as the Data Controller. 

Currently, there’s no standard way to handle such cases other than discussing and determining each organisation’s perspective, then negotiating until at least a scenario similar to scenario 4 is reached, if not a proper combination of scenarios 1 and 2.

In essence, EdTech suppliers should be prepared for questions from schools and should respond clearly. They should understand which scenarios apply to them and communicate this effectively. If the suppliers have integrated compliance into their operations, providing these answers becomes easier. Schools committed to their own compliance journey seek efficient methods to obtain and evaluate information from EdTech vendors.

Additional support can be provided by looking at frameworks and controls, such as the recently published Global Education Security Standard. It is important to reach out to your stakeholders and speak to school DPOs and technical staff as well. In short, check you are doing what your contracts and agreements say you do. Check those contracts and agreements and put the school at the centre of decisions. Check that those contracts and agreements, and anything else you share with customers, are readable and understandable as the schools need it to be able to keep their staff, their children and their children’s families up to date with what is going on with personal data. Do this and you will be surprised to see how many customers will be glad. After all, your reputation is everything.

Tony Sheppard has spent over 25 years working in schools, Local Authorities and with EdTech vendors on local, regional and national programmes, specialising in privacy, data protection, information governance and safeguarding, and supporting school changes through the delivery of EdTech.

Tony now supports EdTech vendors in understanding the roles and responsibilities they face with personal data, bringing together a breadth of experience and common sense approaches to supporting organisations in how they support schools with data protection and privacy. Tony is also the Information Governance Lead at NetSupport.