What counts as a personal data breach
The definition is in Article 4(12) of the UK General Data Protection Regulation. A personal data breach is "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". The school, or in an academy the trust, is the data controller, so the duties that follow sit with it rather than with the member of staff who made the mistake.
Three things about that definition matter in a school. It includes accidental breaches, so a well-meant email to the wrong address is a breach in exactly the way a stolen laptop is. It is not only about disclosure: data that is destroyed, altered or made unavailable has also been breached, which is why a ransomware attack that encrypts the management information system counts even if nothing leaves the building. And it covers personal data however it is held, on paper, in the MIS, in a staff member's inbox or in a message on a phone.
The Department for Education's guidance for schools puts the same test in plainer words: personal data that is lost or stolen, destroyed or changed without consent, or accessed by someone without permission. The ICO's guidance lists sending personal data to an incorrect recipient, access by an unauthorised third party, a lost or stolen device and loss of availability among its examples.
The law behind all of this is UK GDPR and the Data Protection Act 2018. The Data (Use and Access) Act 2025 has amended both, and the ICO confirmed on 19 June 2026 that all its data protection provisions are now in force, so check the date on any ICO page you rely on, and work from current guidance rather than a breach procedure written in 2018 and re-dated since.
What a school data breach looks like in practice
Schools hold a great deal of sensitive personal data about children, much of it special category data, and they share it constantly with parents, local authorities, health services and suppliers. The breaches that follow are overwhelmingly ordinary:
- The misdirected message. An email, letter or text about one pupil sent to another family, or to the whole class list; a reply-all that exposes every parent's email address; the wrong attachment on a report to the local authority.
- The over-shared file. A spreadsheet with a hidden tab of free school meals or SEN data; a document uploaded to a parent app or website where everyone can open it.
- The lost thing. A laptop, memory stick, trip folder, medical list or safeguarding note left on a bus, a printer or a staffroom table.
- The wrong access. A pupil who can see a shared drive they should not, a former member of staff whose account still works, a supply teacher given more of the MIS than the role needs.
- The cyber incident. Phishing that hands over a password, or a ransomware attack that encrypts or steals school data. Rarer, but the largest in scale.
- The conversation. A safeguarding detail shared in a parent group chat, a class list photographed and forwarded, a medical need discussed by message on a device the school does not control.
A near miss is not a breach. An email caught in the outbox, or a document recalled before anyone could open it, is worth recording because it shows where the next breach will come from, but it does not start a reporting clock. The distinction is whether personal data actually reached, or became available to, someone who should not have it, or was lost, altered or destroyed.
The common thread is people rather than technology, which is why the DfE expects every member of school staff to be able to recognise a breach and know how to report it internally, straight away, to the person the school's data protection policy names.
The 72-hour test: whether to tell the ICO
Article 33(1) of UK GDPR sets the duty: the controller "shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the Commissioner", unless the breach is unlikely to result in a risk to the rights and freedoms of the people affected. The ICO's guidance puts the test in one line: if a risk is likely, you must notify; if a risk is unlikely, you don't have to report it.
Four points decide most school cases.
- The clock starts at awareness, not at the incident, and not when the paperwork reaches the DPO. The ICO points to the Article 29 Working Party guidelines for when a controller becomes aware, and in a school that moment is often a teacher telling a colleague, not a form reaching the office. The clock counts hours, not school days, so a breach discovered on the last afternoon of term does not wait for the new term.
- Assess the risk to the people, not to the school. The DfE guidance asks who is affected, how many, and what could happen to them, naming safeguarding issues, identity theft and significant distress. The ICO asks you to assess both the severity of the potential impact on people and the likelihood of it occurring. A child's name sent to one other parent is a different case from the same child's new address sent to an estranged parent, even though the error is identical.
- The type of data changes the answer. Special category data such as health and SEN information, safeguarding records, free school meals status, bank details and anything that would locate a child all make a risk more likely. So does the recipient: a local authority officer who confirms deletion is not the same as a parent in a dispute with the family.
- You can report in phases. The ICO's guidance says Article 33(4) allows the required information to be given in phases, provided that is done without undue further delay. Where a report is made after 72 hours, it must say why. The worst outcome is waiting to be sure while the clock runs out.
A report to the ICO must describe the nature of the breach, including where possible the categories and approximate number of people and records concerned; give the name and contact details of the data protection officer; describe the likely consequences; and describe the measures taken or proposed to deal with it. Every school must appoint a DPO, and the DfE expects the DPO to support the school through the process and to act as the contact with the ICO. The ICO's report a breach pages include a self-assessment to help decide whether a report is needed.
The decision belongs to the school as controller, advised by the DPO. It should be taken by someone with authority, recorded with its reasons, and taken quickly, not left with the member of staff who made the error.
The breach log: every breach, however small
Article 33(5) requires the controller to "document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken", and says that documentation must enable the regulator to verify compliance. That duty applies to every breach, not only the breaches reported to the ICO. The DfE's guidance calls it good practice to record and investigate every personal data breach, however small, because recording every incident is what lets the DPO spot trends.
A breach log that will stand up to an ICO enquiry or a complaint records, for each incident:
- when it happened, when the school became aware, and who reported it to whom
- what personal data was involved, whose, how many people and whether any of it was special category or safeguarding data
- how it happened, in plain words, without naming the member of staff in the log itself
- what was done to contain it: recall, deletion confirmed by the recipient, passwords reset, access removed
- the risk assessment, and the decision whether to report to the ICO, with the reasons and who took it
- the ICO reference and date, if reported, and whether and how the people affected were told
- what changed afterwards: training, a setting on the email system, a process for sending reports
The column most often left blank is the reasoning behind a decision not to report. That is the one the ICO would ask about if a family complained later, and "DPO advised low risk" is not reasoning. Write down why the risk was judged unlikely.
The log is also an information governance document, and one an auditor or the ICO may well ask to see. The DPO should report breach numbers and themes to the governing body or trust board at least annually, and the pattern matters more than any single entry: twelve misdirected emails in a term is a training and systems finding, not twelve pieces of bad luck. Keep the log for as long as your retention schedule says, and in line with the school's wider data retention policy.

