Whether your school is already back in full swing, or still preparing for the upcoming academic year, schools aren’t just welcoming students back to classrooms, they are also opening the door to heightened risks. Each year, the start of term brings a surge in activity: new enrollments, updated systems, fresh logins and increased digital traffic. This is not to mention all of the work that has been done over the summer to prepare for the year ahead. Unfortunately, this busy season also creates prime opportunities for data breaches and security incidents, and at 9ine we are already seeing these emerge both in schools and with EdTech vendors over the last few weeks.
In this article, we’ll provide an overview of some recent data breaches we have supported our clients through and the practical steps schools need to take to respond to a breach (including how 9ine can help).
A data breach is any incident where personal data is lost, destroyed, altered, disclosed or accessed without permission. Breaches can be on purpose, including through cyber attacks, which are malicious attempts to disrupt, damage, or gain unauthorised access to a school’s computer system, networks or devices. Because schools are busy, well-connected, often under pressure and hold a lot of sensitive children’s data, they are the perfect target for cyber attackers who exploit weak spots to gain entry to systems and valuable data. Some of the most common types of cyber attacks include: Phishing, Ransomware, Malware, Credential Theft, Distributed Denial-of-Service (DDoS) Attacks or Unauthorised Access.
But breaches can be accidental too, due to human error. For example, a staff member could send an email containing personal data to the wrong recipient or online tools could be used without proper checks or settings, which could lead to a breach. In fact, Mimecast found that human error contributed to 95% of data breaches in 2024.
It’s also important to understand that EdTech Vendors can have breaches which impact the schools that are using their systems. This can include breaches at their third party suppliers (known as supply chain data breaches).
Whilst not every incident will result in harm, some breaches can have serious consequences for students, families, staff, and the school itself. Breaches can also lead to fines, operational costs and disruption, regulatory action and reputational damage.
Let’s take a closer look at some of the breaches we have been supporting clients through at 9ine over August 2025 to see what happened, and what schools and EdTech vendors needed to do because of them.
A supply chain breach is a type of cyber attack where an attacker exploits a vulnerability in a vendor or supplier to gain access to a company’s data, network or systems. In the case of this particular breach, a school was using an EdTech vendor’s product and it was actually one of the vendor’s subprocessors who originally suffered the breach.
The vendor’s subprocessor suffered a cyber attack, where their systems were accessed by an unauthorised user who was able to extract personal data. This data included information which belonged to various schools using the EdTech Vendor’s products, including names, dates of birth, contact details, and identification details and numbers. This type of data in the wrong hands could lead to risks of fraud and identity theft.
For the Vendor: This meant that they had to ensure that their subprocessor had investigated the breach thoroughly, and carried out actions to prevent the breach occurring again. They also had to do an immediate security review of their own systems to check that the breach had not allowed access along the supply chain, and implemented security measures to prevent this type of breach occurring again. They also had to notify all impacted schools, advise them of the specific data belonging to them that had been breached, as well as what the mitigations that they (and their subprocessor) had put in place, and what the school should do next. The vendor also had to report this breach to the relevant Regulator(s).
For Schools: They were notified by the vendor of the breach, had to work with the vendor to understand all of the details of what had happened and the steps that the vendor would be putting in place to make sure that this didn’t happen again. The school also had to report the breach to the relevant Regulator(s). They also had to understand who had been affected at the school and what data had been compromised, so that they could notify them of the breach, the potential risks to them because of it, and the next steps that they should take to protect themselves.
During internal testing, a school identified a security flaw in a system they were using, which was managed by an external vendor. The flaw allowed individuals to login to an account without a password, if they could enter a valid user ID. This vulnerability was introduced as part of a migration at the school, due to an error in the application’s authentication logic. This meant that anyone with access to a student, or staff member’s user ID, could log into their account and see their personal data such as name, contact details, ID number, photograph and transaction history. Whilst there was no evidence of misuse, there were also no system logs kept, so the school was unable to verify access to the system at the time of exposure.
For the School: The school had to investigate the incident and notify the vendor, so that they could do the necessary work to remedy the situation and patch the vulnerability. They also had to notify the Regulator, as despite the lack of evidence of misuse, the notification requirements for breaches in the country in which they are based is low. They also had to notify affected data subjects, but because they had not kept system logs, it was impossible to understand which accounts had been logged into during the relevant time period. This meant that they had to notify all individuals with an account.
For the Vendor: They were notified by the school of the vulnerability and had to take the steps which would allow the school to fix it, including to introduce the ability to log access and enhance the authentication controls, including to require that a password be used.
A school became aware from alerts by parents and guardians that a third party vendor system they used was allowing families at the same school to see comments from other families in relation to absence requests in a particular feature of the system. As these were free-text fields and could have related to holidays, medical appointments, sickness etc. the personal data that was accessible to other families included student details and potentially sensitive details such as health information. The vendor confirmed that no attachments were accessible, but if a parent or guardian had chosen to include health (or other personal information) in the comments, then this would have been accessible to other families in the same school.
For the School: They had to make the vendor aware of the issue, so that they could issue a new release. They then needed to make sure that their system was running the latest release to stop the incident and exposure of the personal data. They also had to investigate exactly what personal data had been available, for how long, and who had accessed it. In this case it would have been all of the comments that the school had stored in the system for the time they had the feature, up until the latest release was up and running. This analysis included looking at the system logs to see who had accessed the system at the time of the vulnerability and then reviewing all of the possible comments they had accessed/could have access to, to understand the extent of the personal data that had been exposed. Upon completing this assessment, the school had to decide whether the amount and type of data meant that this incident would be classed as a reportable breach to Regulators and whether they needed to notify affected data subjects. They also had to liaise with the parents and guardians that had reported the breach to them.
For the Vendor: When contacted by the school, the vendor had to take steps to fix the vulnerability. As this was a vulnerability in their cloud platform, it would have affected all schools using the feature. This meant that they needed to identify which schools were using that feature and contact them to advise them of the vulnerability and what next steps they needed to take (similar to the process that the original reporting school followed), including to make sure that they were running the latest version of the software.
Whilst each of these breaches had different root causes and different steps to take to resolve them, there are many things that they have in common.
We know that spending time at the start of the new academic year managing a breach is not what schools want to be doing. At 9ine, we can help your school in a number of ways, supporting you to prevent breaches, but also helping you to respond when they happen, allowing you to focus on what schools do best - education. Some of the ways in which we can help you include:
9ine equips schools to stay safe, secure and compliant. We give schools access to all the expertise they need to meet their technology, cyber, data privacy, governance, risk & compliance needs - in one simple to use platform. For additional information, please visit www.9ine.com or follow us on LinkedIn @9ine.