When I get asked what the single largest issue is with helping schools on their data protection and privacy journeys, I try to stop laughing and explain that you cannot focus on one thing and treat it with a silver bullet. It is never just one thing. Neither is it a bunch of things on their own, as it is usually a group of things that result in the problem being far greater than the sum of its parts.

There is a myriad of ways that schools can deal with this, and supported by good DPOs, and it takes a bit of time and willingness on all parties. There, I said it … ALL parties. Yes, that means EdTech suppliers too.

I hate to think of the countless hours I spent as a DPO trying to decipher T&Cs, Privacy Notices, End-user agreements (how on earth is a 6-year-old going to agree to something when *they* are the end-user?), Data Processing Agreements, Data Sharing Agreements (and there is a very big difference between those last two!) and so much more. Those companies that I loved and cherished were the ones who truly understood that clear language and helping the school answer difficult questions is a really good idea. Those who throw legalese and 35 pages agreements (and that is before the Schedules and Appendices) at schools are either hiding something, inept or simply overwhelmed by using documentation and legal agreements to cover their posterior!

I tend to keep it simple when talking to EdTech companies, as that is how schools want it.

• Schools want to know that you understand that they, the school, are the ones who should be in control. You might write the Data Processing Agreement, but it is, ultimately, their instructions to you, so make them clear and reasonable.
• You *will* be writing for a varied audience, so you may need to cover an overview through to in-depth technical areas. Make these agreements layered so that you can do this.
• You have done a fantastic job of designing and developing some wonderful systems and resources. You are expected to have thought about data protection by design *and* by default, as well as the same for security. If it is a bolt-on, then you may need to think again.
• Your solution may be one of the best things in the world. Still, it would be best if you were clear about why you made it a certain way, how you expect it to be used with the personal data that is usually provided and then you *have* to accept that schools are inventive and may use it completely differently. At least give them the information to start with though. It truly will save a lot of their time.
• Don’t be scared to go and ask schools about things. You may have a presumption about how your solution is used, but you need to take into account the end-users. Do 7-year-olds understand what your solution does? How are you going to help the school explain it to them? You do know that schools have to be able to explain things to everyone and that the levels of understanding vary? How have you benchmarked your expectations of the different age ranges? Are there other resources available to help with this?
• Know the difference between a Third Party and a Sub-processor. Be honest when explaining these to schools.
• Know the difference between a Data Controller and a Data Processor. Be honest with yourself when you are trying to be a Data Controller with data that is entrusted to you by schools.

Some companies may feel that they are too small to handle the above, whilst some may feel too large and that they don’t really need to bother. As schools get better and better advice on what to look for, the EdTech company that helps them across all areas in their school life is going to be the one that they trust and adopt. Don’t get left out. Think!