Telling families, and the misdirected message
Article 34(1) requires the school to tell the people affected "without undue delay" where the breach is likely to result in a high risk to their rights and freedoms. That is a higher threshold than the one for reporting to the ICO, so there will be breaches you report to the regulator without writing to every family, and a few where you tell the family even though the law would not strictly require it, because they need to act.
The ICO's guidance says the communication must describe, in clear and plain language, the nature of the breach, the name and contact details of the DPO or another contact point, the likely consequences, and the measures taken or proposed, including anything done to limit the harm. For the affected individuals in a school that usually means a phone call from someone senior, followed by a letter, and not a form email from the office. Where the pupil is old enough to understand, consider whether they should be told directly as well as their parents.
Article 34(3) sets three exceptions: the data was protected, for example by encryption, so that it is unintelligible to anyone not authorised; later action means the high risk is no longer likely to materialise; or telling each person individually would involve disproportionate effort, in which case a public communication is needed instead. Record which exception you relied on and why.
The misdirected message deserves its own procedure, because it is the breach a school is most likely to have this week. Four steps cover most of it:
- Contain. Try to recall it, then contact the recipient, ask them not to open, forward or keep it, and ask for written confirmation that it has been deleted. Record the confirmation, or its absence.
- Check the safeguarding angle first. A contact address, a school placement or a health detail reaching the wrong person may be a safeguarding matter before it is a data protection one. Involve the designated safeguarding lead immediately.
- Assess and decide. Apply the 72-hour test, write the decision in the breach log with its reasons, and decide separately whether the family must be told under Article 34.
- Fix the cause. Email address autocomplete, reply-all to large lists, attachments pulled from a shared folder and personal data in group messages to parents cause most misdirected messages. A delay on outgoing email, a rule that pupil reports go by a secure route, and data protection training on these specific patterns prevent more breaches than a general reminder to take care.
Blame is the enemy of the log. A member of staff who fears discipline for a misdirected email will try to fix it quietly, and a quiet fix is how a 72-hour reporting duty is missed. The data protection policy should say plainly that reporting a breach promptly is what is expected, and that the school's response will focus on the data, not the person.
Where the first 72 hours actually happen
Every part of the procedure above assumes the school can see the breach. In practice the most important evidence often sits where it cannot.
The first report of a breach is rarely a form. It is a text to the business manager on a Friday evening: "I think I sent Year 4's reports to the wrong mum." It is a parent messaging a teacher's personal number to say they have received another child's letter. It is a staff group chat in which someone asks whether the photographed class list should have gone out. Each of those fixes the moment the school became aware, which is the moment the 72 hours began, and each sits on a personal phone the school does not control.
Some breaches happen inside those conversations. A teacher answering a parent from a personal phone sends a pupil's details to the wrong contact. A medical update meant for one colleague lands in a staff group chat that includes someone who has since left. The school is the controller of that personal data, but it cannot recall the message, cannot see who received it, and cannot confirm deletion, because the conversation never happened on anything the school owns. The breach log ends up recording what someone remembers rather than what was sent.
That is not a reason to stop staff raising the alarm by text; a quick message is exactly what the school wants. It is a reason to give those messages somewhere to land that the school holds. ComplyChat is a messaging service for that: school conversations in a channel the school controls, recorded on the server as they are sent, with everyone added told that the channel is on the record. On paid plans, parents, support staff and supply colleagues without a school account can be in a channel with a mobile number verified by SMS, and the lasting record files into the school's own Microsoft 365 once its tenant is connected, under the school's retention rules. It will not stop a message going to the wrong person, and it is not a breach management system; the DPO's log and judgement still do that work. ComplyChat Free is one private group and direct messages with three calendar months of recent history and no Microsoft 365 archive, so it is not a place to keep a breach record.
A question for the next leadership or governors' meeting: for the last three breaches in the log, could the school show from its own systems when it first became aware, or would the answer come from somebody's phone?
Official guidance and your next step
The DfE's managing breaches of data, part of its data protection in schools guidance, is written for school staff and includes worked examples. The ICO's guide to personal data breaches is the authority on the reporting test and the contents of a report, and the text of Article 33 and Article 34 is on legislation.gov.uk. Quotations here are from those pages as read on 25 September 2026. For a cyber incident, the National Cyber Security Centre publishes guidance and support for schools alongside the ICO route.
This guide is a practical summary for schools and academies in England, not legal advice about a particular breach. On a live incident, involve your DPO at once and take advice before deciding not to report something serious.
Then do one thing this term: take the breach log to the DPO and check that every entry has the time of awareness, a written reason for the reporting decision, and a record of whether the family was told. Any entry missing one of those is the one to fix first.
We build ComplyChat for the work conversations schools need to keep. A data breach is usually first reported, and sometimes caused, in a message on a phone the school does not control, and that is where the 72 hours begin. Explore Free personal messaging, or compare the paid plans if your school needs a lasting Microsoft 365 record.
Sources
Every document this guide quotes or links to, in the order it first cites them.
- ICO's report a breach pages ico.org.uk
- Managing breaches of data gov.uk
- Data protection in schools gov.uk
- Guide to personal data breaches ico.org.uk
- Article 33 legislation.gov.uk
- Article 34 legislation.gov.uk


